| Subject | Re: [IBO] not post transactions until requested |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-12-18T22:05:16Z |
At 01:27 AM 19/12/2008, you wrote:
It's important to understand that you don't POST transactions. You "post" statements, when you execute them. "Post" is a Delphi concept that, for Fb and IB, equates to "successfully executing a DML statement". You post statements, you commit *transactions*. AutoCommit is another client-side concept. What it means is "successfully execute a single DML statement and immediately commit the transaction".
When you also use CommitRetaining to perform the commit, you can be relieved of the need to think about transactions at all. It *is* a server-side facility, that Borland invented so that Paradox and Access programmers could make the transition to client/server systems without having to exercise their brains. In reality, CommitRetaining, though it has its uses for dataset-based operations, is a killer for garbage collection. By all means use it in *appropriate* conditions (of which a self-contained DML operation is not one!) but ensure that the program flow imposes a hard COMMIT call at regular intervals.
You can fix your immediate problem (and others) by using an explicit TIBOTransaction *instead* of the default transaction. Create the transaction with the proper attributes for the control you want to exercise, and assign it to the the DefaultTransaction property of your IBODatabase *from the outset*. You want Autocommit to be False; you want to use StartTransaction before you execute your DML statements and call Commit only when your Commit button is clicked.
Always think out the workflow *at task level* and wrap each task in its own distinct start...commit package. If you're not used to checking the state of a transaction at the outset of a task, then your time has now come. ;-)
Helen
>I use a TIBODatabase for my connection and use the default transaction.It is not COMMIT RETAINING that is the up-front problem here, but that you are using AutoCommit. Welcome to a world where the inherited BDE model doesn't fit with proper usage of a client/server database system like Fb or InterBase.
>
>I create TIB_DSQL objeects and execute the SQL to update values in a
>table. But I want to not post the transactions until the user presses
>'Save' (where I call .commit). Right now I see in the monitor log that
>COMMIT RETAINING is automatically sent to the server
>
>Can I make the server wait until I explicitly call Commit?
It's important to understand that you don't POST transactions. You "post" statements, when you execute them. "Post" is a Delphi concept that, for Fb and IB, equates to "successfully executing a DML statement". You post statements, you commit *transactions*. AutoCommit is another client-side concept. What it means is "successfully execute a single DML statement and immediately commit the transaction".
When you also use CommitRetaining to perform the commit, you can be relieved of the need to think about transactions at all. It *is* a server-side facility, that Borland invented so that Paradox and Access programmers could make the transition to client/server systems without having to exercise their brains. In reality, CommitRetaining, though it has its uses for dataset-based operations, is a killer for garbage collection. By all means use it in *appropriate* conditions (of which a self-contained DML operation is not one!) but ensure that the program flow imposes a hard COMMIT call at regular intervals.
You can fix your immediate problem (and others) by using an explicit TIBOTransaction *instead* of the default transaction. Create the transaction with the proper attributes for the control you want to exercise, and assign it to the the DefaultTransaction property of your IBODatabase *from the outset*. You want Autocommit to be False; you want to use StartTransaction before you execute your DML statements and call Commit only when your Commit button is clicked.
Always think out the workflow *at task level* and wrap each task in its own distinct start...commit package. If you're not used to checking the state of a transaction at the outset of a task, then your time has now come. ;-)
Helen