Subject | Re: [IBO] C++Builder 6, IBObjects and BDE -> Firebird Migration |
---|---|
Author | Helen Borrie |
Post date | 2006-08-18T00:20:59Z |
At 11:30 PM 17/08/2006, you wrote:
(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 styles
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, etc.)
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 good
indexes and has already understood *why* Paradox-style client methods
are performance killers for client/server.
The 2(a) style can be disappointing, especially if the developer made
the decision to dump the BDE and convert to IBO, in the belief that
the BDE is entirely responsible for his poorly-performing IB application.
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 on
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
>On the subject of BDE -> Firebird conversion, it looks like blindThat altogether depends on *what* you are converting.
>substitution of BDE components with IBO components will negate much of
>the power of Firebird and will lead to degradation of performance and
>code overkill.
(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 styles
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, etc.)
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 good
indexes and has already understood *why* Paradox-style client methods
are performance killers for client/server.
The 2(a) style can be disappointing, especially if the developer made
the decision to dump the BDE and convert to IBO, in the belief that
the BDE is entirely responsible for his poorly-performing IB application.
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 on
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