>In a reaction to the discussion whether or not to use an index on DELETED(), i want to say the following
>
>
>- Indexes with a tag on deleted don't improve performance when there are not many DELETED records.
>
>When there are not many deleted records in the desired recordset, the optimizer won't improve the performance as it must use an extra index which could be more of a burden than a benefit.
>
>- Partial optimization could be better than full optimazation.
>
>Many of use are mislead by thinking that full optimization is better and faster than partial optimization. This is simply NOT True in all cases:
>If 95% of the resultset is optimized by a small index and only 5% by a large index (such as an index on a C(100) field) it could be wise to drop the large index as it slows down performance when updating or inserting large amounts of data.
>
>This rule applies to the deleted tag as well. If a resultset won't have much benefit of the deleted() tag it may run even faster without it.
>
>- By working with very large tables a tag on deleted could be dangerous.
>
>Very large tables means very large indexes. To let the optimizer to do its work the indexes must be in memory. When there is not sufficient memory to load all the indexes the optimizer won't work at all resulting in a dramatic increased response time.
>
>- Large tables never should have many deleted records.
>as they take up a lot of diskspace which in itself decreases performance.
>
>- Indexes on DELETED() should only be used in some particular cases.
>
>In some multitable query's or Relations the performance could benifit by a index on deleted(). If tables contain more than a few deleted records and are joined with eachother in a Query, the performance COULD be tuned with a index on DELETED().
>
>IN GENERAL: Don't use index tags on DELETED()

There are few minor uncertainties in your conclusions. The main one is that it's really difficult to predict what is 'few' deleted records means and when/where this limit will be overcome and lack of Deleted() tag will become more visible. Also, VFP does not take whole index to memory, if it would be so, it just could not work with large tables on network. Your last statement shows some real point: deleted() tag is helpful for multitable queries, and if you have one large table query then you just use SEEK/SKIP to get the best performance (i.e. it will be deleted_tag irrelevant issue). It's natural to expect that real app will use different kind of queries (multi-tabled, one-tabled, and so on), so tag should be there, but tuning can be accomodated by different means, sometimes it will use deleted() tag and sometimes SKIP it.