cancel
Showing results for 
Search instead for 
Did you mean: 

DBIF_RSQL_INVALID_CURSOR while debugging

Former Member
0 Kudos

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.

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

hi ramandeep,

i don't think that thisquestion belongs into this particular forum; if you post this question in the ABAP forum you'll get an answer within seconds. but nevermind...

I think all the answers to your question are in the output of the debugger. The debugger does implicitely commit while you step to your loop. the DB cursor pointing to a record in your record set gets invalid by the commit. trying to 'move the cursor' to the next position raises the dump.

the easiest solution to avoid this is mentionend in the debug output: use

select into table

and loop through the internal table.

regards,

anton

Former Member
0 Kudos

Hi,

I did not mention earlier that this dump happens on only one of our test servers. On another server, we are able to debug with a select...endselect.

Regards,

Raman