# SQLCODE -508: Cursor not positioned on a row

Source: https://wndsoftware.com/mainframe-errors/sqlcode-508

### SQLCODE -508: Cursor not positioned on a row

SQLCODE -508 (SQLSTATE 24504) means an UPDATE or DELETE ... WHERE CURRENT OF ran while the cursor was open but not on a row. Typical cases are an update after FETCH returned +100, or a second positioned statement after the row was deleted.


#### Other names for this code

Also written as `SQL -508`, `SQLCODE=-508`, `SQLCODE = -508`, `db2 -508`, `sqlstate 24504`, `SQL0508N`, `db2 cursor not positioned on a row`, `SQL0508`.


### What it means

An open cursor isn't always on a row. Right after OPEN it sits before the first row. After a FETCH that returns [+100](https://wndsoftware.com/mainframe-errors/sqlcode-100) it sits after the last row. After a DELETE ... WHERE CURRENT OF it sits in the gap where the deleted row was, before the next one. In all these positions there's no current row, so a positioned UPDATE or DELETE has nothing to act on, and Db2 returns -508.

After a positioned UPDATE, the cursor stays on the updated row. You can update the same row again, but once you delete it you need another FETCH before the next positioned statement.

The cursor is still open after -508. It's the program's sequence of statements that is wrong, not the cursor.


### Common causes

- The loop runs the UPDATE before checking the FETCH result, so the last pass updates after FETCH returned +100.
- The program deleted the current row with DELETE WHERE CURRENT OF and then ran a positioned UPDATE on the same row.
- A positioned UPDATE or DELETE runs straight after OPEN, before the first FETCH.
- A FETCH failed with a negative SQLCODE, the program didn't check it, and the cursor wasn't left on a row.
- Another cursor in the same program deleted the row, or updated a column of an index the cursor uses, so the cursor lost its position. A ROLLBACK TO SAVEPOINT that undid the row has the same effect.


### How to find the problem

- Display the SQLCODE of the last FETCH before the failing statement. +100 or a negative value is the answer in most cases.
- Follow the loop's logic. Check where the FETCH result is tested compared with the positioned UPDATE or DELETE.
- Look for other statements in the program that touch the same row before the failing statement, such as a DELETE or UPDATE through another cursor, or a ROLLBACK TO SAVEPOINT.


### How to fix it

- Test the FETCH result first. Run positioned statements only when the FETCH returned 0.
- After a DELETE WHERE CURRENT OF, FETCH again before another positioned statement.
- If a row needs both an update and a delete decision, decide first and run only one of them.
- Check the SQLCODE after every FETCH, and handle negative codes before using the cursor again.


### IBM documentation

[IBM documentation: -508](https://www.ibm.com/docs/en/db2-for-zos/13.0.0?topic=codes-508). Use the documentation for your installed release.

[Report a correction to WND Software](https://wndsoftware.com/contact#message).

Technical reviewer: [Albert Joseph](https://wndsoftware.com/authors/albert-joseph), WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s Db2 for z/OS documentation for your release.


### Related codes

[SQLCODE -507 Cursor not open for UPDATE or DELETE Read →](https://wndsoftware.com/mainframe-errors/sqlcode-507)
[SQLCODE +100 Row not found Read →](https://wndsoftware.com/mainframe-errors/sqlcode-100)
[SQLCODE -501 Cursor not open Read →](https://wndsoftware.com/mainframe-errors/sqlcode-501)
[SQLCODE -503 Column not in the cursor's FOR UPDATE list Read →](https://wndsoftware.com/mainframe-errors/sqlcode-503)
[SQLCODE -911 Deadlock or timeout, rolled back Read →](https://wndsoftware.com/mainframe-errors/sqlcode-911)

### Questions


#### Can I update the same row twice through the cursor?

Yes. After a positioned UPDATE the cursor stays on that row. After a positioned DELETE it doesn't, so you need another FETCH.


#### Is the cursor closed after -508?

No. It's still open, so you can FETCH again or CLOSE it as normal.


#### Is it the same on Db2 for LUW?

Yes. Db2 for LUW reports SQL0508N with SQLSTATE 24504.

[Db2 SQLCODEs](https://wndsoftware.com/mainframe-errors/db2-sqlcodes) · [SQLCODE -507](https://wndsoftware.com/mainframe-errors/sqlcode-507) · [SQLCODE -514](https://wndsoftware.com/mainframe-errors/sqlcode-514)

[← All error codes](https://wndsoftware.com/mainframe-errors/)