Subject | Re: [IBO] Auditable series and transactions |
---|---|
Author | Mark Pickersgill |
Post date | 2004-06-14T06:12:07Z |
Monday, 14 June 2004, 4:06 PM
Hi Helen,
Thanks for the insight...it's always useful to have some insight on
how the people in the know do things!
I took your advice and removed the <Default> transaction from the
connection object and explicitly linked a transaction to the
TIB_Query components being used...but it still doesn't seem to
rollback the work done by the trigger :(.
I'm going to try and replicate the process in a separate app and
see how that goes.
*sigh*...'tis never easy :P
Mark
HB> Agreed, the help is confusing...but, based on my own experience, the
HB> <Default> internal transaction created for the connection if you don't use
HB> your own transaction object is NOT the same as the <Default> transaction
HB> created for datasets if you don't bind them to a specific transaction
HB> object. I really hate to "dumb-down" my applications with default
HB> transactions. On this basis, I always do this:
HB> 1. Create transaction objects in terms with the statement objects in
HB> mind. Typically, I have two ReadCommitted ones: one for what I call
HB> "hit-and-run" jobs and one for the interactive task as a whole.
HB> 2. Then I hook the connection object's DefaultTransaction to the
HB> transaction that I want to be doing this "main task".
HB> 3. If I've got reports in the app, I'll usually have another transaction
HB> sleeping in the wings in Concurrency isolation: the only time it's ever in
HB> Started state is when the report is actually running.
HB> What are "hit-and-run" jobs, I hear you ask. Well, at FormCreate, when I'm
HB> filling stringlists with database-originated stuff, I'll use this
HB> transaction. I'll have methods in the app to refresh these objects which,
HB> again, use this transaction. It is *always* hard-committed as soon as I've
HB> got what I want. I commit the other transaction before I start this
HB> one; and refresh the other datasets after it's finished.
HB> I'll also use this transaction for any quick singleton queries and executes
HB> that I want to do outside the context of the datasets. Hard-commit
HB> immediately the work is done.
HB> The ReportTrans I commit immediately the report finishes because there's no
HB> reason not to and it's a bit easy to leave those darned concurrency
HB> transactions around, hanging onto resources that aren't used any further.
HB> Helen
Hi Helen,
Thanks for the insight...it's always useful to have some insight on
how the people in the know do things!
I took your advice and removed the <Default> transaction from the
connection object and explicitly linked a transaction to the
TIB_Query components being used...but it still doesn't seem to
rollback the work done by the trigger :(.
I'm going to try and replicate the process in a separate app and
see how that goes.
*sigh*...'tis never easy :P
Mark
HB> Agreed, the help is confusing...but, based on my own experience, the
HB> <Default> internal transaction created for the connection if you don't use
HB> your own transaction object is NOT the same as the <Default> transaction
HB> created for datasets if you don't bind them to a specific transaction
HB> object. I really hate to "dumb-down" my applications with default
HB> transactions. On this basis, I always do this:
HB> 1. Create transaction objects in terms with the statement objects in
HB> mind. Typically, I have two ReadCommitted ones: one for what I call
HB> "hit-and-run" jobs and one for the interactive task as a whole.
HB> 2. Then I hook the connection object's DefaultTransaction to the
HB> transaction that I want to be doing this "main task".
HB> 3. If I've got reports in the app, I'll usually have another transaction
HB> sleeping in the wings in Concurrency isolation: the only time it's ever in
HB> Started state is when the report is actually running.
HB> What are "hit-and-run" jobs, I hear you ask. Well, at FormCreate, when I'm
HB> filling stringlists with database-originated stuff, I'll use this
HB> transaction. I'll have methods in the app to refresh these objects which,
HB> again, use this transaction. It is *always* hard-committed as soon as I've
HB> got what I want. I commit the other transaction before I start this
HB> one; and refresh the other datasets after it's finished.
HB> I'll also use this transaction for any quick singleton queries and executes
HB> that I want to do outside the context of the datasets. Hard-commit
HB> immediately the work is done.
HB> The ReportTrans I commit immediately the report finishes because there's no
HB> reason not to and it's a bit easy to leave those darned concurrency
HB> transactions around, hanging onto resources that aren't used any further.
HB> Helen