Abap Forum on Gate²App

Hallo gse,

also in 46B geht das nicht.

Der einzige workaround der mir so adhoc einfällt ist die Übergabe eines Tabellentyps, also:

data: lt_gentab type ref to data,
lv_tabtype(30) type c value 'SADRVB_TAB'.

create data lt_gentab type (lv_tabtype).

Das müsste funktionieren. Probier's mal

Gruß,
Steff

Moin.

Ab 6.10 kann der CREATE DATA itabs erzeugen. Bei Release <=4.6x können itabs mit der Methode cl_alv_table_create=>create_dynamic_table
erzeugt werden. Der Methode ist ein Feldkatalog zu übergeben, in dem die Felder FIELDNAME, REF_TABLE und REF_FIELD gesetzt werden müssen (ich glaube statt der REF_*-Felder kann auch ROLLNAME gesetzt werden, aber zitiert mich damit nicht).
FIELDNAME enthält den jeweiligen Feldnamen der erzeugten itab, REF_* den Feldbezug im DDIC (wenn das mit ROLLNAME geht muss hier das Datenelement stehen).

Viel Spass beim Experimentieren,
Haubi

Womit wir von ABAP Core wieder zu ABAP Objects gekommen sind.
Irgendwie ist die Aufteilung in verschiedene Foren vielleicht doch nicht so glücklich.

hi steff,

sorry wenn ich wieder etwas ausholen muss.
Ziel meiner Bemühungen war es, mit Hilfe der Übergabeparameter des Funktionsbausteins einen Update auf ein x-beliebiges DDIC-Objekt zu vollziehen. Im Moment (s.u.) ist der Zugriff auf den DDIC dynamisch. Fehlt noch das Erzeugen des/r Arbeitsbereichs/internen Tabelle (bisher durch explizites Benennen des DDIC-Objektes typisiert). Wie gesagt, gleiche Idee: Der Importparameter bestimmt Aussehen und Aufbau des/r Arbeitsbereichs/internen Tabelle (l_wa_tabname bzw. l_it_tabname)

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. DATA: l_wa_tabname TYPE yrdsdwk0_veraend,
2.         l_it_tabname LIKE STANDARD TABLE OF l_wa_tabname.
3.  
4. DATA: lt_gentab      TYPE REF TO data,
5.         lv_tabtype&#40;30&#41; TYPE c.             "VALUE 'YRDSDWK0_VERAEND'.
6.  
7.   lv_tabtype = i_tabname.
8.  
9.   CREATE DATA lt_gentab TYPE &#40;lv_tabtype&#41;.
10.  
11.   SELECT *
12.     INTO TABLE l_it_tabname
13.     FROM &#40;lv_tabtype&#41;    "dynam. DDIC-Objekt!
14.     WHERE bukrs = '0050'
15.     AND   vt = '00X'
16.     ORDER BY PRIMARY KEY.
17.  
18.  

GeSHi ©

Ich habe schon mal versucht, l_wa_tabname mit Hilfe von (lv_tabtype) zu deklarieren. Aber irgendwie funktioniert das nicht.

@hubi
vielen dank fuer den hinweis. Du kennst nicht zufällig einen Beispielreport im System, der nach diesem Verfahren eine dynamische Tabelle erzeugt?


Euch beiden jedenfalls herzlichen Dank

gse

Ziel meiner Bemühungen war es, mit Hilfe der Übergabeparameter des Funktionsbausteins einen Update auf ein x-beliebiges DDIC-Objekt zu vollziehen.

Wessen Idee war das denn? Die Idee ist gar nicht gut.

hi frank,

wenn Du das sagst wird das schon stimmen.
Ich dachte ich koennte mir hierdurch Erleichterung fuer kuenftige Programme schaffen, indem ich diesen FuBa einfach immer nur mit den richtigen Parametern fuettere und so meine DB-Aktionen realisiere.

Vielleicht hilfst Du mir noch zu verstehen, was an dieser Idee nicht gut ist.
Danke im Voraus! gse

Hi gse,

nur mal so aus Neugier: Wenn Du das realisierst, dann aber nicht für jedes x-beliebige DDIC-Objekt sondern DDIC-Objekt im Sinne einer DB-Tabelle, oder verstehe ich Dich falsch?!

Gruß,
Steff

hallo liebe leutz,

angenommen ich will jetzt meinen SELECT komplett dynamisch aufbauen, also in einem weiteren import-parameter ein feld benennen, was dann als kriterium in der WHERE-klausel anwendung findet.

beispiel:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. SELECT *
2.     INTO TABLE l_it_tabname
3.     FROM &#40;lv_tabtype&#41;                 "dynam. DDIC-Objekt!
4.     WHERE bukrs = '0050' .
5.  

GeSHi ©

dynamisch sollen dann quasi auch die Felder des DDIC-Objektes mit übergeben werden. also so was aehnliches wie:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. SELECT *
2.     INTO TABLE l_it_tabname
3.     FROM &#40;lv_tabtype&#41;                 "dynam. DDIC-Objekt!
4.     WHERE lv_tabtype-schluessel = lv_field.
5.  

GeSHi ©

lv_tabtype-schluessel waere demnach komponente von lv_tabtype und lv_field ebenfalls importparameter bzw. selektionskriterium.

gruss gse

hi steff,

aeeeehhhh......... ja! klar, so hab ich das gemeint!

ahhhh...... Du verstehst mich!;)

gse

wahnsinn,
da hab ich doch glatt mal was selbst gefunden!
an dieser stelle mal ein sorry an diejenigen, die ich mit meiner fragerei endlos nerve!

und fuer all die anderen interessierten:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. DATA: cond&#40;72&#41; TYPE c,
2.           itab LIKE TABLE OF cond.
3.  
4. PARAMETERS: city1&#40;10&#41; TYPE c, city2&#40;10&#41; TYPE c.
5.  
6. DATA wa TYPE spfli-cityfrom.
7.  
8. CONCATENATE 'CITYFROM = ''' city1 '''' INTO cond.
9. APPEND cond TO itab.
10.  
11. LOOP AT itab INTO cond.
12.   WRITE cond.
13. ENDLOOP.
14.  
15. SELECT  cityfrom
16.   INTO  wa
17.   FROM  spfli
18.   WHERE &#40;itab&#41;.
19.  

GeSHi ©

gruss und weiterhin frohes schaffen!

gse