Not to belabor the point, but it is not just key fields. If the
datawindow update property says to include modified (or modifiable) columns in
the where clause, you need to be concerned about those changing as well.
----- Original Message -----
Sent: Tuesday, August 29, 2000 11:01
PM
Subject: RE: PFCSIG Datawindow Error
while updating
This problem occurs when u have retrieved a record for a given
key say for e.g. invoice_no and the invoice no. is changed by u or by some
other user prior to your save.
First of all the key fields should never be allowed to be
changed. In case u are allowing then in Rows-> Update properties change the
setting of update to 'KEY VALUES' (But this is a little slow then the other
settings).
Frankly speaking insure that the Key fields are not getting
changed.
Regards,
Rajendra Shetty
(Programmer/Analyst)
Mastek Ltd.
(CS - IIS
Dept.)
Unit 106, SDF-4,
SEEPZ,
Andheri (E),
Mumbai - 400 096.
India.
Phones : +91-22-829 0635 Ext :
1050
-----Original Message-----
From:
Daniel Coppersmith [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 29 August, 2000 8:24 AM
To: Griffith, Daniel M.; 'Sawant Prasad'; [EMAIL PROTECTED]
Subject: Re: PFCSIG Datawindow Error while updating
To add to Dan's ideas, it can also happen if you use
setItemStatus to set a
row or columns status to a new
value (i.e. notModified! or DataModified!).
Dan's SQL
Spy idea will be your best bet. If you are getting nothing but
?'s where there should be values in the SQL, turn off Binding
when you
connect to the database. It will slow
down the SQL but for testing it's
worth it.
D
----- Original Message -----
From:
Griffith, Daniel M. <[EMAIL PROTECTED]>
To:
'Sawant Prasad' <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Tuesday, August 29, 2000
7:53 AM
Subject: RE: PFCSIG Datawindow Error while
updating
> 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]
>
> [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]
