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.

　　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

　　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.