> > Your case looks like an extension to this. It is doing a join to
> > itself, and would therefore have two fields named test_id. In

your

> > case, it chooses the "wrong" one.
>
> But its not ambiguous. There are two tables in the from part of

the

> select. One named test and the other parent (which is an alias to

the

> test table) and so you should have two columns of test_id but one

for

> the table test and the other for parent and I explicitly specify in

the

> select that I want the test.test_id and not parent.test_id so there

is

> no ambiguity that I can see.

You missed my point. It is not ambiguous on your query. It is
ambiguous because of how FB 1.5 implements it. This query may well
work in Firebird 2 (or it may not, but you can test it)

Added confirmation is that it works

> properly in the other databases I've tried and that Firebird

doesn't

> trigger the abiguity error that it does now when it thinks its

ambiguous.

2 words, Backwards compatibility

Firebird has being getting more and more strict with ambiguous
queries. For example

select ID
from tableA a
join table B b on (a.id=b.tableaid)

would return something in FB 1 and IB6, but in FB 1.5, you will get

Dynamic SQL Error
-SQL error code = -204
-Ambiguous field name between table tableA and table tableBDynamic
-ID

>
> > The work around is simple, use aliases for both tables as you

have

> > done in your second example.
>
> It should not be needed and I suspect the SQL specs would agree

with me

> on this and that Firebird is getting it wrong. Or perhaps this is

a

> case where the SQL specs are themselves ambiguous but I still think

that

> Firebird is getting it wrong.

Yes it is, but seriously, use aliases and get on with life.

Adam