>>>I don't think re-creating it possible. However, right now I'm copying last night backup data to my local drive. Once it's done, I'll apply recent database changes, Reindex, Repair (all through SDT), then resume my tests.
>>>
>>>cEntered_User is the field with GetUserID() as default value. I added it explicitly to all my insert commands, so it would not be calculated. Thanks again for this great idea which I'm sure would speed up this process a lot. ValidateSSN and age calculation parts were also updated since yesterday, but here I don't expect to gain very much.
>>>
>>>I haven't switched back to scatter approach suggested by John Koziol since I already took time re-writing that code and converting to insert fields...
>>
>>I didn't say add explicitly. Still would be calculated, no? I meant if it's something returning an integer in sequence, then get starting value only, allocating a block of ids ahead for your insertions and directly use integers in that block. ie:
>>

>>lnStartID = GetUserIDAsBlock( m.lnPreEstimatedInsertions )
>>lnInserted = 0
>>*...
>>userID = lnStartID + m.lnInserted
>>* insert ...
>>lnInserted = m.lnInserted + 1
>>

>>
>>I didn't mean reindex but recreate from scratch. With reindex it's likely you'd continue to get error. I don't know how SDT handles.
>>
>>I still think insert style wouldn't have much impact for 4K+ or 4K+ * 16 records. One hour is simply too long for VFP. I would even think to insert them all into a new cursor with same structure, then when done do a single append from (or insert..select). Removing indexes during insert/append and recreating them after would also help.
>>Cetin
>
>SDT has clever mechanism of re-creating indexes. I didn't look into the code, but asked my colleague and he told me it re-creates indexes from scratch and has some clever code to preserve RI.
>
>That's an idea (using temp cursors), but will lead to a complex code re-write. As I said, we need to insert data into at least 16 different tables during the process.
>
>cEntered_User is the name of the user who entered the data (NNOSO001 for me). So, by using
>insert into myTable (field1, field2, cEntered_User) values (Val1, Val2, this.cUserID) I save time of calculating this value.
>
>We're using GUID for PK, so they had to be calculated on each insert using SP. That's time spent, of course, but there is nothing I can do about it.

You're using GUID for PK? Excellent.
"on each insert using SP. That's time spent, of course, but there is nothing I can do about it."
Wrong! Of course you can and save considerable time. With an SP it's likely code has API declaration in it. If you move API declaration outside SP and use your own code instead you might save minutes. API declaration is time consuming.

"(using temp cursors), but will lead to a complex code re-write" I'm not sure the code would be more complex. To me it looks like it'd be less complex.
PS: No RI code is the most clever RI code.
Cetin