>>>Does the SET DELETED setting not affect views in a dbc?
>>>
>>>I have a view that does not return DELETED records at all, yet I can write a SELECT statement in the Command Window, and I get the desired effect of the SET DELETED setting.
>>
>>(First off, I did not point out that view is running against local dbf tables)
>>
>>Well, I think I see what is going on... The with "set deleted on", the records do not appear in the results, and with "set deleted off", the deleted records do appear in the results; it's just that I did not see that little black box beside the record in the Browse window, so you cannot tell that the record is deleted.
>>
>>Looks like I just need to add an int field to use as a deleted marker, as this will surely cause me problems when I convert my app over to a SQL Server back end.
>
>Set deleted should always be ON. And deleted records should always be treated as "gone forever", that's how a SQL server back end treats deleted records. Personally I never delete records, instead I have a logical field called Reusable.

In this case I have an automated system that adds a record to another table, but any user may then come along "delete" the pushed-in record, and if so, the automated system should not try to add it back, which it will if he see that his record is no longer there. So, I need the "deleted" record to still be there in the second table, so I can look for it by a key, but not add it back if the user has already marked it as deleted ("ignore" may be a better word in this case).

So, I guess even in SQL back end, I'll never delete the record, just change it's "ignore" flag to .t. So far, in vfp tables, the Deleted() flag has served this purpose, but I now see the weekness to this approach when targeting a SQL backend.