| Subject | Re: [IBO] Need help on migration from IBX to IBO |
|---|---|
| Author | Helen Borrie |
| Post date | 2004-02-09T06:05:54Z |
At 05:36 AM 9/02/2004 +0000, you wrote:
typical" projects, choosing one that doesn't have an enormous number of
data access objects in its datamodule. That way, it should be easier to
analyse the correspondences. Begin with the first exception, deal with it
and move on to the next.
BDE you have that "safety platform" in the centre, the TIBO* components.
statement of any kinds, be it direct DSQL or an EXECUTE PROCEDURE call.
IBO also has a very useful TIB_Cursor component - an unbuffered "dataset" -
very handy for row-by-row operations (if you must!!) and can also be used
as a slightly less lightweight alternative to TIB_DSQL for EXECUTE
statements. It's also great for fast loading and reloading
"point-and-shoot" selectors into non-data-aware structures for use in
things like lookup lists.
TDataset-compatible way).
backed up by regular hard commits to avoid stockpiling the garbage.
properties for three database connections; you can add more implicitly by
customising the transaction parameter block through code.
This list works best if you can present an actual problem description. "I
need to do this....I tried that but got the exception "Blah...."
Always cite the versions of database, client library, Delphi and IBO. Some
problems can be quite version-specific...
Helen
>I have seen a lot about migration from BDE to IBO, but nothingPossibly a good starting place would be to begin with one of your "most
>concerning migration from IBX to IBO.
>
>I've gone through the installation for BCB6 and now I can see the
>components added, ready to be used. However, my application consists
>of at least 25 exe's that would need to migrate.
>
>I have experimented with the Greplace tool and it worked just fine.
>However, I get zillions of errors and finally the forms can not be
>shown.
typical" projects, choosing one that doesn't have an enormous number of
data access objects in its datamodule. That way, it should be easier to
analyse the correspondences. Begin with the first exception, deal with it
and move on to the next.
>If there is a person who has gone through this in the past, I wouldIt's certainly harder to predict than a BDE conversion. At least with the
>really appreciate some guidance concerning migration from IBX to IBO.
>
>If such a move is NOT a simple one, then I would like to know, too.
BDE you have that "safety platform" in the centre, the TIBO* components.
>I use IBSQL a lot.The best equivalent to look at is TIB_DSQL. It encapsulates an executable
statement of any kinds, be it direct DSQL or an EXECUTE PROCEDURE call.
IBO also has a very useful TIB_Cursor component - an unbuffered "dataset" -
very handy for row-by-row operations (if you must!!) and can also be used
as a slightly less lightweight alternative to TIB_DSQL for EXECUTE
statements. It's also great for fast loading and reloading
"point-and-shoot" selectors into non-data-aware structures for use in
things like lookup lists.
>I do have all my transactions controlled.TIB_Transaction (or TIBOTransaction, if you are going the
TDataset-compatible way).
>Some are CommitRetaining and some are Commit.All IB transactions can be either - although CommitRetaining needs to be
backed up by regular hard commits to avoid stockpiling the garbage.
>In some programs I need a transaction that commits on two databases.No problem, TIB_Transaction can be multi-connection. You have explicit
properties for three database connections; you can add more implicitly by
customising the transaction parameter block through code.
This list works best if you can present an actual problem description. "I
need to do this....I tried that but got the exception "Blah...."
Always cite the versions of database, client library, Delphi and IBO. Some
problems can be quite version-specific...
Helen