dump while debugging single step for select..endselect

[Former Member]

hi ,

why do when we press F5 in a select ...endselct gives a dump.

[Former Member]

Hi,

I think performance issue is there in u r select statement.

Put a brackpoint after endselect in debugging and press F8 insted of F5.

It executes remaining part of u r code.

Reward if useful.

Regards,

Narasimha

[Sm1tje]

It has nothing to do with performance, but this is just one of those things in debugging a SELECT ENDSELECT. I believe this has something to do with ' CURSOR' being lost or something and this only happens in debugging.

So only thing you can do is skip this statement in debugging and put a break point at endselect like mentioned before.

additional info:

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.

Edited by: Micky Oestreich on May 15, 2008 3:34 PM

[Former Member]

hi,

Place a break point after endselect statement and execute to avoid dump ...

Regards,

Santosh

[Former Member]

No i am interested in the cause, why we are getting a dump . If the cursor is lost in database may i know why this happens.

[Former Member]

Hi

I think it's a problem the system triggers a COMMIT while debbuging and so the cursor is lost and the dump occurs.

Max

[Former Member]

Why does COMMIT statement cause problem . even while debugging there are lots of istances where Commit is done .but why it gives a dump.

[Former Member]

Hi

Because the COMMIT releases and clears all database parameters (used by the program), so the cursor used for the select too.

In this situation the system can't know which'll be the next record to be read and the dump occurs.

I don't think there a statament COMMIT into SELECT/ENDSELECT loop, the system does an implicit COMMIT while debugging.

Max

[Sm1tje]

like I said before, because of this:

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.

These are 'things' on DB level, which seem to occur, and which we should accept as it is.

[matt]

There's some system parameter in RSPARAM that varies when the implicit commit happens. Something to do with roll memory, IIRC...

Anyway, this is one of the biggest reasons why it is a really BAD idea to use SELECT... ENDSELECT, unless you really really have to You can end up being unable to debug a program that's going wrong in production. This cost one client I had a great deal of money...

matt

[Former Member]

by commit stament i was meaning implicit commits

now if some one does F6 why it is not giving dump. does there no commit excuted. then why does it goes excuting it.

[Former Member]

Hi ,

If syntax is correct , it doesn't show short dump. ..

check sample code ...

PARAMETERS : p_mtart TYPE mara-mtart.

data : w_ma type mtart.

• Malidating the Material Type

SELECT mtart FROM mara

INTO w_ma

UP TO 1 ROWS

WHERE mtart = p_mtart.

ENDSELECT.

IF NOT sy-subrc EQ 0.

write : /05 'no records found'.

else.

write : /05 w_ma.

ENDIF.

Rewatrd if useful

Thanks

Jagadeesh.G

Edited by: Jagadeshwar Gollapelly on May 15, 2008 3:49 PM