Skip to Content
author's profile photo Former Member
0
Former Member

DBIF_RSQL_INVALID_CURSOR dump during debugging

Posted on Feb 17, 2005 at 01:32 PM 144 Views

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

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

3 Answers

  • Best Answer
    author's profile photo Former Member
    Former Member
    Posted on Feb 17, 2005 at 01:53 PM
    2

    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

    Add a comment
    10|10000 characters needed characters exceeded

    • Srinivas Adavi Former Member
      Feb 17, 2005 at 07:20 PM

      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

    Comment on This Answer
  • author's profile photo Rich Heilman
    Rich Heilman
    Posted on Feb 17, 2005 at 01:43 PM
    0

    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

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Feb 18, 2005 at 03:46 AM
    0

    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.

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.