| Subject | Re: [IBO] New User: converting from Pdox do IB/IBO |
|---|---|
| Author | Helen Borrie |
| Post date | 2004-03-17T15:58:52Z |
At 04:18 PM 17/03/2004 +0100, you wrote:
have it work decently. Paradox and Firebird are just completely different.
What IBO *does* sell itself as, is the easiest route to get from the BDE to
a proper connectivity interface for IB/Fb. You're confusing the BDE with
Paradox.
Porsche into a tricycle!!). IBO is *not* designed to make IB/Fb feel like
Paradox and it never says that it is. It would defeat its own purpose if
it tried to do that. The transition that IBO performs well is to get you
from IB/Fb + the BDE to IB/Fb minus the BDE. Transforming your database
from Paradox to Firebird is a whole different can of worms.
In fact, if you are doing the transition from Paradox to Firebird at the
same time as you are doing the transition from the BDE to IBO, you have
more than double the learning curve. The first thing you have to shake off
is the "table" notion. Fb/IB are all about SQL, abstract, normalized
relations, server-based computing, thin clients, small, fast packages of
data on demand...everything that Paradox isn't.
entire contents of a table in memory. With client/server databases, you
don't. Your application code is all about queries - targeting data with
WHERE clauses, linking relations with joins. delegating searches and
operations to the server. If you need the Paradox architecture, then give
up on client/server. They are not compatible. And there is no "PdxObjects".
techniques. There is no escaping that.
Helen
>Hi,No. In fact, there is no way to make a Paradox app into a Firebird app and
>
>I feel I want to jump in here ;-)
>
>Everything you say is true, but IBObject is sold as the easiest solution to
>change from Paradox to Firebird.
have it work decently. Paradox and Firebird are just completely different.
What IBO *does* sell itself as, is the easiest route to get from the BDE to
a proper connectivity interface for IB/Fb. You're confusing the BDE with
Paradox.
>That means, I hope, that a lot of behind the scenes optimizations have beenCertainly not. You can't do magic to turn a tricycle into a Porsche (or a
>performed to present the existing application with a Paradox feel - even if
>they are TTable's, while internally the correct client/server database
>actions are performed.
Porsche into a tricycle!!). IBO is *not* designed to make IB/Fb feel like
Paradox and it never says that it is. It would defeat its own purpose if
it tried to do that. The transition that IBO performs well is to get you
from IB/Fb + the BDE to IB/Fb minus the BDE. Transforming your database
from Paradox to Firebird is a whole different can of worms.
In fact, if you are doing the transition from Paradox to Firebird at the
same time as you are doing the transition from the BDE to IBO, you have
more than double the learning curve. The first thing you have to shake off
is the "table" notion. Fb/IB are all about SQL, abstract, normalized
relations, server-based computing, thin clients, small, fast packages of
data on demand...everything that Paradox isn't.
>So a FindKey should be quick no matter what. No ? If not, we might as wellFindKey is a desktop database technique. It presupposes that you have the
>not use IBObjects.
entire contents of a table in memory. With client/server databases, you
don't. Your application code is all about queries - targeting data with
WHERE clauses, linking relations with joins. delegating searches and
operations to the server. If you need the Paradox architecture, then give
up on client/server. They are not compatible. And there is no "PdxObjects".
>That does not mean you are incorrect as the difference between C/S andSorry, Erik, no magic medicine. Different architecture, different
>Paradox of course.
techniques. There is no escaping that.
Helen