Maximale Anzahl der Einträge in einem internen Tabelle

Re: Maximale Anzahl der Einträge in einem internen Tabelle

Hallo, die Doku wird sicher weiter helfen

https://help.sap.com/doc/abapdocu_752_i ... t_itab.htm

Gruß Wolfgang

Re: Maximale Anzahl der Einträge in einem internen Tabelle

Das beste wäre es, wenn du es direkt über den Select machen könntest: Wenn die interne Tabelle gegeben ist: In dem Link von Wolfgang sind ja jede Menge Codebeispiele vorhanden...

eine andere Möglichkeit wäre, mit einem LOOP über die Tabelle alle vorkommenden Orte in einer anderen Tabelle zu sammeln.

Re: Maximale Anzahl der Einträge in einem internen Tabelle

Das klingt wie eine Herausforderung für black_adept: Löse dieses Problem einzeilig mit dem REDUCE-Befehl unter der Maßgabe, dass die am häufigsten auftretende Stadt nebst der Anzahl ihres Auftretens als zweispaltige Struktur zurückgeliefert wird, wobei vorher nicht bekannt ist, welche Stadt das sein wird. (Für Typisierungen sind natürlich weitere, vorhergehende Programmzeilen erlaubt.)

Auf die Schnelle weiß ich nicht, wie das bewerkstelligt werden kann, aber mein Gefühl sagt mir, dass solch REDUCE möglich ist, und die Erfahrung sagt mir, dass black_adept ihn finden kann. 😁

Wenn ich es selbst machen müsste, würde ich wahrscheinlich versuchen, zwei REDUCEs ineinander zu schachteln: Der innere erzeugt eine zweispaltige Tabelle (Stadt;Auftretensanzahl) und der äußere zieht daraus die am häufigsten auftretende Stadt nebst deren Auftretensanzahl. Das ist, wie gesagt, noch nicht zu Ende gedacht und nicht notwendigerweise der richtige oder einfachste Ansatz.

Re: Maximale Anzahl der Einträge in einem internen Tabelle

Mir gefällt die Lösung! 😁 Wobei ich REDUCE i( INIT count = 0 nicht so mag. Ich finde es schöner, den Typ der INIT-Variable explizit anzugeben, was nebenbei den Effekt hat, dass man vorne eine Raute nutzen kann, also REDUCE #( INIT count TYPE i

"Schön" oder "nicht schön" ist eine Frage der Gewohnheit, glaube ich. Wir empfinden die Syntax als "nicht schön", weil wir sie nicht gewohnt sind. Ich kann mich noch erinnern, als ich zum ersten Mal den SWITCH-Befehl gesehen habe. Meine reflexartige Reaktion war: "Wer braucht denn sowas?" Später wollte ich ihn nicht mehr missen, aber FOR war mir definitiv zu kompliziert.

Was soll ich sagen, mittlerweile nutze ich FOR sehr gerne, hatte bis vor kurzem aber noch gehörigen Respekt vor REDUCE. An den gewöhne ich mich jetzt gerade, und Dein nettes Beispiel ist eine Anregung für mich, mich auch mal mit dem GROUPS des FOR auseinanderzusetzen, das ich bislang noch nicht auf dem Schirm habe.

Je mehr man aber selber in dieser neuen Syntax programmiert, desto besser kann man sie lesen, und ich behaupte, wer das in sein geistiges Repertoire aufgenommen hat und bei jeder sich bietenden Gelegenheit nutzt, der liest Deine Lösung einfach runter und versteht auf Anhieb, wie sie funktioniert. Es ist also nicht so, dass Deine Lösung nicht schön wäre, sondern unser Auge muss geschult werden, ihre Schönheit zu sehen. Wer dazu nicht bereit ist (und das sind leider viele), der wird natürlich immer auf dem Standpunkt beharren, dass früher alles besser gewesen ist.

Re: Maximale Anzahl der Einträge in einem internen Tabelle

Das wird ein syntaktisches Zugeständnis an den Umstand sein, dass man GROUPS mit oder ohne Gruppenvariable (Gruppenschlüsselbindung oder Repräsentantenbindung) angeben kann. In beiden Fällen wird wohl der Einheitlichkeit halber die Workarea hinter dem GROUP BY referenziert. In Deinem Alternativbeispiel referenzierst Du stattdessen den Tabellennamen selbst. Bedenke aber, dass die Workarea nicht identisch, sondern nur konvertierbar typisiert werden muss wie eine Zeile der internen Tabelle! Das gleiche gilt auch bei LOOP AT .. GROUP BY. Ich persönlich finde es sogar redundant, wie von Dir vorgeschlagen den Tabellennamen anzugeben; beim GROUP BY eines SELECTs macht man das ja auch nicht. Von mir aus könnte man also sogar schreiben:
Aber dann würdest Du nach der Tabellenspalte gruppieren, obwohl Du bei der Repräsentantenbindung im nachfolgenden Code mit der Workarea-Spalte als Gruppenspalte arbeitest, die womöglich ganz anders heißt! Das wird der SAP nicht gefallen haben. Deshalb (so meine Vermutung) haben sie gesagt, die GROUP BY-Klausel muss sich immer auf die Spaltennamen der Workarea-Variable beziehen, aus der Dein Gruppenfeld dann Spaltennamen und Typisierung erbt. Und daraus folgt, dass die Workarea-Variable immer angegeben werden muss, auch wenn ihr Wert bei der Gruppenschlüsselbindung stets initial ist.