Hi Walter,

Acknowledging that DELETED records do cause trouble/confusion to many people, as well as real implementation problems, what about something along these lines...

Let VFP, at the TABLE level, have an indicator telling the required handling of DELETED records. Default would be "as traditional" but other options would be to 'ignore totally' (as if they do NOT exist in there) or 'Recycle' (as your suggestion, implying igonre totally too), or ... (you name it - I'm sure there are other useful possibilities).

Being at the table level would remove any possible conflict from program to program in apps.

Just an idea

Cheers,

Jim N

>Graig,
>
>>Not necessarily. Many times people want deleted records indexed. Also, something has to track deleted records. I doubt very much this idea would help. In fact, it would probably severely hurt performance.
>
>I don't say that deleted records won't be indexed anymore, I only say that it must be possible to optimize indexes with a filter on deleted records when set deleted is on.
>
>The current situation is that indexes with a filter on deleted() don't optimize. I just want an exception for a !DELETED() filter. Since in the vast majority of apps SET DELETE = ON, the index covers the whole table (non deleted records), thus rushmore should be invoked.
>
>If this would be implemented, there is no need anymore for the INDEX ON DELETED() tag (which IMO always was a dog). When set deleted is off, the indexes scoped to non deleted records won't be used for rushmore, but all normal indexes will. Therefore this wish is to be regarded as a Enhancement Request.
>
>To avoid confusion about other filtered indexes (other than the FOR !DELETED() filter) it should be implemented in another way like:
>
>INDEX ON Field TAG Tag NONDELETED ....
>
>But internally it should be the same as a Filter on non deleted() records.
>
>Walter,