>>No I did not. Could you share some hints?
>
>I'll try :) The basic idea from tests is that for non-filtered SQL result sets (views, cursors, tables), and SET DELETED ON, the following occurs:
>
>Any index available is used by the SQL as needed. But if the index on the "field" (including deleted, which has an internally added WHERE clause of Deleted = .F. at runtime) in the source is unbalanced, entire indexes are loaded into memory (and across networks, if not local).
>
>This is true for any indexes, but logicals are the most likely to be seriously unbalanced. by their nature.
>
>To illustrate, with index on Deleted, and no deleted records exist, the entire index is pulled into memory. The same is true for any other fields where there are a great many matching records, and your WHERE clause is looking for that match.
>
>The point is that if you're not going to have very many deleted records, an index on deleted can only hurt performance for this type of SQL situation. On the other hand, it will still speed up other optimizable situations, so you have to consider where your indexes will be used...

I understand this logic. However, I still believe that personally I should have DELETED() tag. Firstly, there are many situations when non-filtered option is good enough, e.g. for ad-hoc queries or reports. Usually, the necessity for non-filtered recordset arises from interface needs, the most popular case is few child records in grid. Here, DELETED() tag consideration is the last straw that convinces me that my preference for SEEK/INSERT cursor against view is more than justifiable.