Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Index on deleted()
Message
De
31/03/2001 21:08:15
 
 
À
31/03/2001 10:09:39
Walter Meester
HoogkarspelPays-Bas
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Divers
Thread ID:
00490398
Message ID:
00490668
Vues:
9
Good point,

The seek mentioned is to access the primary key which, when the record is deleted, is inverted. No additional indexes are required to support this method. It is not necessary to index on deleted to locate deleted records. With this technique only the primary index is needed therefore no extra overhead is experienced.

The number of deleted records is minimized, file sizes can stabilize (depending on the application) and tables do not require packing or reindexing as often.


Glenn

>Glenn
>
>>This sounds like a good argument for recycling deleted records. Generally when I recycle tables with an integer primary key I invert the key, ie
>>
>>1000 becomes -1000
>>
>>With a technique like this you probably can maintain an index on Deleted()because there are so few so as not to create a problem. When recycling like this you are not required to maintain an index on deleted, rather to locate a deleted record all you need do is SET NEAR ON on and SEEK -1. To encapsulate this behavior I have a stored procedure in the DBC.
>
>Glen, The problem is that for every Rushmore action (USE, SET FILTER, LOCATE, SCAN, SQL-SELECT, ETC) almost the whole index tag is send over the network for optimization. If you've got a million record table on your server, it just takes forever to just USE the table (USE mytable) when SET DELETE = ON.
>
>For locating deleted() records it is better to maintain a:
>INDEX ON .T. FOR DELETED()
>and just seek for .T. (SEEK(.T.)).
>
>Just search the UT about discussions about the DELETED() tag. You'll come to the conclusion that it generally is a bad idea.
>
>Walter,
>
>
>
>>Glenn
>>
>>>Crystian,
>>>
>>>Why do you want to use an index on DELETED(). If for performance reason:
>>>
>>>An index on DELETED() seldom solve performance problems, but frequently creates one. When using large tables, it can be really a pain to work with: a query over a network in a multiuser environment over a large table, will likely take forever. In most cases you're better of without.
>>>
>>>There have been lots of discussion regarding this subject. The may 1999 issue in FPA explains why it might be a bad idea.
>>>
>>>Walter,
>>>
>>>
>>>
>>>>Hello,
>>>>
>>>>I want to set indexes programmatically.
>>>>How do I set an index on DELETED()?
>>>>
>>>>I try INDEX ON Deleted() TAG Deleted().
>>>>
>>>>It won't accept this tagname, but in Modify Structure I can use the tag name Deleted(). Should I leave the () away or is there another way?
>>>>
>>>>Thanks for your help.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform