GetServerValuesOnConcurrencyException updated values are stored where?


GetServerValuesOnConcurrencyException updated values are stored where?...
Author
Message
Rob Toyias
Rob Toyias
StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)
Group: Forum Members
Posts: 31, Visits: 179
Hi all,

I have a question about GetServerValuesOnConcurrencyException.  Where is the data stored that is returned by this setting?  I can see the select statement being fired (when I mudge the data to setoff the Concurrency Exception) , but I'm not seeing the 'new' values.  Are they supposed to overwrite the current values in the BO, or are they stored somewhere else for comparison?

Thanks

StrataFrame Team
S
StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)
Group: StrataFrame Developers
Posts: 3K, Visits: 2.5K
That property is only used when the CollisionNotificationType is set to ThrowException.  If it's set to RaiseEvent, then the values are always retrieved. 

On RaiseEvent, the retrieved values are compared to the local values and the RowCollision/FieldCollision objects are constructed and provided through the ConcurrencyException event of the business object.

On ThrowException, the retrieved DataRow is placed in a save error object which is placed within the SaveErrors collection of the exception object that is thrown.  If you set the GetServerRow property to false, the row is not retrieved and the value in the save error is null.

Rob Toyias
Rob Toyias
StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)StrataFrame Beginner (37 reputation)
Group: Forum Members
Posts: 31, Visits: 179
Ben,



Thanks for the great info!



I'm seeing what I think is strange behavior then when I set CollisionNotificationType to RaiseEvent.



Stepping through the code (after I've altered data to cause a concurrency error) I get to bo.Save(). The Concurrency Event is raised but then the code exits and no error is thrown. I'd expect it to continue.



If I set it to throw exception then an exception is thrown as expected.



So should the code be exiting like I described on RaiseEvent?



Thanks!
StrataFrame Team
S
StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)StrataFrame Developer (4.4K reputation)
Group: StrataFrame Developers
Posts: 3K, Visits: 2.5K
The RaiseEvent doesn't exit the Save() when the exception is encountered.  It's designed for you to show some UI to the end-user while in the event handler.  After the event handler exits (and you're still in the middle of the Save()), the data layer will attempt to re-save the row with the selected changes (if the e.ResaveRow property is set to True). 

So, that behavior is by design... the RaiseEvent option is designed to allow you to make a choice and re-save the record without having to call Save() again; it just does it inline.

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