>As far as your code goes, it seems to me that optimized code should equal or beat SELECT - SQL in most cases. If you've tried SEEK/SCAN WHILE a la JVP, and you're moving record pointers yourself (you might try doing it without SET RELATIONs) I don't think it gets much faster. I'd be GLAD to be proven wrong here!

I think this is a case of "when is OPTIMIZED not fast"? The answer, here, is when you are using unique keys so that every key field has an index record, and you must hit every one in an entire table.

My suspicion now is that SQL...NOT IN is actually using the tags to check existence (though it may say it's NOT OPTIMIZED), or else this process would be much slower than it is. As it is, the SQL...NOT IN is about as fast as the optimized SCAN or DELETE FROM WHERE IN.