Alternative for sentence CREATE DATA

[Former Member]

The sentence CREATE does not work in release 4.6c and it is right in 6.00.

DATA:    LT_1   TYPE REF TO DATA.

DATA:    L_NESTRUCT  TYPE T777D-DBTAB.

CREATE DATA LT_1  TYPE TABLE  OF (L_NESTRUCT).

Thank you very much

[schneidertho]

Hi Ignacio,

not sure, if I can answer 100% of your question... 4.6c is so long ago...

If I conclude correctly from the release notes, the functionality you are asking for is simply not there.

• 4.6a news http://help.sap.com/abapdocu_702/en/abennews-46-data-references.htm#!ABAP_MODIFICATION_2@2@
• 6.10 news http://help.sap.com/abapdocu_702/en/abennews-610-referenzen.htm#!ABAP_MODIFICATION_7@7@

Have no good idea, because I am not sure what you want to do. Understand that you want to create an internal table (maybe based on some user input). But what is the overall requirement?

Maybe someone else has additional thoughts.

Best regards

Thorsten

[Former Member]

Hi Ignacio,

As per the 4.6a changes highlighted by Thorsten , the below source code might work in 4.6c. This however takes only ABAP dictionary types. I also stumbled upon another post in the forum with the same issue as yours.

http://scn.sap.com/thread/62127

REPORT  ztest_vr_2.

PARAMETERS : p_type TYPE string," Data element

             p_tab  TYPE string." Table type.

DATA : gt_text TYPE STANDARD TABLE OF text72,

       g_prog TYPE sycprog,

       gs_text TYPE text72,

       gr_data TYPE REF TO data.

FIELD-SYMBOLS : <fs_data> TYPE ANY.

gs_text =  'report z_test_vr_3.'.

APPEND gs_text TO gt_text.

IF p_tab IS NOT INITIAL.

  CONCATENATE p_tab 'OF' INTO p_tab SEPARATED BY space.

ENDIF.

CLEAR gs_text.

CONCATENATE 'data:' 'g_dyn_var' 'type' p_tab p_type '.' INTO gs_text SEPARATED BY space..

APPEND gs_text TO gt_text.

CLEAR gs_text.

gs_text =  'form RETURN_REF CHANGING CR_REF TYPE REF TO DATA.'  .

APPEND gs_text TO gt_text.

CLEAR gs_text.

gs_text =  'GET REFERENCE OF G_DYN_VAR INTO CR_REF. '  .

APPEND gs_text TO gt_text.

CLEAR gs_text.

gs_text = 'endform.'.

APPEND gs_text TO gt_text.

GENERATE SUBROUTINE POOL  gt_text NAME g_prog.

PERFORM return_ref IN PROGRAM (g_prog) CHANGING gr_data .

ASSIGN gr_data->* TO <fs_data>.

Thanks,

Venkat.

[Ruediger_Plantiko]

Ignacio,

I have no system in that release to test here. But in an old release like this, I would prefer to work with a standard table of fixed type c, with a length like 1024. This is how the F4 guys have worked in those times, and the code is still running (you may look into the F4IF_... function modules to see running examples - the result list of F4 is a generic table, containing its data in a table with a long CHAR line type).

constants: gc_maxlength type i value 1024. " Adapt the length if necessary.

types: ty_line type c length gc_maxlength,

          ty_line_tab type ty_line occurs 0.

Then, instead of assigning field-symbols, you use MOVE to put the data into the type c field, and also to read them back later.

You max check the actual length of your DBTAB structure against GC_MAXLENGTH and issue a short dump if that length is exceeded.

If the simple MOVE doesn't work, since your table contains character data mixed with non-character data and the check for this situation is already implied in your release, you can use the "shadowed move" technique to trick out the syntax check - a bit dirty, but it's a way out, if you have no alternatives in your release:

field-symbols: <lv_c> type c.

assign ls_any to <lv_c> casting.  " LS_ANY: Structure containing non-char data

move <lv_c> to lv_line.                " LV_LINE: Type C

append lv_line to lt_lines.

Venkat's solution, involving dynamic code generation, is nice & elegant, but costly in terms of performance.

Regards,

Rüdiger

[Former Member]

Hi Rüdiger,

field-symbols: <lv_c> type c.
assign ls_any to <lv_c> casting.  " LS_ANY: Structure containing non-char data
move <lv_c> to lv_line.                " LV_LINE: Type C
append lv_line to lt_lines. 

Smart move! .

I have one question; How would you handle nested/deep structures (tables/reference types)? 

Thanks,

Venkat.

[Ruediger_Plantiko]

Hi Venkat,

I know it's impolite to answer a question with a question:

But what result would you expect when moving a reference to a type c field?

Regards,

Rüdiger

[Former Member]

Hi Rüdiger,

I was expecting an another trick up the sleeve to handle such scenarios  .

The reason why i posed that question was the OP (maybe) wanted to dynamically memory allocate a Nested structure ,

L_NESTRUCT  TYPE T777D-DBTAB

I was hoping there could be a solution apart from the dynamic code generation - Personally I am not a big fan  of dynamic code generation.

As you had said the best would be to ask the customer for an upgrade .

Thanks,

Venkat.

[Ruediger_Plantiko]

Venkat,

in case of nested structures or components of table type, one should think about the proper type of the target container. Obviously, type C of whatever length will not be appropriate. I have no idea for a target type in 4.6C. (From release 6.20 onwards, one could choose an XSTRING, however, and fill it with EXPORT ... TO DATA BUFFER.)

Regards,

Rüdiger

[Ruediger_Plantiko]

... and ask the customer for an upgrade

[matt]

In 46c, I generally resort to generated subroutines.

[Ruediger_Plantiko]

... that's fine and will give you no performance issues, if you save the subroutines as a subroutine pool with INSERT REPORT (as SE16 does).

[former_member186741]

you can use this to create a 'table' in 4.6c...

  DATA: lt_fieldcatalog TYPE lvc_t_fcat,

        lo_ztab_tab  TYPE REF TO data.

FIELD-SYMBOLS:
<table>    TYPE table.

* create a field catalog for the table
    CALL FUNCTION 'LVC_FIELDCATALOG_MERGE'
         EXPORTING
              i_structure_name = L_NESTRUCT
         CHANGING
              ct_fieldcat      = lt_fieldcatalog.

* create an internal table dynamically...

    CALL METHOD cl_alv_table_create=>create_dynamic_table

      EXPORTING

        it_fieldcatalog           = lt_fieldcatalog

      IMPORTING

        ep_table                  = lo_ztab_tab     .

* point field symbol to the table
    ASSIGN lo_ztab_tab->* TO <table>.

* <table> can now be accessed as an internal table!