We are actually using vpn in to remote control a desktop at a client site and then running from there. The VFP app resides there but the data is from there to another location across a T1 with the directory drive mapped for vfp. I'm in the process of getting permission from the client to install a small vfp command utility to test and see if I get the results I expect and can see the indices, et al.



>>The size of the table itself is around 137,987kb. There is an index on the field used in the where and order by. Even pulling the top 10 where lastname='SMITH' ORDER BY lastname takes 5 minutes or MORE. Ridiculous. In fact, the small app used for testing only starts out with a small amount of memory (around 62,000) and while the query runs, it jumps to 230,000kb in the task manager.
>>
>>The VFP app which also accesses the same data (all A-Z) across a T1 pulls it in 3 seconds. Except that a search query in that app will take just 5 minutes as well. It is a 3rd party app and it is written in VFP but I do not have access to the code. But basically, a simple query is almost immediate in VFP across the T1 and too slow to even consider in dotnet using oledb. Just hoping I really missed something obvious...
>>
>>It looks like every record is coming across the wire...
>>
>>Ok, just checked and they have a drive mapped across the t1 to the data. I think (I stress think) that they are USING the table in VFP and using a select statement for their searches. That is why it is fast UNLESS they do a search in the vfp app and it is slow no matter what in dotnet. Just guessing though...
>>
>>
>>
>>
>>
>>
>>>>Pulling even the top 200 records can take 1-3 minutes. Very slow. We're trying to see what the delay is (it could be anything in the topology other than the driver). They don't have SQLServer on their system so we can't test pulling records from sqlserver as a comparison. In the past, adding an index tag in foxpro on the tables has improved performance, but we really don't know what may be the culprit here.
>>>>
>>>>
>>>>
>>>>>Tracy,
>>>>>
>>>>>Hard to tell when we don't know the case of the behavior.
>>>>>For instance, try to play with setting the recordset cursorlocation. This is what helped me in the past:
>>>>>
>>>>> .CursorLocation = adUseClient
>>>>>
>>>>>
>>>>>
>>>>>>Foxpro tables exist across a T1 link. Using a winform (for testing but it will be a process on the server) in vb.net and OLEDB to ADO to grab data from vfp tables. Very slow. Recommendations? The best way to handle it?
>>>
>>>What is the size of the data your pulling down? Are you testing against a single or multiple tables and with no index?
>
>I agree that it looks like your pulling a lot of data down the wire. The VFP OLEDB provider should use the available index if it will optimize the query.
>Can you run the sql select from VFP to check the rushmore optimization?