Unexpected behavior during BO Save-on-Transaction


Author
Message
Kirk M Sherhart
Kirk M Sherhart
StrataFrame Novice (95 reputation)StrataFrame Novice (95 reputation)StrataFrame Novice (95 reputation)StrataFrame Novice (95 reputation)StrataFrame Novice (95 reputation)StrataFrame Novice (95 reputation)StrataFrame Novice (95 reputation)StrataFrame Novice (95 reputation)StrataFrame Novice (95 reputation)
Group: Forum Members
Posts: 41, Visits: 259
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 happensAngry 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.
Replies
Larry Caylor
Larry Caylor
StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)
Group: Awaiting Activation
Posts: 592, Visits: 3.7K
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

Edited 13 Years Ago by Trent L. Taylor
StrataFrame Team
S
StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)
Group: StrataFrame Developers
Posts: 3K, Visits: 2.5K
Good catch, Larry.

I'll change it to call the other overload.  Thanks.
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...





Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search