topic Understanding Dynamic Tables (RTTS) in Application Development and Automation Discussions

Understanding Dynamic Tables (RTTS)

Former Member — Thu, 21 Jun 2012 14:55:32 GMT

Hi guys,

While i was playing with dynamic tables and i can't figure how to get the exact data type from data elements.

I'll explain better in code

* Declare Data. ( dynamic fields )

DATA: gt_fields TYPE STANDARD TABLE OF char30,

gs_fields TYPE char30,

gt_comp TYPE cl_abap_structdescr=>component_table,

gs_comp LIKE LINE OF gt_comp,

go_element TYPE REF TO cl_abap_elemdescr,

go_struct TYPE REF TO cl_abap_structdescr.

LOOP AT gt_fields INTO gs_fields.

* Element descripiton

go_element ?= cl_abap_elemdescr=>describe_by_name( gs_fields ).

* Field name

MOVE gs_fields TO gs_comp-name.

* Field type

gs_comp-type = cl_abap_elemdescr=>get_c( go_element->length ).

APPEND gs_comp TO gt_comp.

ENDLOOP.

This code is good and i can manage to build a dynamic table from this.

But:

1) gs_fields ( where i store the name of the fields ) can only be chart type ( get_c () ). if i send a field which type is integer i get dump and is normal.

2) when i display with alv i don't get any description in my column header.

I managed to get a better result but not as i wanted. ( i want a completely dynamic table )

-> Define a type in my program. add fields. ( ex: matnr type mara-matnr, mara-mtart etc )

-> Get components from existing type:

go_struct ?= cl_abap_typedescr=>describe_by_name( 'TY_MY_TYPE' ).

gt_comp = lo_struct->get_components( ).

I tried different options but none was good. I think is still something regarding how i fill my go_element i think. Do you have any ideas?

Thank you,

Alex F.

Re: Understanding Dynamic Tables (RTTS)

former_member184497 — Fri, 22 Jun 2012 09:48:21 GMT

Hi,

Please refer the blog for you queries

http://scn.sap.com/people/arunkumar.prabakaran/blog

Here a FM is used to generate dynamic internal table with different data type

Re: Understanding Dynamic Tables (RTTS)

Clemenss — Fri, 22 Jun 2012 15:24:45 GMT

Hi Alexandru Fediuc,

the best thing is to use existing data elements to create the dynamic table.

So you may extend your table that it carries a fieldname and a datatype (data element or DDIC structure and component) for each field to be created.

See here the (tested) sample program:

FORM dyndata .

TYPES:

BEGIN OF ty_dyndata,

fieldname TYPE fieldname,

data_type TYPE string,

END OF ty_dyndata,

ty_t_dyndata TYPE STANDARD TABLE OF ty_dyndata.

DATA:

lt_dyndata TYPE ty_t_dyndata,

lo_salv_table TYPE REF TO cl_salv_table,

lo_structdescr TYPE REF TO cl_abap_structdescr,

lo_typedescr TYPE REF TO cl_abap_typedescr,

lo_tabledescr TYPE REF TO cl_abap_tabledescr,

lr_data TYPE REF TO data,

lr_dyntable TYPE REF TO data,

lt_component TYPE cl_abap_structdescr=>component_table.

FIELD-SYMBOLS:

<dyndata> TYPE ty_dyndata,

<component> TYPE LINE OF cl_abap_structdescr=>component_table,

<dyntable> TYPE table.

* example with 2 fields

APPEND INITIAL LINE TO lt_dyndata ASSIGNING <dyndata>.

<dyndata>-fieldname = 'ORDER'.

<dyndata>-data_type = 'VBAK-VBELN'.

APPEND INITIAL LINE TO lt_dyndata ASSIGNING <dyndata>.

<dyndata>-fieldname = 'ITEM'.

<dyndata>-data_type = 'VBAP-POSNR'.

APPEND INITIAL LINE TO lt_dyndata ASSIGNING <dyndata>.

<dyndata>-fieldname = 'COMPANY'.

<dyndata>-data_type = 'BUKRS'.

APPEND INITIAL LINE TO lt_dyndata ASSIGNING <dyndata>.

<dyndata>-fieldname = 'COUNT'.

<dyndata>-data_type = 'I'.

* creation of dynamic table

LOOP AT lt_dyndata ASSIGNING <dyndata>.

TRY.

CREATE DATA lr_data TYPE (<dyndata>-data_type).

APPEND INITIAL LINE TO lt_component ASSIGNING <component>.

<component>-type ?= cl_abap_datadescr=>describe_by_data_ref( lr_data ).

<component>-name = <dyndata>-fieldname.

CATCH cx_root.

* error handling

* ... cannot create data of type <dyndata>-data_type

ENDTRY.

ENDLOOP.

* new description object for structured type

lo_structdescr = cl_abap_structdescr=>create( lt_component ).

* create table description for structure decription

lo_tabledescr = cl_abap_tabledescr=>create(

p_line_type = lo_structdescr

p_table_kind = cl_abap_tabledescr=>tablekind_std

p_unique = abap_false ).

* create dynamic data object (table)

CREATE DATA lr_dyntable TYPE HANDLE lo_tabledescr.

* use table

ASSIGN lr_dyntable->* TO <dyntable>.

* append a couple of records

DO 10 TIMES.

APPEND INITIAL LINE TO <dyntable>.

ENDDO.

* create SALV object

TRY.

cl_salv_table=>factory(

IMPORTING

r_salv_table = lo_salv_table

CHANGING

t_table = <dyntable>

CATCH cx_salv_msg .

ENDTRY.

* display table

lo_salv_table->display( ).

ENDFORM. " DYNDATA

As you may have noticed, I used field-symbols quite frequently. For a reason: INTO <work area> is NEVER faster than the use of field-symbols, field-symbols save memory and they can be used much more flexible.

We have column headers for data created based on structure fields (VBAK-VBELN) and data elements (BUKRS), not for direct type (I).

Also, the ALV consistency check reports a warning for this field:

BTW: The ALV consistency check can be invoked by holding CTRL and SHIFT keys, pointing in an empty area of the grid and double-right-click the mouse. (If someone can tell me how to catch a double-right-click and the CTRL-SHIFT key press, he or she is invited for dinner)

The description in column header is taken from field catalog. If you use SALV object model, the object model will create the field catalog it self. It works better if the data element refers to a dictionary DOMAIN, direct data type in data element causes inconsistencies.

Hope you can make use of this,

Regards,

Clemens

Re: Understanding Dynamic Tables (RTTS)

Former Member — Sat, 23 Jun 2012 08:26:12 GMT

Sorry, but the link is empty.

Re: Understanding Dynamic Tables (RTTS)

Former Member — Sat, 23 Jun 2012 08:34:54 GMT

Wow, thx! Very good example and very useful.

I found myself a way to , to refer directly to a data dictionary type by using:

go_data type ref to cl_abap_datadescr

and use in my loop :

go_data ?= cl_abap_datadescr=>describe_by_name ( gs_fields )

and then just use

gs_comp-type = go_data.

This is a bit faster for exercise. But it all depends on what you have to do.

BTW: The ALV consistency check can be invoked by holding CTRL and SHIFT keys, pointing in an empty area of the grid and double-right-click the mouse. (If someone can tell me how to catch a double-right-click and the CTRL-SHIFT key press, he or she is invited for dinner)

Did you try handling double_click in alv oo? making a local class , and maybe registering the events? i'm a start so i'm not sure

Re: Understanding Dynamic Tables (RTTS)

Clemenss — Sat, 23 Jun 2012 14:18:46 GMT

Thanks for the comment. Yes you are right, that's what I found out later that you can always use cl_abap_datadescr=>describe_by_name, it works identical. But if you look into the code of describe_by_name, you will see that it is more complex than describe_by_data_ref.

I did not take measures regarding speed in comparison. Usually dynamic table creation is used only once per execution, the difference can't be noticed. Even for a mass run, I have serious doubts that this action will be significant at all - compared to the rest of using the table.

Thank you for the hint for catching the double-right-click. I tried some time ago, even used pretty much time debugging - no success whatsoever.

Regards

Clemens

Re: Understanding Dynamic Tables (RTTS)

Clemenss — Sat, 23 Jun 2012 14:26:06 GMT

Hi,

well at least the search function still works 🙂

Dynamic Internal Table Population Code :

I would recommend not to use the code presented here. The used METHOD cl_alv_table_create=>create_dynamic_table

is from pre-RTTS times and uses obsolete coding technique including limited use (generate subroutine) and unwanted database commit.

Though, the code may be changed and adapted to RTTS easily.

Regards

Clemens