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 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.