DBIF_RSQL_INVALID_CURSOR dump during debugging

[Former Member]

Hi all,

I'm trying to debug in SE37 'BAPI_GL_ACC_GETPERIODBALANCES' RFC-FM but, in a select loop (within READ_BALANCES_HW form), I'm able to see the first select loop but, when the system tries to process the second one, this dump occurs:

Run-time error DBIF_RSQL_INVALID_CURSOR

Exception CX_SY_OPEN_SQL_DB

I've already found and read OSS Notes 2104 and 675, but no COMMIT WORK message appears in the ABAP debugger and, however, we extended available number of work processes for debugging in the profile parameters (rdisp/wpdbug_max_no = 8)...

Within the select loop there is also a COLLECT (related to an internal table) after a MOVE-CORRESPONDING...can this statement lead to a database commit that causes the database to lose the cursor ?

Here is the standard code...

SELECT * FROM GLT0

WHERE RLDNR = '00'

AND RRCTY = '0'

AND RVERS = '001'

AND BUKRS = COMP_CODE

AND RYEAR = FISC_YEAR

AND RACCT = GL_ACCOUNT

AND RPMAX = '016'.

MOVE-CORRESPONDING GLT0 TO GLTAB.

COLLECT GLTAB.

ENDSELECT.

By the way, how can I do my debug analysis ?

Thanks in advance !

Bye,

Roberto

[RichHeilman]

I've had this same problem in the past. If you don't really need to debug that select loop, just put a breakpoint after it and blow right passed it.

Regards,

Rich Heilman

[Former Member]

Hi Roberto,

this time in another forum. The reason for your dump is, that the debugging procedure causes a commit work. This closes your current cursor. You should try the following code:

SELECT * into corresponding fields of gltab FROM GLT0

WHERE RLDNR = '00'

AND RRCTY = '0'

AND RVERS = '001'

AND BUKRS = COMP_CODE

AND RYEAR = FISC_YEAR

AND RACCT = GL_ACCOUNT

AND RPMAX = '016'.

As data is not summarized in this case you need to sum it in a following loop or using

select sum(field1) sum(field2) ...

But in this case you also need to implement a group by clause in your select statement.

If you need more information, let me know.

regards

Siggi

[Former Member]

Hi Rich,

yours is a simple (and, for this reason, the best one !) work-around, but the problem still remains...

Siggi,

you are a real forum surfer !

However I'm referring to a std code that I can't logically change (and I don't want to reproduce all in a custom development only for testing purpose) and I'm not able to see any COMMIT on my process...

By the way,

thanks for the answers !

Roberto

[ssimsekler]

Hi Roberto

So nice to see you here. OK. This dump is normal because during debugging runtime looses the cursor opened in the database. This is written in the explanation part of the short dump text. And as far as I know, there is no correction for this. This is one of the reasons why I hate "SELECT...ENDSELECT" statement. What you can do is Rich's suggestion, inspect the values after collection although I know this may be not what you require.

Kind Regards

*--Serdar

ssimsekler@yahoo.com

[Former Member]

Hi Serdar,

nice to meet you me too !

Ok, I understand my issue...I never use select/endselect statement, but SAP evidently is not always of the same opinion !!!

However, trying the same (step by step) procedure, I have no problem in a different environment (different kernel and so on)...and, believe me, this is a real strange behaviour !

So, why I'm receiving different result if the debug process is always the same (and in my opinion there are no statements that can cause a db cursor loss in this piece of code...) ???

In the meanwhile I'm going in my different (and working) environment...if anyone is able to find the anwer to this enigma

However...thanks to all !

Bye,

Roberto

[Former Member]

Hi Roberto

I've not a really Answer to the strange behaviour in different Environment, only a few Hints.

There are some SAP Notes:

675 Unexpected abends in SELECT loops (COMMIT)

2104 Error messages DBIF_...._INVALID_CURSOR

Maybe your Workprocs in the two Environment are setted differently, e.g. rdisp/wpdbug_max_no is too low. in this case the abap debugger terminate.

best regards

christian

[Former Member]

Hi Roberto,

As it was mentioned in the OSS notes you posted here, debugging a 'Select' 'Endselect' loop doesn't always result in a short dump except , I quote the OSS note 2104 here

<i>The "COMMIT WORK" message appears in the ABAP debugger
when programs or screens require regeneration, or when
not enough free capacity is available in the system (or
else the debugger blocks a system process).            

Normally only one work process is released for debugging. 
This is generally insufficient in a development system, 
as processes can be blocked for other reasons too 
(background processing, CPI-C connections, and so on).

The number of work processes made available for debugging 
can be configured using the profile parameter rdisp/wpdbug_max_no.</i>

So, no wonder that it is giving different results in different environments. In fact, when there are no other processes running except for yours, even in the same environment where you got the dump, you might be able to debug it or atleast go further than the first record selected, all this provided there are no commits happening in between.

Essentially, whether you get a dump or not depends on what is the demand for the processes available and if commits are there. The parameter will increase the number of processes available for debugging, but I am not sure if you are going to dedicate the same number of processes in an production environment versus development. Also, you should remember that in production there are multiple servers available in a typical installation, but there will only be one development server. All these factors will play a role in whether you get a dump or not.

Regards,

Srinivas

[Former Member]

A standard in Screen Processing with ABAP is that the system performs a COMMIT before each screen is presented to the user. This needs to be well understood if you are programming database updates and doing Screen Processing. The debugger is presenting a new screen with every step that you ask it to present, so a COMMIT is performed and the cursor is lost.

The COLLECT command has nothing to do with database calls. It is used to update an internal table which is held in memory so that is not the cause of the abend that you are receiving.

Rich has the right suggestion. Before the SELECT starts, double click a line after the ENDSELECT to set a break point and then use the 4th button - CONTINUE, to skip to the next breakpoint. You can also put the cursor on the line where you want it to stop and hit CONTINUE.

Let us know how it goes.