>Hi all,
>
> We have an oBizObj1 that fills a SQLResult cursor via SPT. We need to move that data to a table in a VFP DBC. So we created a obizobj2 with the VFP table in the environment. We SCAN through the cursor of oBizObj1, SCATTER NAME loRec, then call a oBizObj2.AddRecord(loRec). The oBizObj2.AddRecord() calls THIS.NEW(), then GATHER loRec.
>
>This works, but we are dealing with 1.5 million recs, so it's slow. We've tried subclassing oBizobj1 and it's DE. Then added the VFP table to the subclassed DE, but we haven't got that to work yet.
>
>Anyone have a design suggestion that is speedy?

First of all I'ld check if the data table can be opened EXCLUSIVE and (if so) whether it is. Eliminates header locking and gives a substantial boost.

Second I'ld try measuring how much of time is spent in the framework .new code and in the actual copying.

If the record layout of cursor and table are compatible, scatter/gather on arrays is faster than scatter name, but I guess this effect will be only marginal percentage wise.

Conceptually I'ld move from record operations to block operations: Something like copy blocks of max(1000, RestOfRecords) Records into array from cursor and append from array into target table. If on the framework level any PK's that have to be sequentially inserted/marked as spent, do this blockwise as well - if you know you need alen(laX, 1) integer keys and you have a key table, increment in 1 record access. For this you probably have to work on the framework level as well <g>. Something like a home spun batch processing... If you need transactional handling, bracket the whole batch operation in one transaction, since failure should not happen often.

Perhaps you can fiddle with the framework to add any relevant info into the cursor first and then append from the cursor into the data table - should be the fastest option, but I have no idea on how much of a re-write of fwk features is needed.

HTH

thomas