Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Filtered query
Message
De
22/04/2010 10:50:00
Mike Yearwood
Toronto, Ontario, Canada
 
 
À
22/04/2010 04:25:57
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Titre:
Versions des environnements
Visual FoxPro:
VFP 9 SP1
Divers
Thread ID:
01461413
Message ID:
01461493
Vues:
49
>Hi Dmitry.
>
>Instead of adding ReadWrite, you should use NoFilter. That way you'll get a real cursor instead of a filtered version of your source, but it will still be read only, so if you accidentially try to modify it you'll still get an error.
>
>As for why it's slow, even with 80,000 records I wouldn't expect a Go Top to take a minute, especially since the index should help it do the check.

GO TOP is not Rushmore Optimizable. No index is used to "do the check".

If you want to check and see where the time is going you can always use Set Coverage and look at the resulting file.
>
>Ian Simcock.
>
>
>>>>
>>>>I wanted to confirm that my thinking/approach in solving the following problem is valid.
>>>>
>>>>Recently a customer called me complaining that a certain place in the application was taking too long (close to a minute). I tracked the issue to the code that was retrieving a query from a table. The SQL Select was as following:
>>>>
>>>>select OneField from MyTable where PK_FLD = nValue into cursor MyCursor
>>>>go top in MyCursor      && This is where I think it takes too much time.
>>>>nValue = evaluate( MyCursor + ".OneField")
>>>>
>>>>
>>>>The slow down occurred - I believe - on the line GO TOP. The table MyTable has approaximately 80,000 records. There is an index tag on PK_FLD. So I believe that the query was filtered and therefore the GO TOP was going through all records in the table instead of just the resulting cursor. I intend to solve the issue by adding READWRITE to the SQL Select and therefore eliminating the possibility of filtered query.
>>>>
>>>>But my question is, is the logic that possibly filtered query is causing this slow down?
>>>
>>>Is the GO TOP line even necessary? My understanding is the record pointer is located at TOP already once the result cursor is created, whether it's the result of a filter or not.
>>
>>You are probably right. I thought about it too but was not sure if the record pointer will be at the top record automatically. Now that you are saying I will do away with GO TOP. But will probably add READWRITE anyway, just in case.
>>
>>Thank you.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform