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.