pdfcrowd.com open in browser PRO version Are you a developer?

Try out the HTML to PDF API

Row Changed Between Retrieve and Update

Row Changed Between Retrieve and Update
This is a common but frustrating error that can create real problems. The cause for this error is one or more
of the following:
1. A primary key for the table is not listed in the Update Properties for the DataWindow.
2. The primary key selected allows and has duplicates.
3. The Update Properties for the DataWindow are improperly set for the needs of the
application.
4. The data did actually change.
If no primary key is listed, this is usually the result of either the DataWindow being created on a table that
did not have a primary key when the DataWindow was created or the DataWindow was created and Allow
Updates was not checked and later checked.
NOTE: If at a later time, the Allow Updates is checked and you select the Table to Update, the Updateable
Columns and Key Columns MUST be selected since they are not automatically selected.
There are cases that the primary key selected is not a "true primary key" in that there can be duplicates
records for each key. In this case the error will only occur when there are actual duplicates for the selected key.
Often this error will go undetected for a long time until a duplicate value is present. This is a hard one to find
since the error will occur on the duplicate value only. This appears to be an intermitted error.
Specifying the WHERE clause for update/delete
Sometimes multiple users are accessing the same tables at the same times and in cases, they may be
actually accessing the same data at the same time. This may be a desired situation and the correct
update/delete specification will protect the data from corruption.
pdfcrowd.com open in browser PRO version Are you a developer? Try out the HTML to PDF API

Key Columns:
This is the least restrictive and will data corruption. This can only be safely used in single user environments
and in multi-user environments when the developer can be 100% sure that only one user at a time will access
the data.
The danger of this is that since the key column is the only column specified in the WHERE clause, another
user can change the data after you retrieve it and when you save, your data will over write the other users data.
The only warning you would get is if the key column changed, which is very unlikely.
Key and Updateable Columns:
This is the PowerBuilder default and provides the greatest level of granularity but may be too restrictive for
the needs of the application. The WHERE clause contains ALL the updateable columns that were selected in
the Update Properties of the DataWindow NOT just the updated (modified) columns.
This will guarantee that only one user can update a row at a time. The problem may arise when two users
retrieve the same row and each changes different data elements (i.e. one user updates the address of the
customer and another updates the middle name). The first user to save the data will be OK and the other user
update will fail.
Key and Modified Columns
This is usually a good setting for most multi-user applications. This allows for multiple users to access the
same row and both make changes to different data elements of the row.
This would prevent the problem above (i.e. one user updates the address of a customer and another
updates the middle name). With this setting, both users would be able to successfully save the data without any
negative impact on the other users data.
Correcting Changed Data


pdfcrowd.com open in browser PRO version Are you a developer? Try out the HTML to PDF API
To correct data errors caused from data changing between retrieve and update (except for duplicate keys)
the following method is an example of what can be employed:
If a row is changed, the DbError event will be triggered with a value of 3 in the argument sqldbcode and
the row number of the failure in the argument row. A message can be displayed to the user and the row
highlighted for the user to see. Allow the user the option to re-retrieve the changed row or discard it. If the user
chooses to re-retrieve the changed data, use the ReSelect() PowerBuilder function. This will re-retrieve ONLY
the row specified. This will allow the user to see the changes to the row and permit them to make any additional
changes they desire.
IMPORTANT: PowerBuilder will stop the update process upon encountering the first error. The
update process can be re-called or stopped at this error. It is usually best to continue the update
process. This will update the database with all other changes and/or mark any other error rows. If the
row that caused the error is in the Filter buffer, you must unfilter it if you want the user to correct the
problem.
Code a 1 as the return value for the DbError event, this will suppress the default PowerBuilder error box
and allow you to display your own message.