I have no idea, but it isn't needed. Buffering is a way to protect the actual DB from changes until you commit. But if you're using SQL Server and reading into cursors (or views, which essentially are the same thing), the cursor acts as a buffer.

If you then buffer the cursor, you're doing double-buffering. I can't think of any reason to do it.


>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.