James,

> >> I was testing out Ramil's XLSQLRep component which had a demo with

SQL

> >> for the EMPLOYEE db specified thus:
> >>
> >> select
> >> FULL_NAME, PHONE_EXT, HIRE_DATE, SALARY, JOB_TITLE
> >> from
> >> EMPLOYEE_PROJECT EP
> >> JOIN EMPLOYEE E ON E.EMP_NO=EP.EMP_NO
> >> JOIN JOB J ON J.JOB_CODE=E.JOB_CODE
> >> and J.JOB_GRADE=E.JOB_GRADE
> >> and J.JOB_COUNTRY=E.JOB_COUNTRY
> >> order by FULL_NAME
> >>
> >> .. and it worked... in Firebird 2.01! I was taken aback because
> >> according to my understanding this "violates" the strict ambiguity
> >>
> > rules
> >
> >> imposed in FB2 because some fields are fully qualified

(alias.field)

> >>
> > and
> >
> >> others are not... or maybe the rule applies selectively on either

side

> >> of a JOIN?
> >>
> >
> > Following many complaints the ambiguity logic was made more
> > 'intelligent' to handle cases as you note above.
> >
> > The reality is that the example is not an ambiguous statement, since

all

> > the 'select' columns are found only in a single table from the

select.

> >
> Actually not. The JOB_TITLE column is in the JOB entity set, while

the

> reset are from the EMPLOYEE entity set.

I meant that each column itself is only found in a single table, not
that all columns are found in the same single table.


Sean