| Subject | Re: [IBO] Auditable series and transactions |
|---|---|
| Author | Helen Borrie |
| Post date | 2004-06-14T05:41:09Z |
At 02:54 PM 14/06/2004 +1000, you wrote:
<Default> internal transaction created for the connection if you don't use
your own transaction object is NOT the same as the <Default> transaction
created for datasets if you don't bind them to a specific transaction
object. I really hate to "dumb-down" my applications with default
transactions. On this basis, I always do this:
1. Create transaction objects in terms with the statement objects in
mind. Typically, I have two ReadCommitted ones: one for what I call
"hit-and-run" jobs and one for the interactive task as a whole.
2. Then I hook the connection object's DefaultTransaction to the
transaction that I want to be doing this "main task".
3. If I've got reports in the app, I'll usually have another transaction
sleeping in the wings in Concurrency isolation: the only time it's ever in
Started state is when the report is actually running.
What are "hit-and-run" jobs, I hear you ask. Well, at FormCreate, when I'm
filling stringlists with database-originated stuff, I'll use this
transaction. I'll have methods in the app to refresh these objects which,
again, use this transaction. It is *always* hard-committed as soon as I've
got what I want. I commit the other transaction before I start this
one; and refresh the other datasets after it's finished.
I'll also use this transaction for any quick singleton queries and executes
that I want to do outside the context of the datasets. Hard-commit
immediately the work is done.
The ReportTrans I commit immediately the report finishes because there's no
reason not to and it's a bit easy to leave those darned concurrency
transactions around, hanging onto resources that aren't used any further.
Helen
>Monday, 14 June 2004, 2:33 PMAgreed, the help is confusing...but, based on my own experience, the
>Hi Helen,
>
>Thank you for your reply.
>
>HB> My guess is that the Post is independently posting and committing the work
>HB> in a different (internally-generated, default) transaction. Set the
>HB> ib_transaction property of the query to the actual transaction that you
>HB> want it to be in, not <Default>.
>
>Is it typical to not set the DefaultTransaction of the TIB_Connection
>if you're after explicit transaction handling (which I use - or at
>least thought I was using)?
>
>Does just setting the DefaultTransaction actually cause IBO to
>generate a new transaction when it needs to? (there's not much info
>in the on-line help for this property :(
<Default> internal transaction created for the connection if you don't use
your own transaction object is NOT the same as the <Default> transaction
created for datasets if you don't bind them to a specific transaction
object. I really hate to "dumb-down" my applications with default
transactions. On this basis, I always do this:
1. Create transaction objects in terms with the statement objects in
mind. Typically, I have two ReadCommitted ones: one for what I call
"hit-and-run" jobs and one for the interactive task as a whole.
2. Then I hook the connection object's DefaultTransaction to the
transaction that I want to be doing this "main task".
3. If I've got reports in the app, I'll usually have another transaction
sleeping in the wings in Concurrency isolation: the only time it's ever in
Started state is when the report is actually running.
What are "hit-and-run" jobs, I hear you ask. Well, at FormCreate, when I'm
filling stringlists with database-originated stuff, I'll use this
transaction. I'll have methods in the app to refresh these objects which,
again, use this transaction. It is *always* hard-committed as soon as I've
got what I want. I commit the other transaction before I start this
one; and refresh the other datasets after it's finished.
I'll also use this transaction for any quick singleton queries and executes
that I want to do outside the context of the datasets. Hard-commit
immediately the work is done.
The ReportTrans I commit immediately the report finishes because there's no
reason not to and it's a bit easy to leave those darned concurrency
transactions around, hanging onto resources that aren't used any further.
Helen