Zuweisung von Tabellenstrukturen
9 Beiträge
•
Seite 1 von 1
9 Beiträge
Seite 1 von 1
Hallo!
Ich habe derzeit folgendes Problem:
Ich würde gerne eine Tabellenstruktur anhand eines variablen Tabellennamens einem Field-Symbol zuweisen.
Normalerweise nutze ich hierzu folgenden Code:
DATA: BEGIN OF work, BUFFER(65500), END OF work.
FIELD-SYMBOLS: <wa> TYPE ANY.
ASSIGN work TO <wa> CASTING TYPE (TABLE_NAME).
Die verwendete ABAP-Version kennt den CASTING-Befehl jedoch noch nicht. Ich habe mich daher an den
obsoleten Varianten versucht:
DATA: buffer(65500) TYPE C.
FIELD-SYMBOLS: <wa> STRUCTURE (TABLE_NAME) DEFAULT buffer.
Hierbei habe ich das Problem, dass ich keine variable Struktur anhand des Tabellennamens angeben kann.
Einige weitere Ansätze scheiterten bislang ebenfalls daran, dass die verwendete ABAP-Version entsprechende
Funktionen etc. nicht kannte.
Für die zweite Variante würde ich z.B. eine interne Tabelle mit entsprechender Struktur benötigen,
die ich anhand des Namens erstellen kann.
Ich habe derzeit folgendes Problem:
Ich würde gerne eine Tabellenstruktur anhand eines variablen Tabellennamens einem Field-Symbol zuweisen.
Normalerweise nutze ich hierzu folgenden Code:
DATA: BEGIN OF work, BUFFER(65500), END OF work.
FIELD-SYMBOLS: <wa> TYPE ANY.
ASSIGN work TO <wa> CASTING TYPE (TABLE_NAME).
Die verwendete ABAP-Version kennt den CASTING-Befehl jedoch noch nicht. Ich habe mich daher an den
obsoleten Varianten versucht:
DATA: buffer(65500) TYPE C.
FIELD-SYMBOLS: <wa> STRUCTURE (TABLE_NAME) DEFAULT buffer.
Hierbei habe ich das Problem, dass ich keine variable Struktur anhand des Tabellennamens angeben kann.
Einige weitere Ansätze scheiterten bislang ebenfalls daran, dass die verwendete ABAP-Version entsprechende
Funktionen etc. nicht kannte.
Für die zweite Variante würde ich z.B. eine interne Tabelle mit entsprechender Struktur benötigen,
die ich anhand des Namens erstellen kann.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4093 / 128 /
940
)
»
Hallo av_deh,
da du ansprichst, dass deine ABAP-Version diverse Sprachmerkmale (noch) nicht beherrscht, wäre es durchaus sinnvoll anzugeben, welchen Releasestand du denn nun hast.
Die Sachen die mir direkt einfallen wären
- Falls du "CREATE DATA" verwenden darfst --> das verwenden
- GENERATE SUBROUTINEPOOL
da du ansprichst, dass deine ABAP-Version diverse Sprachmerkmale (noch) nicht beherrscht, wäre es durchaus sinnvoll anzugeben, welchen Releasestand du denn nun hast.
Die Sachen die mir direkt einfallen wären
- Falls du "CREATE DATA" verwenden darfst --> das verwenden
- GENERATE SUBROUTINEPOOL
Hallo!
Zunächst einmal vielen Dank für die Reaktion.
Der SAP-Releasestand ist 45B.
Die "CREATE DATA"-Anweisung konnte ich nicht einsetzen, da die Initialisierung
der hierzu benötigten Variablen nicht funktioniert:
DATA: WA_REF TYPE REF TO DATA.
Hier wird DATA als unbekannte, bzw. nicht initialisierte Variable erkannt.
Ich habe mich mal an GENERATE SUBROUTINE POOLS versucht, das sieht prinzipiell
sehr interessant aus, allerdings verstehe ich nicht, wie ich eventuelle Ergebnisse
aus der Subroutine wieder herausbekomme, um sie im Hauptprogramm nutzen zu können.
Ein Field-Symbol als Eingabe mit dem Typ ANY kann innerhalb der Subroutine ja leider
nicht umdefiniert werden.
Zunächst einmal vielen Dank für die Reaktion.
Der SAP-Releasestand ist 45B.
Die "CREATE DATA"-Anweisung konnte ich nicht einsetzen, da die Initialisierung
der hierzu benötigten Variablen nicht funktioniert:
DATA: WA_REF TYPE REF TO DATA.
Hier wird DATA als unbekannte, bzw. nicht initialisierte Variable erkannt.
Ich habe mich mal an GENERATE SUBROUTINE POOLS versucht, das sieht prinzipiell
sehr interessant aus, allerdings verstehe ich nicht, wie ich eventuelle Ergebnisse
aus der Subroutine wieder herausbekomme, um sie im Hauptprogramm nutzen zu können.
Ein Field-Symbol als Eingabe mit dem Typ ANY kann innerhalb der Subroutine ja leider
nicht umdefiniert werden.
Beitrag
von black_adept (Top Expert / 4093 / 128 /
940
)
»
Hallo av_deh,
bei 4.5 war für mich tatsächlich GENERATE SUBROUTINEPOOL die einzige Möglichkeit gewesen dynamisch Feldsymbole anzulegen. Und du hast natürlich recht, dass man das Feldsymbol innerhalb der dyn. Routine nicht umbiegen kann. Aber mit ein wenig Phantasie konnte man von hinten durch die Brust ins Auge das doch hinbekommen. Wenn man das Coding sieht ist es sogar relativ simpel.
Da ich grad noch ein altes 4.5er System im Zugriff habe hab ich mal einen meiner alten Codeschnipsel genommen und auf das Wesentliche gekürzt. Das Beispielt sollte dir zeigen wie es dann geht.
Hmm - die Makrozeile soll so lauten - die Code-Formatierung macht die Stelle leider kaputt.
APPEND &1 TO T_SOURCE.
bei 4.5 war für mich tatsächlich GENERATE SUBROUTINEPOOL die einzige Möglichkeit gewesen dynamisch Feldsymbole anzulegen. Und du hast natürlich recht, dass man das Feldsymbol innerhalb der dyn. Routine nicht umbiegen kann. Aber mit ein wenig Phantasie konnte man von hinten durch die Brust ins Auge das doch hinbekommen. Wenn man das Coding sieht ist es sogar relativ simpel.
Da ich grad noch ein altes 4.5er System im Zugriff habe hab ich mal einen meiner alten Codeschnipsel genommen und auf das Wesentliche gekürzt. Das Beispielt sollte dir zeigen wie es dann geht.
Code: Alles auswählen.
REPORT LINE-SIZE 1000.
FIELD-SYMBOLS: <TABLE> TYPE ANY. " Hier kannst du auch TYPE STANDARD TABLE nehmen
DATA: SUB_POOL TYPE SYREPID.
PARAMETERS: P_TAB TYPE TABNAME OBLIGATORY DEFAULT 'T000'.
START-OF-SELECTION.
PERFORM CREATE_SUBPOOL.
IF <TABLE> IS ASSIGNED.
BREAK-POINT. " Hat geklappt
ELSE.
BREAK-POINT. " Hat nicht geklappt
ENDIF.
*---------------------------------------------------------------------*
* FORM CREATE_SUBPOOL *
*---------------------------------------------------------------------*
FORM CREATE_SUBPOOL.
DATA: T_SOURCE TYPE STANDARD TABLE OF ABAPSOURCE
WITH NON-UNIQUE DEFAULT KEY.
DEFINE AS. " Add Source
APPEND &1 TO T_SOURCE.
END-OF-DEFINITION.
AS: 'REPORT.',
'DATA: TAB TYPE STANDARD TABLE OF',
P_TAB,
'.',
'FORM DYN.',
'PERFORM callback in program (sy-cprog) using tab.',
'ENDFORM.'.
GENERATE SUBROUTINE POOL T_SOURCE NAME SUB_POOL.
CHECK SY-SUBRC = 0.
PERFORM DYN IN PROGRAM (SUB_POOL).
ENDFORM.
*---------------------------------------------------------------------*
* FORM CALLBACK *
*---------------------------------------------------------------------*
FORM CALLBACK USING P_TAB TYPE STANDARD TABLE.
ASSIGN P_TAB TO <TABLE>.
ENDFORM.APPEND &1 TO T_SOURCE.
Hallo,
zugegebenermaßen wäre ich darauf jetzt nicht gekommen.
Ein Problem, das bei mir nun noch aufgetreten ist, ist die fehlende
Zuweisung der C-Variable, die ich bislang nur über die Initialisierung
des Field-Symbols hinbekommen habe:
DATA: buffer(65500) TYPE C.
FIELD-SYMBOLS: <wa> STRUCTURE (TABLE_NAME) DEFAULT buffer.
Da ich aus einem SELECT-Befehl heraus die Daten in das Field-Symbol
einsetze, bekomme ich mit dem reinen ASSIGN der Tabellenstruktur
aus der CALLBACK-FORM leider dennoch Probleme:
ein ähnliches Problem wie zuvor: Ich bekomme die Variable wieder nicht ins Hauptprogramm.
Habt ihr hierzu noch einen Tipp für mich?
zugegebenermaßen wäre ich darauf jetzt nicht gekommen.
Ein Problem, das bei mir nun noch aufgetreten ist, ist die fehlende
Zuweisung der C-Variable, die ich bislang nur über die Initialisierung
des Field-Symbols hinbekommen habe:
DATA: buffer(65500) TYPE C.
FIELD-SYMBOLS: <wa> STRUCTURE (TABLE_NAME) DEFAULT buffer.
Da ich aus einem SELECT-Befehl heraus die Daten in das Field-Symbol
einsetze, bekomme ich mit dem reinen ASSIGN der Tabellenstruktur
aus der CALLBACK-FORM leider dennoch Probleme:
Wenn ich nun aber die Initilisierung in die CALLBACK-FORM verlege, habe ichBei der Anweisung "SELECT...INTO wa" sind an der Argumentposition
"wa" tiefe Datenobjekte nicht unterstützt.
Elementare tiefe Datentypen sind interne Tabellen und Objektreferenzen.
Allgemeine tiefe Datenobjekte sind elementare tiefe Datentypen oder Strukturen,
die tiefe Datenobjekte enthalten.
Im vorliegenden Fall hat der Operand "wa" den nciht-flachen Typ "h".
ein ähnliches Problem wie zuvor: Ich bekomme die Variable wieder nicht ins Hauptprogramm.
Habt ihr hierzu noch einen Tipp für mich?
Beitrag
von black_adept (Top Expert / 4093 / 128 /
940
)
»
Hallo av_dev,
das Problem was du momentan erfährst hat nichts mit der dynamischen Struktur zu tun sondern ist einfach ein simpler Syntaxfehler.
Wenn du mein Beispielcoding genommen hast, kannst du im Debugger sehen, dass das Feldsymbol "<table>" nicht unbedingt überraschenderweise auf eine (momentan leere) interne Tabelle zeigt.
Aber dann muss dein Select nicht "SELECT...INTO wa" sondern "SELECT...INTO TABLE <table>" lauten
das Problem was du momentan erfährst hat nichts mit der dynamischen Struktur zu tun sondern ist einfach ein simpler Syntaxfehler.
Wenn du mein Beispielcoding genommen hast, kannst du im Debugger sehen, dass das Feldsymbol "<table>" nicht unbedingt überraschenderweise auf eine (momentan leere) interne Tabelle zeigt.
Aber dann muss dein Select nicht "SELECT...INTO wa" sondern "SELECT...INTO TABLE <table>" lauten
Hallo,
da ich das Thema für die letzten zwei Wochen zurückstellen musste, kann ich erst nun wieder antworten.
Das "SELECT .... INTO TABLE <table>", bzw. "FETCH .... INTO TABLE <table>" mit Cursor, stellt mich scheinbar
vor ein ähnliches Problem, welches ich bereits zuvor hatte. Ich bekomme die Daten zwar in eine
interne Tabelle gepresst, dies jedoch nur als gesamte Tabelle und nicht zeilenweise.
Der ursprüngliche Code las die jeweilige Tabelle zeilenweise in eine Text-Variable mit übergeordneter
Struktur, wodurch sich die einzelnen Felder der Zeile haben ansprechen und weiterverarbeiten lassen
(Daher auch das SELECT ..... INTO <wa>). Würde ich die Daten nun zuvor in eine interne Tabelle laden
(was bei einer BSEG z.B. eventuell aufgrund der Größe kritisch werden könnte), stehe ich wieder vor dem
Problem, die Daten zeilenweise und ansprechbar zu extrahieren.
Zugegebenermaßen mag hier auch eine Wissenslücke meinerseits vorliegen, da meine ABAP-Kenntnisse
doch eher als begrenzt anzusehen sind.
da ich das Thema für die letzten zwei Wochen zurückstellen musste, kann ich erst nun wieder antworten.
Das "SELECT .... INTO TABLE <table>", bzw. "FETCH .... INTO TABLE <table>" mit Cursor, stellt mich scheinbar
vor ein ähnliches Problem, welches ich bereits zuvor hatte. Ich bekomme die Daten zwar in eine
interne Tabelle gepresst, dies jedoch nur als gesamte Tabelle und nicht zeilenweise.
Der ursprüngliche Code las die jeweilige Tabelle zeilenweise in eine Text-Variable mit übergeordneter
Struktur, wodurch sich die einzelnen Felder der Zeile haben ansprechen und weiterverarbeiten lassen
(Daher auch das SELECT ..... INTO <wa>). Würde ich die Daten nun zuvor in eine interne Tabelle laden
(was bei einer BSEG z.B. eventuell aufgrund der Größe kritisch werden könnte), stehe ich wieder vor dem
Problem, die Daten zeilenweise und ansprechbar zu extrahieren.
Zugegebenermaßen mag hier auch eine Wissenslücke meinerseits vorliegen, da meine ABAP-Kenntnisse
doch eher als begrenzt anzusehen sind.
Beitrag
von black_adept (Top Expert / 4093 / 128 /
940
)
»
Hallo av_dev,
einerseits könntest du in dem generierten Code die Zeiledurchersetzen ( ohne System grade - aber das sollte die Struktur der Tabelle sein )
oder du lässt den generierten Code so wie er ist und wenn du deine zu dem Zeitpunkt noch leere Tabelle <tab> hast, machst du ein "APPEND INITIAL LINE TO ..." und danach ein "READ TABLE ... INDEX 1 INTO <zeile>" um eine Variable mit dem gewünschten Typ zu haben.
Oder du erweiterst das Generierungscoding um eine zweite Variable und Rücksprungroutine und lässt dir so beides - Tabelle und zugehörige Strukturvariable- zurückgeben.
einerseits könntest du in dem generierten Code die Zeile
Code: Alles auswählen.
'DATA: TAB TYPE STANDARD TABLE OF',
Code: Alles auswählen.
'DATA: TAB TYPE',oder du lässt den generierten Code so wie er ist und wenn du deine zu dem Zeitpunkt noch leere Tabelle <tab> hast, machst du ein "APPEND INITIAL LINE TO ..." und danach ein "READ TABLE ... INDEX 1 INTO <zeile>" um eine Variable mit dem gewünschten Typ zu haben.
Oder du erweiterst das Generierungscoding um eine zweite Variable und Rücksprungroutine und lässt dir so beides - Tabelle und zugehörige Strukturvariable- zurückgeben.
Hallo!
Leider scheint das nicht zu funktionieren. Selbst wenn ich die erzeugte Variable aus dem generischen Code nur mit "TAB TYPE"
erstelle, ist das Ergebnis in der Callback-Form, bzw. auch im Hauptprogramm, nicht als STRUCTURE nutzbar (laut Syntax-Check).
Für die vorliegende ABAP-Version konnte ich den Code bislang nur über eine feste Beispiel-Eingabe (für DD02L) zum Laufen bringen:
Anstelle des dd02l akzeptierte er bislang nur Variablen folgender Form:
Ich hatte nun folgende Varianten in und nach der Callback-Form probiert:
Die zweite Möglichkeit, die Variable <table> als leere Tabelle mit der
ersten Zeile zu füllen und dann mit dem READ-Befehl in eine Variable
<zeile> zu pressen, endete ebenfalls in einer Fehlermeldung, da dies
mit einer TYPE ANY-Variablen nicht funktioniert.
Ein ASSIGN im Vorfeld bringt leider nichts, da dann nicht der gewünschte
Typ zugewiesen wird (so erhalte ich beispielsweise durch eine vorherige
Zuweisung des Typs C nur einen gefüllten String ohne Tabellenstruktur).
Leider scheint das nicht zu funktionieren. Selbst wenn ich die erzeugte Variable aus dem generischen Code nur mit "TAB TYPE"
erstelle, ist das Ergebnis in der Callback-Form, bzw. auch im Hauptprogramm, nicht als STRUCTURE nutzbar (laut Syntax-Check).
Für die vorliegende ABAP-Version konnte ich den Code bislang nur über eine feste Beispiel-Eingabe (für DD02L) zum Laufen bringen:
Code: Alles auswählen.
DATA: buffer(65500) TYPE C.
FIELD-SYMBOLS: <wa> STRUCTURE dd02l DEFAULT buffer.Code: Alles auswählen.
DATA: var1 LIKE dd02l.
FIELD-SYMBOLS: <wa> STRUCTURE var1 DEFAULT buffer.Code: Alles auswählen.
DATA: buffer(65500) TYPE C.
FIELD-SYMBOLS: <wa> STRUCTURE p_tab DEFAULT buffer.
------------
DATA: buffer(65500) TYPE C.
FIELD-SYMBOLS: <wa> STRUCTURE <table> DEFAULT buffer.ersten Zeile zu füllen und dann mit dem READ-Befehl in eine Variable
<zeile> zu pressen, endete ebenfalls in einer Fehlermeldung, da dies
mit einer TYPE ANY-Variablen nicht funktioniert.
Ein ASSIGN im Vorfeld bringt leider nichts, da dann nicht der gewünschte
Typ zugewiesen wird (so erhalte ich beispielsweise durch eine vorherige
Zuweisung des Typs C nur einen gefüllten String ohne Tabellenstruktur).
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
20249
Views
Views
Dynamische Tabellenstrukturen im ABAP
von Uwe.Rimarski » 26.02.2011 10:20 • Verfasst in ABAP Objects®
von Uwe.Rimarski » 26.02.2011 10:20 • Verfasst in ABAP Objects®
1
Antw.
Antw.
1415
Views
Views
0
Antw.
Antw.
1777
Views
Views
BADI ( CL_EXM_IM_ME_PROCESS_PO_CUST / Cursor Zuweisung )
von Kleenmex » 25.07.2007 15:33 • Verfasst in Material Management & Produktionsplanung
von Kleenmex » 25.07.2007 15:33 • Verfasst in Material Management & Produktionsplanung
2
Antw.
Antw.
642
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 11 Stunden von ralf.wenzel 104 / 10087
vor 11 Stunden von ralf.wenzel 104 / 10087
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 11 Stunden von ralf.wenzel 104 / 10087
vor 11 Stunden von ralf.wenzel 104 / 10087