Hi all -
I have a bit of a vexing problem that I'm hoping someone out there has seen and diagnosed and fixed...
We have a remote user who is running our forms-based application off of a laptop that connects to our database via a VPN connection. She is pulling up a record and editing several fields in the record. These fields span across several business objects - a base object with several children. When she saves her edits she gets a 'successful' message, but none of the edits are saved. No errors on her end or on the logging on our end. If she goes into the record and edits ONE field and saves it, it saves fine.
We have not been successful in reproducing the problem here in-house. We can edit a hefty number of fields in the record (more than any of our users would routinely edit), save the thing, and all is happy.
I've double-check the error messaging, the transaction time-outs, the connection time-outs, etc. but I'm at a real loss to try and figure this out since we can't reproduce the problem!
Has anyone out there seen this behavior?
TIA,
Cyd
What kind of UI? And what kind of exception handling do you have around the data portal and/or Save() method call? Sometimes, especially with any async code, exceptions from Save() get swallowed by .NET unless you have explicit exception handling and logging code.
The UI is home-made Visual Studio 2008 (c#) using Infragistics Controls. I'm using a try...catch block around the save:
try
{
Cursor.Current = Cursors.WaitCursor;
mBaseObject = mBaseObject.Save();
RefreshCommonObjects();
}
catch (Csla.DataPortalException ex)
{
MessageBox.Show(ex.Message, c_SaveErr, MessageBoxButtons.OK, MessageBoxIcon.Error);
result = false;
}
finally
{
Cursor.Current = Cursors.Default;
}
Should I be doing this differently?
And thanks!
No, that looks fine. So we can be pretty confident that the data portal isn't encountering a network error, and that no exception is thrown from the server then.
So that really leaves some issue with server-side code. Are you letting CSLA handle the transactions (using the Transactional attribute) or are you doing transactions yourself?
Normally the only way CSLA would do a rollback is with an exception, and if that's the case the exception would flow back to the client. Since the client isn't seeing an exception, it seems unlikely that the server is throwing an exception?
Well, that's good to hear. I've been working with the CSLA for a few years now (btw bless you! I love it!), but that sure doesn't preclude me from doing something boneheaded!
I'm letting the CSLA handle the transactions, so I'm thinking that that's fairly safe.
The server-side is all stored procs, and very simple CRUD at that. But whenever anything is edited, a copy of the original object is inserted to a history table for audit trail and the new info is updated, so there's a lot going on. The history object is a child of the "live" object. The only thing that I can think of is some sort of transaction time-out that is rolling everything back; but as you say, I would think that that would cause an exception to come back.
I spent the better part of yesterday and today breaking the history object out into their own base/child structure and am now saving those separately (and in a separate transaction) from the "live" objects. Didn't really want to do that, and since I still can't replicate the problem I can't really prove anything with it. But I thought that that would decrease the time spent in the transactions and perhaps clear up the problem for her.
One thing I did observe yesterday is that I sent the user an email at around 12:30 MDT. She did not receive it until nearly 4:00 MDT. Of course, when she clicks the 'Save' in the app the success message came back in a reasonable amount of time (about a second). What I don't know about network packet flow could fill a book - so that may mean nothing.
I feel your pain having dealt with these sorts of problems on occasion. You tend to spend hours trying to reproduce unlikely situations to no avail.
Anyway, why don't you add some textual logging on your server side when the save begins and ends - say using log4net, then at least when the user says that the problem occurred you can at least take a look at the logs and see whether it makes sense, or they're making it all up 
Good luck!
Yeah - this kind of stuff makes me crazy! Maybe I could just score a winning Power Ball ticket tomorrow... ;-D
But thanks for the sympathy - and the suggestion. I think I'll do that. Right after I buy a couple of quick picks...
Copyright (c) Marimer LLC