Subject | Ambiguous SQL :: Your Views Please |
---|---|
Author | Helen Borrie |
Post date | 2001-08-26T08:46:50Z |
Hi all Firebird users or intending users
and
HI DIANE <---- we could use your opinion here too!
An old bug in IB has been tidied up. Here is an example (thanks, Hans Hoogstraat):
select a.compname from company a , employee b
where a.compname = b.compname
and b.empno = :empno
order by compname
The ambiguity here is that the statement does not identify which table's compname to order by and the results are somewhat unpredictable - contradictory, even, if you compare database versions.
In Firebird, Claudio has tidied up the dyn code so that an ambiguity such as this will be detected. Currently, it simply causes a silent warning. The plan is to make it throw an error in Rls 2.
However, there are voices in devel who would like to make even Rls 1 throw an error, rather than a warning which is not detectable.
The effect of the change - when it happens - will be to cause exceptions in your applications where you are using such ambiguous statements.
What we'd like discussed is whether you want to keep things the way they are for Rls 1, knowing that the axe will fall in Rls 2; or whether your preference is to bite bullet and have it activated now.
Thanks all,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________
and
HI DIANE <---- we could use your opinion here too!
An old bug in IB has been tidied up. Here is an example (thanks, Hans Hoogstraat):
select a.compname from company a , employee b
where a.compname = b.compname
and b.empno = :empno
order by compname
The ambiguity here is that the statement does not identify which table's compname to order by and the results are somewhat unpredictable - contradictory, even, if you compare database versions.
In Firebird, Claudio has tidied up the dyn code so that an ambiguity such as this will be detected. Currently, it simply causes a silent warning. The plan is to make it throw an error in Rls 2.
However, there are voices in devel who would like to make even Rls 1 throw an error, rather than a warning which is not detectable.
The effect of the change - when it happens - will be to cause exceptions in your applications where you are using such ambiguous statements.
What we'd like discussed is whether you want to keep things the way they are for Rls 1, knowing that the axe will fall in Rls 2; or whether your preference is to bite bullet and have it activated now.
Thanks all,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________