My question is this, when exactly do I know a transactional save has been successful?



The code below is from the documentation for illustration purposes.



Lets say that the BO me.customers had records added that were imported from an XML file. Once I know that information is safely saved off to my SQL server I want to dispose of/archive the XML source.



Where in the code below would you actually be 100% sure the values were saved successfully enough to delete the file?



Thank you.



Public Sub SaveAllOnTransaction()

'-- Add a try around the transaction processing

' This enables the process to call TransactionRollback()

' if anything bad happens during the transaction process.

Try

'-- Start the transaction

BusinessLayer.TransactionBegin(Data.IsolationLevel.ReadCommitted)



'-- Save the business objects on the transaction

Me.Customers.Save(True)

Me.Orders.Save(True)

Me.OrderItems.Save(True)



'-- When business objects are saved on the transaction, the

' pending changes to their internal DataTables are NOT saved

' until TransactionEnd() is called...

'-- Call transaction end to commit the transaction queries and

' accept the pending changes on all of the business objects

' that participated in the transaction.

BusinessLayer.TransactionEnd()



Catch ex As Exception

'-- If an exception occurs during the saving of the records, then

' abort the transaction.

BusinessLayer.TransactionRollback()

End Try

End Sub


Keith Chisarik

Also, is a transaction overkill on a save to a single BO?



If yes, the same question applies, when/how exactly do I KNOW that BO.SAVE() was successfully written to the SQL Server?



Thanks.

Keith Chisarik

Using a transaction for a single BO is not necessarily overkill...it just depends on what youa re attempting to accomplish.  So this is just really up to you.

As for knowing when the save has been successful, this too is up to you   If you have not received any errors, broken rules, exceptions, etc.  then it would more than likely be a good save and the TransactionCommit would be ready to be called.  That is the point of a transaction, you can place save logic while it is saving and if something happens, be it an error or just some broken logic, you can issue the TransactionRollback.  Does this make sense.  Knowing whether you are ready to call the TransactionCommit is up to you to know.  If you have not received any errors, in most cases, it would be safe to call the TransactionCommit.  Make sense?

Yes, is there a return value to TransactionCommit? I didnt see one defined using the Object Browser.



In VFP I got a return value on by buffered table when I issued a commit, when I got a .T., I knew to feel all warm and fuzzy about my data save. I guess I am looking for that same thing here.

Keith Chisarik

Well, all business objects return a success state.  For example:

If MyBO.Save() = Success Then
     TransactionCommit()
ENd If

And as for the one table question.  The answer is not necessarily.  Read the post I added prior to this one. 

Perfect, thanks!





Keith Chisarik

Good deal

It is possible for the TransactionCommit() to throw an exception, so if you put your code after the TransactionCommit(), then you can be sure that it was committed successfully, because if the TransactionCommit fails, then it will throw an exception (which is why you have the TransactionRollback() in the catch of the try/catch structure).  Also, if you put your TransactionCommit() in an If test like that other sample, then make sure you put the TransactionRollback() in the Else of the test in case the TransactionCommit() is never called, otherwise the database might keep the table locked.