Posted by Rom Elwell on 02-Oct-2014 09:52


  • Running 32-bit OE10.2B7 on Win7 64-bit system.
  • The attributes PREFER-DATASET and MERGE-BY-FIELD are set to their respective default values (PREFER-DATASET = FALSE, MERGE-BY-FIELD = TRUE).  
  • .NET clients passing ADO datasets to an OE AppServer for record Update/Delete (UD) processing.  The proper before-image and/or after-image data are correct (reflecting the UD operation).


  • Every time a client sends a dataset to the AppServer for UD processing, the Progress method SAVE-ROW-CHANGES returns the error: SAVE-ROW-CHANGES found <name> record with conflicting change by another user. (11913).
  • This error occurs with every UD operation, although no other client has updated the target data row in the DB Table, thus there should be no 'conflicting changes'.  Simply changing a value in a single column in a single row, or deleting a row in the associated dataset is causing SAVE-ROW-CHANGES to throw the error 11913.


  • I am asking for suggestions on how to debug this issue.  Very clearly there is a bug in our server-side logic that is causing the call to SAVE-ROW-CHANGES to believe that another user has updated the target data row.  I am familiar with the attribute ROW-STATE. Is there a similar attribute to check the field state?
  • Is there a way to trap which field(s) in the data-source are in conflict?  While we know which field(s) were updated in the buffer calling SAVE-ROW-CHANGES, it is unexpected that the associated fields in the data-source are in a conflicted state.
  • We do use the attribute TRACKING-CHANGES (set to TRUE) when we need to modify a buffer, however, this attribute is not called in the workflow for Update/Delete operations.
  • If we set the value of PREFER-DATASET to TRUE, then no error is thrown, as expected, but we are then unable to capture if another user updated a different column in the same data row (concurrency)

All Replies

Posted by mihai.pintea on 09-Oct-2014 03:14

This error could appear when before image suffer some changes and is different from the database. You could try, before doing the UD operation on server, to compare before image against database to see if some value are different. If is so this means that at server display the respective fields had been changed.

This thread is closed