I've come across some unexpected behavior when using bo.Save(true) (i.e. BO-level saving, not form-level saving)

If I have a simple saving method as follows:

void SaveProject() {
    BusinessLayer.TransactionBegin("", IsolationLevel.ReadCommitted);
    SaveUndoResult result = bo.Save(true);
    if (result == SaveUndoResult.Success) {
        BusinessLayer.TransactionCommit("");
    }
    else {
        BusinessLayer.TransactionRollback("");
    }
}

Let's suppose I call SaveProject(), but the bo fails its CheckRules.  Therefore, the save operation fails and the transaction is rolled-back, as expected.  However, the internal value of bo._IsSavedOnTransaction is set to true by bo.Save function, even though the rules checked fail. (Note: the call to BusinessLayer.TransactionRollback does not reset the value bo._IsSavedOnTransaction to false.)

Now, if I fix the cause of the rule failure and call ProjectSave() a second time, nothing happens Why? Because the value bo._IsSavedOnTransaction is true from the first call, and bo.IsDirty (called in the bo.Save() routine) returns false.  Therefore, no save is attempted.

I don't know if this is a bug or a feature.  At least, it's unexpected behavior.

Hi Kirk,
Not sure if this will fix your issue, but it is always good to use a Transaction Key value for your transactions, so try your code adding a TransactionKey parameter to the following methods:

BO.Save(True, "MyTransactionKeyValue")
BusinessLayer.TransactionCommit("","MyTransactionKeyValue")
BusinessLayer.TransactionRollback("","MyTransactionKeyValue").

Edhy Rijo

I'm having a similar issue. I hadn't run into this before since I haven't made heavy use of transactions. But now I have two objects on a form that I need to keep in sync so I wrapped the save by form in a transaction. Everything is fine, unless the transaction fails and is rolled back. In my case the error was a foreign key constraint. Once the the transaction is rolled back the IsDirty state on one of my objects is complety messed up and the only way out is to refill the object.

If I remove the transaction for the save it will still fail but the IsDirty state is correct. I haven't looked through the SF code yet but it sounds like it might be related to the following post. Did anyone ever verify if this is an issue? http://forum.strataframe.net/Topic29628.aspx?Keywords=IsDirty

-Larry

After taking a look at the BusinessLayer code I think I understand what it going on. Transaction.Rollback only rolls back transactions at the database level. When you have multiple business objects in a transaction, objects that have been saved but not committed prior to an exception being thrown are not rolled back leaving the SavedOnTransactionFlags set. Normally business rules should prevent the transaction from failing in the first place, but if it does the only way I’ve  found to recover is to create a new instance of the objects that were save but not committed and refill them.  Is there any other way to reset an object that has been saved but not committed without creating a new instance?

Hi Larry,
I have not look at the source code, but if the transaction fails and in your case, because a foreign key was not assigned, the End User would not have a way to recover from that issue.  If in fact this issue is a bug and you need to force the BO.IsDirty back to True, simply call the BO.Edit() and that should take care of the IsDirty issue.

Edhy Rijo

You're right, guys, that's a bug.  I've never run into it before because we always use the TransactionCommit() and TransactionRollback() calls within a Try/Catch.  If the TransactionCommit() throws an exception, then the TransactionRollback() is called to clean up any records that failed to insert together.

Hi Ben,
Welcome back!!!!

Thanks for the explanation, I am sure Larry will try to implement the change.  In my case I use transactions the same way you do and never hit that issue.

Edhy Rijo

Hi Ben,

Thanks for the info, I'll give it a try. There is one other little problem in the code.  When TransactionRollback, line 6241,  is called without a transaction key (default key) it is calling TransactionRollback on the DataLayer instead of BusinessLayer so it would bypass the root overload that you just modified.

-Larry

''' <summary>        
''' Rolls back the transaction that is tied to all business objects associated with the given database        
''' (All business objects that have the same database name use the same transaction.)        
''' </summary>        
Public Shared Sub TransactionRollback(ByVal DataSourceKey As String)  -->      
DataLayer.TransactionRollback(DataSourceKey, DEFAULT_TRANSACTIONKEY)        
End Sub

Good catch, Larry.

Thanks for the quick fix. I made the changes and recompiled and it works like a champ.

-Larry