At 12:37 AM 25/04/2006, Dany wrote:

>The solution should be the one that caters for best practices in the
>future. A funny workaround to allow legacy applications right away will
>probably backfire later when writing more advanced applications.
>
>I know that I have been using the ability of IBO and the FB 1.5.x API to
>return field names and relation names. A query contains a view or a SP
>and I can ask what the fields real source was after prepare. Will such
>functionality be broken? I have also some logic in my application that
>creates alias names on the fly. On some occasions I have used the table
>name as alias :(
>
>Going to FB 2 will be very complicated for me either solution that Jason
>chooses. But it would probably coax me into better code-writing with a
>cleaner solution.
>
>I really think that the FB team should have allowed for a "dialect"-like
>possibility to use the old aliasing style.

They did: it's called Firebird 1.5.3.

Seriously, Dany, the added strictness of the distribution rules is
not something one could choose to use or not. It is necessary
because of the major clean-up and refactoring of the optimiser and of
indexing. Everyone wants more speed from queries, everyone wants
predictable distributions, etc. etc.

Firebird 2 has been on the map for a long time. It's not as though
the notion that getting more speed and featurosity from distributed
queries would involve a lot of architectural change in the engine was
unheralded. The distribution rules already got tighter in Fb 1.5 and
broke a lot of folks' prior utilisation of "holes" in the InterBase
implementation.

We've had three years to clean up our act. Third-party drivers are
bound to be affected by changes and it's a "given" that, to some
degree, there's an inevitable lag between release of the new version
of the DB engine and the driver catch-up. Driver developers no
longer have that old "luxury" of guessing that not much changes in
the engine from version to version. The InterBase era is over.

Helen