>>HOw do you expect DELETED() to know which alias to check DELETED in? I made this mistake before, trying to use DELETED in a SQL query, and found that you can only depend on it when there is one and only one table involved in the query, so SLQ doesn't get confused. Also, specifying the alias: DELETED("Employee") doesn't work either... apparently something along the line breaks when you try to mix the VFP DML (DELETED()) with SQL.
>
>Yeah, I had also tried deleted("employee") to no avail. I do however expect the subquery to run first and for SQL to properly interpret a simple and explicit select contained within the parentheses. Looks fairly straightforward to me.
>
>Bottom line, I was just making sure I had not overlooked some obvious error in my syntax. However, I still see no reason why this should not work. I am going to try a more creative way later tonight.

One thing I've learned, DML functions work in single-table queries (with only one alias, that's important), and even then only when you use them without an alias, so it defaults to the one alias it has available. Anything that has an alias as an [optional] parameter is unreliable, since you won't know which alias will it take. And you can't specify the alias, because it uses some fake internal aliases, which can't be known beforehand - and if you use an existing alias, it will use whatever the function needs from the alias open outside of the SQL process, so in this case it would use the Deleted("employee") from the current record in Employee, so it's .t. or .f. for all the records processed.

In this case, I see no other way but using a temporary cursor with Select blah blah from employee where whatever and !deleted() into curs temp, and then select ... where ... in (select * from temp).