Subject Re: [IBO] C++Builder 6, IBObjects and BDE -> Firebird Migration
Author George
--- In, Helen Borrie <helebor@...> wrote:
> At 11:30 PM 17/08/2006, you wrote:
> >On the subject of BDE -> Firebird conversion, it looks like blind
> >substitution of BDE components with IBO components will negate
much of
> >the power of Firebird and will lead to degradation of performance
> >code overkill.
> That altogether depends on *what* you are converting.
> (1) To some people "BDE -> Firebird conversion" means converting a
> Paradox or Access application to Firebird and IBO.
> (2) To some others, it means converting a BDE app with an Interbase
> back-end to Firebird and IBO. In this group are two distinct
> of application:
> a) IB apps that were formerly Paradox, etc. apps that were
> historically swapped out, retaining elements like TTables, looping
> structures, composite keys, index-driven searches (locate, findkey,
> b) IB apps that were developed deliberately for client/server use
> and hence already use client/server and network-friendly mechanisms
> Clearly, conversion from a 2(b) situation is the smoothest. The
> developer has already performed a proper database conversion, has a
> well-performing database structure with clean relationships and
> indexes and has already understood *why* Paradox-style client
> are performance killers for client/server.
> The 2(a) style can be disappointing, especially if the developer
> the decision to dump the BDE and convert to IBO, in the belief that
> the BDE is entirely responsible for his poorly-performing IB
> The (1) and (2a) styles take a lot more rework than many people are
> willing to accept initially. As a consultant I've walked into
> numerous situations where the developers just "don't know what they
> don't know" about client/server development. In some cases, they
> have been developing with a Firebird or IB back-end without anyone
> site having knowledge even of SQL!
> A GReplace from VCL to IBO is *not* a magic bullet that is going to
> make your Paradox-style system behave like well-designed
> client/server system. It's just one stepping stone on the learning
> curve. It's exceedingly unwise to assume that the objective is
> merely one of duplicating your Paradox database into Fb/IB and
> swapping over the components. You will spend the rest of your life
> trying to make all those Paradox-driven thingies work, while the
> light at the end of the tunnel gets more and more dim.
> Sermon over for today.
> Helen

Not a sermon but a more eloquent way of putting what I meant to say.