Jonathan,

This piece of code really slowed down the perfomance:

DO WHILE !FEOF(ln_SDF_File)

   **
   ** Increment the number of records.
   **
   ln_NumRecs = ln_NumRecs + 1

   **
   ** Read the current line from the SDF file.
   ** Add one character to the beginning to account for the deletion mark.
   **
   lc_Line = SPACE(1) + FGETS( ln_SDF_File, 2000 )

   **
   ** Write the current record to the DBF file.
   **
   = FWRITE( ln_DBF_File, lc_Line )

ENDDO

We discussed this recently in another thread, that low-level functions would be slower, than APPEND FROM.
The original idea was just copy the file under different name and do the rest of the work. Unfortunately, copying process may take even longer, than your approach for huge files... Let's assume for the start: that we operate with relatively small files (less than 16MB), and the file is alredy copied under different name (still dat/txt extension, we'll change it at the end).


>The "SDF Append" is an APPEND FROM ... SDF from the SDF file to the destination table directly. The "SDF->DBF, DBF Append" is using my program to convert the SDF to a DBF, then appending that table to the destination table. Yes, it does appear to be slower to go the conversion route, unless someone can find something that will speed that up.
>
>>>OK, here are some numbers. I had 64,152 records in an SDF-formatted file (~11 MB), at 362 bytes per record. Before each timing test, I started with an empty destination table. All of the times are in seconds.
>>>
>>>

>>>                      Run1   Run2   Run3   Run4     Average
>>>SDF Append            12.15  11.13  10.98  10.94    11.30
>>>SDF->DBF, DBF Append  13.10  13.52  12.44  12.88    12.99
>>>

>>>
>>
>>Which one is which? Your program is a little slower, right?
>>
>>
>>>>>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.
>>>>
>>>>The only theoretical speedup could be achieved if we could use the LFs for delete marks, and invent an extra field to keep the CRs. In that case, you wouldn't have to go record by record; the number of records could be taken as just the file size divided by record_length+2 and the whole file could be appended at once. Though, I doubt that you would gain any significant speed increase - LLFF are as fast as it gets.
>>>>
>>>>Nice work, very well documented, and probably very fast. BTW, what's the speed gain compared with Append SDF?