Speichern einer Internen Tabelle als Attribut
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
12 Beiträge
•
Seite 1 von 1
12 Beiträge
Seite 1 von 1
Hallo,
meine Klasse soll eine Helperklasse für Tabellen werden. Von außen soll eine interne Tabelle übergeben werden können (im_itab), die diese Klasse speichern, füllen und selectieren kann. Jetzt scheitert es leider daran, dass ich nicht weiss, wie ich das Feldsymbol <itab> (TYPE ANY TABLE) als Attribut der Klasse speichern darf. Mein Versuch das Attibut wie folgt zu speichern:
ITAB / Instance Attribute/ Private / Type / ANY TABLE
Führt zu der Fehlermeldung:
'Datenobjekte dürfen nicht generisch typisiert werden. Die Tabellenarten "ANY" oder "INDEX" sind generisch.'
Der SETTER sieht wie folgt aus:
Wie kann ich mir den Zeiger <itab> als Attribut merken?
meine Klasse soll eine Helperklasse für Tabellen werden. Von außen soll eine interne Tabelle übergeben werden können (im_itab), die diese Klasse speichern, füllen und selectieren kann. Jetzt scheitert es leider daran, dass ich nicht weiss, wie ich das Feldsymbol <itab> (TYPE ANY TABLE) als Attribut der Klasse speichern darf. Mein Versuch das Attibut wie folgt zu speichern:
ITAB / Instance Attribute/ Private / Type / ANY TABLE
Führt zu der Fehlermeldung:
'Datenobjekte dürfen nicht generisch typisiert werden. Die Tabellenarten "ANY" oder "INDEX" sind generisch.'
Der SETTER sieht wie folgt aus:
Code: Alles auswählen.
METHOD set_itab.
DATA: itab TYPE REF TO data.
CREATE DATA: itab LIKE im_itab.
FIELD-SYMBOLS: <itab> TYPE ANY TABLE.
ASSIGN: itab->* TO <itab>.
ENDMETHOD.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hallo,
das Grundproblem ist doch, dass der Tabellenaufbau erst zur Laufzeit festgelegt wird.
Mann kann zwar "TYPE ANY TABLE" typisieren, aber ja nicht per DATA definieren. Dies ist nur für Feldsymbole erlaubt, die zum Zeitpunkt der Zuweisung typisiert werden.
Eigentlich kannst Du schon mit deinem Feldsymbol auf die übergebene Tabelle zeigen:
assign im_table to <itab>.
Nur die Probleme fangen ja dann erst an:
- Selektieren von beliebigen DDIC-Tabellen
- Ansprechen von beliebigen Spaltennamen
Hier hilft m.E. nur generischer Code (z.B. durch
GENERATE SUBROUTINE POOL) in dem man sich das
gewünschte Coding zusammenbaut.
Norbert
das Grundproblem ist doch, dass der Tabellenaufbau erst zur Laufzeit festgelegt wird.
Mann kann zwar "TYPE ANY TABLE" typisieren, aber ja nicht per DATA definieren. Dies ist nur für Feldsymbole erlaubt, die zum Zeitpunkt der Zuweisung typisiert werden.
Eigentlich kannst Du schon mit deinem Feldsymbol auf die übergebene Tabelle zeigen:
assign im_table to <itab>.
Nur die Probleme fangen ja dann erst an:
- Selektieren von beliebigen DDIC-Tabellen
- Ansprechen von beliebigen Spaltennamen
Hier hilft m.E. nur generischer Code (z.B. durch
GENERATE SUBROUTINE POOL) in dem man sich das
gewünschte Coding zusammenbaut.
Norbert
...........
Just do it !
Just do it !
Hallo Norbert,
vielen Dank für Deine Antwort.
Leider kann ich mir keinen Weg vorstellen in ABAP-Objects Klassen-Attribute zur Laufzeit zu erzeugen
Dynamisch auf DDIC-Structuren bzw. Selects auf die, in der Klasse gespeicherte, ITAB zu erstellen ist Problem.
Den Code um den Importparameter im_ddic_tablename erweitert kann mittels eines Selects auf irgendeine DDIC-Structur zugegriffen werden. (auch mit WHERE Bedingungen ...)
Um nicht den Faden zu verlieren 
, meine Frage ist : Wie kann im ABAP-O das Feld <itab> als Klassen-Attribute gespeichert werden?
vielen Dank für Deine Antwort.
Leider kann ich mir keinen Weg vorstellen in ABAP-Objects Klassen-Attribute zur Laufzeit zu erzeugen
Dynamisch auf DDIC-Structuren bzw. Selects auf die, in der Klasse gespeicherte, ITAB zu erstellen ist Problem.
Den Code um den Importparameter im_ddic_tablename erweitert kann mittels eines Selects auf irgendeine DDIC-Structur zugegriffen werden. (auch mit WHERE Bedingungen ...)
Code: Alles auswählen.
SELECT * FROM (im_ddic_tablename)
INTO CORRESPONDING FIELDS OF TABLE <itab>
OK,
meine Generierung von Klassenattributen bezog sich eher auf eine lokale Klasse, die im ABAP-Coding angelegt wird, als auf die SE24, die
einen festen Eintrag mit nicht-generischer Typisierung erwartet.
Tja, scheint so nicht vorgesehen zu sein.
meine Generierung von Klassenattributen bezog sich eher auf eine lokale Klasse, die im ABAP-Coding angelegt wird, als auf die SE24, die
einen festen Eintrag mit nicht-generischer Typisierung erwartet.
Tja, scheint so nicht vorgesehen zu sein.
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Definier dir dein
nicht in der Methode sondern als Privates Attribut.
ITAB / Instance Attribute/ Private / Type REF TO / DATA
Dann würde ein Methodenaufruf wie folgt aussehen:
Damit kannst du ab jetzt über itab->* auf die Tabelle zugreifen. Du musst halt nur in den enstprechenden Methoden immer ein Feldsymbol bereithalten um wirklich damit arbeiten zu können nach dem Assign.
Code: Alles auswählen.
data: itab TYPE REF TO data.ITAB / Instance Attribute/ Private / Type REF TO / DATA
Dann würde ein Methodenaufruf wie folgt aussehen:
Code: Alles auswählen.
METHOD set_itab.
field-symbols: <fs> type table.
CREATE DATA: itab LIKE im_itab.
assign itab->* to <fs>.
<fs> = im_itab.
ENDMETHOD.Danke für den Tipp, das funktioniert soweit. 
Gespeichert sind die Klassen-Attribute:
ITAB (Type Ref To DATA) mit der Referenz auf die ITAB
DDIC_TABLENAME mit dem Namen der DDIC-Tabelle
Mein Problem ist jetzt, die interne Tabelle zur Verarbeitung wieder auf den DDIC-Type zu casten.
Hier ein hilfloser Versuch (funktioniert leider nicht):
Hier krachts bereits beim compilieren. ASSIGN: "H_ITABTYPE" ist zu "<ITAB>" typinkompatibel.
Gespeichert sind die Klassen-Attribute:
ITAB (Type Ref To DATA) mit der Referenz auf die ITAB
DDIC_TABLENAME mit dem Namen der DDIC-Tabelle
Mein Problem ist jetzt, die interne Tabelle zur Verarbeitung wieder auf den DDIC-Type zu casten.
Hier ein hilfloser Versuch (funktioniert leider nicht):
Code: Alles auswählen.
METHOD do_something.
DATA: h_itabtype TYPE REF TO data.
CREATE DATA h_itabtype TYPE TABLE OF (me->ddic_tablename).
FIELD-SYMBOLS: <itab> TYPE ANY TABLE.
ASSIGN: me->itab->* TO <itab> CASTING LIKE h_itabtype.
... do something with <itab>.
ENDMETHOD.
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Ist das nicht ein wenig kompliziert? Warum das Typecasting?
Ich denke mal ein einfaches
tut es auch.
Hat außerdem den Vorteil, dass es auch mit Tabellen funktioniert, die nicht im DDIC abgelegt sind.
Ich denke mal ein einfaches
Code: Alles auswählen.
METHOD do_something.
FIELD-SYMBOLS: <itab> TYPE ANY TABLE.
ASSIGN: me->itab->* TO <itab>.
* ... do something with <itab>.
* z.B.
FIELD-SYMBOLS: <wa> TYPE ANY.
LOOP AT <itab> ASSIGNING <wa>.
ENDLOOP.
ENDMETHOD.Hat außerdem den Vorteil, dass es auch mit Tabellen funktioniert, die nicht im DDIC abgelegt sind.
du hast föllig recht, ohne typecasting ist es einfacher
die klasse soll mit der internen tabelle arbeiten können. das geht leider nicht, wenn die struktur nicht bekannt ist.
in meinem fall ist es hilfreich, wenn bei get_itab eine beliebige itab für die rückgabe vorgegeben werden kann. um diese mittels 'INTO CORRESPONDING FIELDS' an den anfragenden zu übertragen.
die klasse soll mit der internen tabelle arbeiten können. das geht leider nicht, wenn die struktur nicht bekannt ist.
in meinem fall ist es hilfreich, wenn bei get_itab eine beliebige itab für die rückgabe vorgegeben werden kann. um diese mittels 'INTO CORRESPONDING FIELDS' an den anfragenden zu übertragen.
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Hmmm - und du meinst sowas muss funktionieren?
Für MOVE-CORRESPONDING müssen Ziel und Quelle Strukturen sein. Beim Syntaxcheck prüft ABAP jetzt, ob dem so ist und bei untypsierten Feldsymbolen kann es sowas nicht feststellen und weigert sich.
Und ich sehe nicht, wie du ohne untypisierte Feldymbole (zur Kompilierzeit) auskommen willst. Die ganze Aktion mit "CREATE DATA" etc. sorgt ja letztlich nur dafür, dass du dem Feldsymbol mit dem du arbeiten möchtest eine definierte Struktur zuweisen kannst. Aber eben erst zur Laufzeit und das ist zu spät für den Syntaxchecker, der das MOVE-CORRESPONDING überprüft.
Für MOVE-CORRESPONDING müssen Ziel und Quelle Strukturen sein. Beim Syntaxcheck prüft ABAP jetzt, ob dem so ist und bei untypsierten Feldsymbolen kann es sowas nicht feststellen und weigert sich.
Und ich sehe nicht, wie du ohne untypisierte Feldymbole (zur Kompilierzeit) auskommen willst. Die ganze Aktion mit "CREATE DATA" etc. sorgt ja letztlich nur dafür, dass du dem Feldsymbol mit dem du arbeiten möchtest eine definierte Struktur zuweisen kannst. Aber eben erst zur Laufzeit und das ist zu spät für den Syntaxchecker, der das MOVE-CORRESPONDING überprüft.
unter ABAP Tips und Tricks (SAP) habe ich dazu folgende Information gefunden:
Den MOVE-CORRESPONDING muss man aber mit ASSIGN COMPONENT für beide Strukturen selber vornehmen.
Dazu läuft man über die Feldliste-Tabelle der einen Tabellen und legt sich für jedes Feld mittels ASSIGN COMPONENT jeweils ein Feldsymbol für Quelle und Ziel an.
Sollte eine der beiden ASSIGN's fehlschlagen, kann man zum nächsten Feld übergehen.
Anschließend noch den Inhalt von Quelle dem Ziel zuweisen. Voilà.
Damit sollte es zur Laufzeit möglich sein, die Feldliste zur Tabelle zu erhalten.Sometimes you may have only a table name and want to retrieve the name of each field of the corresponding table. For example, when you want to use ASSIGN COMPONENT fieldname OF TABLE table.
An ABAPer's first reaction is to read the standard ABAP basis tables DD02L, DD03L, etc
This way of reading fields is very slow. Use methods from the class CL_ABAP_TYPEDESCR instead.
Example:
data: descr_struc_ref TYPE REF TO cl_abap_structdescr.
descr_struc_ref ?= cl_abap_typedescr=>describe_by_name('SFLIGHT' ).
Here is the result of descr_struct_ref after the execution of this piece of code
ABSOLUTE_NAME C 200 \TYPE=SFLIGHT
TYPE_KIND C 1 u
LENGTH I 4 80
DECIMALS I 4 0
KIND C 1 S
STRUCT_KIND C 1 F
COMPONENTS h 8 Table[14x40]
HAS_INCLUDE C 1
The table COMPONENTS is filled with :
LENGTH DECIMALS TYPE_KIND NAME
3 | 0 |C |MANDT
3 | 0 |C |CARRID
4 | 0 |N |CONNID
8 | 0 |D |FLDATE
etc.
You have the fields name and a lot more information about the table. This class can also handle structure, table type, etc.
Note that this method is very fast because it uses the database layer directly thanks to SYSTEM CALLs.
To have a look at the class, use transaction SE24.
Den MOVE-CORRESPONDING muss man aber mit ASSIGN COMPONENT für beide Strukturen selber vornehmen.
Dazu läuft man über die Feldliste-Tabelle der einen Tabellen und legt sich für jedes Feld mittels ASSIGN COMPONENT jeweils ein Feldsymbol für Quelle und Ziel an.
Sollte eine der beiden ASSIGN's fehlschlagen, kann man zum nächsten Feld übergehen.
Anschließend noch den Inhalt von Quelle dem Ziel zuweisen. Voilà.
Gruß
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Danke für Eure (Deine) Engelsgeduld
Habe einen Weg gefunden, mit dem ich leben kann. Weise ich einen Datensatz meiner Struktur der DDIC-Struktur zu, kann ich diese verarbeiten.
Gespeichert sind die Klassen-Attribute:
ITAB (Type Ref To DATA) mit der Referenz auf die ITAB
DDIC_TABLENAME mit dem Namen der DDIC-Tabelle
Die Methode bekommt den Parameter
CH_ITAB (Type Data)
schön
Die Frage ist jetzt kann ich der Methode noch einen weiteren Parameter wa_itab mit der gewünschten Struktur der itab mitgeben und diesen der itab <ret_itab> zuweisen?
Welchen Typ muss der Parameter wa_itab haben und wie kann ich ihn in der Methode verwenden?
Aufrufbeispiel:
Habe einen Weg gefunden, mit dem ich leben kann. Weise ich einen Datensatz meiner Struktur der DDIC-Struktur zu, kann ich diese verarbeiten.
Gespeichert sind die Klassen-Attribute:
ITAB (Type Ref To DATA) mit der Referenz auf die ITAB
DDIC_TABLENAME mit dem Namen der DDIC-Tabelle
Die Methode bekommt den Parameter
CH_ITAB (Type Data)
Code: Alles auswählen.
METHOD get_itab.
DATA: wa_itab TYPE REF TO data,
ret_itab TYPE REF TO data.
CREATE DATA: wa_itab TYPE (me->ddic_tablename),
ret_itab LIKE ch_itab.
FIELD-SYMBOLS: <itab> TYPE ANY TABLE,
<ret_itab> TYPE STANDARD TABLE,
<wa_itab> TYPE ANY.
ASSIGN: me->itab->* TO <itab>,
wa_itab->* TO <wa_itab>,
ch_itab TO <ret_itab>.
LOOP AT <itab> INTO <wa_itab>.
APPEND <wa_itab> TO <ret_itab>.
ENDLOOP.
ENDMETHOD.
schön
Die Frage ist jetzt kann ich der Methode noch einen weiteren Parameter wa_itab mit der gewünschten Struktur der itab mitgeben und diesen der itab <ret_itab> zuweisen?
Welchen Typ muss der Parameter wa_itab haben und wie kann ich ihn in der Methode verwenden?
Aufrufbeispiel:
Code: Alles auswählen.
...
DATA: BEGIN OF wa_itab,
irgendwas(30).
INCLUDE STRUCTURE t000.
DATA: END OF wa_itab.
DATA: itab LIKE STANDARD TABLE OF wa_itab.
...
CALL METHOD db->get_itab
EXPORTING
IM_RET_STRUCT = wa_itab.
CHANGING
ch_itab = itab.
...
Eine Lösung würde wie folgt funktionieren:
Gespeichert sind die Klassen-Attribute:
ITAB (Type Ref To DATA) mit der Referenz auf die ITAB
DDIC_TABLENAME mit dem Namen der DDIC-Tabelle
Die Methode bekommt die Parameter
CH_ITAB (Type Data)
IM_RET_STRUCT (Type Data)
Kann das ganze einfacher gelöst werden? (Bin Abap und Abap-O Anfänger)
Gespeichert sind die Klassen-Attribute:
ITAB (Type Ref To DATA) mit der Referenz auf die ITAB
DDIC_TABLENAME mit dem Namen der DDIC-Tabelle
Die Methode bekommt die Parameter
CH_ITAB (Type Data)
IM_RET_STRUCT (Type Data)
Code: Alles auswählen.
METHOD get_itab.
DATA: wa_itab TYPE REF TO data,
wa_ret_itab TYPE REF TO data,
ret_itab TYPE REF TO data.
CREATE DATA: wa_itab TYPE (me->ddic_tablename),
wa_ret_itab LIKE im_ret_struct,
ret_itab LIKE ch_itab.
FIELD-SYMBOLS: <itab> TYPE ANY TABLE,
<ret_itab> TYPE STANDARD TABLE,
<wa_itab> TYPE ANY,
<wa_ret_itab> TYPE ANY.
ASSIGN: me->itab->* TO <itab>,
wa_itab->* TO <wa_itab>,
wa_ret_itab->* TO <wa_ret_itab>,
ch_itab TO <ret_itab>.
LOOP AT <itab> INTO <wa_itab>.
MOVE-CORRESPONDING <wa_itab> TO <wa_ret_itab>.
APPEND <wa_ret_itab> TO <ret_itab>.
ENDLOOP.
ENDMETHOD.
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
3742
Views
Views
Daten aus internen Tabelle in Tabelle speichern
von Stahle71 » 03.06.2015 11:03 • Verfasst in ABAP® für Anfänger
von Stahle71 » 03.06.2015 11:03 • Verfasst in ABAP® für Anfänger
10
Antw.
Antw.
4885
Views
Views
Objekt mit Referenz als Attribut auf DB speichern?
von dejo79 » 08.02.2017 17:00 • Verfasst in ABAP Objects®
von dejo79 » 08.02.2017 17:00 • Verfasst in ABAP Objects®
2
Antw.
Antw.
2622
Views
Views
Inhalt einer internen Tabelle in einer Datei speichern
von Gast » 23.11.2005 15:53 • Verfasst in ABAP® Core
von Gast » 23.11.2005 15:53 • Verfasst in ABAP® Core
4
Antw.
Antw.
568
Views
Views
Tabelle als Attribut bei einer Methode
von Julia.hrtm » 28.10.2024 13:07 • Verfasst in ABAP® für Anfänger
von Julia.hrtm » 28.10.2024 13:07 • Verfasst in ABAP® für Anfänger
4
Antw.
Antw.
4808
Views
Views
Aus einer Tabelle Daten einer internen Tabelle filtern - Interne Tabelle ist eine Tabelle ohne Kopfzeile
von Sonne1234 » 09.12.2019 08:29 • Verfasst in ABAP® für Anfänger
von Sonne1234 » 09.12.2019 08:29 • Verfasst in ABAP® für Anfänger
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1156
vor 2 Tagen von DeathAndPain 4 / 1156
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1156
vor 2 Tagen von DeathAndPain 4 / 1156