Spalten Interner Tabellen nacheinander auslesen.

Spalten Interner Tabellen nacheinander auslesen.

Hey Ihr!
Ich habe eine Frage und zwar möchte ich eine Interne Tabelle auslesen. Hierbei jedoch spalte für spalte vorgehen.
Habe die Tabelle bis jetzt mit einem Loop und ASSINGNING FIELD-SYMBOL ausgelesen. Ungefähr so:

it_test:
Spalte1 Spalte2 Spalte3 Spalte4
12 15 16 18
13 29 13 13

LOOP AT it_test ASSIGNING FIELD-SYMBOL(<fs_line>).
var = <fs_line>-[Name der Spalte]
ENDLOOP.

Nun will ich die selbe Loop schleife mehrmals ausführen und dabei die Spalte hochzählen lassen. Also beim zweiten durchlauf die Werte der nächsten spalte auslesen und so weiter.
Die größe der Tabelle ist hierbei dynamisch. Wie kann ich das tun? Habe in verschiedenen Foren noch keine Erklärung dafür gefunden.

Schonmal Vielen Dank für die Hilfe!

LG JulDen

Re: Spalten Interner Tabellen nacheinander auslesen.

Vielen Dank schonmal für die Hilfe!

In deinem Beispiel kann ich nun Zeile für Zeile alle Spalten durchgehen.
Mein Ziel war es allerdings erst alle Werte der Spalte1 dann der Spalte2 und so weiter auszugeben.
Wenn möglich auch mitten drin einsteigen.

Ich kann nur aus Java berichten und stelle mit es so vor als würde ich zum Beispiel mit Index [0][3] anfangen.
([0] = Zeile, [3] = Spalte)
Dann durch den ersten Index durchloopen [1][3], [2][3], [3][3], [4][3]
und im zweiten durchlauf den zweiten Index erhöhen [0][4], [1][4], [2][4], ...

Ist das Überhaupt möglich?

Sorry für die blöde Fragestellung .

Re: Spalten Interner Tabellen nacheinander auslesen.

Er hat (minimal) ein 7.40-System. Das hättest Du eigentlich erkennen müssen , schließlich hat er geschrieben:
Das ist eine Inline-Deklaration eines Feldsymbols, die meines Wissens vor 7.40 nicht geht.

Im übrigen funktioniert Dein Code nicht, da Du den LOOP direkt per EXIT verlässt und damit nur die erste Tabellenzeile spaltenweise einliest. Auch der DO gefält mir nicht; IMHO schreit das nach einem WHILE. Sonst brauchst Du diesen klobigen IF für die EXIT-Bedingung und verlässt Dich im übrigen darauf, dass sein Code innerhalb des LOOPs Dir Deinen SY-INDEX nicht versaut.

Ich würde Deinen Code so abwandeln:
Das geht auch garantiert noch schöner. Die Prüfung von END_OF_DO gehört eigentlich außerhalb die LOOP-Schleife, weil er das pro WHILE-Durchlauf nur einmal machen muss. Gibt garantiert eine Funktion (wahrscheinlich irgendwo in dieser komischen ABAP_TYPEDESCR-Klasse), mit der man die Anzahl der Komponenten der Struktur ermitteln kann. Bin aber zu faul, das jetzt genau nachzusehen. Diese Methode sollte man einmal aufrufen, die Zahl der Komponenten ermitteln und dann in der äußeren Schleife damit vergleichen. Wahrscheinlich ist dann sogar wieder ein DO am besten, allerdings in der Form DO number_of_components TIMES. Dann brauchst Du den hässlichen IF für die Exit-Bedingung nicht und musst auch nicht (wie ich oben) in einer WHILE-Schleife händisch einen Counter hochzählen.

Re: Spalten Interner Tabellen nacheinander auslesen.

Alternativ auch eine Variante mittels RTTI und dann Assign mit Feldnamen:

Re: Spalten Interner Tabellen nacheinander auslesen.

Mal nachrechnen.
- Da es sich um ein Übungsprogramm handelt - Punkt dafür
- Die relative Unkenntnis des OP - Punkt dagegen
- Die Verwendung "neuer" Sprachelemente zur Übung - Punkt dafür
- Die Lesbarkeit ( vor allem durch die Verwendung des CAST-Operators ) - Punkt dagegen
- Die Notwendigkeit das /eigentlich/ kommentieren zu müssen - Punkt dagegen
_______
-1 PUnkt

Antwort: Nein

Re: Spalten Interner Tabellen nacheinander auslesen.

Hä? Was hat ein cast mit OO zu tun?


Ralf

Re: Spalten Interner Tabellen nacheinander auslesen.

Trotzdem ist das kein Argument gg OO. Man kann die Methodenaufrufe auch entflechten, das ist lediglich eine Frage der Schreibweise. Da hat jeder seine Vorlieben: Mir ist sowas lieber als lauter Datenobjekte, die man nur einmalig / „on the fly“ braucht (weshalb ich Inline-Deklarationen für solche Fälle bevorzuge, um mal ein OO-freies Beispiel zu bringen). Aber eben in diesem Falle mit einer Kommentarzeile dazu, die das Überlegen erspart.

Empfehlenswert für den Anfänger ist es deshalb nicht, weil der sich um das eigentliche Problem kümmern soll statt sich mit den Deskriptoren der SAP zu beschäftigen. Als Elektriker-Lehrling habe ich auch mit einfachen Schaltungen angefangen, um konkret zu Lernen, wie ein Selbsthaltemechanismus bei einem Schütz funktioniert — ohne dass ich (später vermitteltes) „Beiwissen“ brauchte, das vom eigentlich zu lernenden Thema ablenkt. Die Nicht-Empfehlung für einen Anfänger ist also kein Argument gegen OO, sondern der Didaktik geschuldet. Als weiterführender Hinweis ist das aber eine sehr gute Variante, das möchte ich ausdrücklich dazusagen.

Raus kommt, was immer rauskommt: Abstraktes Coding ist vielseitiger, aber eben auch abstrakter. Gerade gestern habe ich eine verallgemeinerte Werthilfe programmiert, von denen wir ähnliche für andere Felder auf anderen Dynpros häufiger brauchen. Das rufen die anderen dann einfach parametrisiert auf und sparen einen Haufen Arbeit. Verstehen müssen die Aufrufer das nicht zwingend, die müssen nur wissen, was sie reinwerfen müssen und was rauskommt. Ich möchte wetten, das machst du mit den meisten SAP-Funktionsbausteinen auch so. Du weißt grob (in einem Satz zusammengefasst) was sie tun und was sie dafür brauchen.

Der Vorteil abstrakten Codings ist oft der, dass die Lösungen an mehreren Stellen (per Aufruf, nicht per Kopie!) einsetzbar, aber zentral wartbar sind. Und nochmal: Mit der Schreibweise an sich hat das aber trotzdem nichts zu tun

Ralf

Re: Spalten Interner Tabellen nacheinander auslesen.

Das Interface einer Methode unterscheidet sich kaum von dem eines Funktionsbausteines. Und natürlich kannst du jedes Attribut und jede Methode mit einer SAPscript-Doku versehen. Nicht alles, was du nicht kennst, existiert nicht. Und die kompakte Schreibweise ist einer der größten Vorteile einer Methode ggü. einem Fb, dessen Aufruf das Coding zerschneidet. Man setzt den Aufruf einer Methode an die Stelle, an der man eine Variable mit dem Ergebnis der Methode setzen würde. In der Mathematik wird Substitution genau andersrum verwendet, darum finde ich das so eingängig.


Ralf