|
View previous topic :: View next topic
|
| Author |
Message |
dejunzhu
Active User
Joined: 08 May 2008
Posts: 390
Location: China
|
|
|
|
I found if I code COMMIT after FETCH CURSOR and before POSITIONED UPDATE CURSOR, SQLCODE -508 always occurrs when POSTIONED UPDATE CURSOR.
1. FETCH CURSOR C1
2. COMMIT
3. POSITIONE UPDATE C1 ==>SQLCODE -508 here....
Why this happens?
I have such requirement, that I should first fetch the next record and if some criteria meets, I shall issue COMMIT first before issue POSITIONED UPDATE. How should I do ?
Please kindly suggest.
Thanks very much. |
|
| Back to top |
|
 |
GuyC
Senior Member
Joined: 11 Aug 2009
Posts: 1281
Location: Belgium
|
|
|
|
why this happens? Because it is described as such in the manuals.
and it doesn't happen ALWAYS. |
|
| Back to top |
|
|
gylbharat
Active Member
.jpg)
Joined: 31 Jul 2009
Posts: 565
Location: Bangalore
|
|
|
|
-508 THE CURSOR IDENTIFIED IN THE UPDATE OR DELETE STATEMENT IS NOT POSITIONED
ON A ROW OR ROWSET THAT CAN BE UPDATED OR DELETED
Explanation: The application program attempted to execute an UPDATE or DELETE WHERE CURRENT OF cursor
statement at a time when the specified cursor was not positioned on a row or rowset of the object table. The cursor
must be positioned on the row that is to be updated or deleted.
This can occur if the cursor is no longer positioned on the row because another cursor in the same application
program delete the row or updates an index column. This includes deletes and index column updates that are
performed as a result of rolling back to a savepoint.
This can also occur with a sensitive dynamic cursor when the FOR ROW n OF ROWSET clause is specified and the
specified row of the current rowset has been updated or deleted.
System action: The statement cannot be processed. No data was updated or deleted, and the cursor position is
unchanged.
Programmer response: Correct the logic of the application program to ensure that the cursor is correctly positioned
on the intended row of the object table before the UPDATE or DELETE statement is executed. Note that for single
row or non-rowset cursors, the cursors are not positioned on a row if FETCH returned SQLCODE +100.
SQLSTATE: 24504 |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| I have such requirement, that I should first fetch the next record and if some criteria meets, I shall issue COMMIT first before issue POSITIONED UPDATE. How should I do ? |
This is Not the requirement. This is merely how you have chosen to implement.
If you explain the business requirement, someone might have an alternate suggestion. |
|
| Back to top |
|
|
dejunzhu
Active User
Joined: 08 May 2008
Posts: 390
Location: China
|
|
|
|
hi, dick,
There is no specific requirement.
I tried this just want to have btter understaning of DB2. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
As this should not be done, it will not lead to a better understanding of db2.
Other than this will cause problems. |
|
| Back to top |
|
|
|
|
