Subject | Re: [ib-support] Parameter order in SQLDA |
---|---|
Author | Geoff Worboys |
Post date | 2002-10-09T23:49:07Z |
Just to add to this for those that are interested...
Besides the already discussed items...
- parameters in subselects come after parameters in the
outer select (and so on recursively)
- order by can cause duplication of parameter definitions
and UNIONs turn off this duplication. If multiple subselect
columns are chosen in the order by then multiple duplications
occur, in the order they appear in ORDER BY, and in the order
governed by any sub-subselects that may exist.
Experimentation (in FB 1.0) has shown that...
- JOIN clause parameters in preceed all other parameters
of the select (within that part of a union)
- HAVING clause parameters follow all other parameters
(within that part of a union), including any subselect
parameters and any duplicated parameters.
Given that not even IBO handles all these situations I can only
presume that the need for parameters in JOIN or HAVING clauses
is very rare - or there would have been complaints by now. So
perhaps I should ignore this and just proceed with with my
developments without worrying about it.
What would be really nice, would be for FB to offer some hint
as to what parameter each XSQLVAR is referring to, perhaps the
statement position or something in the alias field.
--
Geoff Worboys
Telesis Computing
Besides the already discussed items...
- parameters in subselects come after parameters in the
outer select (and so on recursively)
- order by can cause duplication of parameter definitions
and UNIONs turn off this duplication. If multiple subselect
columns are chosen in the order by then multiple duplications
occur, in the order they appear in ORDER BY, and in the order
governed by any sub-subselects that may exist.
Experimentation (in FB 1.0) has shown that...
- JOIN clause parameters in preceed all other parameters
of the select (within that part of a union)
- HAVING clause parameters follow all other parameters
(within that part of a union), including any subselect
parameters and any duplicated parameters.
Given that not even IBO handles all these situations I can only
presume that the need for parameters in JOIN or HAVING clauses
is very rare - or there would have been complaints by now. So
perhaps I should ignore this and just proceed with with my
developments without worrying about it.
What would be really nice, would be for FB to offer some hint
as to what parameter each XSQLVAR is referring to, perhaps the
statement position or something in the alias field.
--
Geoff Worboys
Telesis Computing