>>It seems that delay is entirely ODBC-origin. I see two things to try.
>>1) Send INSERT Into newtable ... SELECT ... From oldtable command through SQLEXEC(). Maybe it will work.
>>If not then
>>2) Maybe you could rethink the whole idea. Why do you need to move data to new table? Maybe you can just create new field(s) in existing table and use them.
>>
>Edward, the systems are two separate manufacturing packages. Both from the same company... but one is newer than the other. The user is upgrading the old to the new. The supplier of the package does not provide a migration tool.
>
>The issue is the difference between the two is quite substantial. There are more fields in the new system, field names have changed, etc. That is why I'm doing the transfer via ODBC. They do provide the ODBC drivers for both systems.
>
>Basically I'm writing the data migration tool. And I seem to be having success in transferring the data, but it is way too slow! I will not be able to transfer data over a weekend.
>
>The reason I got the contract, and I'm now taking a bath on it, is the supplier offered to do it, but it would take 4-5 days minimum! And the users would need to be shut down for that time. I am trying to write something that would do the same thing over a weekend.
>
>Any ideas on how to extridite myself, cleanly and without getting burned even more? If it is ODBC related, I can't see how I'm going to be able to do it in the timeframe required.

It seems their ODBC driver is flaky :).

Can you spread the task over a few machines? That way you'd still be able to win it by brute force.