This doesn't sound like a PFC question, but a basic PB one. But, it
might help you to enable the PFC SQLSpy to determine the WHERE clause that
is being executed.
It sounds like the DataWindow Update Properties are not set consistently
with the way your application is behaving. Basically, when PB performs the
Update() function, it executes a SQL UPDATE statement. The DW Update
Properties specify which columns to include in the WHERE clause for that
UPDATE.
It is there to help you detect when two people are attempting to update
the same row of data. Image two people do retrieves of the same row. Some
time later, the first person updates the data. Some time after that, the
other person attempts to update the data. The WHERE clause determines which
row to update, and depending on the settings, the UPDATE statement may fail
because the row is not found. That leads to the 'row changed between
retrieve and update' message.
I'm assuming you currently have the update properties set to include all
columns.
Your options include:
1. Change the WHERE clause to include only modified columns. This way,
you will only encounter the message when two people edit the same columns in
the same row. (With all columns, you get the message even if the persons
update different columns on the same row.)
2. Change the WHERE clause to include only key columns. This way, you
will only encounter the message when the first person deletes the row that
the second person later tries to update. Note that many people think that
setting it to 'key columns' eliminates the problem--it does not.
It is also possible that embedded SQL in your code is updating the row
before the DataWindow's update function is executed. This would be the same
as if another user had updated the data.
Another possibility, less common, is that you retrieve the data, some
column(s) that are in the UPDATE WHERE clause change in the DataWindow, your
code performs a ResetUpdate(), again modifies the column(s) in the WHERE
clause and *then* the Update() function is called. After a ResetUpdate(),
PB will use the values in the DW's "Original" buffer in the WHERE clause.
Because your code changed them, they no longer match what's on the server,
which again leads to the UPDATE statement failing.
Actually, it's not common in general, but I do see it when developers
call the Update() function with no parameters, instead of Update(false,
false) and then managing the flags themselves.
Another somewhat common defective technique that leads to this is setting
a row's attributes after adding a new row, then generating a unique primary
key id, then calling resetUpdate() without writing the "blank" row to the
server. This would prevent a "do you want to save prompt" from appearing
unless the user changes something. The problem is that once the user
changes something, and the Update() function is called, PB treats it like an
UPDATE, instead of an INSERT. And since the row was never written to the
server, the UPDATE fails (even if you have the WHERE clause properties set
to key only).
More information on this can be found in the PowerBuilder online books
and training materials.
Have a nice day,
--dang
-----Original Message-----
From: Sawant Prasad [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 29, 2000 05:19
To: [EMAIL PROTECTED]
Subject: PFCSIG Datawindow Error while updating
Can u please help me.
When i am updating a datawindow i get the following error.
Datawindow Error
Row changed between retrieve and update.
Can anyone provide me the solution at the earliest.
This error is not regular. It comes rarely.
Thanking you in advance
Prasad Sawant
email - [EMAIL PROTECTED]
> [EMAIL PROTECTED] HOSTED BY IIGG, INC. FOR HELP WITH LIST SERVE COMMANDS, ADDRESS
> A MESSAGE TO [EMAIL PROTECTED] WITH THE FOLLOWING MESSAGE: help pfcsig
> SEND ALL OTHER INQUIRES TO [EMAIL PROTECTED]
