>>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
"You don't manage people. You manage things - people you lead" Adm. Grace Hopper
Pflugerville, between a Rock and a Weird Place