>>>>We have a vertical market app, it's been going for ages and the latest version we split out the data layer by creating data object.
>>>>
>>>>Longer term the aim is to move to a SQL back end and then eventually to a .Net front, but in the mean time the data objects read VFP tables and scatters the fields into properties of the object. The UI then reads/writes to the object properties.
>>>>
>>>>We also load the fields into a second property so field 'surname' would become .surname and also .o__surname so we can see within the UI and object if the value has changes (o__) being original value.
>>>>
>>>>This has worked fine and we have been rolling out to our install base. However we have hit a snag at some sites where the .Save() on the data objects is running very slow.
>>>>
>>>>The .Save() uses aMembers, loops through all the properties, if the property name starts with .o__ it know it is a data property, it Evaluates the current value, original value and table value (other users may have changed record in table). If the value has changed it uses a replace statement to update the table.
>>>>
>>>>I am looking for advise for neater/faster ways I might accomplish the data save?
>>>
>>>I can't say I like the idea of using just a variation of property names to distinguish state. Surely it would be cleaner to maintain two copies of the object - one for the original state and one to take changes. That would also tie in better with any requirement to also check against current database state....
>>>
>>>That said, my VFP is too rusty to remember if there is a simple way of quickly checking whether all properties of two objects of the same type have equal values. If there *were* then unchanged objects would not need drilling into.....
>>
>>If you keep two (data )objects you can use compObj()
>
>Thx. I did dredge that up from my memory and updated the post.
>So do you think keeping a clone would be a better approach. Maybe even as a nested property of the modifiable object ?


Yes, I do think a clone would be faster when it comes to comparing

You could have

bizObj
      .OriginalDataObj
          .surname
          ...
      .OriginalDataObjCopy
         .surname

Then, that begs the question how Gary's bizobj gets constructed. If it is using afields - which I suppose - having seen .o__surname - it may be slow
May be faster using scatter twice

 scatter memo name bizObj.OriginalDataObj
 scatter memo name bizObj.OriginalDataObjCopy

But in any case, since the performance problems are only at a couple of sites - I suspect it will be more network related