Performanceprobleme bei Loop
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.Hallo community,
ich habe eine interne Tabelle mit ca. 200.000 Einträgen.
Diese werden in einem Loop!!! 200.000 mal durchlaufen.
Was natürlich zu erheblichen Performanceproblemen bis hin zum Time out führt, was ja auch nachvollziehbar ist.
Ich versuche jetzt diesen Loop zu ersetzen.
In diesem Loop werden Felder der ItabA zur Weiterverarbeitung an 2 andere itabs weiter gegeben und
an 2 Range Tabellen.
Der Loop macht ansonsten nix! Nur andere Itabs / Ranges füllen.
Ich habe keine Lösung gefunden, da die Strukturen nicht kompatibel sind etc.
Wisst ihr schlauen Köpfe eine Möglichkeit?
Andererseits habe ich mir auch Gedanken gemacht, ob ich nicht einfach einen 2. und 3. Select auf die DB machen soll und nur die Daten holen soll, die diese Ranges und itabs benötigen.
3 Selects mit Array Fetch könnten u.U. schneller sein als 200.000 Loops?
Tips willkommen.
Gruß
coco
ich habe eine interne Tabelle mit ca. 200.000 Einträgen.
Diese werden in einem Loop!!! 200.000 mal durchlaufen.
Was natürlich zu erheblichen Performanceproblemen bis hin zum Time out führt, was ja auch nachvollziehbar ist.
Ich versuche jetzt diesen Loop zu ersetzen.
In diesem Loop werden Felder der ItabA zur Weiterverarbeitung an 2 andere itabs weiter gegeben und
an 2 Range Tabellen.
Der Loop macht ansonsten nix! Nur andere Itabs / Ranges füllen.
Ich habe keine Lösung gefunden, da die Strukturen nicht kompatibel sind etc.
Wisst ihr schlauen Köpfe eine Möglichkeit?
Andererseits habe ich mir auch Gedanken gemacht, ob ich nicht einfach einen 2. und 3. Select auf die DB machen soll und nur die Daten holen soll, die diese Ranges und itabs benötigen.
3 Selects mit Array Fetch könnten u.U. schneller sein als 200.000 Loops?
Tips willkommen.
Gruß
coco
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
1. Kannst du die interne Tabelle evtl. verkleinern, also weniger Felder einlesen?
2. Du kannst mit "SELECT feldname AS low INTO corresponding-fields" evtl. direkt in die RANGES-Tabelle lesen und so einen Verarbeitungsschritt sparen. Die anderen Felder (SIGN, OPTION) änderst du mit einem Schlag mittels MODIFY
wa_rangetab-sign = 'I'.
wa_rangetab-option = 'EQ'.
MODIFY rangetab FROM wa_rangetab TRANSPORTING SIGN OPTION WHERE sign = space.
3. Probier aus, ob der SELECT-Zusatz [url=http://tricktresor.de/content/index.php ... 30&aID=524[PACKAGE-SIZE[/url] schneller ist
4. Wenn der Select ansich schnell ist, ist es evtl. sogar sinnvoll diesen vielleicht zwei oder dreimal auszuführen und als Ziel jeweils andere interne Tabellen zu nehmen.
2. Du kannst mit "SELECT feldname AS low INTO corresponding-fields" evtl. direkt in die RANGES-Tabelle lesen und so einen Verarbeitungsschritt sparen. Die anderen Felder (SIGN, OPTION) änderst du mit einem Schlag mittels MODIFY
wa_rangetab-sign = 'I'.
wa_rangetab-option = 'EQ'.
MODIFY rangetab FROM wa_rangetab TRANSPORTING SIGN OPTION WHERE sign = space.
3. Probier aus, ob der SELECT-Zusatz [url=http://tricktresor.de/content/index.php ... 30&aID=524[PACKAGE-SIZE[/url] schneller ist
4. Wenn der Select ansich schnell ist, ist es evtl. sogar sinnvoll diesen vielleicht zwei oder dreimal auszuführen und als Ziel jeweils andere interne Tabellen zu nehmen.
Beitrag
von a-dead-trousers (Top Expert / 4457 / 227 /
1198
)
»
Brauchst die Daten in der "großen" internen Tabelle eigentlich dauerhaft?
Weil wenn du aus einer Tabelle drei machst, vervierfacht sich die Datenmenge im Speicher.
Also alles was nicht gebraucht wird möglichst zeitnah löschen.
Ach ja: Auf keinen Fall LOOP AT ... INTO ... verwenden. Schon gar nicht bei so großen Monster-Tabellen. IMMER mit Feldsymbolen (ASSIGNING) oder Zeigern (REFERENCE INTO) arbeiten.
Ansonsten würde ich dem PACKAGE-SIZE den Vorzug geben und wie gesagt die nicht mehr benötigen Datensätze gleich wieder löschen.
Weiterer Tipp: Wirklich nur die Felder von der Datenbank selektieren die gebraucht werden und auch die Struktur der internen Tabelle entsprechend verkleinern.
lg ADT
Weil wenn du aus einer Tabelle drei machst, vervierfacht sich die Datenmenge im Speicher.
Also alles was nicht gebraucht wird möglichst zeitnah löschen.
Ach ja: Auf keinen Fall LOOP AT ... INTO ... verwenden. Schon gar nicht bei so großen Monster-Tabellen. IMMER mit Feldsymbolen (ASSIGNING) oder Zeigern (REFERENCE INTO) arbeiten.
Ansonsten würde ich dem PACKAGE-SIZE den Vorzug geben und wie gesagt die nicht mehr benötigen Datensätze gleich wieder löschen.
Weiterer Tipp: Wirklich nur die Felder von der Datenbank selektieren die gebraucht werden und auch die Struktur der internen Tabelle entsprechend verkleinern.
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 4136 / 131 /
956
)
»
Grundsätzlich hat a-d-t ja recht - aber ganz so kategorisch würde ich die Version mit den Workareas trotzdem nicht ablehnen.a-dead-trousers hat geschrieben:Ach ja: Auf keinen Fall LOOP AT ... INTO ... verwenden. Schon gar nicht bei so großen Monster-Tabellen. IMMER mit Feldsymbolen (ASSIGNING) oder Zeigern (REFERENCE INTO) arbeiten.
Denn die der Aussage zugrunde liegende Tatsache ist, dass Assigning deutlich schneller ist als die Zuweisung zu einem Feldsymbol ( bei mir ist das ein Faktor 3-4, den man da gewinnen kann ). Aber ich habe selten ein Programm kennen gelernt bei dem die Zuweisung beim Loop der am Ende Ausschlag gebende Faktor war, sondern dass dies i.A. bei einer Laufzeitanalyse unter "vernachlässigbare Effekte" zu verzeichnen war.
Ich habe mir z.B. gerade mal ein Beispiel gebaut wo ich mit 200.000 Einträgen auf einer recht breiten Tabelle ( MARA ) einen loop mit Feldsymbol und einen Loop mit Workarea gemacht habe.
Ergebnis ( auf diesem Testsystem ): Workarea: 160.000; Feldsymbol: 45.000 Man sieht also dass die Aussage von a-d-t völlig korrekt ist und das Assigning deutlich schneller.
Aber da die o.a. Werte Mikrosekunden sind sprechen wir hier über einen Unterschieb von 0,2 Sekunden zu 0,045 Sekunden. Und wenn ich im Originalposting "Timeout" lese kann ich mir beim besten Willen nicht vorstellen, dass dies tatsächlich zu einer Verbesserung der Gesamtsituation führen wird.
Fuer mich ist die erste entscheidende Frage: Werden alle 200.000 Eintraege gebraucht? Falls Nein, ist dort mein erster Ansatz.
Grundsaetzlich nur die Daten (Zeilen und Spalten) von der Datenbank lesen, die auch gebraucht werden.
Und es gibt eben auch Programme, die viele Daten brauchen und verarbeiten und dadurch gezwungenermassen lange laufen.
Und in solchen Faellen muss man andere Mittel anwenden. Background, Package Size, Commit absetzen... wenn es dann sein muss.
Grundsaetzlich nur die Daten (Zeilen und Spalten) von der Datenbank lesen, die auch gebraucht werden.
Und es gibt eben auch Programme, die viele Daten brauchen und verarbeiten und dadurch gezwungenermassen lange laufen.
Und in solchen Faellen muss man andere Mittel anwenden. Background, Package Size, Commit absetzen... wenn es dann sein muss.
Hallo zusammen,
hier ist der Loop der tatsächlich sehr lange braucht.
Damit ich eine Laufzeitanalyse machen kann habe ich den Report mit geringeren Datensätzen laufen lassen.
Und am meisten Zeit hat die Methode mit diesem Loop gebraucht.
Ich kann die Datei nicht hochladen.
Ich stell den betreffenden Auszug hier rein.
Gruß
coco
hier ist der Loop der tatsächlich sehr lange braucht.
Code: Alles auswählen.
CLEAR ls_prps.
LOOP AT lt_prps_auth INTO ls_prps_auth WHERE display IS NOT INITIAL.
READ TABLE lt_prps INTO ls_prps
WITH KEY objnr = ls_prps_auth-objnr.
IF sy-subrc <> 0.
CONTINUE.
ENDIF.
lsr_objnr-low = ls_prps-objnr.
APPEND lsr_objnr TO er_objnr.
CLEAR: ls_pspnr_info.
MOVE-CORRESPONDING ls_prps TO ls_pspnr_info.
INSERT ls_pspnr_info INTO TABLE et_pspnr_info.
ls_prctr_info-prctr = ls_prps-prctr.
ls_prctr_info-kokrs = ls_prps-pkokr.
COLLECT ls_prctr_info INTO et_prctr_info.
ENDLOOP.
Und am meisten Zeit hat die Methode mit diesem Loop gebraucht.
Ich kann die Datei nicht hochladen.
Ich stell den betreffenden Auszug hier rein.
Code: Alles auswählen.
Treffer Brutto [µsec] Netto [µsec] Brutto [%] Netto [%]
1 198.025.221 189.441.558 94.25 90.17
coco
Versuche doch erst einmal, richtig Informationen zu liefern.
Und Dein Auszug bringt auch keine Erkenntnis.
Mein erster Blick viel sofort auf:
Alle Datensaetze wo das Feld Display nicht initial sind, gehoeren erst gar nicht in die Tabelle.
Oder gibt es einen Grund warum Du es doch machst?
Danach reden wir dann vielleicht noch ueber Move-Corresponding und Collect und Read table ..binary search ... in einem LOOP>
Viel Text, aber keine Infos. Nicht einmal die "Methode" nennst Du beim Namen.Damit ich eine Laufzeitanalyse machen kann habe ich den Report mit geringeren Datensätzen laufen lassen.
Und am meisten Zeit hat die Methode mit diesem Loop gebraucht.
Ich kann die Datei nicht hochladen.
Ich stell den betreffenden Auszug hier rein.
Und Dein Auszug bringt auch keine Erkenntnis.
Mein erster Blick viel sofort auf:
Warum laedst Du Daten in eine interne Tabelle, die Du in dem Loop ueberhaupt nicht benoetigst?LOOP AT lt_prps_auth INTO ls_prps_auth WHERE display IS NOT INITIAL.
Alle Datensaetze wo das Feld Display nicht initial sind, gehoeren erst gar nicht in die Tabelle.
Oder gibt es einen Grund warum Du es doch machst?
Danach reden wir dann vielleicht noch ueber Move-Corresponding und Collect und Read table ..binary search ... in einem LOOP>
Beitrag
von black_adept (Top Expert / 4136 / 131 /
956
)
»
Sind die beiden Tabelle lt_prps_auth und lt_prps beide sehr groß? Wenn ja wird dein Laufzeitproblem mindestens durch die oben angegebenen Programmzeilen verursacht werden. ( 200.000 x 200.000 = 40.000.000.000 )c oco hat geschrieben:Code: Alles auswählen.
... LOOP AT lt_prps_auth INTO ls_prps_auth WHERE display IS NOT INITIAL. READ TABLE lt_prps INTO ls_prps WITH KEY objnr = ls_prps_auth-objnr. ... ENDLOOP.
und könnte dadurch gelöst werden, dass beide Tabellen mit einem sinnvollen Schlüssel definiert werden und mit diesem auch auf sie zugegriffen wird.
Beitrag
von Frank Dittrich (Expert / 674 / 0 /
15
)
»
Garantiert hast Du recht, und nahezu die komplette Laufzeit in der Loop geht fürblack_adept hat geschrieben:c oco hat geschrieben: Sind die beiden Tabelle lt_prps_auth und lt_prps beide sehr groß? Wenn ja wird dein Laufzeitproblem mindestens durch die oben angegebenen Programmzeilen verursacht werden. ( 200.000 x 200.000 = 40.000.000.000 )
und könnte dadurch gelöst werden, dass beide Tabellen mit einem sinnvollen Schlüssel definiert werden und mit diesem auch auf sie zugegriffen wird.
Code: Alles auswählen.
READ TABLE lt_prps INTO ls_prps
WITH KEY objnr = ls_prps_auth-objnr.
Wenn man bei Tabelle lt_prps die sequentielle Suche vermeidet (je nach sonstiger Verwendung der itab und SAP-Release unterschiedliche Möglichkeiten (SORTED oder HASHED TABLE mit passendem Key, oder einfach auch die STANDARD TABLE vor der LOOP einmal passend sortieren und dann mit BINARY SEARCH drauf zugreifen oder mal die Tipps&Tricks-Section der SE30 nach der performanten Verarbeitung interner Tabellen in verschachtelten LOOPs durchsuchen) wird diese LOOP deutlich schneller.
Das hilft aber nichts, wenn das Ziel dann eine Range mit ca. 100000 EInträgen ist.
Für SELECTs mit WHERE field IN range ... kann man das vergessen, weil das SELECT-Statement zu groß wird.
Und wenn man die Range in LOOP AT itab WHERE field IN range ... verwendet und itab auch wieder ca. 200000 EInträge hat, hat man das jetzige Poblem nur an eine andere Stelle verschoben.
Die Frage ist also, was soll eigentlich erreicht werden, wie sieht das Mengengerüst für die zu analysierenden Tabellen aus, welche Menge Daten muss am Ende selektiert werden, usw...
Frank
Nur als Anmerkung: der READ TABLE ... WITH KEY macht nicht notwendigerweise eine sequentielle Suche. Ist in dem Beispiel LT_PRPS eine SORTED oder HASHED TABLE mit dem Schlüssel OBJNR wird dieser Schlüssel auch verwendet, d.h. es findet eine binäre Suche bzw. ein direkter Schlüsselzugriff statt.Frank Dittrich hat geschrieben:Garantiert hast Du recht, und nahezu die komplette Laufzeit in der Loop geht fürblack_adept hat geschrieben:c oco hat geschrieben: Sind die beiden Tabelle lt_prps_auth und lt_prps beide sehr groß? Wenn ja wird dein Laufzeitproblem mindestens durch die oben angegebenen Programmzeilen verursacht werden. ( 200.000 x 200.000 = 40.000.000.000 )
und könnte dadurch gelöst werden, dass beide Tabellen mit einem sinnvollen Schlüssel definiert werden und mit diesem auch auf sie zugegriffen wird.drauf.Code: Alles auswählen.
READ TABLE lt_prps INTO ls_prps WITH KEY objnr = ls_prps_auth-objnr.
Wenn man bei Tabelle lt_prps die sequentielle Suche vermeidet (je nach sonstiger Verwendung der itab und SAP-Release unterschiedliche Möglichkeiten (SORTED oder HASHED TABLE mit passendem Key, oder einfach auch die STANDARD TABLE vor der LOOP einmal passend sortieren und dann mit BINARY SEARCH drauf zugreifen oder mal die Tipps&Tricks-Section der SE30 nach der performanten Verarbeitung interner Tabellen in verschachtelten LOOPs durchsuchen) wird diese LOOP deutlich schneller.
Zu groß nicht. Der Kernel macht aber "5-er Häppchen" daraus, d.h. es finden int(lines(range)/5)+1 Zugriffe auf die DB statt. Macht die Abfrage aber auch nicht schneller...Frank Dittrich hat geschrieben: Das hilft aber nichts, wenn das Ziel dann eine Range mit ca. 100000 EInträgen ist.
Für SELECTs mit WHERE field IN range ... kann man das vergessen, weil das SELECT-Statement zu groß wird.
ACK.Frank Dittrich hat geschrieben: Und wenn man die Range in LOOP AT itab WHERE field IN range ... verwendet und itab auch wieder ca. 200000 EInträge hat, hat man das jetzige Poblem nur an eine andere Stelle verschoben.
Sehe ich auch so.Frank Dittrich hat geschrieben: Die Frage ist also, was soll eigentlich erreicht werden, wie sieht das Mengengerüst für die zu analysierenden Tabellen aus, welche Menge Daten muss am Ende selektiert werden, usw...
Frank
Basierend auf dem Coding-Ausschnitt würde ich erstmal prüfen, ob LT_PRPS als SORTED oder sogar HASHED TABLE definiert werden kann. Alternativ (wenn das eben nicht geht) vorher ein SORT auf die Tabelle und der READ TABLE mit BINARY SEARCH. Das sollte schon mal Druck vom Kessel nehmen.
Grüße,
Haubi
Hallo,
erstmal vielen Dank für die zahlreichen Comments.
Ich versuche jetzt mal sie der Reihe nach zu beantworten.
Die Methode heißt: Authority_check_prctr.
Es geht um Berechtigungsprüfungen auf Profitcenterebene. Dann Berechtigungsprüfungen auf Psp-Elemente.
Da hast du Recht!!! Das war auch mein Ansatz. Wenn Display initial ist, dann werfe ich sie gleich raus. Aber wenn ein User alle Berechtigungen hat, dann wird das nicht viel nützen, weil er dann alle 200.000 Datensätze trotzdem hat.
In der Tabelle lt_prps_auth sind alle PSP-Elemente aus lt_prps drin, die gekennzeichnet sind, ob sie die Berechtigung haben oder nicht.
Dann werden zur Weiterverarbeitung alle Psp-Elemente in die Range er_objnr gefüllt. Nur die Objektnummern. Mit diesen wird später ein Select auf die Stammdatentabelle gemacht.
Diese Felder werden wiederum für die Weiterverarbeitung in die et_pspnr_info gefüllt. Wird bei Budgetierungen verwendet.
Zum Merken, welche Profitcenter da sind werden die vorhandenen Profitcenter auch in einer internen Tabelle et_prctr_info gesammelt.
Zur Übersicht aller Profitcenter von allen Stammdaten.
lt_prps ist eine Standardtabelle mit Schlüssel PRPS. PRPS gibts nicht in der Tabelle lt_prps_auth.
Viele Grüße
coco
P.s. zu meiner Verteidigung: Ich habe die Methode nicht geschrieben, ich soll sie jetzt so umschreiben, dass sie performanter wird.
erstmal vielen Dank für die zahlreichen Comments.
Ich versuche jetzt mal sie der Reihe nach zu beantworten.
Die Methode heißt: Authority_check_prctr.
Es geht um Berechtigungsprüfungen auf Profitcenterebene. Dann Berechtigungsprüfungen auf Psp-Elemente.
[/quote]Unit605 hat geschrieben: Mein erster Blick viel sofort auf:
Warum laedst Du Daten in eine interne Tabelle, die Du in dem Loop ueberhaupt nicht benoetigst?LOOP AT lt_prps_auth INTO ls_prps_auth WHERE display IS NOT INITIAL.
Alle Datensaetze wo das Feld Display nicht initial sind, gehoeren erst gar nicht in die Tabelle.
Da hast du Recht!!! Das war auch mein Ansatz. Wenn Display initial ist, dann werfe ich sie gleich raus. Aber wenn ein User alle Berechtigungen hat, dann wird das nicht viel nützen, weil er dann alle 200.000 Datensätze trotzdem hat.
ja sie sind beide gleich groß.black_adept hat geschrieben:Sind die beiden Tabelle lt_prps_auth und lt_prps beide sehr groß? Wenn ja wird dein Laufzeitproblem mindestens durch die oben angegebenen Programmzeilen verursacht werden. ( 200.000 x 200.000 = 40.000.000.000 )c oco hat geschrieben:Code: Alles auswählen.
... LOOP AT lt_prps_auth INTO ls_prps_auth WHERE display IS NOT INITIAL. READ TABLE lt_prps INTO ls_prps WITH KEY objnr = ls_prps_auth-objnr. ... ENDLOOP.
und könnte dadurch gelöst werden, dass beide Tabellen mit einem sinnvollen Schlüssel definiert werden und mit diesem auch auf sie zugegriffen wird.
In der Tabelle lt_prps sind alle PSP-Elemente drin.Frank Dittrich hat geschrieben: Die Frage ist also, was soll eigentlich erreicht werden, wie sieht das Mengengerüst für die zu analysierenden Tabellen aus, welche Menge Daten muss am Ende selektiert werden, usw...
Frank
In der Tabelle lt_prps_auth sind alle PSP-Elemente aus lt_prps drin, die gekennzeichnet sind, ob sie die Berechtigung haben oder nicht.
Dann werden zur Weiterverarbeitung alle Psp-Elemente in die Range er_objnr gefüllt. Nur die Objektnummern. Mit diesen wird später ein Select auf die Stammdatentabelle gemacht.
Code: Alles auswählen.
ls_pspnr_info-posid = ls_prps-posid.
ls_pspnr_info-pspnr = ls_prps-pspnr.
ls_pspnr_info-objnr = ls_prps-objnr.
ls_pspnr_info-prctr = ls_prps-prctr.
ls_pspnr_info-post1 = ls_prps-post1.
ls_pspnr_info-psphi = ls_prps-psphi.
ls_pspnr_info-pkokr = ls_prps-pkokr.
ls_pspnr_info-izwek = ls_prps-izwek.Zum Merken, welche Profitcenter da sind werden die vorhandenen Profitcenter auch in einer internen Tabelle et_prctr_info gesammelt.
Zur Übersicht aller Profitcenter von allen Stammdaten.
Code: Alles auswählen.
ls_prctr_info-prctr = ls_prps-prctr.
ls_prctr_info-kokrs = ls_prps-pkokr.[/quote]Haubi hat geschrieben: Nur als Anmerkung: der READ TABLE ... WITH KEY macht nicht notwendigerweise eine sequentielle Suche. Ist in dem Beispiel LT_PRPS eine SORTED oder HASHED TABLE mit dem Schlüssel OBJNR wird dieser Schlüssel auch verwendet, d.h. es findet eine binäre Suche bzw. ein direkter Schlüsselzugriff statt.
lt_prps ist eine Standardtabelle mit Schlüssel PRPS. PRPS gibts nicht in der Tabelle lt_prps_auth.
Viele Grüße
coco
P.s. zu meiner Verteidigung: Ich habe die Methode nicht geschrieben, ich soll sie jetzt so umschreiben, dass sie performanter wird.
Hallo,
hier ist mein Lösungsansatz: ich konnte es noch nicht testen, da wir auf dem Testsystem keine Massendaten haben.
Und es fehlt noch die Range Tabelle et_prctr_info.
Diese wird collected. Da weiß ich nicht, wie ich das ohne Loop lösen soll.
Viele Grüße
coco
Viele Grüße
coco
hier ist mein Lösungsansatz: ich konnte es noch nicht testen, da wir auf dem Testsystem keine Massendaten haben.
Code: Alles auswählen.
DATA: lt_prps TYPE STANDARD TABLE OF prps. --> Soll ich es vom Typ Hash Table machen obwohl ich unten mit Binary Search suche??
DELETE lt_prps_auth WHERE display IS NOT INITIAL. --> alles was Berechtigung hat fliegt raus
LOOP AT lt_prps_auth ASSIGNING <ls_prps_auth>.
READ TABLE lt_prps TRANSPORTING NO FIELDS WITH KEY objnr = <ls_prps_auth>-objnr BINARY SEARCH.
IF sy-subrc = 0. --> aus der Tabelle sollen alle Objekte rausfliegen, die keine Berechtigung haben
DELETE lt_prps INDEX sy-tabix.
ENDIF.
ENDLOOP.
IF lt_prps IS NOT INITIAL.
MOVE-CORRESPONDING lt_prps to lt_pspnr_info.
IF sy-subrc = 0.
SELECT objnr AS low --> hier bin ich mir unsicher, ob das was bringt
INTO CORRESPONDING FIELDS OF TABLE er_objnr
FROM prps
FOR ALL ENTRIES IN lt_prps
WHERE objnr = lt_prps-objnr.
ls_objnr-sign = 'I'.
ls_objnr-option = 'EQ'.
MODIFY er_objnr FROM ls_objnr
TRANSPORTING sign option
WHERE sign NE 'I'.
ENDIF.
Code: Alles auswählen.
ls_prctr_info-prctr = ls_prps-prctr.
ls_prctr_info-kokrs = ls_prps-pkokr.
COLLECT ls_prctr_info INTO et_prctr_info.Viele Grüße
coco
Viele Grüße
coco
Anmerkung:
Der Befehl AUTHORITY-CHECK ist recht teuer. Wenn es um Performance bei großen Datenmengen und vielen Authority-Checks geht, ist es empfehlenswert, die Ergebnisse von Berechtigungsprüfungen in einer internen Tabelle zu Puffern, um dann wiederkehrende Authority-Checks gegen diesen Puffer zu machen. (Wir haben uns dazu eine zentrale Methode geschrieben, die das macht)
Außerdem ist es oft ratsam (leider nicht immer möglich), sich vor der eigentlichen Datenbeschaffung Range-Tabellen mit den erlaubten Werten aufzubauen und diese dann in den folgenden Selects als Bedingung mitzugeben, da dann oft eine erheblich reduzierte Datenmenge übrigbleibt.
Der Befehl AUTHORITY-CHECK ist recht teuer. Wenn es um Performance bei großen Datenmengen und vielen Authority-Checks geht, ist es empfehlenswert, die Ergebnisse von Berechtigungsprüfungen in einer internen Tabelle zu Puffern, um dann wiederkehrende Authority-Checks gegen diesen Puffer zu machen. (Wir haben uns dazu eine zentrale Methode geschrieben, die das macht)
Außerdem ist es oft ratsam (leider nicht immer möglich), sich vor der eigentlichen Datenbeschaffung Range-Tabellen mit den erlaubten Werten aufzubauen und diese dann in den folgenden Selects als Bedingung mitzugeben, da dann oft eine erheblich reduzierte Datenmenge übrigbleibt.
Code: Alles auswählen.
DATA: lt_prps TYPE STANDARD TABLE OF prps. --> Soll ich es vom Typ Hash TABLE machen obwohl ich unten mit BINARY SEARCH suche??
DELETE lt_prps_auth WHERE display IS NOT INITIAL. --> alles was Berechtigung hat fliegt raus
LOOP AT lt_prps_auth ASSIGNING <ls_prps_auth>.
READ TABLE lt_prps TRANSPORTING NO FIELDS WITH KEY objnr = <ls_prps_auth>-objnr BINARY SEARCH.Wenn Du den Zusatz BINARY SEARCH machst muss die Tabelle vorher von Dir sortiert werden. Leider schreibst Du nicht, wie die Tabelle aufgebaut wird und wo Du sie sonst benutzt.
Hashed hat den Vorteil, dass die Zugriffszeit über den Schlüssel (also hier OBJNR) konstant ist. Der BINARY SEARCH bzw. Schlüsselzugriff auf SORTED TABLE ist im direkten Vergleich langsamer. Nicht viel, kann sich hier aber schon bemerkbar machen (200.000 x 200.000 Zugriffe...).
Der SELECT im Nachgang hat auf jeden Fall das von mir oben erwähnte 5er-Problem: bei der Selektion mit FOR ALL ENTRIES (ebenso wie IN <rangetab>) werden immer 5 Einträge der angegebenen ITab für einen DB-Zugriff verwendet. Gehen wir im schlimmsten Fall von Deinen 200.000 Einträgen aus hast Du 40.000 Roundtrips zur Datenbank. Das wird sich aber nach Lage der Dinge sowieso nicht vermeiden lassen...
Wenn Du aber vorhast, mit ER_OBJNR auch wieder eine DB-Abfrage zu machen verdoppelt sich Dein Problem. Eventuell wäre es also besser, die Objektnummern direkt aus LT_PRPS in ER_OBJNR zu übernehmen - ohne DB-Zugriff.
Grüße,
Haubi
Vergleichbare Themen
6
Antw.
Antw.
2127
Views
Views
1
Antw.
Antw.
2638
Views
Views
Loop Loop & Loop - wie am besten eine Verschachtelung vermeiden?
von Sonne1234 » 05.02.2020 16:29 • Verfasst in ABAP® für Anfänger
von Sonne1234 » 05.02.2020 16:29 • Verfasst in ABAP® für Anfänger
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.