Ansicht
Dokumentation

03477 - FOR ALL ENTRIES IN itab WHERE cond since 40B_COM

03477 - FOR ALL ENTRIES IN itab WHERE cond since 40B_COM

PERFORM Short Reference   PERFORM Short Reference  
This documentation is copyright by SAP AG.
SAP E-Book

FOR ALL ENTRIES IN itab WHERE cond since 40B_COM

Greetings,

I think this is DB2/400 specific but I'm not sure. We have a few programs
which hit very large tables (KONV, BSEG, etc.). In order to reduce the
number of records required before selecting from these big guys, we usually
build an internal table which narrows down the number of records we really
want and then when we do the select-into-from statement, we use the "for all
records in" the internal table where (for instance) the document number in
the internal table equals the document number in KONV. This has worked for a
long time (and is a pretty common ABAP sql procedure from what I can tell).
Now if the internal table has no records in it, it selects 4 times the total
number of records in KONV into an internal table and then blows up as soon
as a sort is issued (TSV_INDEX_INDEX_NO_ROLL_MEMORY). I have read most of
the notes on that error and agree you can't protect an idiot from himself.
If they want to try and select a volume of data which would choke an
elephant, they deserve to get a dump. However, that is not the case here.
They should get NO RECORDS (and actually fall through rather quickly). Has
anyone else seen this? Is this maybe an IBM DB problem where since the split
from the kernel, it is not resolving that "for all entries in" clause
correctly? Is there a coding alternative to that "for all entries in". (i.e.
If I were in interactive SQL, I would use a subselect where "file1.docnumber
in (select docnumber from file2) or something like that)

Thanks,
Rick

Durban Tours - Südafrika Safari

Addresses (Business Address Services)   BAL Application Log Documentation  
This documentation is copyright by SAP AG.

Length: 1988 Date: 20240419 Time: 223534     sap01-206 ( 2 ms )