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.

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.