Code: Alles auswählen.
TYPES: BEGIN OF lty_gt_vbakvbap,
vbeln TYPE vbeln, " Vertriebsbelegnummer (VBAK)
auart TYPE auart, " Verkaufsbelegart (VBAK)
erdat TYPE erdat, " Angelegt am (VBAK)
vkorg TYPE vkorg, " Verkaufsorganisation (VBAK)
vkbur TYPE vkbur, " Verkaufsbüro (VBAK)
vkgrp TYPE vkgrp, " Verkäufergruppe (VBAK)
posnr TYPE posnr_va, " Position (VBAP)
matnr TYPE matnr, " Materialnnummer (VBAP)
arktx TYPE arktx, " Bezeichnung (VBAP)
werks TYPE werks_ext, " Werk (VBAP)
kwmeng TYPE kwmeng, " kumulierte Menge (VBAP)
meins TYPE meins, " Basismengeneinheit (VBAP)
END OF lty_gt_vbakvbap.
DATA: gt_vbakvbap TYPE SORTED TABLE OF lty_gt_vbakvbap WITH NON-UNIQUE KEY vbeln.
SELECT * INTO CORRESPONDING FIELDS OF TABLE gt_vbakvbap
FROM vbak AS a
INNER JOIN vbap AS b ON a~vbeln = b~vbeln
WHERE a~audat IN s_audat
AND a~auart IN s_auart
AND b~werks IN s_werks
ORDER BY a~vbeln.
Code: Alles auswählen.
* Bestelldaten aus EKBE (mithilfe von EKKN) selektieren
SELECT * INTO CORRESPONDING FIELDS OF TABLE gt_ekbeekkn
FROM ekbe AS a
INNER JOIN ekkn AS b ON a~ebeln = b~ebeln AND a~ebelp = b~ebelp
FOR ALL ENTRIES IN gt_vbakvbap
WHERE b~vbeln = gt_vbakvbap-vbeln
AND a~bewtp = 'E'. " Bestellentwicklungstyp: nur Wareneingang
SORT gt_ekbeekkn BY vbeln ebeln ebelp.
* Zusammenführen der beiden internen Tabellen
LOOP AT gt_vbakvbap INTO wa_vbakvbap.
wa_outtab-vbeln = wa_vbakvbap-vbeln.
wa_outtab-vbeln = wa_vbakvbap-vbeln.
wa_outtab-auart = wa_vbakvbap-auart.
wa_outtab-audat = wa_vbakvbap-audat.
wa_outtab-vkorg = wa_vbakvbap-vkorg.
wa_outtab-vkbur = wa_vbakvbap-vkbur.
wa_outtab-vkgrp = wa_vbakvbap-vkgrp.
wa_outtab-posnr = wa_vbakvbap-posnr.
wa_outtab-matnr = wa_vbakvbap-matnr.
wa_outtab-arktx = wa_vbakvbap-arktx.
wa_outtab-werks = wa_vbakvbap-werks.
wa_outtab-kwmeng = wa_vbakvbap-kwmeng.
wa_outtab-meins = wa_vbakvbap-meins.
LOOP AT gt_ekbeekkn INTO wa_ekbeekkn WHERE vbeln = wa_vbakvbap-vbeln. " Bestellung zur VBELN vorhanden, Daten einfügen
wa_outtab-budat = wa_ekbeekkn-budat.
wa_outtab-ebeln = wa_ekbeekkn-ebeln.
wa_outtab-ebelp = wa_ekbeekkn-ebelp. " keine Bestellung vorhanden, Felder leer lassen
ENDLOOP.
APPEND wa_outtab TO gt_outtab.
CLEAR wa_outtab.
ENDLOOP.
Code: Alles auswählen.
LOOP AT gt_ekbeekkn INTO wa_ekbeekkn WHERE vbeln = wa_vbakvbap-vbeln AND ebelp = wa_vbakvbap-posnr+1(5).
Ich habe das Konzept von unique und non-unique noch nicht ganz verstanden.DeathAndPain hat geschrieben:Warum hast Du eigentlich den Schlüssel von gt_vbakvbap als non-unique definiert? Der ist doch garantiert unique, da Du Aufträge aus der VBAK liest, und die hat vbeln als Primärschlüssel!
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Legxis
Das ist ein nicht zu unterschätzender Vorteil von internen Tabellen mit qualifiziertem Schlüssel.DeathAndPain hat geschrieben:...während es bei einem unique-Schlüssel nur einen einzigen Eintrag mit diesem Schlüssel (d.h. dieser Kombination von Spaltenwerten) in Deiner internen Tabelle geben darf, sonst dumpt's. Das ist sehr nützlich zum Auffinden von Programmierfehlern: Mich haben schon häufig Dumps wegen mehrfacher Einträge mit demselben Schlüssel, die ich bei Programmerstellung für unmöglich gehalten habe, auf programmlogikrelevante Denkfehler meinerseits gebracht.
Ich meinte so das Übliche "marctab type standard table of marc". Aber war klar, dass der Einwand kommtDeathAndPain hat geschrieben:Bei Standardtabellen kannste auch einen qualifizierten Schlüssel angeben.
Code: Alles auswählen.
DATA MARCTAB TYPE STANDARD TABLE OF MARC WITH KEY MATNR.
Wann war Speicherverbrauch bzw. der Gewinn den du hier erzielst das letzte Mal ein Faktor für dich?DeathAndPain hat geschrieben:...Ich habe es mir zur Angewohnheit gemacht, bei der Definition von Standardtabellen WITH EMPTY KEY dazuzuschreiben. Bringt Klarheit und spart ein paar Bytes.
Die braucht man eigentlich dauernd, wenn man dem User die Möglichkeit einer Sortierung geben will. Oder wenn die Reihenfolge einfach wichtig ist aber eben nicht dem (üblichen) Schlüssel entspricht (z.B. ATP-Rückgabe von SAP-StandardFuBa ). Oder wenn man schlüsselverändernde Operationen erlauben will. Oder , oder , oder.....DeathAndPain hat geschrieben:Ab und zu braucht man Standardtabellen ja doch, etwa für Table Controls, ALV-Ausgabetabellen oder wenn man CSV-Dateien einliest oder ausgibt.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 3):
a-dead-trousers • DeathAndPain • gtoXX
Ich habe das immer im Auge, auch wenn es nur um Kleinkram geht. Ist ein Stück Perfektionismus auf meiner Seite. Aber natürlich nur, wenn der Aufwand im überschaubaren Rahmen liegt. "WITH EMPTY KEY" hinzuschreiben ist wenig aufwendig genug für meinen Geschmack. Auch den FREE-Befehl setze ich dann und wann mal ein, um Puffertabellen zu leeren, die ihren Zweck für die Berechnung meiner Ergebnisse erfüllt haben.Wann war Speicherverbrauch bzw. der Gewinn den du hier erzielst das letzte Mal ein Faktor für dich?
Was eigentlich nur in den von mir genannten Fällen, nämlich bei Ausgabetabellen, der Fall ist.Die braucht man eigentlich dauernd, wenn man dem User die Möglichkeit einer Sortierung geben will.
Bei Datenbanktabellen gehen die nicht, aber sind die auch bei internen Tabellen nicht zulässig? Wäre ich zumindest nie drüber gestolpert, dass mir deswegen ein MODIFY auf die Bretter gegangen wäre. Wobei es natürlich auch sein kann, dass ich sowas nie versucht habe, weil es inhaltlich nur selten Sinn machen dürfte.Oder wenn man schlüsselverändernde Operationen erlauben will.
Im Prinzip würde ich das auch so sehen, nur bei den Hashtabellen habe ich große Zweifel am Sinn. Nachdem ich seinerzeit meine Performance-Tests durchgeführt habe (ich berichtete hier) und dabei zu dem Ergebnis gelangt bin, dass das Füllen von Hashtabellen so lange dauert, dass man im Verhältnis zu der Zeilenanzahl irrsinnig viele Lesezugriffe brauchen würde, um verglichen mit sortierten Tabellen durch Lesezeitersparnis die zum Füllen der Tabelle (Berechnen der Hashwerte) benötigte Zeit wieder reinzuholen, bin ich überzeugt, dass es in meinen Programmen niemals einen Fall geben wird, bei dem die Hashtabelle die bessere Wahl wäre. Zumal ich feststellen musste, dass die Suchzeit in Hashtabellen noch nicht mal ganz konstant ist, sondern gleichfalls mit der Zeilenanzahl ansteigt, was von der Theorie her ja nicht so sein sollte (wenn auch nur in sehr moderatem Umfang).Jede Tabellenart hat ihre Daseinsberechtigung, man muss nur wissen was man vorhat und dann den richtigen Typ auswählen.
Aber die anderen Tabellen, die ich benutze, haben Positionsnummern und damit mehrere Einträge mit derselben VBELN.DeathAndPain hat geschrieben:In Deinem Fall ist der Schlüssel VBELN. Das ist der Primärschlüssel der Tabelle VBAK, soll heißen, es kann in der VBAK keine zwei Einträge mit demselben VBELN geben (da Datenbank-Primärschlüssel immer unique sind)