PowerBuilder and SQL Sever ‘row changed between retrieve and update’ error.

One issue I was working on was triggering ‘row changed between retrieve and update‘ error on DataWindowupdate. Code was kinda simple, just retrieve some values in DataWindow, move some values to Deleted buffer and then call update. No other data manipulations etc. Found that table had some database trigger that was fired on delete. Disabled the trigger and there error message was gone. So trigger was causing that. Trigger also was quite simple, just cursor going through deleted rows and selecting and updating few values in other tables.

Googling told me that in Microsoft SQL server, if a table has an insert, update, or delete trigger, the number of affected rows returned to the SQLNRows property of the Transaction object after an INSERT, UPDATE, or DELETE command depends on the driver. With an ADO.NET driver, the value returned is the sum of the rows affected by the command itself and the trigger. When you are connected to Microsoft SQL Server using ADO.NET or OLE DB, you can set the RecheckRows run time database parameter (introduced in PowerBuilder 10.5) to 1 to recheck how many rows of data were affected by the INSERT, UPDATE, or DELETE command itself and return that value in the SQLNRows property. Setting RecheckRows to 1 before issuing an INSERT, UPDATE, or DELETE command causes a SELECT @@ROWCOUNT command to be executed. To improve performance, you should set it only when required, and reset it to the default value of 0 after use. Example: SQLCA.DBParm=”RecheckRows=1″.

Another solution could be setting SET NOCOUNT { ON | OFF } in trigger itself. SET NOCOUNT ON stops the message that shows the count of the number of rows affected by a Transact-SQL statement or stored procedure from being returned as part of the result set. When SET NOCOUNT is ON, the count is not returned. When SET NOCOUNT is OFF, the count is returned. The @@ROWCOUNT function is updated even when SET NOCOUNT is ON. SET NOCOUNT ON prevents the sending of DONE_IN_PROC messages to the client for each statement in a stored procedure. For stored procedures that contain several statements that do not return much actual data, or for procedures that contain Transact-SQL loops, setting SET NOCOUNT to ON can provide a significant performance boost, because network traffic is greatly reduced.

As I had to make fix in PowerBuilder application, adding QLCA.DBParm=”RecheckRows=1″ before and QLCA.DBParm=”RecheckRows=0″ after Update call solved this problem.