| Subject | Re: [IBO] New To Queries |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-01-02T05:11:11Z |
At 03:26 PM 2/01/2009, you wrote:
The "Post" concept comes from Paradox, which doesn't have transactions. In Pdx you would call Post to - literally - post changes from the local memory image of the data to the physical table on the disk.
For Fb/IB, Post is used to achieve the first phase of a DML operation on a record in a table. It causes a DML statement to be submitted concerning the record whose keys are in the current record buffer of your dataset. At the server side, a new version of the record is created that is known only to your transaction.
Each Post call performs such an operation, creating one or many new versions of records in your transaction's "space". If the transaction is COMMITTED, all things being equal your new record versions will be made the "latest committed versions" of those records, visible to other transactions.
The Autocommit setting was Borland's idea to make unskilled Paradox developers feel as though they were working with Paradox when they were actually working with IB, Oracle or whatever. The idea was to dumb the whole thing down so developers could think it was OK to write apps for transactional databases without needing to understand multi-user concurrency issues. In an Autocommit transaction, each DML statement gets committed immediately Post is called.
Autocommit can have its uses but, in the main, it prevents you from designing an effective task-driven workflow. If you want to use it, set Autocommit true in your transaction object. If you're using a TIBODatabase, set it there, as that component is a connection and single-transaction rolled into one.
CommitAction *is* an IBO thing - it determines what kind of behaviour you want in the UI of a live dataset after changes have been committed. Use the IBO Help - trace back through the green Hierarchy links - you'll get the deepest level of help at the base class, in most cases. Link through to TIB_CommitAction to see which actions are available.
Helen
>I am moving from TIBOTables to TIBOQueries. Using TIBOTables, thereNo, you're a bit confused here I think. The behaviour you're talking about is AutoCommit and it has nothing to do with table vs query components. It is a property of the transaction.
>is apparently some work done behind the scenes after a POST is
>performed and apparently this work is up to me when using TIBOQueries.
>
>Is there documentation anywhere that I can use to determine what I
>need to do when using TIBOQueries? The action I want to happen is to,
>following a POST, have the updates immediately applied to the database.
The "Post" concept comes from Paradox, which doesn't have transactions. In Pdx you would call Post to - literally - post changes from the local memory image of the data to the physical table on the disk.
For Fb/IB, Post is used to achieve the first phase of a DML operation on a record in a table. It causes a DML statement to be submitted concerning the record whose keys are in the current record buffer of your dataset. At the server side, a new version of the record is created that is known only to your transaction.
Each Post call performs such an operation, creating one or many new versions of records in your transaction's "space". If the transaction is COMMITTED, all things being equal your new record versions will be made the "latest committed versions" of those records, visible to other transactions.
The Autocommit setting was Borland's idea to make unskilled Paradox developers feel as though they were working with Paradox when they were actually working with IB, Oracle or whatever. The idea was to dumb the whole thing down so developers could think it was OK to write apps for transactional databases without needing to understand multi-user concurrency issues. In an Autocommit transaction, each DML statement gets committed immediately Post is called.
Autocommit can have its uses but, in the main, it prevents you from designing an effective task-driven workflow. If you want to use it, set Autocommit true in your transaction object. If you're using a TIBODatabase, set it there, as that component is a connection and single-transaction rolled into one.
>I have located APPLYUPDATES, COMMITUPDATES, and COMMITACTION, but theAPPLYUPDATES and COMMITUPDATES are methods of cached datasets, another Borland notion. If you cache the dataset, you override the Autocommit behaviour. ApplyUpdates is a statement-level method that is equivalent to Post for a live dataset; CommitUpdates is a transaction-level method that commits the applied updates for the whole transaction. When using IBO you really have no need to bother with caching datasets as it has a lot of built-in behaviour that makes such clumsiness unnecessary. However, it is available in the TIBO classes if you want it. Documentation for those inherited methods is in the Delphi VCL help.
>help file lacks documentation on their purposes and when they are to
>be used and why.
CommitAction *is* an IBO thing - it determines what kind of behaviour you want in the UI of a live dataset after changes have been committed. Use the IBO Help - trace back through the green Hierarchy links - you'll get the deepest level of help at the base class, in most cases. Link through to TIB_CommitAction to see which actions are available.
Helen