:: The optimizer resolves IN <subquery> predicates to EXISTS
:: <set> anyway.

So IN = EXISTS? Or are they processed differently in any way?

Is there a reason if the subquery is static (ie no fields referneced from
outer) that FB does not run it once and cache the result set?

:: >What if I
:: >just did a EXISTS not not a NOT EXISTS? Any diff?
::
:: Yes. Different result by 180 degrees.

Why does not create such a difference for FB? Is it because it has to scan,
vs using some kind of index?

:: No, it won't be any use for an update. It wasn't clear what
:: you wanted the
:: set for....

Yes sorry. When I first posted, I didn't think it was important info at that
time.

:: This sort of thing is most efficiently done in an executable
:: SP, since you

Unfortuantely SP's are not an option for me. I wont go into details, but its
not possible for us. We are running the "procedure" currently in our code
and the code runs on the server directly so its essentialy a "stored
procedure" anwyays. It of course does have the over head of reaching in/out
of the DB that a true SP would not, but its fast enough.