>>I forgot to say... this is where the problem started.
>>
>>The original application was VB/Access. They moved to VFP (as the backend)
>>because the load of data on Access was to heavy and the response time was
>>getting too slow... but it was faster then the response time they are having
>>now.
>>
>>So, moving it back to Access might be a solution... although it would still be
>>slow to the management. (Got to admit I forgot to include that solution in the
>>scenario)
>
>Is Fetch Data in Background turned off on the ODBC driver?
>
>Are your tables indexed to take advantage of Rushmore?
Details on Rushmore that I forgot to mention :)
The updates are done with replace/update and not with a SQL Statement. They are using the ADO's recordset object to update the database (ex.: oRS.update).
The tables have indexes but I will need to look into it (they admit to not fully grasp the Rushmore Technology). But with replace/update it should not impact right?
Also, there was a thread (few months back) discussing replace/update VS SQL Update and the conclusion, that I remember anyways, is that both will work and it is mostly a matter of preference. I prefer Select statements, but do you think that it would help to use SQL statements in this situation?
Ben Rail
Business Solutions
LOGI.design