Subject | Re: [IBO] Cursor doesn't see value |
---|---|
Author | Helen Borrie |
Post date | 2004-03-17T21:35:55Z |
At 05:30 PM 17/03/2004 +0000, you wrote:
want to use the default transaction. But around the TDataset stuff I don't
trust the dataset not to create its own transaction under some conditions
(as TDataset does). That's not something I ever want to leave to chance so
I use explicit transactions always.
When I have more than one transaction in a session, I prefer to drop a
transaction object onto the DM for each transaction object that the app is
going to use. I explicitly set one as the DefaultTransaction in the
connection object. Then you are always sure (in your code) what you are
testing and committing and where your exceptions are coming from.
Pay attention to the isolation level and committing properties of each
transaction. Don't use tiConcurrency or CommitRetaining on something you
are building for batch execution.
Using a TIBOTable for a batch update sounds like an unhealthy legacy from
desktop days to me; it sounds topsy-turvey that you are running a batch
transaction off a table and an interface off a cursor...
Helen
> >>> Why are you leaving the ib_transaction property blank?As a minimum, select the <default> transaction for any datasets that you
>
>In my application, I have 2 situations where data is manipulated. I
>have users entering data and I have a batch process that runs
>periodially to perform some updates. The batch process is controlled
>by a transaction. For all of the data entriy items I've left the
>transaction blank. How should I handle this?
want to use the default transaction. But around the TDataset stuff I don't
trust the dataset not to create its own transaction under some conditions
(as TDataset does). That's not something I ever want to leave to chance so
I use explicit transactions always.
When I have more than one transaction in a session, I prefer to drop a
transaction object onto the DM for each transaction object that the app is
going to use. I explicitly set one as the DefaultTransaction in the
connection object. Then you are always sure (in your code) what you are
testing and committing and where your exceptions are coming from.
Pay attention to the isolation level and committing properties of each
transaction. Don't use tiConcurrency or CommitRetaining on something you
are building for batch execution.
Using a TIBOTable for a batch update sounds like an unhealthy legacy from
desktop days to me; it sounds topsy-turvey that you are running a batch
transaction off a table and an interface off a cursor...
Helen