>>>Hi Naomi,
>>>
>>>We took a more simplistic approach; we attach a dataObj to the biz obj. Upon instantiation of bizobj, the bizObj.dataObj is populated with initial data values. Our base class biz object has a method that compares current bizobj prop values to its attached dataObj prop values, thus detecting changes. Thus, we are not relying on either the presentation or the data layer to detect changes, which IMO, should be strictly a function of the biz layer.
>>>However, we are still in the development phase, though this seems to be working well so far.
>>>I too would like to hear more about other's approach/comments to this issue.
>>>
>>>Sorin
>>>
>>
>>That also sounds like a good idea and I was thinking about it myself, but you, of course, realize that it limits you to one record change in a time. Otherwise the code will become hairy, like my colleague likes to say <g>
>>
>
>If each biz obj has its own dataObj, then it wouldn't be a problem, unless one biz obj is populated from multiple data records, which is not our case.
>

No, I mean one record from a table in a time. How can you handle multiple records change using your approach?

In our case the biz objects usually handle changes from one table, but they can handle multiple records changes by using GetNextModified approach...

>>Also, I assume, your Save button is always enabled. In our implementation using MereMortals framework it is always enabled.
>
>The Save button is a different story. We handle that at the form/presentaion level, comparing current controls values with their initial values saved by the form class. However, you're right; our Save button is always enabled when in editing mode.