>>>Why would one do this?
>>>
>>>Scenario:
>>>
>>>Data is pulled from SQL server into cursor for an individual
>>>Cursor is then buffered
>>>Cursor is updated from input form (there is no update/commit on the cursor, just replaces)
>>>SQL server is updated from cursor.
>>>Data is repulled from SQL server into cursor for the same individual
>>>
>>>We have instances where (at least) one field is not making it 'back' from SQL server and is causing issues further downstream in the process and, of course, it's only happening on occasion.
>>
>>I prefer to do all of the above except for the last step. It would be more important to buffer the cursor if it's a set of records - like the line items of an invoice - however, doing things a single way seems best to me. So even for a single record, buffer the cursor. Then you can check if any changes were made, rather than just doing a sql update - no sense incuring network traffic (or even ODBC) until you need to. In the case when the server fires a trigger that updates the record, you may need to re-pull the data...
>
>
>Again, I'm not seeing the logic of making a copy of the copy. I always thought that was why you were using a cursor in the first place and, at most, only one record is pulled back per individual person

The logic is in doing a single job the same way every time. That is something I rarely see and without it, there is a ton of custom code which can break. How goofy would it be to put up drywall using screws, gum, duct-tape instead of . The buffering is so you can determine if the user changed anything. I don't see enabling buffering as copying the record.

I also avoid macro subs as much as possible. Code like below does not suggest this was done well at all. There is not even an IN clause in the replace.

IF NOT &lcField == &lcMemVar
>> REPLACE &lcField WITH &lcMemVar
>> ENDIF