Here is the case.
EditableRootListBase is bound to a datagridview. I delete a row. The delete fails at the database due to contrainsts. The error gets displayed to user, and the row remains in the grid. No problem.
But now when I select another row, I get a datarow error again, because it is still trying to delete the initial row. I know it is the same row as I check the Id in the delete method.
So then, when I initially try deleting, I use cancel edit in the datarow exception handler. This is not working because I am still getting dataError exception.
One problem I will try is: Maybe I am throwing the wrong type of exception in the dataportal. When I catch the contraint exception, I throw an application exception. Maybe I have to throw a dataportal exception?
One more thing: When I handle the dataError:
Heath
Is this with a local or remote data portal configuration?
If local, I have a suspicion as to the cause - ERLB doesn't clone the object before saving it, and so when the failure occurs the object's state is left still changed (IsDeleted is true).
If this is the case, you may try changing the SaveItem() method in ERLB from this:
try
{
// do the save
this[index] = (T)item.Save();
}
to this:
try
{
// do the save
this[index] = ((T)((ICloneable)item.Clone())).Save();
}
In 3.0.2 I'm looking to resolve this in a more automated fashion - and actually did resolve it in Csla.Wpf.CslaDataProvider - but I forgot that the issue existed here as well. I'll need to add that change to ERLB as well.
(the real change is slightly more sophisticated, because it is potentially smart enough to not do the clone if the data portal is running in remote mode - and uses a new config setting to be that smart)
I am running locally during development.
I have tried cloning the object prior to saving, then when the delete fails, I replace the object in the binding source. Didn't work. In the end I had to clone the entire list, and then replace the datasource.
I will try changing the saveItem method. Once I switch over to running remotely, I suppose this will cause a little extra overhead, but not nearly as much as cloning the entire datasource.
Thanx
Prior to 3.0.2 switching to a remote data portal would cause
extra overhead. However, in 3.0.2 I’ve added a new config setting so you
can turn on a switch so the data portal itself will do the clone, but only when
necessary. In 3.0.2 the default is to have this option off (for backward
compatibility), but in 3.5 I intend to change the default to true - a breaking
change, but one which makes everything work much smoother in the long run.
Rocky
From: jhw
[mailto:cslanet@lhotka.net]
Sent: Monday, September 17, 2007 9:16 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] editableRootListBase delete error
I am running locally during development.
I have tried cloning the object prior to saving, then when the delete fails,
I replace the object in the binding source. Didn't work. In the end I had to
clone the entire list, and then replace the datasource.
I will try changing the saveItem method. Once I switch over to running
remotely, I suppose this will cause a little extra overhead, but not nearly as
much as cloning the entire datasource.
Thanx
Copyright (c) Marimer LLC