Code: Alles auswählen.
DATA: itab1 TYPE TABLE OF mara,
itab2 TYPE TABLE OF marc,
itab3 TYPE TABLE OF makt,
wa_itab1 LIKE LINE OF itab1,
wa_itab2 LIKE LINE OF itab2,
wa_itab3 LIKE LINE OF itab3.
SELECT * FROM mara INTO CORRESPONDING FIELDS OF TABLE itab1.
SELECT * from marc INTO CORRESPONDING FIELDS OF TABLE itab2.
LOOP AT itab1 INTO wa_itab1.
LOOP AT itab2 INTO wa_itab2 WHERE matnr = wa_itab1-matnr.
wa_itab3-matnr = wa_itab2-matnr.
APPEND wa_itab3 TO itab3.
ENDLOOP.
ENDLOOP.
Code: Alles auswählen.
loop at table1 assigning field-symbol(<table1>).
" wenn es einen Eintrag mit der selben Materialnummer in Tabelle 2 gibt, hänge die Zeile
if line_exists( table2[ kunnr= <table1>-kunnr] ).
" neue zeile in tabelle 3 erzeugen
append initial line to table3 assigning field-symbol(<table3>).
" gleichnamige felder von tabelle1-zeile zu tabelle3-zeile schieben
move-corresponding <table1> to <table3>.
endif.
endloop.
Das halte ich für ein Gerücht. Geschachtelte SELECTs sind nicht gern gesehen, geschachtelte LOOPs hingegen sind kein Problem.LostDarkness hat geschrieben:Ich bin selbst nicht so der Erfahrenste und weiß das Loops in Loops ungern gesehen sind
Ich bin schon vom System vor allem möglichen Mist gewarnt worden, aber noch nie vor einem nested loop. Noch nicht mal in ausblendbarer Form.Was schreibst du denn da? Natürlich sollte man nested loops vermeiden, darum warnt das System auch davor, wenn es welche erkennt.
Abhängig davon, was die zu lösende Aufgabenstellung ist, kann das aber notwendig sein. Dann ist es erforderlich und ganz normal. Deswegen habe ich in meiner Antwort ja geschrieben, dass man das Problem verstehen und logisch korrekt modellieren muss, damit man keine unnötigen nested loops hat, die sich eben nicht aus der Aufgabenstellung ergeben, sondern die Komplexität (und Laufzeit) nur ohne Not aufblähen.Überleg mal, wie oft eine Operation durchgeführt wird, wenn du zwei Tabellen a 1.000 Sätze hast und sie im inneren loop stehen.
Ich schon.DeathAndPain hat geschrieben:Ich bin schon vom System vor allem möglichen Mist gewarnt worden, aber noch nie vor einem nested loop. Noch nicht mal in ausblendbarer Form.Was schreibst du denn da? Natürlich sollte man nested loops vermeiden, darum warnt das System auch davor, wenn es welche erkennt.
Auweh. Also, einen LOOP AT....WHERE.... macht man nicht über Standardtabellen, weil dabei jeder Satz angefasst wird, um zu prüfen, ob er der WHERE-Bedingung entspricht. Deutlich performanter ist das mit sortierten Tabellen (dann werden wirklich nur die Sätze angesprungen, die der WHERE-Bedingung entsprechen) oder mit einem Aufsetzpunkt. Man kann und sollte bei solchen Konstrukten immer dafür sorgen, dass jeder Satz nach Möglichkeit nur einmal durchlaufen wird (eben auch im inneren LOOP).DeathAndPain hat geschrieben:Aber wenn Du beispielsweise zu bestimmten Verkäufergruppen alle Materialien wissen willst, die von den jeweiligen VKGRP in einem bestimmten Zeitraum verkauft worden sind, dann wird Dir nichts anderes übrigbleiben, als zunächst einmal zu dieser VKGRP aus der VBAK alle relevanten Aufträge zu lesen. Performanterweise machst Du das per SELECT INTO TABLE. Anschließend musst Du zu diesen Aufträgen alle betroffenen Positionen lesen. Performanterweise machst Du das per SELECT FOR ALL ENTRIES IN (alternativ durch Aufbau einer passenden RANGES-Tabelle). Und dann musst Du pro VKGRP hingehen, einen LOOP über Deine Auftragstabelle WHERE VKGRP = ... machen und darin dann einen LOOP auf Deine Positionstabelle machen und Deine Positionen ranholen.
Das ist die Code-Inspector-Prüfung "Geschachtelte Schleifen" aus der Gruppe "Performance-Prüfungen".ralf.wenzel hat geschrieben:Ich schon.DeathAndPain hat geschrieben:Ich bin schon vom System vor allem möglichen Mist gewarnt worden, aber noch nie vor einem nested loop. Noch nicht mal in ausblendbarer Form.Was schreibst du denn da? Natürlich sollte man nested loops vermeiden, darum warnt das System auch davor, wenn es welche erkennt.
Code: Alles auswählen.
Was wird geprüft?
Geschachtelte Schleifen
Sucht nach Schleifen, die selbst wiederum in Schleifen enthalten sind.
Dies sind:
o LOOP ... ENDLOOP.
o DO ... ENDDO.
o WHILE ... ENDWHILE.
o PROVIDE ... ENDPROVIDE.
Gemeldet wird, wenn zwei der obigen Schleifentypen ineinander
geschachtelt sind bzw. in einer SELECT ... ENDSELECT-Schleife vorkommen.
Die Verwendung in Modularisierungseinheiten, die innerhalb einer
Schleife aufgerufen werden, kann nicht festgestellt werden.
SELECT-Statements innerhalb einer Schleife werden in einer anderen
Prüfung untersucht.
Richtig.ewx hat geschrieben:Das ist die Code-Inspector-Prüfung "Geschachtelte Schleifen" aus der Gruppe "Performance-Prüfungen".
Und wenn einen die Prüfung stört einfach die innere Schleife in eine eigene Modularisierungseinheit refactoren...ralf.wenzel hat geschrieben:Richtig.ewx hat geschrieben:Das ist die Code-Inspector-Prüfung "Geschachtelte Schleifen" aus der Gruppe "Performance-Prüfungen".
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
DeathAndPain
Wir haben dafür eine kleine Modifikation eingebaut. Es wird bis zu einer Tiefe von X ( kann man einstellen ) nach den nested loops gesucht. Hatte anfangs bedenken ob das so klappen kann wie wir uns das erhofft haben, aber es funktioniert tatsächlich wie wir es brauchen ( heißt es werden die sourcen, welche innerhalb des loops aufgerufen werden ( also Methoden, Fubas und Forms ), durchsucht. ).ralf.wenzel hat geschrieben:Das ist in der Tat ein Problem: Sowas erkennt die Prüfung leider nicht.
Vermutlich. Man muss halt bedenken, dass einige Sourcen unter umständen mehrmals durchsucht werden könnten.. daher die Tiefe nicht allzu "Hoch" setzen..ralf.wenzel hat geschrieben:Die Laufzeit wird auch der Grund sein, warum die SAP das nicht eingebaut hat. Ist aber ein interessanter Ansatz. Aber warum als Modifikation und nicht als eigene Prüfung?
An welcher Stelle habe ich geschrieben, dass die verwendeten internen Tabellen Standardtabellen sein sollen?!?Ralf hat geschrieben:Auweh. Also, einen LOOP AT....WHERE.... macht man nicht über Standardtabellen
Ja, ok, wenn man explizit den Code Inspector startet, dann mag der einem in dieser Richtung Vorschläge machen. Die reguläre Programmprüfungen, die teils mit Pragmas ausblendbar sind, haben sowas nicht dabei. Noch nicht mal mit Pragma.ewx hat geschrieben:Das ist die Code-Inspector-Prüfung "Geschachtelte Schleifen" aus der Gruppe "Performance-Prüfungen".
Sowas wird sich doch von ganz alleine immer wieder ergeben. Wenn ich mir ein durchschnittliches Programm anschaue, wieviel Ebenen die Aufruftiefe da umfasst, da kann mir keiner erzählen, dass es nicht häufig vorkommt, dass in irgendeinem in der Aufrufhierarchie weiter unten liegenden Codestück auch mal ein kleiner LOOP drin ist. Darum darf man sich als Aufrufer ja noch nicht einmal kümmern, weil ja das Paradigma der Kapselung und Geheimhaltung gilt.black_adept hat geschrieben:Und wenn einen die Prüfung stört einfach die innere Schleife in eine eigene Modularisierungseinheit refactoren...Ralf hat geschrieben:Das ist in der Tat ein Problem: Sowas erkennt die Prüfung leider nicht.