Unable to get invoice output from a Billing Document....Getting a dump

[Former Member]

Hi All,

We have an issue when generating invoice output from a billing document. The issue is when I click on print preview after some 10-15 mniutes, I get a dump saying TIME OUT ERROR.. We asked the BASIS team to increase time but even after increasing time It give a dump...

This is definitely a performance issue with the print program. The dump clearly show the dump in the below part of the code...

SELECT vbeln auart

FROM vbak

INTO TABLE gi_vbak

FOR ALL ENTRIES IN c_vkdfif

WHERE vbeln EQ c_vkdfif-vbeln.

IF sy-subrc EQ 0.

SORT gi_vbak BY vbeln.

LOOP AT c_vkdfif.

READ TABLE gi_vbak WITH KEY vbeln = c_vkdfif-vbeln

INTO gwa_vbak BINARY SEARCH.

IF sy-subrc EQ 0.

IF ( gwa_vbak-auart EQ c_zc04 ) OR ( gwa_vbak-auart EQ c_zcr4 ).

DELETE TABLE c_vkdfif.

ENDIF.

ENDIF.

CLEAR gwa_vbak.

ENDLOOP.

ENDIF.

can you please suggest as to how what best can we do to avoid this dump....

Thanks

Abhii.....

[mohammedahasanullah_mulla · Accepted solution]

Hi Abhi,

Check whether the internal table c_vkdfif is initial,if its initial then thats the reason its trying to fecth all the contents from the database table vbak.Check what should be the condition if c_vkdfif internal table is initial.

Thanks,

Ahsan

[Former Member]

Hi,

i do not know if it helps, but change your code as follows:

if not c_vkdfif is initial.

SELECT vbeln auart

FROM vbak

INTO TABLE gi_vbak

FOR ALL ENTRIES IN c_vkdfif.

WHERE vbeln EQ c_vkdfif-vbeln

IF sy-subrc EQ 0.

SORT gi_vbak BY vbeln.

LOOP AT c_vkdfif.

READ TABLE gi_vbak WITH KEY vbeln = c_vkdfif-vbeln

INTO gwa_vbak BINARY SEARCH.

IF sy-subrc EQ 0.

IF ( gwa_vbak-auart EQ c_zc04 ) OR ( gwa_vbak-auart EQ c_zcr4 ).

DELETE TABLE c_vkdfif.

ENDIF.

ENDIF.

CLEAR gwa_vbak.

ENDLOOP.

ENDIF.

endif.

In fact it is the same solution as above. If c_vkdfif is empty you are reading the complete vbak table. Also on the database server this can be take a TOO long time.

success.

Gr., Frank

[Former Member]

Hi I am sorry the actual code was as below :-

IF NOT c_vkdfif IS INITIAL.

SELECT vbeln posnr lfrel banfn

INTO TABLE gi_vbep

FROM vbep

FOR ALL ENTRIES IN c_vkdfif

WHERE vbeln EQ c_vkdfif-vbeln.

CHECK sy-subrc = 0.

SORT gi_vbep BY vbeln ASCENDING.

• Begin of changes:DD1K902390

SELECT vbeln auart

FROM vbak

INTO TABLE gi_vbak

FOR ALL ENTRIES IN c_vkdfif

WHERE vbeln EQ c_vkdfif-vbeln.

IF sy-subrc EQ 0.

SORT gi_vbak BY vbeln.

LOOP AT c_vkdfif.

READ TABLE gi_vbak WITH KEY vbeln = c_vkdfif-vbeln

INTO gwa_vbak BINARY SEARCH.

IF sy-subrc EQ 0.

IF ( gwa_vbak-auart EQ c_zc04 ) OR ( gwa_vbak-auart EQ c_zcr4 ).

DELETE TABLE c_vkdfif.

ENDIF.

ENDIF.

CLEAR gwa_vbak.

ENDLOOP.

ENDIF.

Can you please provide me a solution...

[Sandra_Rossi]

Could you make sure c_vkdfif does not have a header line? (or post the data definition of this internal table if you're not sure)

Or try to force the test of internal table (this eliminates the risk of testing the header line):

IF c_vkdiff[] IS NOT INITIAL.

[Former Member]

Hi ,

IF you are not passing any Value or Looping this gi_vbep Table .

Then avoid Sorting : syntax

SORT gi_vbep BY vbeln ASCENDING.

Also use [ ] when your checking for the Value

Like this

IF NOT c_vkdfif[ ] IS INITIAL.

Hope it Solves ..

With Regards,

Vinu.R

[Former Member]

Hi Sandra,

C_VKDFIF is a tables parameter in the Functional Module Exit EXIT_SAPLV60P_008, which is of type dictionary structure VKDFIF.

In the Functional Module Interfact in Table parameters it is declared as bwloe : -

CVKDFIF LIKE VKDFIF.

Also Let me tell u When I put a BREAK- POINT on the read statement & execute the control doesnt go to this debug point where as it goes to dump.

Kindly suggest...

[Sandra_Rossi]

as it is a TABLES parameter, it means it has a header line, so do the code as I said.

[Former Member]

Hi Sandra,

Let me also tell you this dump is not coming when there are less no of items in a billing document. In my case the billing document which user is using has around 406 items in it..

Kindly suggest.

[Sandra_Rossi]

okay, but if your code has never gone to prod, and is still under test, do as I said because it's erroneous code (even if it's not the bug)

I guess the problem is with this strange syntax (never saw it; I don't know what it does exactly) : DELETE TABLE c_vkdfif.

Instead use DELETE c_vkdfif.

[Former Member]

hi,

a refresh of our abap knowledge

DELETE TABLE itab [FROM wa].

Effect

Behaves similarly to variant 2. The values for the table key are taken from the corresponding components of the (structured) field wa. The field must be compatible with the table line of itab. This method allows you to delete from a table without the table key having to be known in advance. If the internal table has a header line, you can leave out the FROM wa addition; the system then takes the key values from the header line.

Seems OK to me, because the header line is filled properly.

Gr.,Frank

[Sandra_Rossi]

What I meant was that statement probably loops at all records until the right is found, thus it does not use binary search, so it's not good for performance, while DELETE c_vkdfif is a direct access. So don't use DELETE TABLE c_vkdfif.

It is not sufficient to explain why there is a timeout of course (400 records without binary search would do an estimated average of only 80.000 loops). The reason could be found only by a debug, we, SDNers, can't do that.