2 interne Tabellen vergleichen
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
13 Beiträge
•
Seite 1 von 1
13 Beiträge
Seite 1 von 1
Hi,
ich hab ein Problem und zwar möchte ich 2 interne Tabellen miteinander vergleichen ob Einträge in der ersten internen Tabelle auch in der zweiten vorkommen. Einen Doppelloop möchte ich vermeiden (Stichwort Performance). Somit hätte ich es wie folgt gemacht (ist nur grob, da ich gerade kein System habe):
Hier habe ich das Problem, dass er das ungleich nicht akzeptiert. Ich hätte gedacht, dass ein Read einfach besser ist, auch aufgrund der Performance. Weiß jemand wie man sowas löst (also das mit dem ungleich) oder kennt jemand eine bessere Alternative?
Vielen Dank.
ich hab ein Problem und zwar möchte ich 2 interne Tabellen miteinander vergleichen ob Einträge in der ersten internen Tabelle auch in der zweiten vorkommen. Einen Doppelloop möchte ich vermeiden (Stichwort Performance). Somit hätte ich es wie folgt gemacht (ist nur grob, da ich gerade kein System habe):
Code: Alles auswählen.
Loop at lt_itab1 into ls_work.
read table lt_ausgabe into ls_ausgabe with key opbel = ls_work
iban <> ls_workd-iban.
Vielen Dank.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Ein Loop hat nicht zwingend schlechtere Performance als ein READ TABLE.
Vielleicht würde dir sowas helfen:
Vielleicht würde dir sowas helfen:
Code: Alles auswählen.
DATA: lv_opbel TYPE opbel,
lv_iban TYPE iban.
SORT lt_ausgabe BY opbel iban.
SORT lt_itab1 BY opbel iban.
LOOP AT lt_itab1 ASSIGNING FIELD-SYMBOL(<work>).
"hier könnte man auch Gruppenstufenverarbeitung nutzen, die ich nicht mag.
"In neueren Releases könnte man dafür GROUP-BY in dem LOOP nutzen
IF <work>-opbel NE lv_opbel OR <work>-iban NE lv_iban.
lv_opbel = <work>-opbel.
lv_iban = <work>-iban.
LOOP AT lt_ausgabe TRANSPORTING NO FIELDS WHERE opbel = <work>-opbel
AND iban <> <work>-iban.
"ungleich
EXIT.
ENDLOOP.
ENDIF.
ENDLOOP.
Du brauchst doch deinen READ nur mit "=" zu machen.
Wenn der Eintrag gefunden wird, weißt du, dass er in der zweiten Tabelle auch vorhanden ist.
Wenn nicht, dann nicht...
Wenn der Eintrag gefunden wird, weißt du, dass er in der zweiten Tabelle auch vorhanden ist.
Wenn nicht, dann nicht...
hmm das wäre ja leider auch wieder ein Loop im Loop, gerade so etwas wollte ich gerne vermeiden. Es geht darum, dass ich eine interne Tabelle habe in der gewisse Zeilen, welche OPBEL-Nummern beinhalten und ich nun eine zweite interne Tabelle habe und ich von dort auch welche in die erste aufnehmen möchte, diese aber nur aufgenommen werden sollen, wenn sie das Kriterium erfüllen, dass die IBAN-Nummer ungleich ist. 
Beispielcoding wäre super
Beispielcoding wäre super wieso nicht?Bright4.5 hat geschrieben:@ewx.
Ja, aber diese Information würde mir nicht viel bringen.
Bright4.5 hat geschrieben:[...]ob Einträge in der ersten internen Tabelle auch in der zweiten vorkommen[...]
verstehe dennoch nicht, warum dir das nichts bringt. ( vielleicht stehe ich auch nur auf den schlauch )
wenn du den Eintrag, mit der gleichen IBAN-Nummer findest, brauchst du halt nichts zu tun, falls du es nicht findest, fügst du den Eintrag aus der Tabelle 1 in Tabelle 2 ein.. ungefähr so ( Pseudocode ):
Ersetze das [ / 93 mit eckigen klammern...
anstatt dem line exists könnte man auch read table hernehmen ( bei älteren releases ) und dann sy-subrc <> 0 prüfen..
Edit:
wie hast dus jetzt gelöst? für den fall das jemnd anders auch mal das problem hat.
wenn du den Eintrag, mit der gleichen IBAN-Nummer findest, brauchst du halt nichts zu tun, falls du es nicht findest, fügst du den Eintrag aus der Tabelle 1 in Tabelle 2 ein.. ungefähr so ( Pseudocode ):
Code: Alles auswählen.
Loop at itab1 into data(struc1).
if not line_exists( itab2[ field1 = struc1-field1 field2 = struc1-field2 ] ).
insert struc1 into itab2.
endif.
endloop. anstatt dem line exists könnte man auch read table hernehmen ( bei älteren releases ) und dann sy-subrc <> 0 prüfen..
Edit:
Bright4.5 hat geschrieben:Okay, vielen Dank an alle ich hätte es gelöst
wie hast dus jetzt gelöst? für den fall das jemnd anders auch mal das problem hat.
Hallo,
sowas sollte mit dem Befehl FILTER gehen. Damit kann man z.B. alle Einträge aus Tabelle A filtern die in Tabelle B enthalten sind oder alle Einträge aus Tabelle A filtern die nicht in Tabelle B enthalten sind. Das ist sehr sehr performant.
Grüße
Alex
sowas sollte mit dem Befehl FILTER gehen. Damit kann man z.B. alle Einträge aus Tabelle A filtern die in Tabelle B enthalten sind oder alle Einträge aus Tabelle A filtern die nicht in Tabelle B enthalten sind. Das ist sehr sehr performant.
Grüße
Alex
Beitrag
von DeathAndPain (Top Expert / 1982 / 269 /
418
)
»
@Saskuac: In Deinem Codebeispiel prüfst Du ja beides auf Gleichheit. Er braucht aber den Fall, dass der erste Wert gleich und der zweite ungleich ist. Er sucht also die Zeilen mit gleichem ersten Wert, kann aber von den Fundergebnissen nur diejenigen gebrauchen, bei denen der zweite Wert sich unterscheidet.
Trotzdem ist das in meinen Augen eine uralte Schwachstelle von ABAP, und bei Einführung der 7.40-Syntax hat die SAP die Möglichkeit liegengelassen, sie zu beheben. Der READ TABLE liefert so oder so nur die erste von möglicherweise mehreren Zeilen zurück, auf die seine Gleichheitsbedingungen zutreffen. Da könnte man genauso auch Prüfungen auf Ungleichheit oder gar noch komplexeren Kram (IN-Operator etc.) erlauben. Für die implizite 7.40-Syntax mit den eckigen Klammern gilt dasselbe. Ein Eindurchlaufloop ist ein höchst hässlicher und schlecht lesbarer Ersatz.
Diese Diskussion hatten wir kürzlich in einem anderen Thread. Einerseits ist es nicht immer zu vermeiden, zweitens ist es auch nicht notwendigerweise schlimm, und dritterseits reden wir hier von einem Pseudo-Loop, der nur einen EXIT enthält und der daher genauso wie ein READ TABLE nur einmalig durchlaufen wird. Damit hat der LOOP zwar eine etwas sperrigere Syntax, ist performancetechnisch aber nicht nennenswert schlechter.Bright4.5 hat geschrieben:hmm das wäre ja leider auch wieder ein Loop im Loop, gerade so etwas wollte ich gerne vermeiden.
Trotzdem ist das in meinen Augen eine uralte Schwachstelle von ABAP, und bei Einführung der 7.40-Syntax hat die SAP die Möglichkeit liegengelassen, sie zu beheben. Der READ TABLE liefert so oder so nur die erste von möglicherweise mehreren Zeilen zurück, auf die seine Gleichheitsbedingungen zutreffen. Da könnte man genauso auch Prüfungen auf Ungleichheit oder gar noch komplexeren Kram (IN-Operator etc.) erlauben. Für die implizite 7.40-Syntax mit den eckigen Klammern gilt dasselbe. Ein Eindurchlaufloop ist ein höchst hässlicher und schlecht lesbarer Ersatz.
Hallo,
man braucht sortierte Tabellen.
von der Logik her folgendes:
lt_auch_in_anderer_Tabelle = FILTER #( lt_Tabelle1 in lt_Tabelle2 where feld1 = feld1 and feld2 = feld2 and ...).
lt_nicht_in_anderer_Tabelle = FILTER #( lt_Tabelle1 EXCEPT in lt_Tabelle2 where feld1 = feld1 and feld2 = feld2 and ...).
Grüße
Alex
man braucht sortierte Tabellen.
von der Logik her folgendes:
lt_auch_in_anderer_Tabelle = FILTER #( lt_Tabelle1 in lt_Tabelle2 where feld1 = feld1 and feld2 = feld2 and ...).
lt_nicht_in_anderer_Tabelle = FILTER #( lt_Tabelle1 EXCEPT in lt_Tabelle2 where feld1 = feld1 and feld2 = feld2 and ...).
Grüße
Alex
Seite 1 von 1
Vergleichbare Themen
3
Antw.
Antw.
4182
Views
Views
3 Tabellen miteinander vergleichen und Treffer ausgeben (Ohne Interne Tabellen)
von Reyvn94 » 07.02.2022 00:34 • Verfasst in ABAP® für Anfänger
von Reyvn94 » 07.02.2022 00:34 • Verfasst in ABAP® für Anfänger
7
Antw.
Antw.
5587
Views
Views
2 interne Tabellen vergleichen
von Frank Schmitt » 24.06.2020 09:40 • Verfasst in ABAP® für Anfänger
von Frank Schmitt » 24.06.2020 09:40 • Verfasst in ABAP® für Anfänger
5
Antw.
Antw.
2343
Views
Views
2
Antw.
Antw.
2418
Views
Views
10
Antw.
Antw.
18017
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Unbeantwortete Forenbeiträge
Smartforms: Formatfehler im Q-System, in Entwicklungssystem nicht
letzen Monat von udo.fehring@mail.de 1 / 33835
letzen Monat von udo.fehring@mail.de 1 / 33835