Subject | Re: [IBO] changing KeyLinks, MasterLinks etc to use aliases |
---|---|
Author | Helen Borrie |
Post date | 2006-11-29T21:57:48Z |
At 07:35 AM 30/11/2006, you wrote:
The aliasing rule doesn't require you to adjust all your dataset
properties to use alias names instead of table names. It requires
you to be *consistent* in your use of table aliases. So I guess if
you have any queries where you use both table identifiers and aliases
in the same statement then your projection will be true.
Re Trond's statement:
SELECT * FROM Rate R
Trond said "it works fine". If so, then Trond is using Fb 1.5. This
statement is syntactically incorrect and should throw an exception at
the Prepare in Fb 2.0 and a warning in Fb 1.5 because no R.* alias
was provided. So that has been incorrect syntax for some years already.
A second point here is that a single-table statement that has no
correlated subqueries should not use aliases. The proper syntax for
Trond's statement, in both 1.5 and 2.0, is
SELECT * FROM Rate
SELECT * FROM Rate
or, supposing the statement contains a correlated subquery:
SELECT R.* ,
(select rl.exchange_factor from Rate_Lookup rl
where R.currency = rl.Currency) as exchange_factor
from Rate R
Note that something like the following would be allowed in 1.5:
SELECT R.* ,
(select Rate_Lookup.exchange_factor from Rate_Lookup
where R.currency = Rate_Lookup.Currency) as exchange_factor
from Rate R
It's not allowed in 2.0. Really, this is the nub of the Fb 2.0
change: enforcement of table identification in multi-table queries
came in 1.5. Fb 2.0 requires the usage of aliases OR table
identifiers to be consistent.
Helen
>Hi all,I think you need to read the Firebird 2.0 release notes too! :-)
>
>I'm currently investigating what it takes to adjust my source code for
>FB 2.0 and IBO 4.7. I've read the IBO release notes and followed the
>FB and IBO mailing lists.
>So far it seems the biggest hurdle will be adjusting all my dataset
>properties to use alias names instead of table names.
The aliasing rule doesn't require you to adjust all your dataset
properties to use alias names instead of table names. It requires
you to be *consistent* in your use of table aliases. So I guess if
you have any queries where you use both table identifiers and aliases
in the same statement then your projection will be true.
Re Trond's statement:
SELECT * FROM Rate R
Trond said "it works fine". If so, then Trond is using Fb 1.5. This
statement is syntactically incorrect and should throw an exception at
the Prepare in Fb 2.0 and a warning in Fb 1.5 because no R.* alias
was provided. So that has been incorrect syntax for some years already.
A second point here is that a single-table statement that has no
correlated subqueries should not use aliases. The proper syntax for
Trond's statement, in both 1.5 and 2.0, is
SELECT * FROM Rate
>Since my app maySELECT * FROM Rate R should be corrected to either:
>have a few hundred TIB_Query and TIB_Cursor components I would very
>much like some automatic conversion - or at least some assistance with
>adjusting the affected properties.
SELECT * FROM Rate
or, supposing the statement contains a correlated subquery:
SELECT R.* ,
(select rl.exchange_factor from Rate_Lookup rl
where R.currency = rl.Currency) as exchange_factor
from Rate R
Note that something like the following would be allowed in 1.5:
SELECT R.* ,
(select Rate_Lookup.exchange_factor from Rate_Lookup
where R.currency = Rate_Lookup.Currency) as exchange_factor
from Rate R
It's not allowed in 2.0. Really, this is the nub of the Fb 2.0
change: enforcement of table identification in multi-table queries
came in 1.5. Fb 2.0 requires the usage of aliases OR table
identifiers to be consistent.
Helen