Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
UPDATE on remote view is very slow
Message
From
23/02/1999 00:08:41
 
 
To
22/02/1999 21:11:30
Calvin Smith
Wayne Reaves Computer Systems
Macon, Georgia, United States
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00190273
Message ID:
00190320
Views:
38
>I assume you are using ODBC? If so that is probably the root of the problem. I just assisted someone with a Delphi executable writing to a visual fox table through ODBC. Importing 15000 records was taking 6 to 8 hours. We were able to reduce the time to 12 minutes by putting the data in a Dbase table and creating a VFP executable that opened the table and pushed the data in.

The export from/import to Access is somehow out of question because I want to automize the whole process and I need VFP for its data processing speed (the dbf table is a result of other processing I'm doing in VFP).

Another reason is that the remote table is Access today, but it will be Oracle in a realtively near future and, maybe, SQL-Server in a far future. So, I don't want to do anything specific to Access.

>I am sure a native Access exe could do the same thing here - woops does anyone actually write access exe programs any more? You could try Scanning the table and scattering to an array and then appending to the table from the array.

True. But this would be almost the same as the SCAN FOR + REPLACE solution which I already tried and which behaves in a similar way as UPDATE.

>Another approach might be to close and then reopen the tables at every 1000 records to cause the MDB to flush its buffers. Access really has problems accepting large amounts of data when transaction processing is not on.

This doesn't work because it takes about 2 minutes to fetch all the records from the remote table and I can't afford to do it at each 1000 records. But... I will try to do it at each 6-7000 if I don't find anything better. :( Thanks!

Vlad
Previous
Reply
Map
View

Click here to load this message in the networking platform