I'm looking for a reasonable way to deal with binding a property to a list of elements where the value in the property longer exist in the list.
Rocky posted in February some pseudo code where a Record class had a Company, Office and Department. For arguments sake let's say that an office was closed and for data integrity the system uses a deleted flag rather than actually removing the record from the system.
My question is if the current record has a reference to an office which has been closed, logically the call to OfficeList.GetList(this.Company); would return only offices which are still open. In this case the binding of the OfficeID property would fail.
I was curious as to what solutions others may have come up with.
Shane Holder
Hi,
For such issues the practise we follows is while fetching the child data, we adds a join in querry to relate the child data with master record and checks if it is deleted. To fetch deleted data as well an overload of Get method is used which ommits the check for deleted flag. This is in response of what i understood from your querry. If it is something else please revert back, i would be pleased to help you if i am capable of. :)
I guess what I am thinking is something along the lines of adding another overload to GetList which would take this.Company as a parameter and an OfficeListId. So that GetList would know that it would need to fetch the current OfficeList entry for Record, then it would need to make sure the entry was not duplicated in the list.
public class Record
{
[NonSerialized]
private OfficeList _officeList;
[Browsable(false)]
public OfficeList OfficeList
{
get
{
if (_officeList == null)
_officeList = OfficeList.GetList(this.Company, this.OfficeListId);
return _officeList;
}
}
{
get { return _OfficeListId;}
set { _OfficeListId = value;}
I have run into this issue extensively.
Basically, I add the deleted value to the list of values and allow it to bind correclty. Then I have rules which say that if the user changes the value it must be to any realy value but if they keep it to the exact same value (which was deleted), then the record will be allowed to be re-saved with other changes.
For example, say we are talking about account codes.
An existing transaction record has account code 123.
Later an Admin de-activates (not deletes) the master record for 123 (flips Status from A to D).
When a user edits the transaction record 123 is added to the list of valid accounts (even though it is de-activated).
The user can change other values in the record and leave account code as 123 and the rules take this into consideration - the original de-activated value is the only value which can be saved to the DB that has Status D. If they change the value to any acitve account, no issue at all. They just can't change it to a different de-activated account.
Hope that makes sense.
Joe
Copyright (c) Marimer LLC