--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:

>
> At 11:41 PM 16/02/2007, George wrote:
>
> >I am concerned about the wider implications - regardless of
> >the 'correctness' of syntax used in earlier versions.
> >
> >It seems each new release, instead of building on previous ones,
> >creates new problems in existing, tested and released code.
>
> A major new release like v.4.7 is responding to new syntax or new
> restrictions imposed by new versions of the database

engine. "Dirty"

> syntax that people have inadvisedly used in the past will be a
> chicken looking for a place to roost.
>
> The tightened join syntax has been presaged for a long time. It
> first showed its face during the v.1.5 beta cycle (which was nearly

2

> years long), when bad old habits became subject to warnings. Now,

at

> 2.0, they throw frank exceptions. That's one example; there are

others.

>
> On the Firebird side, these decisions were not arbitrary. Some
> important things remained non-implemented from the InterBase days

and

> some scary distribution bugs existed for joined sets. People were
> warned then to fix up their client code or be prepared for some bad
> times with v.2.0.
>
> Fb 2.0 brought along a lot of new challenges for IBO, such things

as

> derived tables, EXECUTE BLOCK and returning relation aliases in the
> statement parameter block. All these things needed supporting,
> requiring a lot of changes in the underlying code in the IBO
> statement objects that parse the SQL.
>
> So, we've been chewing hard tack for a while, while Jason and Ramil
> have been getting it right.
>
> So - the cost for developers of legacy apps *and* of components and
> older drivers, who have been less careful than they might have been
> about not depending on the "tricks" one can do to exploit a faulty
> language implementation, is that The Day of Judgement Has Come.
>
> >We have evaluated IBObjects and are seriously considering
> >incorporating it into our products but we are very concerned about
> >configuration control and backward compatibility. From messages in
> >this forum, upgrading seems a somewhat risky business, especially

if

> >considering migrating to Firebird 2.0 from 1.5.
>
> Migration is always a risky business and should never be considered

a

> trivial exercise. For the application developer, it requires fully
> researching the changes on the database side and recognising what
> work might have to be done in the app code to make it work
> properly. For the component developer, it's doubly tricky,
> especially so when one has had a suite that was extremely stable

with

> the older (and still active) v.1.5.
>
> >Clients / Users know nothing of IBObjects, (nor should they). All
> >they will see is an application that used to work that now has
> >problems after a routine maintenance upgrade. This will reflect

badly

> >on us.
>
> And so it should. Upgrading to a totally new version of the

database

> engine is not "routine maintenance". You shouldn't be deploying a
> major new version of the database engine without thoroughly testing
> its impact on your legacy app code and doing what it takes to make

it

> work correctly.
>
> >The only way to avoid these client problems will be to revisit
> >all old test scripts from scratch, adding to the admin overhead and
> >associated costs. There is also no telling what impact there may be
> >on user support documentation.
>
> Then don't upgrade to 2.0. Stick with 1.5 and IBO 4.6Aa and give
> yourself time to do the redevelopment necessary.
>
> >It is a problem for us and we will monitor the situation before
> >making a final decision.
> >
> >I would welcome any comments or assurances in this area.
>
> I don't think there are any assurances other than those you can

give

> yourself by always aiming to "code complete". Bending SQL to save

a

> bit of typing is OK only as long as you can get away with it: it's
> going to bite you eventually. If you want to stick with the tricks
> then don't upgrade to a version that no longer tolerates them.
>
> You'll never get away with treating a major db engine upgrade as
> "routine maintenance". A new release is always going to change
> things. The way the db engine market is now, a new release that
> doesn't do something radical isn't considered remarkable at all.
>
> Helen
>

Helen

Thanks for the background. Can we assume that users such as us, who
have no legacy IBObjects code prior to v4.5 should have no problems
in that we should not have written any 'bad habits' into our
evaluation code? When 4.7 is stable and we can migrate to Firebird
2.0, assuming our existing code does not impact on the additional /
modified Firebird functionality, will our 4.5 code function unchanged?

As an aside, I was speaking from a client perspective when I spoke of
maintenance releases. No matter how extensive an upgrade, clients
only see a maintenance release - an annoyance on any scale - software
is only a tool to support a business after all.

George