on 01-25-2006 10:47 AM
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
87 | |
10 | |
10 | |
10 | |
7 | |
6 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.