Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Using method create_dynamic_table

Former Member
0 Kudos

Hi,

I am using the above method (class cl_alv_table_create) to, whowouldathunkit,  create an internal table: I have a construction of two nested WHILE loops to fill the internal table i_fcat which goes into the method so that it is not necessary to know how many tables (outer loop) and fields (inner loop) there are or even how many fields there are to any given table, it can vary.

Now I have two problems with the internal table being generated by this method:

1) The datatypes are always C, it seems: There is a SELECT which fetches some data from DB tables and puts it into this internal table. As long as it fetches only C-type fields, it works fine. As soon as it includes a D-type field like ERDAT, it fails because a D-type field cannot be squeezed into a C-type one.

2) The method cannot work with two fields that have the same name; This is, however, quite commonplace between different SAP tables, so it is more than probable that my SELECT will in the long run include several fields that come from different tables, yet have the same name (you see I'm trying to make this program dynamic, the user will enter what tables and fields he wants in a dialog).

Can anybody give me any hint as to how I can fix this? Can I perhaps use that method in a way so that it automatically defines the datatypes matching the DB object (f.e., if I have KNA1-ERDAT, that is datatype D - if the method were to take table_name and field_name and just define the datatype of the field to match that field, that would be perfect). I know there is a field "DATATYPE" in the line_type underlying the table_type LVC_T_FCAT that I use for i_fcat.

Thanks a lot!

Best regards,

Sapperdapper

1 ACCEPTED SOLUTION

raymond_giuseppi
Active Contributor
0 Kudos

Usually to build an internal table via field catalog from multiple database tables, I start collecting field catalog from database table (LVC_FIELDCATALOG_MERGE) and then copy only required record into the final field catalog, renumbering records (*), and maintaining also an internal table of columns to extract (**). When duplicate names arise, I rename them in the field catalog.

Regards,

Raymond

(*) <field>-col_pos = sy-tabix

(**) APPEND 'MKPF~MBLNR' to lt_columns. then SELECT (lt_columns) FROM... where lt_columns is a table of string.

6 REPLIES 6

Former Member
0 Kudos

Hi, may be you can have a look at sample code in SE38 by giving program name as  BCALV_TABLE_CREATE.

raymond_giuseppi
Active Contributor
0 Kudos

Usually to build an internal table via field catalog from multiple database tables, I start collecting field catalog from database table (LVC_FIELDCATALOG_MERGE) and then copy only required record into the final field catalog, renumbering records (*), and maintaining also an internal table of columns to extract (**). When duplicate names arise, I rename them in the field catalog.

Regards,

Raymond

(*) <field>-col_pos = sy-tabix

(**) APPEND 'MKPF~MBLNR' to lt_columns. then SELECT (lt_columns) FROM... where lt_columns is a table of string.

0 Kudos

Hi Raymond,

unfortunately I cannot do any renaming: You see, the crucial point from which I go is actually the SELECT that queries data from a set of joined DB tables and puts them into an internal table for further processing. To do that somewhat speedy and not alltoo resource-intensive, I am currently using the option INTO CORRESPONDING FIELDS. That means that if the user of my program enters two fields labeled ERDAT - from two different tables - that will be in my SELECT and it will look for one field labeled ERDAT for each occurence of the field from the DB, so there have to be two fields of that name in my internal table. When I rename one, the SELECT will fail  or I would have to modify the SELECT to use some other option. Is there another one comparably fast? I'm open for options.

Thanks a lot!

Best regards,

Sapperdapper

0 Kudos

Remember I use a :

SELECT (fieldlist) INTO TABLE <itab>.

I don't use any CORRESPONDING usually as I build the field catalog AND the selected field list together, so

- my created internal table has fields ERDAT and ERDAT2 in sequence

- my selected field list has A~ERDAT and B~ERDAT in sequence

- the fields sequence and definition in the internal table exactly match those of the select

- so A~ERDAT will be copied into ERDAT and B~ERDAT into ERDAT2

If the CORRESPONDING FIELDS addition is not specified, wa must contain enough components and the contents of the columns are assigned to the components of wa from left to right in the order specified after SELECT.

- to help user in layout maintenance I usually also create fields groups from the original table name

Regards,

Raymond

0 Kudos

Hi Raymond,

I think what you're doing is going in the right direction for what I'm trying to do. Let me explain a bit what I'm doing. I'm a newbie to ABAP, so thinking loud does not seem a bad idea.

- I have a number of variables (one for each field) from the dialog - those are the fields the user  

  wishes to download, the variables will all be numbered in one sequence.

- I then take those variables in sequence and fill them into the internal table i_fcat for that method.

- I (will) also use those variables to build my SELECT statement, concatenated with the
  table-name, but in the same sequence.

=> Working around that "duplicates-problem" with the method and using INTO TABLE, no CORRESPONDING would thus not be a problem since I can easily make sure the sequence of fields is the same.

What I may be able to do is just use the CONCATENATE function to make the field_names I fill into i_fcat the like of KNC1-ERDAT and KNA1-ERDAT. That way, I won't have duplicates and when my SELECT goes left_to_right without looking at the field_names, that will work just fine.

I'll try this out immediately.

Best regards,

Sapperdapper

P.S.: Okay, that works. Thank you very much! There remains much to do, but I am one little step further now.

To stay in context with the title of this thread, the next thing I need to do is find a way to get the datatype right: As I said, all is well as long as I have only fields that have a C-like datatype. What still poses a problem are fields having another datatype, e.g. ERDAT (datatype D).

0 Kudos

Hi all,

thanks for all the help! I'll close this now as "Assumed answered". I am now using that method and I have fully dynamized the SELECT statement including the joins, so for now all is fine. Now comes testing and searching for a scenario where my code will not work...

Thanks for all the help!

Best regards,

Sapperdapper