I don't know if I can't explain my thoughts or I'm not carefully read...
[cut]

>
> 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?

NO!!!!
I'm just telling that if you (community) are screaming for a incompatibility that takes 2 IBO lines to be fixed, you should be worried much more about the above "incompatibility".
Since I'm sure that you will have to fix your code since I'm sure you did in the old apps ambiguous join syntax, the Insert fix will be made in a shap, or, in the worse case, with the same effort.

>
> 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.

I know but I'm surprise for this situation:
a) FB RC2, new syntax fix
b) Marco Menardi (me) had to fix lot of queries with bad join syntax and test the apps (wery time consimung)
c) none in the community was afraid about "old good apps" that can be broken by this fact
---
d) Insert problem
e) Marco Menardi (me) had to fix IBO code and recompile (5 minutes)
f) lot of community members screaming loud about "broken compatibility" of old code...

So my question: how is that??????????
Of course I'm happy for the join fix, of course I will be happy for the FB1.01 release, this is not the point. The point is: why do you need FB1.01 for "old apps" and don't worry about new join syntax check? Why upgrade database of old, already working with no problem, apps? Expecially if you don't have the code to recompile, it seems to me very very risky....
(btw, if dialect 1 there is no error for ambiguous joins, but only a warning... where and how is raised the warning? In the log file? thanks)

Thanks
Marco Menardi