Alternative to CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE

[Sandra_Rossi]

TL;DR If you have a short dump GENERATE_SUBPOOL_DIR_FULL due to CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE, here is a method which replaces it and avoids the short dump. It has exactly the same parameters.

---

Before RTTC (release 6.40 in 2004), the solution to create a variable of a type known only at run time was possible by using the dynamic generation of ABAP code with GENERATE SUBROUTINE POOL.

Instead of building the ABAP code line by line, it was more convenient to call the static method CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE, which uses internally GENERATE SUBROUTINE POOL, to which you pass an ALV field catalog, and it returns the internal table corresponding to the catalog. It was used even if no ALV was displayed, for instance for storing the result of a dynamic SELECT (with columns or table only known at run time).

The big issue of GENERATE SUBROUTINE POOL is that it raises the short dump GENERATE_SUBPOOL_DIR_FULL if it's called more than 36 times in a given internal session.

If you are using CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE and you experienced such a short dump, then you may solve this problem by replacing the standard static method with the static method ZCL_ALV_TABLE_CREATE_RTTC=>CREATE_DYNAMIC_TABLE at github, which has exactly the same parameters but avoids the short dump because it creates the internal table with RTTC.

Before:

  cl_alv_table_create=>create_dynamic_table(

        EXPORTING

          it_fieldcatalog           = lt_fieldcat_lvc

        IMPORTING

          ep_table                  = grt_std

        EXCEPTIONS

          generate_subpool_dir_full = 1

          OTHERS                    = 2 ).

After:

  zcl_alv_table_create_rttc=>create_dynamic_table(

        EXPORTING

          it_fieldcatalog           = lt_fieldcat_lvc

        IMPORTING

          ep_table                  = grt_std

        EXCEPTIONS

          generate_subpool_dir_full = 1

          OTHERS                    = 2

        ).

Note that the exception GENERATE_SUBPOOL_DIR_FULL is still there for keeping the compatibility with the standard method, but it cannot happen anymore.

Note that there are also 3 standard function modules which call the static methods of CL_ALV_TABLE_CREATE (REUSE_ALV_CREATE_TABLE, ALV_CREATE_TABLE, LVC_CREATE_TABLE), so you might replace their calls with the corresponding static methods of ZCL_ALV_TABLE_CREATE_RTTC.

 

[former_member606445]

One problem I found with using this call recently was that the user wanted me to add colors to the dynamic ALV and I found it impossible to specify  a "LVC_T_SCOL" table in the fieldcatalog.


I then switched over to using CL_ABAP_STRUCTDESCR to define the ALV layout via a combination of static structure and dynamic types and then used CREATE DATA to instantiate my dynamic table.

[Sandra_Rossi]

CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE only handles the creation of a column XYZSTYLEZYX of type LVC_T_STYL by setting the parameter I_STYLE_TABLE = 'X'. Feel free to propose a pull request to extend ZCL_ALV_TABLE_CREATE_RTTC (with a new parameter I_COLOR_TABLE for instance) or to raise an issue.

[shaun_oxley]

Hi Sandra

Hope you are doing well.

This class/approach is exactly what we are looking for to overcome the generate_subpool_dir_full  36 instance limit. I created the PUBLIC class today and called it from a copy of CL_FDT_XL_SPREADSHEET in method GET_RANGE_ITAB_FROM_XMLDOC.

Sadly I am getting a short dump in method FB_TABLE_CREATE_STRING because the logic does not pick up the INTTYPE 'g' and therefore the field catalog is not fully constructed.

I could be missing the point somewhere (it has happened before) and I am fairly new to GitHub, could you kindly offer some help in this matter?

Have a great day, Derek (Shaun)

[Sandra_Rossi]

Hi Derek (Shaun)

Thank you. I have seen a big bug in the code (ELSE missing), and I have uploaded the corrected code.

Sandra

[konstantinos_vassiliadis]

Hello,

I try using the code but I get the following syntax error:

 

Method FB_TABLE_CREATE_STRING syntax error

[Sandra_Rossi]

I guess you are using an old ABAP version.

Try this workaround and tell me whether it works:

DATA type_name TYPE string.

type_name = ls_fieldcat-ref_tabname && '-' && ls_fieldcat-ref_fieldname.

ls_comp_type ?= cl_abap_typedescr=>describe_by_name( type_name ).

[Triantafillos_p]

Thank you very much for you effort!

[SiddZaman]

Thank you so much! Appreciate your efforts, this was extremely helpful.

[danielsanchezalcaide]

Hi Sandra,

First of all, thanks for your work on this, it's really useful.

I faced a short dump regarding the method fb_table_create_string because it didn't recognize the data types 'N' nor 'C'. I just solved it by simply adding the following in your code:

 IF ls_fieldcat-datatype = 'CHAR' OR ls_fieldcat-datatype = 'C'.

 IF ls_fieldcat-datatype = 'NUMC' OR ls_fieldcat-datatype = 'N'.

Hope it helps others.

Greetings!

[Sandra_Rossi]

Thanks for contributing. You can contribute directly to my GitHub repository by forking + using abapGit.

Note that your ABAP program should not fill datatype with C or N, it should use CHAR or NUMC only. C or N are ABAP types (length 1). CHAR or NUMC are DDIC types (length 4).

But I agree the code should handle it nicely and just raise an exception instead of a short dump (+ remember to handle exceptions in the calling program).

[danielsanchezalcaide]

Thanks Sandra for your comment,

I will check why the main program is generating C and not CHAR.

Regards,

Daniel.

[Sandra_Rossi]

Note also that if CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE used to work, and failed when you replace it with ZCL_ALV_TABLE_CREATE_RTTC=>CREATE_DYNAMIC_TABLE, it's probably due to a change of standard subroutine FB_TABLE_CREATE_STRING of program SAPLSKBH. The method FB_TABLE_CREATE_STRING of ZCL_ALV_TABLE_CREATE_RTTC was once a copy of standard subroutine. We could adapt the method to reflect the change of standard behavior.