problem with FETCH NEXT CURSOR

[Former Member]

Hi expert,
could someone tell me why the below FETCH NEXT CURSOR keep getting the data from the database table although it has just 400000 records?
the statement keep going till I receive a dump with

no more storage space available for extending an internal table

OPEN CURSOR WITH HOLD lv_cursor FOR 
SELECT artkl_id FROM ZZ_artk.
DO. 
CLEAR lt_artk . 
FETCH NEXT CURSOR lv_cursor INTO CORRESPONDING FIELDS OF TABLE lt_artkl_data PACKAGE 
SIZE 10000. 
APPEND LINES OF lt_artk_data TO lt_artk_all.
IF sy-subrc <> 0 . 
CLOSE CURSOR lv_cursor_artkl_id.
EXIT.
ENDIF.
ENDDO.

Best regards

Jenie

[Tomas_Buryanek]

You should check sy-subrc after FETCH. Not after APPEND command.

[Former Member]

I did this but in vain the problem is that sy-subrc is is always = 0, in this case the data will be called again and again

[Sandra_Rossi]

jennifer1988 it is just illogical to do it your way (and sometimes dangerous, hopefully APPEND does not alter SY-SUBRC). Instead, write it like this, it's just more logical:

FETCH NEXT CURSOR lv_cursor INTO CORRESPONDING FIELDS OF TABLE lt_artkl_data 
       PACKAGE SIZE 10000.
IF sy-subrc <> 0 . 
CLOSE CURSOR lv_cursor_artkl_id.
EXIT.
ENDIF.
APPEND LINES OF lt_artk_data TO lt_artk_all.

[DoanManhQuynh]

jennifer1988 : if it keep going mean it still fetchable, its very clear in F1 help about that.

[Sandra_Rossi]

The interest of using FETCH is to keep in memory a limited number of lines, not the whole table. So why do you append all the lines to an internal table? (your code is exactly like doing SELECT artkl_id FROM zz_artkl INTO TABLE lt_artk_all).

[Former Member]

Hi Sandra,

I am using append just to control and stand on how many records has been called and this appended Table will not be used further...

[Sandra_Rossi]

jennifer1988 you ran into a memory problem, so 400.000 lines was too much in your situation, so either you troubleshoot the memory problem which is not related to your ABAP code (cf my other answer), or you reduce the memory consumption and you don't load all the lines of the table (if it's just to count the lines, then just use SELECT COUNT( * )).

[Sandra_Rossi]

In your short dump, you should see the number of lines of the internal table, the memory used, etc. If needed, use the debugger to list the data objects sorted by the amount of memory used.

[matt]

If you run in debug you should be able to solve by yourself.