It's probable that you're REPLACE command is what is taking all of the time. My suggestion had to do with the fact that when you do a large APPEND FROM all of the tags in the structural compound index file are updated with each record appended. Many times a combined APPEND FROM with no index tag updates followed by a full REINDEX will take less time. To do this rename the .cdx file to something else like tablname.was, when you next use the table you will have to allow VFP to rewrite the .dbf header since there is no .cdx associated with the file. Do the APPEND FROM then rename tablname.was back to tablname.cdx then USE tablname index tablname (this reassociates the .cdx to the .dbf) then REINDEX. It sounds like a pain but may save you some processing time.
Good Luck.

>Hi Dore,
>
>I'm not sure, that I understand your advice, could you please elaborate a little more? This table (I mean the target shell) has lots of compound indexes.
>
>TIA
>
>>>Hi everybody,
>>>
>>>We're having this problem: our SQL produces ~1000000 records. SQL works fast. Then we need to place this records into Database with predefined structure, indexes, etc. So, firstly it prepares a shell Database and a table and then uses Append from command (runs DeNull program in between). This operation takes already ~15 min. and it's not finished yet. What can you suggest to optimize it?
>>>
>>>Thanks in advance.
>>
>>Depending upon the number of and complexity of the index tags in the structural compound index file it might make sense to decouple the .dbf and .cdx files, do the APPEND FROM, relink the .dbf and .cdx and REINDEX.