Hi All,
I have a peculiar problem here and need some assistance. I have a BO with 16 properties (two of which are Lists derived from BusinessListBase. When I retrieve a particular object from the database and check the IsDirty property it is True unless I explicitly mark it as old (MarkOld()) at the end of DP_Fetch. I noticed that the TestTracker project doesn’t require this and am wondering why?
Any insight would greatly help.
Thanks,
Which version of the framework are you using? I'm not entirely sure, but if I remember right one used to have to call MarkOld() after doing a fetch.
The server dataportal's fetch (version 3.5.1) calls:
target.MarkOld();
Now, if you're setting values via properties or something after this occurs, you're going to dirty your object.
Which version of CSLA are you using?
We are using the latest and greatest 3.5.1 of the framework. Our Fetch routine looks something like:
private void DataPortal_Fetch(Criteria criteria)
{
using (SqlConnection cn = new SqlConnection(Database.DBName))
{
cn.Open();
using (SqlCommand cm = cn.CreateCommand())
{
cm.CommandType = CommandType.StoredProcedure;
cm.CommandText = "getObject";
using (SafeDataReader dr = new SafeDataReader(cm.ExecuteReader()))
{
while (dr.Read())
{
Fetch(dr);
}
}
}
}
MarkOld();
}
The Fetch routine is your standard DB to Property assignement. I added the MarkOld() at the end to make the IsDirty flag to false. If I remove this one line it is True.
Ah, you're setting properties? That's probably what you're running into... the MarkOld() call occurs before DataPortal_Fetch is called on the business object (within the server dataportal's fetch).
With managed properties, we explicitly use LoadProperty rather than SetProperty such that we don't trigger the object validation rules / property changed events. I suspect you aren't using managed properties. When I wasn't using managed properties the general practice I had taken, which I believe is how it is advised, is to assign values to your fields rather than through properties.
Hope that helps,
Chris
Hi Chris,
I am actually utilizing the LoadProperty (I probably shouldn't have used the word Set in my previous statement). I have found where the issue is but am not sure what the resolution is. As I had mentioned previously, I have two properties which which are derived from BusinessListBase. The dirty flag is switched from False to True back in the UI Code immediately after I return back and execute the following line:
If (BusinessObject.EditableListObject.Count > 0)
{
}
In the scenario I am testing, the Count property is 0. I've evaluated the BO before and after this line and it's False before and True there after.
Any ideas?
It's probably somehow getting dirtied when you're accessing EditableListObject... I wonder, if you replace the conditional with something like: ReadProperty(_editableListObjectProperty).Count do you still get the dirty-ing behavior?
If so, I guess the question is - why is it dirtying the object - I'm not sure off the top of my head!
Found two issues. The first was within the property get routine which was using SetProperty instead of LoadProperty for the child object. The second was within the grandchild object. The Child_Fetch method had one property that did not use the LoadProperty method but directly assigned the property. Once I corrected these two items, the BO is no longer dirty when it accesses the Count() property nor when it's bound to the UI.
Thanks for the help.
Copyright (c) Marimer LLC