Code: Alles auswählen.
TYPES: BEGIN OF ts_tage,
dzlgt TYPE i,
dvzgt TYPE i,
END OF ts_tage.
Code: Alles auswählen.
FIELD-SYMBOLS: <fs_table> TYPE STANDARD TABLE.
DATA lt_comp TYPE cl_abap_structdescr=>component_table.
DATA lr_struc TYPE REF TO cl_abap_structdescr.
DATA lr_table TYPE REF TO cl_abap_tabledescr.
DATA lr_data TYPE REF TO data.
"Dynamische Struktur erzeugen
LOOP AT it_field_value ASSIGNING FIELD-SYMBOL(<wa_field_value>).
APPEND INITIAL LINE TO lt_comp ASSIGNING FIELD-SYMBOL(<wa_comp>).
<wa_comp>-name = <wa_field_value>-ziel.
<wa_comp>-type ?= cl_abap_datadescr=>describe_by_data( p_data = <wa_field_value>-value ).
ENDLOOP.
lr_struc = cl_abap_structdescr=>create( lt_comp ).
lr_table = cl_abap_tabledescr=>create(
p_line_type = lr_struc
p_table_kind = cl_abap_tabledescr=>tablekind_std
p_unique = abap_false ).
CREATE DATA lr_data TYPE HANDLE lr_table.
ASSIGN lr_data->* TO <fs_table>.
APPEND INITIAL LINE TO <fs_table> ASSIGNING FIELD-SYMBOL(<wa_table>).
Folgende Benutzer bedankten sich beim Autor msfox für den Beitrag:
JM1804_ABAP
Ich denke, das ist einfach eine Programmieraufgabe zum Umgang mit dynamisch definierten Strukturen und Tabellen. Eine Tabelle beliebig oft um eine bestimmte Struktur als neue Spalten zu erweitern (denen man dann ja auch jeweils eindeutige Spaltennamen geben muss, die sich von den bisherigen unterscheiden), dafür kann ich mir keinen sinnvollen produktiven Einsatzzweck vorstellen.
Dagegen ist nichts einzuwenden; das ist halt so ein Anwendungsfall, bei dem man eine dynamisch erzeugte Tabelle braucht. Nur: In dem Moment, in dem Du die Tabelle (zur Laufzeit) erzeugst, solltest Du vollständige Information über die benötigten Spalten haben. Nachher der fertigen Tabelle noch dynamisch weitere Spalten hinzuzufügen, wie Du es ursprünglich beschrieben hast, geht nicht und ergibt in meinen Augen auch keinen Sinn.JM1804_ABAP hat geschrieben: ↑12.06.2023 10:11-Das im vorhinein Einplanen der Felder ist leider nicht so einfach möglich, da die Felder je nach Selektion eine andere Überschrift brauchen.
Das ist ganz schlecht, wenn der Entwickler nicht weiß, was der Zweck des Programms ist (was die Anwender damit erreichen wollen), weil er dann keine mündigen Designentscheidungen treffen kann. Ich verwende dann gerne einen Vergleich, für den ich von manchen sehr auf politischer Korrektheitslinie befindlichen Zeitgenossen gerne mal angefeindet werde und sage, dass ist, wie wenn Du einen vorgefertigten Programmierauftrag nach Indien vergibst, und dort sitzt dann ein Programmierer im Keller, programmiert das blind herunter, und am Ende gibt's ein Schälchen Reis. Wenn Du das machst, dann bist Du wirklich nur "Programmierer" und nicht "Entwickler". Im SAP-Umfeld halte ich das für besonders problematisch. Da sollte jeder Programmierer auch ein Stück weit Berater sein. Erst diese Kombination macht ihn zum "Entwickler" (und führt dazu, dass er sein meist sehr ordentliches Gehalt wert ist).JM1804_ABAP hat geschrieben: ↑12.06.2023 10:11-Ja das Programm soll am Ende produktiv genutzt werden. Ich kann aber leider selber nicht sagen, was der Sinn dahinter ist, da mir das Verständnis der Anwenderseite fehlt.
nein, braucht man nicht. Da alle Spalten den gleichen Type haben, kann man ausreichen Spalten definieren (m001, m002, etc) und diesen im Feldkatalog einen entsprechenden Titel zuweisen.DeathAndPain hat geschrieben: ↑13.06.2023 12:50Dagegen ist nichts einzuwenden; das ist halt so ein Anwendungsfall, bei dem man eine dynamisch erzeugte Tabelle braucht.JM1804_ABAP hat geschrieben: ↑12.06.2023 10:11-Das im vorhinein Einplanen der Felder ist leider nicht so einfach möglich, da die Felder je nach Selektion eine andere Überschrift brauchen.
Ich glaube ich habe mein Problem im ersten Threadpost falsch geschildert.DeathAndPain hat geschrieben: ↑13.06.2023 12:50Dagegen ist nichts einzuwenden; das ist halt so ein Anwendungsfall, bei dem man eine dynamisch erzeugte Tabelle braucht. Nur: In dem Moment, in dem Du die Tabelle (zur Laufzeit) erzeugst, solltest Du vollständige Information über die benötigten Spalten haben. Nachher der fertigen Tabelle noch dynamisch weitere Spalten hinzuzufügen, wie Du es ursprünglich beschrieben hast, geht nicht und ergibt in meinen Augen auch keinen Sinn.JM1804_ABAP hat geschrieben: ↑12.06.2023 10:11-Das im vorhinein Einplanen der Felder ist leider nicht so einfach möglich, da die Felder je nach Selektion eine andere Überschrift brauchen.
Das wäre theoretisch eine einfachere Lösung für mich, aber wie kann man während eines Loops auf den Feldkatalog vom SALV zugreifen?ewx hat geschrieben: ↑13.06.2023 13:10nein, braucht man nicht. Da alle Spalten den gleichen Type haben, kann man ausreichen Spalten definieren (m001, m002, etc) und diesen im Feldkatalog einen entsprechenden Titel zuweisen.DeathAndPain hat geschrieben: ↑13.06.2023 12:50Dagegen ist nichts einzuwenden; das ist halt so ein Anwendungsfall, bei dem man eine dynamisch erzeugte Tabelle braucht.JM1804_ABAP hat geschrieben: ↑12.06.2023 10:11-Das im vorhinein Einplanen der Felder ist leider nicht so einfach möglich, da die Felder je nach Selektion eine andere Überschrift brauchen.
IMHO sollte man das auch so machen, denn dann zerstört man nicht das Layout eines ALV-Grid, sobald sich diese jemand für eine mit dynamisch erzeugter Tabelle abspeichert! M001 bleibt M001, auch wenn sich der Titel von Monat zu Monat zu "JUN 2023" zu "JUL 2023" zu "AUG 2023" usw ändert.