Michael, there's something that's been on my cleanup list for awhile.

If you create a record past end-of-table in a fixed-length file, you implicitly create a bunch of records, all with the value of 0 because there's no out-of-band "deleted" value. However, whether or not a cursor will return those records or a search will find those records, depends on whether there's been a sync, that is, after the page is reconciled, the next scan/search will see the records, but while they're sitting on the append list, they'll not be seen by scans and will return not-found on a search.

I figure that we can either document that fixed-length gets can return either not-found or 0x00 for implicitly created records, or, we can change things so the search functions and cursor functions figure out if there's a missing record and return empty data for it.

I also wondered if this is a problem for existing table code that's splitting up columns among multiple files?

I took a look at the code changes we'd need to make this all consistent, and they aren't too bad, with one exception: the changes to make __cursor_skip_prev() work for this case are daunting. (My plan was to check to see if the next entry on the skip list is recno - 1, or if there are missing records, maybe there's something better?)

If we want to do the code changes, maybe we could do page searches for the specific record number instead of a previous-scan for bit-fields? Or am I misunderstanding how __cursor_skip_prev() works, and it's not so bad?

--keith