>>>>>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?
>>>>>
>>>>>
>>>>>Gary.
>>>>
>>>>Some thoughts
>>>>
>>>>(1) amembers and eval() seem fast enough. I do not think that that would be a bottleneck - should it be then you can generate the code for each table object
>>>>
>>>>(2) What do you do when two (or more) fields have changed ? One replace statement or more than one ?
>>>>
>>>>I'd be inclined to generate the sql update statement with one or more fields to update (not a replace statement should you use that) on the fly and then execute it
>>>>
>>>>(3) Can you find the bottleneck in the .Save() method ?
>>>>
>>>>(4) update : with/endwith is about 11 % faster
>>>>

>>>>with m.obj && or m.this
>>>>    loop properties
>>>>endwith
>>>>

>>>
>>>I think I remember reading that aMembers may be slower. You can also add FOXOBJECT to the last loop.
>>
>>And how would you do that ?
>
>Good point. I thought you were looping through each property
>

>for each loProperty in this.Properties FOXOBJECT
>  ...
>next

Unless Properties is a collection/array belonging to the data object - it won't work