Ansicht
Dokumentation
03480 - FOR ALL ENTRIES IN itab WHERE cond since 40B_COM
ROGBILLS - Synchronize billing plans Fill RESBD Structure from EBP Component StructureThis documentation is copyright by SAP AG.
FOR ALL ENTRIES IN itab WHERE cond since 40B_COM
Hi Rick,I did notice in the help text that the clause 'For all entries..' will
perform as follows:
" If the internal table itab contains no entries, the processing
continues as if there were no WHERE condition cond."
This tells me that if your itab is empty, you will select * from KONV which
could cause the below dump. Of course, I just dabble in ABAP, and I am by
no means an expert at programming.
I hope this helps,
Mike D. Martin
SAP Basis Administrator
SOLA Optical, USA
707-763-9911 x6106
mmartinZs...
-----Original Message-----
From: Rick Githens [mailto:RGithensZg...]
Sent: Monday, October 15, 2001 11:46 AM
To: 'SAP400 ListServer'
Subject: 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
BAL_S_LOG - Application Log: Log header data PERFORM Short Reference
This documentation is copyright by SAP AG.
Length: 3031 Date: 20240426 Time: 205636 sap01-206 ( 2 ms )
