At 09:03 AM 15-03-02 +0000, Marco Menardi wrote:

>SELECT A.FIELDA, B.FIELDA
>FROM A JOIN B
>ON FIELDX = FIELDY
>WHERE FIELDA="99"
>ORDER BY FIELDA
>...
>I think that THIS IS THE MAIN COMPATIBILY PROBLEM, not the Insert one. If
>you think that your old apps, with the Insert fix, will not encounter the
>above, ok, FB1 has to be fixed for old app compatibility. BUT I think that
>even with the Insert fix, you will not be able to run your old app against
>FB1 without change your code in the Joins (I had to do in my apps).

Marco,
There is a vast difference between the two.

The ambiguous join syntax causes incorrect data to be delivered. AND note,
it does not break Dialect 1 apps. Are you advocating that the ambiguous
join safeguard be reversed so that you can continue to deliver inaccurate
datasets to your customers?

The identified columnlist did not deliver wrong data. In the case of the
ambiguous join, it is imperative that bad (=faulty) code be discovered and
fixed. In the case of the identified columnlist, there was no bug to fix.

In any case, this is now an empty debate. It seems doubtless now, that
there will be a 1.01 release in which Claudio will have revisited the issue
of identified columns in inserts, to disallow that which is
illegal: INSERT INTO ATABLE (ATABLE.*) and other such engine-breakers,
whilst leaving the identified column a matter of developer discretion, as
it was before.

And, to all of you, when it happens, consider making it a point to thank
Claudio...


regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at
www.ibobjects.com