DBIF_RSQL_INVALID_CURSOR while debugging

[Former Member]

We are getting the above short dump while debugging within a select-endselect statement in our DEV system. One work process has been allocated as a debug process in the SAP profile parameter rdisp/wpdbug_max_no. But we get this dump even when only one debug session is active across the system. We are not getting the message "Commit work has been executed" during debug but looks like a commit is being executed after each dialog step. SM50 does show the work process in debug mode.

Please advise.

The details of the short dump are pasted below.

Regards,

Raman

Runtime Errors DBIF_RSQL_INVALID_CURSOR

Exception CX_SY_OPEN_SQL_DB

Occurred on 01/24/2006 at 20:54:50

-

---

Invalid interruption of a database selection.

-

---

What happened?

-

---

Error in ABAP application program.

The current ABAP program "ZSR00274" had to be terminated because one of the

statements could not be executed.

This is probably due to an error in the ABAP program.

Unable to perform database selection fully.

record.

-

---

What can you do?

-

---

If the error occurs in debugging mode, you should

first run the process without debugging activated.

If the error persists outside debugging, you must check the application

program more closely.

Print out the error message (using the "Print" function)

and make a note of the actions and input that caused the

error.

To resolve the problem, contact your SAP system administrator.

You can use transaction ST22 (ABAP Dump Analysis) to view and administer

termination messages, especially those beyond their normal deletion

date.

-

---

Error analysis

-

---

An exception occurred. This exception is dealt with in more detail below

. The exception, which is assigned to the class 'CX_SY_OPEN_SQL_DB', was

neither

caught nor passed along using a RAISING clause, in the procedure

"EXTRACT_OPEN_ORDERS" "(FORM)"

.

Since the caller of the procedure could not have expected this exception

to occur, the running program was terminated.

The reason for the exception is:

One of the database selections included a database commit.

The selection was then supposed to continue. Before a

database commit, however, all outstanding database selections must be

concluded.

Possible causes in the application program:

Within a loop (SELECT/LOOP/EXEC SQL), one of the following

statements is used:

- MESSAGE (apart from MESSAGE S...)

- COMMIT WORK

- ROLLBACK WORK

- CALL SCREEN

- CALL DIALOG

- CALL TRANSACTION

- SUBMIT

- BREAK-POINT

- WAIT

In debugging mode, a program sometimes triggers

a "COMMIT WORK" during the database selection. As a result

this termination may also occur in debugging mode with a correct

program.

A "COMMIT WORK" during debugging may be due to the following reasons:

1. A program or screen was regenerated

and updated in the database.

2. Each user needs a private process in debugging mode, but

the number of available processes is restricted. If this

limit is exceeded, each debugging step then requires a

"COMMIT WORK".

The error occurred in a statement in which table "VBAP " is accessed.

-

---

How to correct the error

-

---

The exception must either be prevented, caught within the procedure

"EXTRACT_OPEN_ORDERS"

"(FORM)", or declared in the procedure's RAISING clause.

To prevent the exception, note the following:

1. If the error occurs in debugging:

_ Repeat the test that caused the error outside debugging mode.

By doing this, you regenerate all the programs and screens

needed for the run and update them in the database, if necessary.

You thereby eliminate one possible cause of the

error.

If the error persists, it could be that the number of

processes available for debugging has been exceeded.

This is often due to a temporary bottleneck caused by

too many users working in the debugging facility at the same time.

If this bottleneck occurs frequently, you should

check whether it is possible to make more processes

available.

2. If the error occurs outside debugging:

The problem cannot be resolved without correcting the application

program.

_ The statements MESSAGE, COMMIT, ROLLBACK, CALL SCREEN, CALL DIALOG,

CALL TRANSACTION and SUBMIT cannot be used within a database

loop.

You can collect the data needed for these statements together in an

internal table and process them

in a loop.

-

With SELECT loops, the statement

SELECT * FROM ... INTO TABLE ...

is often useful.

[Former Member]

See this .

A breakpoint in SELECT loops can cause an exception through loss of the database cursor. The reason for this is that - during debugging - a database Commit is triggered

Else, try

select * from ... [Your select statement]

PERFORM subr ON COMMIT.

...

FORM subr.

WRITE 'Commit performed'.

ENDFORM.

[suresh_datti]

Hi Ramandeep,

You can ignore the short dump.. this always happens if you single step through a SELECT..ENDSELECT loop in de-bug mode.. there is nothing wrong with the code..

Regards,

Suresh Datti

[Former Member]

Hi raman,

refer this thread.

[Former Member]

Hi all,

I am aware that we cannot have explicit or implicit commits within a select-endselect loop. But the system does not(or should not) execute commits while a session is running in debug mode. The short dump occurs only on one of our test servers and not on others.

Anyways, thanks for your replies.

Regards,

Raman

[Former Member]

Hi

I think it depends on your SAP servers (DEV, TEST and PROD) are setted and how many hits are in that table.

Anyway this dump can occur and you can do nothing: you should ask help to your administrator.

But you can use LOOP/ENDLOOP statament instead of SELECT/ENDSELCT by inserting all hits you need to analyze in an internal table.

Max