Subject Re: [IBO] Some further IBO/FB1 incompatibility considerations
Author mmenaz
Probably my english is so poor that I can not meke the point clear, I apologise. What I was referring to is that (from FB1 release note):
...
Ambiguous JOIN statements are now rejected
InterBase does not prevent you from submitting a statement like this:
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).
For current applications, the problem does not exist, since you have the source, you have only to recompile. If you manually build "bad" Insert SQL statement, you only have to make them "good" like you had to do with the joins. What's so terrible?
Regards
Marco Menardi


--- In IBObjects@y..., lester@l... wrote:
> ( Try Again - I duplicated one on ib-support rather than
> resending this <g> )
>
> > I don't want to insist, since I'm an happy IBO user and this incompatibility problem was annoying me too.
> > But my thought was based upon the fact that the other "fix" of FB1 (the not table qualified columns in a join) is (maybe) THE MAIN PROBLEM, since I'm sure that all old apps using joins will be break by this new syntax check.
>
> Every current IBO application is broken by the change. There
> is nothing wrong with the old code, is is simply that Jason
> adds the table name to the column name in an insert
> statement.
>
> INSERT INTO x ( x.C1, x.C2 )
>
> the x. element is now creating an error, because of
> preventing the use of x.* which actually crashed Interbase.
> There is nothing wrong with including the table name, except
> strict adherence to the syntax. The result is always
> correct, unlike some of the other instances where the result
> was ambiguouse.
>
> > IF this is true, just recompiling (I had only to recomplile) or changing some hand made SQL is trivial, compared to the join problem (I had a lot of them to fix). IF I'm wrong upon this point, ok, FB has to be fixed...
> > But I think that the even with the fix, you will have to recompile those old apps you have forgot about...
> > Anyway, since FB will be fixed, I'm curious to see how many old apps will still work with it :)
>
> The bottom line is that some people may not even have the
> source to recompile, so they are stuck and not able to
> upgrade. If they want to run old code while building new
> replacements they would have to do it on an older version of
> FB. Some old applications will probably have problems, if
> they had 'random' results anyway, but to repeat, as it
> stands at the moment NO existing IBO application can run on
> FB1 ( if it INSERTS records <g> )
>
> --
> Lester Caine
> -----------------------------
> L.S.Caine Electronic Services