‎2009 May 13 8:46 AM
Hello all,
I hope one of you has an awnser for me.
We are running 6.0 and if I start debugging and someone else also starts a debug session he will get a abap dump but the program works fine normally.
Is there a setting anywhere where you can determine how many debug sessions are allowed?
This a part of the dump which appears:
Runtime Errors DBIF_RSQL_INVALID_CURSOR
Except. CX_SY_OPEN_SQL_DB
Date and Time 13.05.2009 09:35:19
Short text
Invalid interruption of a database selection.
What happened?
Error in the ABAP Application Program
The current ABAP program "ZCHR_BILL_INBOUND" had to be terminated because it
has
come across a statement that unfortunately cannot be executed.
Unable to perform database selection fully.
Error analysis
An exception occurred that is explained in detail below.
The exception, which is assigned to class 'CX_SY_OPEN_SQL_DB', was not caught
in
procedure "GET_DATA" "(FORM)", nor was it propagated by a RAISING clause.
Since the caller of the procedure could not have anticipated that the
exception would occur, the current program is 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:
While a read process from a database cursor is taking place
(within a loop SELECT/LOOP/EXEC SQL or before a FETCH command),
one of the following statements is used:
- MESSAGE (apart from MESSAGE S...)
- COMMIT WORK
- ROLLBACK WORK
- BREAK-POINT
- WAIT
- CALL FUNCTION ... DESTINATION (synchronous RFC)
- CALL FUNCTION ... STARTING NEW TASK
- RECEIVE RESULTS
- CALL DIALOG
- CALL SELECTION-SCREEN
- CALL TRANSACTION
- CALL SCREEN, or any other statement that results in the display of a
new screen
Whenever a program runs in debugging mode, a "COMMIT WORK" can
possibly be triggered during database selection. This abnormal
termination can also occur in debugging mode even with a correct......
Kind rgds,
Patrick
‎2009 May 13 8:48 AM
‎2009 May 13 8:48 AM
‎2009 May 13 8:53 AM
Hi
But it seems to be a problem while reading a database table, so probably into SELECT/ENDSELECT cycle: it doesn't seem to be a problem on the number of debug session.
U should considere while debugging the system can raise a COMMIT, if you're in SELECT/ENDSELECT cycle, the cursor can be lost and that dump occurs.
Max
‎2009 May 13 10:06 AM
>
> Hi
>
> But it seems to be a problem while reading a database table, so probably into SELECT/ENDSELECT cycle: it doesn't seem to be a problem on the number of debug session.
>
> U should considere while debugging the system can raise a COMMIT, if you're in SELECT/ENDSELECT cycle, the cursor can be lost and that dump occurs.
>
> Max
What Max says is absolutely true. Again it is a Basis issue - they can allocate more resources to the debug process, so that it doesn't do a commit, and hence doesn't lose the cursor and so doesn't dump.
matt
‎2009 May 13 8:54 AM
This error often comes when at the same time two database selection(select/endselect) or operation (on the same table) on database triggered . So can you please run debug session one by one and see if still short-dump exists?
Cheers