Hello.
I am opening a recordset using ADO 2.6 in a program written in VB6 Service Pack 5 on Windows XP Professional SP2. The database I'm using is Oracle 9i.
I open the recordset like this:
This returns data which is then put into a Dictionary object - each field in the recordset goes into an item in the Dictionary object.
This Dictionary object is passed to a procedure which performs some calculations on it, and the Dictionary object is returned. Then it is looped through and its values are then assigned to the appropriate fields in the recordset object.
After the loop, I do oRSItems.Update. Sometimes this doesn't generate an error, but other times it produces this error:
An error has occurred in OraOLEDB.
Error number: -2147467259
ROW-00014: Cannot update row as the data in the database has changed.
Why is this error occurring and what can I do about it? I've tried multiple combinations of lock types, cursor types, and cursor locations and have got nowhere.
Thank you
Peter Etherington
I am opening a recordset using ADO 2.6 in a program written in VB6 Service Pack 5 on Windows XP Professional SP2. The database I'm using is Oracle 9i.
I open the recordset like this:
Code:
oRSItems.Open sSQL, Globals.adoConnection, adOpenKeyset, adLockPessimistic, adCmdText
This returns data which is then put into a Dictionary object - each field in the recordset goes into an item in the Dictionary object.
This Dictionary object is passed to a procedure which performs some calculations on it, and the Dictionary object is returned. Then it is looped through and its values are then assigned to the appropriate fields in the recordset object.
After the loop, I do oRSItems.Update. Sometimes this doesn't generate an error, but other times it produces this error:
An error has occurred in OraOLEDB.
Error number: -2147467259
ROW-00014: Cannot update row as the data in the database has changed.
Why is this error occurring and what can I do about it? I've tried multiple combinations of lock types, cursor types, and cursor locations and have got nowhere.
Thank you
Peter Etherington