Hi Peter,

I've never had a problem with SET DELETED. It has always worked as expected for me.

I wouldn't agree with you that it's "misleadingly supported". MS is very clear about it : Be careful, you may get unexpected results.

Regards,

Liam


>Hi to all,
>
>I'm wondering... Since long I propagate that SQL-statements should exclude deleted records (if that's what you want) by using WHERE NOT DELETED() in the statement. I have this idea that the Select-SQL reacts to the setting of SET DELETED, but that it's not waterproof, that it may happen that occasionally deleted records will be included anyway, unexpectedly. Therefore, I always exclude them by using WHERE NOT DELETED() explicitly in the statement.
>However, this poses a problem if the Select-SQL gets data from two or more tables, since the alias-argument of DELETED() isn't supported as you'd expect. (Rather, it's misleadingly supported, since it may point to a table/cursor that's not involved in the Select-SQL - which uses USE .. AGAIN - but does exist and has a record pointer and thus always returns the same result, True or False.)
>
>I've added an item to the wishlist: Support for use of local alias when referencing functions like DELETED() and RECNO() in SQL-Query Wish #1093
>
>But what I'm now interested in: Have others experienced unexpected results with SET DELETED ON and therefore do the same as I do? Or is everybody happy with using SET DELETED ON preceding the Select-SQL?

Liam O'Hagan
MCP VFP Desktop Apps