KILL anything ambigious or not designed.

I don't want to be caught again and spent hours to find
my mistakes at release 2 :)

Best Regards
Hans

=======================================================

Helen Borrie wrote:

>
> 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
> _______________________________________________________
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/