Well, I wrote a program that will do this. It still needs some tweaking, like checking for file existance and such. However, I don't think you'll see any speed improvements by doing this and performing a DBF APPEND over doing an SDF APPEND to begin with, since there will be some time involved in getting the DBF created from the SDF file. However, it was a good learning experience. Most of the info I got came from what everyone has posted in this thread, plus looking in the help under "Table File Structure". I think there may be a typo there. For the last bit of reserved bytes in the field header portion, it says it goes from bytes 19-32, but since they start at 0 and the field header is supposed to be 32 bytes, it should probably read as going from bytes 19-31.

The program can be found at: http://www.crosslink.net/~jcochran/jonathan/SDF_To_DBF.htm. I would appreciate any feedback anyone has to offer.


>>>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.
>>
>>Very interesting idea, Houston. Would be great, if somebody would implement it (no, not me :)) Dragan, are you lurking? :)
>
>No, you won't get me this time :)
>Last time I did this was in 1990, when we still didn't have the low level file functions, so I had to play around with GW Basic to get the thing done. It actually took creating an empty .dbf with the exact structure, then appending the records (I actually had a hosed chunk of a real .dbf file, whose header got hosed by a virus or disk failure), then storing the number of records into the header. It was lots of guesswork, because I didn't have the exact format of the header back then. Frankly, it's still feasible, it's just the CRLFs that need to be handled first - see my other message.
>
>OK, I wrote the specs, who's coding :)