gelöst Selektion aus Datenbanktabelle mithilfe von interner Tabelle

[Legxis]

Hallo!

Ich muss einen sehr ausführlichen Report erstellen. Bisher habe ich immer Joins benutzt, dies ist aber in dem Fall nicht möglich, da es zu viele Tabellen und Vorraussetzungen gibt. Daher benötige ich eine Methode, wie man nach und nach die Daten selektieren kann.

Ich habe mit einem Select circa ein Drittel der Daten selektiert, jetzt möchte ich die anderen hinzufügen, allerdings kann man ja bei einem Selekt nicht die interne Tabelle als WHERE Bedingung nehmen, um mit den Daten aus der internen Tabelle zu vergleichen.

Zum Verständnis der Code:

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.

Nun hätte ich z.B. noch gerne Daten aus der EKBE wie EBELN, EBEP und BUDAT. (Und VGABE muss auf 1 gesetzt sein, da es nur Wareneingang sein soll.) Die EBELN zu meinen VBELN kann ich über die Tabelle EKKN finden.
Aber wie setze ich das um, da meine VBELN doch in einer internen Tabelle stehen, wie selektiere ich anhand davon von einer Datenbanktabelle?

Ich danke im Vorraus für Hilfe, ich bin noch sehr neu in ABAP und habe wie gesagt bisher immer nur Joins benutzt.

[ewx]

SELECT ... FOR ALL ENTRIES

[Legxis]

Ich bin nun soweit gekommen:

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.

Mein Problem ist jetzt, dass in meiner outtab (wenn Bestelldaten eingefügt werden) EBELP immer die letzte Positionsnummer ist, weil immer mehrmals durch den inneren Loop gegangen wird, bis die VBELN unterschiedlich sind.
Aber wenn ich in den inneren Loop einen Append tue, dann wird, nachdem der Loop verlassen wird, nochmal Appended, also doppelte Einträge gemacht.
Ich weiß nicht, wie ich das jetzt lösen soll.

[ralf.wenzel]

Der APPEND unter dem LOOP muss raus, so einfach ist das.


Ralf

[DeathAndPain]

Und dafür muss er in den inneren LOOP rein, da Du, wenn ich Dich richtig verstanden habe, alle Positionen in Deiner Ausgabetabelle haben willst.

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!

[Legxis]

Ich wollte in der Endtabelle auch die Einträge der ersten Tabelle haben, bei denen es keine Daten aus der zweiten gab, nicht nur die Einträge, zu denen beide Tabellen Daten haben.
Deshalb funktionierte es nicht, das APPEND in den inneren LOOP zu tun.
Mein Problem wurde gelöst indem ich auch die Positionsnummer geprüft habe (dafür muss Länge angepasst werden).

Code: Alles auswählen

  LOOP AT gt_ekbeekkn INTO wa_ekbeekkn WHERE vbeln = wa_vbakvbap-vbeln AND ebelp = wa_vbakvbap-posnr+1(5).  

Die Daten aus weiteren Tabellen habe ich dann ebenfalls mit einen SELECT FOR ALL ENTRIES und den geschachtelten LOOPS umgesetzt, dann allerdings statt APPEND natürlich MODIFY verwendet.
Ich bin noch nicht ganz fertig, mal schauen ob alles richtig ist.

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!

Ich habe das Konzept von unique und non-unique noch nicht ganz verstanden.

[ralf.wenzel]

Ein NON-UNIQUE-Schlüssel darf mehrfach vorkommen.


Ralf

[DeathAndPain]

...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.

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). Da Du Deine interne Tabelle aus der VBAK füllst, ist dies daher auch für Deine interne Tabelle garantiert, und Du solltest den Schlüssel als unique definieren.

Klar, non-unique funktioniert immer, aber man beraubt sich damit eines wertvollen Kontrollmechanismusses.

[ralf.wenzel]

...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.

Das ist ein nicht zu unterschätzender Vorteil von internen Tabellen mit qualifiziertem Schlüssel.

Ralf *kann Standardtabellen nicht leiden

[DeathAndPain]

Bei Standardtabellen kannste auch einen qualifizierten Schlüssel angeben.

[ralf.wenzel]

Bei Standardtabellen kannste auch einen qualifizierten Schlüssel angeben.

Ich meinte so das Übliche "marctab type standard table of marc". Aber war klar, dass der Einwand kommt


Ralf

[DeathAndPain]

Ich auch. Du kannst ja Deinen Code erweitern:

Code: Alles auswählen

DATA MARCTAB TYPE STANDARD TABLE OF MARC WITH KEY MATNR.

Dann ist es syntaktisch wie bei sortierten Tabellen (mal abgesehen vom nicht verwendbaren Schlüsselwort unique). Einen Nutzen habe ich bei Schlüsseln auf Standardtabellen freilich nie so recht gesehen. Ich glaube, bei den AT-Events in LOOPs oder bei COLLECT bringen sie was. Ansonsten ist es aber eigentlich Speicherverschwendung, dass bei Standardtabellen defaultmäßig ein Schlüssel angelegt wird. Ich habe es mir zur Angewohnheit gemacht, bei der Definition von Standardtabellen WITH EMPTY KEY dazuzuschreiben. Bringt Klarheit und spart ein paar Bytes.

Ab und zu braucht man Standardtabellen ja doch, etwa für Table Controls, ALV-Ausgabetabellen oder wenn man CSV-Dateien einliest oder ausgibt.

[black_adept]

...Ich habe es mir zur Angewohnheit gemacht, bei der Definition von Standardtabellen WITH EMPTY KEY dazuzuschreiben. Bringt Klarheit und spart ein paar Bytes.

Wann war Speicherverbrauch bzw. der Gewinn den du hier erzielst das letzte Mal ein Faktor für dich?

Ab und zu braucht man Standardtabellen ja doch, etwa für Table Controls, ALV-Ausgabetabellen oder wenn man CSV-Dateien einliest oder ausgibt.

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.....
Jede Tabellenart hat ihre Daseinsberechtigung, man muss nur wissen was man vorhat und dann den richtigen Typ auswählen.

[DeathAndPain]

Wann war Speicherverbrauch bzw. der Gewinn den du hier erzielst das letzte Mal ein Faktor für dich?

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.

Die braucht man eigentlich dauernd, wenn man dem User die Möglichkeit einer Sortierung geben will.

Was eigentlich nur in den von mir genannten Fällen, nämlich bei Ausgabetabellen, der Fall ist.

Oder wenn man schlüsselverändernde Operationen erlauben 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.

Jede Tabellenart hat ihre Daseinsberechtigung, man muss nur wissen was man vorhat und dann den richtigen Typ auswählen.

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).

[Legxis]

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)

Aber die anderen Tabellen, die ich benutze, haben Positionsnummern und damit mehrere Einträge mit derselben VBELN.