Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Any plans to increase the table size from 2 GB(Microsoft
Message
De
02/02/2004 16:15:36
 
 
À
02/02/2004 15:54:11
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00872674
Message ID:
00873143
Vues:
26
Hi Greg,

I just want to add the observations of one very stubborn person as regards this issue (of TAG on DELETED() being good or not)...

I SURELY AGREE that today a TAG on DELETED() is most likely a BAD IDEA.
And the FPA Advisor referred to 'shows' categorically that the same is found in FPD (or maybe FPW) 2.6.
Yet I just cannot get out of my mind a few experiences where, back in FPD2.5/2.6 days, the simple addition of a TAG on DELETED() did turn a very slow SQL query into one that was lightning fast.

I notice, too, that VFP9 (Europa) has something that also addresses optimizing when there is a TAG on DELETED(). Let's hope that it is good AND survives to implementation.

regards

>Walter,
>
>That's interesting because AccPac Pro Series has deleted() indexes on practically every table. Could it be because many installations never pack out tables for months and months on end?
>
>I'm definitely not disagreeing with your advice, I just want to think about it before ripping all the Deleted() indexes out of Pro Series.
>
>Greg
>
>>Hi martin,
>>
>>>Just wanted to point out that my own experience showed me that it is not plain record count what slow things down, but having too many deleted records. The delay at USEing the table can be prevented with proper indexes on deleted(), as it is caused basically because a scan is needed to find the first non-deleted record.
>>
>>A very, VERY dangerous advice. an INDEX ON DELETED() will cause you headaches on large tables since for every rushmore optimizable expression about the whole index tag needs to travel the network before even finding one record. A simple browse statement can take several seconds to execute esspecially on slower networks.
>>
>>A simple USE could take several seconds as well (though I could not quickly replicate this behaviour in VFP8). It is way better to ensure that no deleted records exists at the top of your table (depending on the index order you set initially with the use command).
>>
>>An index on deleted() almost never is a good idea. This is a proven fact and there even is an article in Advisor handling this specific problem. So please, please remember: Throw away your indexes on deleted()...
>>
>>Walter,
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform