Question: What differs the TpFIBDataSet.ApplyUpdToBase method from TpFIBDataSet.ApplyUpdates?
Answer: Both methods write changes made in the dataset to the database (if the CachedUpates dataset property is set to True). These methods show different behaviour when working with the local dataset cache.
Sending record changes to the database ApplyUpdates marks the records as processed. When changes of first N records have been successfully applied and N+1 changes were not applied, the transaction cannot be rolled back (as first N records are marked as processed, recurrent ApplyUpdates calls won’t be applied to their changes).
Unlike ApplyUpdates, ApplyUpdToBase does not do any operations with the local cache. This method only sends changes to the server. If you need to mark records as processed, you can use an additional CommitUpdToCache method.
So a successful execution of ApplyUpdates is similar to the consequence of two methods:ApplyUpdToBase;
If no errors occur after this code is executed, the changes will be successfully applied to the database, committed by Commit and the local dataset cache will be marked as applied. In case any errors occur after the execution of ApplyUpdToBase, all the applied changes will be rolled back (UpdateTransaction.RollBack), and the dataset will be prepared for a new execution.
with TpFIBDataSet1 do try ApplyUpdToBase; UpdateTransaction.Commit; CommitUpdToCach; except UpdateTransaction.RollBack; raise end;
FIBPlus has taken the headache out of this project. When I got the current contract, FIBPlus was included on the work computer from the client. I quickly found it easier to use and more powerful than any other Firebird component suite I had tested. When I ran into a problem setting up a persistent calculated field, the tech support people saved the day. I would also add that I tested Zeos, IBX, DBGo, UIB, and other FBconnectors. FIBPlus outperformed all of them, and FIBPlus was run on an older machine than the others were. That was most impressive.>>