Subject Re: [IBO] Some further IBO/FB1 incompatibility considerations
> After two day from the discovery that the Insert statements automatically created by IBO are incompatible with the new FB1 (or vice versa ;), I think that this problem will not be of big damage because:
> a) The IBO fix is very little (two lines) and can be made by Jason on the old code that is already supported (3.6something), or by any registered user
> b) this will not prevent the adoption of FB1 more than the new control on syntax in column name in joins. I had a lot of queries with joins and columns not table qualified (ambiguous between two or more tables), so when I adopted FB I had to fix and recompile my code. In this situation, adding a) fix is a snap.
> So, since b) is out of question (I mean, FB will not revert to a confusing syntax), a) should be a minor issue for IBO users, or am I missing something? Do you really think your customers are able to update their database by themselves? And, are they really using Fb_RC2? or more probably they are using Interbase... so a) problem?

The problem has nothing to do with a confusing syntax -
there is nothing wrong with the SQL IBO is creating - it
just depends how you interpret the rules. The code is valid
and produces correct answers, it just does not now work,
because it is flagged as a problem because of fixing the
real faults. There is no argument that on FB2 this matter
should be corrected.


The problem is that none of our existing code will run on
FB1 Final, and I for one can not start changing that code,
willy nilly, until I prove that the released Firebird is
stable. Chicken and egg. I need to be able to run existing
24/7, safety tested programs on Firebird1 Final, if I change
both code and engine "Where is the problem?" if one pops up.

Fortunatly Ann H has agreed that breaking all the currently
installed IBO code base is not acceptable, so we will
hopefully get a reprieve. One of the rules on FB1 was not to
break existing applications unless the application was
actually producing inconsistant results anyway. In this
instance the answer is always correct.

Lester Caine
L.S.Caine Electronic Services