Hi Helen,

<snip>

> >Could you point out the ambiguities?
>
> > for
> > select memberid, <---------

<snip> ... </snip>

> > do
>
> for
> select om.memberid,

<snip> ... </snip>

> do

That fixed it. But I don't understand why. In my mind the select for
the IN clause was bracketed and therefor should not have anything to
do with the rest of the outer select statement. Would the problem be
in the fact that I had the same column name from two different tables
and the engine couldn't properly decide what one I was refering to?
Even though the brackets properly seperated the two statements?

> >I'm currently using Marathon
> >v3.0.0.50 RC1 (Using IBObjects v4.5x) as such I'm not using IB_SQL.
>
> Ah, but it's the same data access interface. So look for a
> checkbox somewhere in the DSQL tool that you are using, where you
> can turn parameter detection off and on. The error message is
> thrown when the editor tries to treat :variable as if it is a
> parameter.

If there is something there I've never seen it before. I'm assuming
that when Pat originally wrote Marathon, he had that switched off by
default for the Stored Proc and Trigger editors. I know I've never
modified it so it must still be setup to execute that way. Good to
know that it's not Marathon.

> The ambiguity should throw its own exception in Fb 1.5. In Fb 1.0,
> it only throws a warning, so you don't see an exception.

I'm running on FB1.5x and all I ever got back, in Marathon, was the
statement Unsupported .... I'll have to track that down and see if
Marathon isn't eating that exception.

> Sure: But this is an IBO exception, being thrown from the editor.
> It's not an engine exception.

Thanks again for your help.