""Leyne, Sean"" <sleyne@...> wrote in message
news:A7526F20AD81874AB68FC1E51862B4DF07E14F@......

> Roger,
>
> > So I am now persuaded. I'll tighten up my code. Ambiguity is dead.
> > Viva Monoguity!

Roger: the problem is not the optimizer, but the DSQL layer. At one time in
the past, someone said that we were producing different results than IB when
a field was common between two tables. The old code simply picked the first
field name that matched and continued parsing the DSQL "nodes" happily.
However, some people (Ann, Neil, John, myself) have changed the DSQL layer
in FB, trying to fix some old issues. We can't guarantee that the order of
the fields in the internal lists will remain the same after changes. The
lists are created from "nodes" that are previously pushed into a stack.
Clear as mud?

Another different issue is when the optimizer produces different access
plans in schemas that look the same, because in one you defined index A
before index B and in the other you did the opposite. You can ask Dmitry
Kuzmenko about this bizarre history.

> You see! That wasn't that painfull was it?
>
> We didn't even have to get out the baseball bats!
>
> <huge grin>

You are a pacifist, Sean! :-)
I was going to kick the spiders and rip their webs to be able to unpack that
old bazooka that I used around Dec-1999 and July-2000.
:-)

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing