>>>>Thanks for the suggestion. So, the above then becomes:
>>>>
>>>>

SELECT id, UPPER(firstname), UPPER(lastname), DELETED() as deletedrec ;
>>>>FROM tablename INTO CURSOR crsTemp

>>>>And it works.
>>>>
>>>It will only work as long as you select from only one table. The minute you join in another table, it will fail to work again.
>>
>>This is easily circumvented by selecting from this particular table into a temp cursor, then use that in any joins later.
>
>Quite right!
>
>>
>>Funny though, I had this idea to have ...deleted() as ... yesterday, but had an impression that someone already said that :). Comes with long threads.
>
>Naomi first and then Thomas, I think and even Tore and me.
>
>I take it farthest though. A single t/f flag is seldom sufficient. A datetime is the ultimate. You get several extra abilities. A few are: 1, you can see all the records a malicious person deleted in one day - without a complex audit trail. 2 - You can delete records more than one year old and then pack. .T./.F. you can't decide which records to physically delete. 3 - You can recall records deleted in the last 10 minutes.

But it's not a simple retrofit. When I'm writing new stuff, I'll certainly keep it in mind, because I agree with you. It's a good idea, but short of rewriting an awful lot of code and changing all the tables in the system....

This is a product that has grown up from Clipper -> rewritten for FPW2.6 -> Rewritten for VFP3, and basically upgraded from that through VFP6 -> VFP8 -> VFP9. Believe me when I say there is code in here that scares me.