>>>>SET DELETED ON/OFF affects much more than BROWSEs. It affects any command which can have a FOR clause. SCAN, for instance. If DELETED is ON, a SCAN is an implied SCAN FOR NOT DELETED(). Also, SEEK() will not find deleted records if DELETED is ON. Also COPY TO ... implies COPY TO ... FOR NOT DELETED() if DELETED is ON. The list goes on and on.
>>>>
>>>>Rich.
>>>
>>>In my somewhat limited experience I have seen cases where things supposed to be implied to work do not work, so implicitly stating them has prevented the problem from occuring. Indexing with deleted on does not exclude deleted records and can cause a real problem when you index unique on a field for a list, etc. It was a thought based on behavior I have experienced and not what I've read in the instruction manuals. Thanks for the info, nice to know.
>>
>>What you're saying makes a lot of sense in one way: there is a lot of code which is written to work around bugs, and to work around commands or settings which don't work "as advertised". However, SET DELETED is something which has worked very reliably since FoxBase. It's so necessary a part of an xBase language, I don't think many developers would have stuck with FoxPro if SET DELETED didn't work.
>>
>>As usual, I could be wrong ...
>>
>>Rich.
>
>I agree with you, but the SET DELETED ON has exhibited some strange behavior with me, which could just be my limited understanding of where it works and where it doesn't. Case in point, with SET DELETED ON, I index unique to get a list to for the user to select from. If the first occurance of the key I index on is a deleted record, it's picked up in the index but then will not display in the list because it's deleted! This drove me nuts because the entries were in the db but wouldn't appear on the list. So, instead of deleting a record, I now blank it (BLANK recno), this prevents this behavior. Just one of those things, those strange and crazy things that we love about FoxPro. Appreciate the feedback, this is the best source because folks like you and many others respond and are willing to help.
>
>Marv

Indexing (INDEX ON...) is one of the commands which is *not* affected by SET DELETED. Which, once you know it, you account for in your programming.

It makes sense to me. Records which are physically there, but marked deleted, should be included in the index regardless of SET DELETED. If they're not included when you INDEX, because DELETED was on at that moment, then you SET DELETED OFF and look at the table with that index active, you still wouldn't see the records, which doesn't make sense. The only way to make an INDEX command exclude deleted records is to INDEX ON < expr > FOR NOT DELETED(). And then of course you've got a TAG (or IDX) which can't be used by Rushmore because it's filtered.

I guess I just proved my earlier statement wrong: not every command with a FOR clause is affected by SET DELETED. INDEX ON has a FOR clause. I just hardly ever use it.

Rich.