Loop Loop & Loop - wie am besten eine Verschachtelung vermeiden?

Re: Loop Loop & Loop - wie am besten eine Verschachtelung vermeiden?

Also das sieht schon bedeutend besser aus als das, was Du in früheren Threads geboten hast.

Die geschachtelten LOOPs sind dann und nur dann sinnvoll, wenn jeweils überhaupt mehrere Fundstellen möglich sind. In den WHERE-Klauseln vergleichst Du ja nur auf Gleichheit. Ich kenne den Inhalt Deiner Datenfelder nicht (komme aus einem anderen SAP-Modul), aber dennoch drängt sich mir der Verdacht auf, dass Du bei den beiden inneren LOOPS nur genau eine Zeile suchst bzw. zu finden erwartest. In dem Falle ist ein LOOP natürlich Overkill.

Außerdem zwei kleine formale Anmerkungen:

• Statt dess IF-Blocks würde sich in Deinem Fall ein CASE-Block bedeutend schöner lesen.
• Den MODIFY brauchst Du nicht; den kannst Du ersatzlos streichen, da Du bei Deinem LOOP ja (lobenswerterweise) nicht mit einer Workarea arbeitest, sondern mit einem Feldsymbol. Das Feldsymbol zeigt direkt in die interne Tabelle hinein. Änderst Du den Wert des Feldsymbols, dann änderst Du direkt die interne Tabelle! Du brauchst also kein MODIFY. Das bräuchtest Du nur, wenn Du einen LOOP INTO anstelle eines LOOP ASSIGNING machen würdest, denn dann würdest Du eine Kopie des Tabellenwertes in eine lokale Variable legen und müsstest diese nachher in die Tabelle zurückschreiben.

Wenn meine Theorie richtig ist, dass bei den beiden inneren LOOP nur jeweils (maximal) eine Fundstelle möglich ist, dann könnte man Deinen Code wie folgt verschlanken:
Wie gesagt, geht das deswegen, weil Du nur auf Gleichheit prüfst. In dem Moment, in dem Deine WHERE-Bedingung auch eine Ungleichheit oder sonstige Bedingung enthält (z.B. WHERE A > B), gibt es zum LOOP leider keine Alternative, auch wenn Du genau weißt, dass Du nur (maximal) eine Fundstelle haben wirst. Dann kannst Du aber zumindest dadurch optimieren, dass Du am Ende des Codes innerhalb des LOOPs den Befehl EXIT. schreibst, damit er gar nicht erst weiter nach Fundstellen sucht, sondern den LOOP direkt verlässt.

Außerdem gefällt mir nicht, dass Du weiterhin mit Standardtabellen arbeitest. Dadurch zwingst Du den ABAP-Interpreter, die Tabelle jedesmal Zeile für Zeile von Anfang bis Ende zu durchsuchen! Das ist so, als wenn ich Dich bitten würde, mir aus dem Telefonbuch die Person mit der Telefonnummer 1234567890 herauszusuchen. Da das Telefonbuch nicht nach Telefonnummern sortiert ist, kannst Du Dir überlegen, wie lange Du daran sitzen würdest. Bitte ich Dich hingegen, mir die Nummer von Grunz, Edelbert herauszusuchen, wirst Du sicherlich bedeutend schneller ein Ergebnis liefern.

Dem ABAP-Compiler geht es nicht anders. Welchen Tabellenschlüssel Du verwenden solltest, wird sofort offenkundig, wenn man Deinen Code anschaut, nämlich den, mit dem Du in Deinem WHERE (bzw. ich in meinem ASSIGN) suchst.

gt_bkpf müsste beispielsweile wie folgt definiert sein:
Wenn dieselbe xblnr zweimal in gt_bkpf vorkommen kann, dann geht das so nicht. Dann würdest Du schreiben:
Beides wird die Laufzeit Deines Programms drastisch reduzieren! Entsprechend solltest Du auch p_toa01 umdefinieren.

Wie sagte mal jemand hier im Forum so schön (es war Ralf): "Eine Standardtabelle ist keine Tabelle, sondern eine Liste." Formal mag seine Aussage nicht korrekt sein, inhaltlich ist sie es durchaus. In dem Moment, in dem Du vorhast, in einer Tabelle zu suchen, sollte diese unbedingt sortiert oder gehasht sein. Ausnahmen gelten allenfalls, wenn Du mit Sicherheit vorhersagen kannst, dass die Tabelle nie mehr als ca. 10 Einträge enthalten wird.