>>We use these for queries, and play lots of (pull my hair out), what if games with them.
The primary difference between a Dbf and an SDF Text file, is the header, the byte (per record) used to indicate deletion status, and the SDF might have CRLF to indicate new records.
>
>In the past I think I've pulled fixed length records into a Dbf that do not have CRLF - so:
>
>I'm not really sure what the ascii code of the deleted byte is, but if you have any control over the structure of the text file, could you have an extra byte added that would appear in the deleted byte spot and ditch the CRLF's?
>
>Then all you would have to add is the header, using low level file I/O. Fabricating the header of course requires that you know how many records will end up in the resulting table. And then, change the extension to Dbf.
>
>I've never done anything like the above - so it could all be complete tosh. Just an idea.
The delete mark is either a space (not deleted) or an asterisk (deleted). Therefore it would be something like adding a final CR plus one space to the header, then appending the file in big byte chunks, adding an additional c(1) field to the structure to hold the CR and replacing all LFs with spaces... which would be a good thing to combine with counting the records as we go, which we may need for the header. Ummmm... sounds like a good days' work, but the speed gain may be enormous. OTOH, I wonder what would happen if we just gave FOX the file without the LFs replaced with spaces, so it would have a LF instead in the delete mark. It may work even without that.
Anyway, it's not that hard to fake a header. YMMV, of course.
