Hello,
A while back I posted this thread, which describes my problem pretty thoroughly, but I'll do it again as I'm kinda running out of ideas on how to fix it.
http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=1068432&SiteID=1
I have a view order page which can show a customer their order. This page uses the viewstate to get the order information (from commerce server) on first page load and store the OrderGroup class (could be purchase order or basket) in viewstate, modifying it over time and allowing the user to commit all changes when the update button is pressed. This works fine in all cases for baskets, but when the order is in the purchase order state, I attempt to change the status of a line item and when the save method is called, I get an optimisticLockException telling me that the purchase order has been modified in storage before I attempted the save.
Now, I can believe that in a production environment this could be the case, especially since I am storing the order in viewstate, but as of now..the app is in development and NOONE besides me is testing, so how could the row be modified in the DB before I try to save is beyond me. Can anyone shed some light on this problem as it's been driving me nuts now for about 2 weeks :)
Thanks,
Dave
still having an issue trying to do a PurchaseOrder.Save()
Sweeps78
Hi Dave,
Another approach is to leave the PurchaseOrder as a per-request item and recall it from the database on each postback as needed:
public PurchaseOrder PurchaseOrder
{
get
{
if (this.purchaseOrder == null)
{
// get PO here
}
return this.purchaseOrder;
}
}
It's probably a better approach because you can never ensure that it hasn't changed in the database between postbacks (while most occur within seconds, there is nothing preventing a postback to happen hours after an initial request). In addition it will keep your ViewState from blowing up (this problem is the bain of my existance at times).
Cheers,
Colin
Ģ&#174&#59;€ğ&#167&#59;QĻ
Ok, I think I found the problem. Two properties of the PurchaseOrder class that determine whether SPD_ORD or SPE_ORD (SPE_ORD, it appears, has the sole purpose of selecting -101 to cause an optimisticLockException, not sure why it was done that way), these two properties are SavedToStorage and LastModifiedAtLoad, both of which are decorated with NonSerialized attributes. Thus on a postback, the object loses any clue it has as to when it was last loaded from the database and just starts thowing exceptions. I'm not really thrilled to find out that I have to save each line item change to the database individually rather than aggregating them and making one single save call, but I'll have to build around it I guess.
Thanks for the help Colin, and to Reflector for as always clearing the convoluted. :)
--Dave
ZopoStyle
I don't have an answer for you, but as a next step can you try saving it right after retrieving it (that is, within the same request thread/round trip)
Have you setup any tracing code to ensure that you aren't retrieving it multiple times
Cheers,
Colin
samithad
Colin,
Yes, I have the Orders.GetPurchaseOrder() function bottlenecked to one function that any other retrieval function calls to get data, and on that particular page, I watch as on the first load the data is retrieved and stored in viewstate. I then hit a button that sends the OrderGroup from the viewstate into a business function that changes it's state and then attempts a save, no further retrieval takes place.. it should be the same object. but it fails.. I was using TransactionScope() in my business function and initially thought that was causing my problems, but with that commented out I had the same effect. When I save immediately after loading it the save does indeed work, but I guess I'm wondering what property the internal save is checking to determine whether the database date is later than the date of last load for the entity because when I check the LastModified property of the line item just before the save() call, it's definitely later than the LastModified date in the database for both LineItem, OrderForm and PurchaseOrder records, and thus should not throw this error.
Thanks,
Dave