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;
CommitUpdToCach;

If you use these two methods, you can handle errors more correctly. E.g.

with TpFIBDataSet1 do
   try
     ApplyUpdToBase;
     UpdateTransaction.Commit;
     CommitUpdToCach; 
      except
      UpdateTransaction.RollBack;
      raise
 end;
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. 





		

	

				Preview text: 			

			













Prices in Euro:



235 (1 copy)

1250 (unlimited)




Volume discounts are available...


Navigation



	

		

			
			
		

	




 
			
We are a small software company with thousands of customers delivering comany wide systems including accounting, logistics, e-commerce, POS, sales etc etc. Several years ago, when we were still a very small company, we used Delphi 3 and Paradox combined with BDE. As our system (and customer base) grew I decided to switch to Delphi 5 and Interbase. Being a huge improvement over Delphi 3 and Paradox, I encountered numerous problems with IBX: memory leaks, performance issues and other problems. Borland was not to be bothered: IBX was provided "as is" and no support was avaliable. 
Not being very eager to use third party components with Delphi at first, I decided to give FIBPlus a try. At once all problems where gone: no more memory leaks and  performance was very consistent. 
But the real advantage of switching to FIBPlus came with the upgrade to D2005: after upgrading there were some problems with the new FIBPlus version. After emailing the problem I received an update within an hour! And this was at 11 pm! A few other (smaller) errors where handled in the same way. 
Our motto is: software is as good as its support. And support of Devrace is just great!
Just a little indication of our FIBPlus use: all our software runs 100% on FIBPlus. Our customers have a total of aprox. 4.800 Firebird databases in production, with a combined size of over 130TB and over 80 million transactions a day. Every
day. And FIBPlus has not failed a single transaction. Not once. There is, however, one (minor) drawback in using FIBPlus: while debugging an application which uses and invalid SQL instruction, de Delphi Debugger returns to the FIBPlus code instead of to our calling code (where the actual error comes from), thereby complicating de debug proces a little. But that is a very small price to pay for a otherwise brilliant third party solution!			 >>

Bas Jordans JorSoft Ltd
			

			

FOR CUSTOMERS
Download full versions and updates in your Personal Area