I should have said I'm dropping aliases except where necessary. In
stored procedures there are essential uses of aliases.

On the client side I use IBO 4.3Aa and most SQL is in TIB_Queries. I
also use the TIB_Query.OrderingLinks property and often use IBO's
[Create] action here to automatically set SQL that allows grids to
be sorted by different columns. This uses full table names. So
removing aliases where not essential is convenient.

--- In firebird-support@yahoogroups.com, "Adam" <s3057043@...> wrote:
>
> > In converting an application from FB 1.5.x to 2.0 I am
eliminating all
> > aliases from my client code because of the new alias rule that
> > eliminates ambiguities.
>
> Personally I see that as throwing the baby out with the bathwater.
You
> would be better off imo to use aliases for everything as it allows
you
> if need be to rejoin to the same table multiple times. For example,
> you may have a table of customers and a referrals table, and you
may
> want to list all customers and which customers referred them etc.
>
> "if an alias for a table is used it must be
> > used always in place of the table name." Its straightforward and
safe.
> >
> > In the FB2 RC1 release notes under PSQL this rule is not stated
or I
> > have missed it. I suppose PSQL is SQL? The ambuguities of SQL
can be
> > carried to PSQL.
> >
> > Does the new table alias rule apply to PSQL? I assume it does
but
> > welcome some better insight.
>
> PSQL is the language used in stored procedures and triggers. It
> includes the ability to run SQL, as well as if statements and
loops etc.
>
> So they are not the same, but obviously if it is considered
ambiguous
> in SQL, then the same statement executed inside a stored procedure
> should also be considered ambiguous.
>
> I find the rule annoying sometimes to be honest. When there is no
> ambiguity as to which field is being referenced, I do not see why
it
> should complain (although the standard says it should), however it
is
> also bad practice. Someone in the future may introduce a field with
> the same name into another table you have joined to, thus making
your
> SQL statement ambiguous sometime in the future.
>
> Adam
>