401
社区成员
发帖
与我相关
我的任务
分享Row changed between retrieve and update.为什么出错
Row changed between retrieve and update.
No changes made to database.
UPDATE h_member SET photo = 'C:\My Documents\My Pictures\q.bmp' WHERE kahao = '1111' AND name IS NULL AND birthday IS NULL AND document IS NULL AND documenthao IS NULL AND unit IS NULL AND fuct IS NULL AND tel IS NULL AND photo IS NULL AND script IS NULL AND changetime IS NULL AND lay IS NULL AND pour IS NULL AND id = 16
No changes made to database.
UPDATE h_member SET photo = 'C:\My Documents\My Pictures\q.bmp' WHERE kahao = '1111' AND name IS NULL AND birthday IS NULL AND document IS NULL AND documenthao IS NULL AND unit IS NULL AND fuct IS NULL AND tel IS NULL AND photo IS NULL AND script IS NULL AND changetime IS NULL AND lay IS NULL AND pour IS NULL AND id = 16
...全文
请发表友善的回复…
发表回复
wangsw 2002-01-15
- 打赏
- 举报
有许多原因可以引发这种情况
yubintj 2002-01-15
- 打赏
- 举报
一般的理解为在datawindow检索数据之后，后台数据已经被改变
programbcb 2002-01-15
- 打赏
- 举报
KEY MODIFICATION属性改为 USE DELETE THEN INSERT最好不用，用use update，要不然可能丢失数据的。
tanghui21 2002-01-15
- 打赏
- 举报
你的数据窗口的UPDATE条件在取出和保存之间发生了改变，在数据窗口的UPDATE属性中的WHERE CLAUSE FOR UPDATE/DELETE属性改为KEY COLUMNS
KEY MODIFICATION属性改为 USE DELETE THEN INSERT
应该没问题了
KEY MODIFICATION属性改为 USE DELETE THEN INSERT
应该没问题了
tanghui21 2002-01-15
- 打赏
- 举报
我原来遇见过这个问题 不过忘了怎么解决的了 让我找找吧
programbcb 2002-01-15
- 打赏
- 举报
一个并发的错误，假如一条记录为A,100,200
两个用户同时检索出来，然后第一个用户修改为A,100,300，然后UPDATE，并成功
第二个用户修改为A,200,200，然后UPDATE，就会出现Row Changed Between Retrieve and Update，一种办法是update属性中改为Key and Modified Columns 或Key Columns，这样可以提高事务的并发性，但是降低了数据的一致性，因为第一个用户的修改被复盖。
两个用户同时检索出来，然后第一个用户修改为A,100,300，然后UPDATE，并成功
第二个用户修改为A,200,200，然后UPDATE，就会出现Row Changed Between Retrieve and Update，一种办法是update属性中改为Key and Modified Columns 或Key Columns，这样可以提高事务的并发性，但是降低了数据的一致性，因为第一个用户的修改被复盖。
tiantianpb 2002-01-15
- 打赏
- 举报
不能为null的字段为空了
qingheping 2002-01-15
- 打赏
- 举报
如何处理错误 “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:
A primary key for the table is not listed in the Update Properties for the DataWindow.
The primary key selected allows and has duplicates.
The Update Properties for the DataWindow are improperly set for the needs of the application.
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.
tiantianpb 2002-01-15
- 打赏
- 举报
有不能为空的字段为空了
qingheping 2002-01-15
- 打赏
- 举报
如何处理错误 “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:
A primary key for the table is not listed in the Update Properties for the DataWindow.
The primary key selected allows and has duplicates.
The Update Properties for the DataWindow are improperly set for the needs of the application.
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.
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:
A primary key for the table is not listed in the Update Properties for the DataWindow.
The primary key selected allows and has duplicates.
The Update Properties for the DataWindow are improperly set for the needs of the application.
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.
liaoshangfa 2002-01-15
- 打赏
- 举报
请问h_member中的Primary Key?
