| Subject | Re: [IBO] IBO vs IBX (Perfomance problem) |
|---|---|
| Author | Helen Borrie |
| Post date | 2003-03-27T14:31:17Z |
At 01:20 PM 27/03/2003 +0000, you wrote:
A service app doesn't have a GUI, so there is no point in using the
TDataset-compatible components. However, if you are devoted to the
familiarity of this architecture, you still don't need TIBOQuery. TIB_DSQL
is the one you use where you are executing statements (including EXECUTE
PROCEDURE). Use TIB_Cursor if your app needs to step through a dataset
from top to bottom. It gets you a row-by-row dataset without the overload
of being scrollable. (If you need a scrollable dataset in a
non-interactive application then there is something VERY wrong with your
design).
If you need only a single transaction in your app, use TIB_Database, or
TIBODatabase (if you must): both are descendants of TIB_Connection; and
you *can* add extra transactions if needed. Otherwise use TIB_Connection
and either its default (internal) transaction, or drop in discrete
TIB_Transactions as required. TIB_Connection + TIB_Transaction are the
conceptual equivalent of the IBX IBDatabase and IBTransaction combination -
except they have a world more capability.
You *can* link TIB_DSQL and TIB_Cursor to TIBODatabase. The "decider" for
using TIBO in preference to TIB_ is where you need to use TDatasource. The
native TIB_Datasource won't link to the VCL UI controls or third-party
stuff that needs TDatasource.
This "hybridization" is probably not relevant to your service app,
though. "Go native" for service apps. The native connectivity has some
very cool features to use idle CPU cycles.
Ask more questions about how to implement your non-interactive processing
to maximize speed. Thirteen seconds sounds like about 1000 X too slow for
50 records - unless each iteration of the process is doing one helluva lot
of stuff.
Helen
> hi all!!!Well, I'm not a guy, but...you shouldn't be using TIBOQuery!!
>
> I have a NTService with IBX... It's processing 50 record in 13
>seconds... I change this service for IBO (IBODataSet), and now
>process 50 record in 40 seconds...
> I change
> IBSSQL -> IBOQuery <---- should be IB_DSQL or IB_Cursor
> IBDataBase -> IBODataBase <--- IB_Connection
> IBTransaction -> IBOTransaction <--- IB_Transaction
> what happend this service?
> Do you have some idea?
>
>Thx guys =]
A service app doesn't have a GUI, so there is no point in using the
TDataset-compatible components. However, if you are devoted to the
familiarity of this architecture, you still don't need TIBOQuery. TIB_DSQL
is the one you use where you are executing statements (including EXECUTE
PROCEDURE). Use TIB_Cursor if your app needs to step through a dataset
from top to bottom. It gets you a row-by-row dataset without the overload
of being scrollable. (If you need a scrollable dataset in a
non-interactive application then there is something VERY wrong with your
design).
If you need only a single transaction in your app, use TIB_Database, or
TIBODatabase (if you must): both are descendants of TIB_Connection; and
you *can* add extra transactions if needed. Otherwise use TIB_Connection
and either its default (internal) transaction, or drop in discrete
TIB_Transactions as required. TIB_Connection + TIB_Transaction are the
conceptual equivalent of the IBX IBDatabase and IBTransaction combination -
except they have a world more capability.
You *can* link TIB_DSQL and TIB_Cursor to TIBODatabase. The "decider" for
using TIBO in preference to TIB_ is where you need to use TDatasource. The
native TIB_Datasource won't link to the VCL UI controls or third-party
stuff that needs TDatasource.
This "hybridization" is probably not relevant to your service app,
though. "Go native" for service apps. The native connectivity has some
very cool features to use idle CPU cycles.
Ask more questions about how to implement your non-interactive processing
to maximize speed. Thirteen seconds sounds like about 1000 X too slow for
50 records - unless each iteration of the process is doing one helluva lot
of stuff.
Helen