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: 

ALV list with empty data - What could have gone wrong?

former_member367551
Participant
0 Kudos

Dear experts,

I'm currently working on some codes to display data (the tables involved really do contain data), but when the codes are executed, the ALV list does not contain any data in it (only the column headers are fine).

What could have gone wrong? I've been staring at the codes for hours now. Please help. Appreciate any help at all.

Displaying ALV data with REUSE_ALV_LIST_DISPLAY:


form display_alv_data .

  CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY'
    EXPORTING
*     I_INTERFACE_CHECK              = ' '
*     I_BYPASSING_BUFFER             =
*     I_BUFFER_ACTIVE                = ' '
      I_CALLBACK_PROGRAM             = w_prog
*     I_CALLBACK_PF_STATUS_SET       = ' '
*     I_CALLBACK_USER_COMMAND        = ' '
*     I_STRUCTURE_NAME               =
*     IS_LAYOUT                      =
      IT_FIELDCAT                    = gt_field_cat[]
*     IT_EXCLUDING                   =
*     IT_SPECIAL_GROUPS              =
*     IT_SORT                        =
*     IT_FILTER                      =
*     IS_SEL_HIDE                    =
*     I_DEFAULT                      = 'X'
*     I_SAVE                         = ' '
*     IS_VARIANT                     =
*     IT_EVENTS                      =
*     IT_EVENT_EXIT                  =
*     IS_PRINT                       =
*     IS_REPREP_ID                   =
*     I_SCREEN_START_COLUMN          = 0
*     I_SCREEN_START_LINE            = 0
*     I_SCREEN_END_COLUMN            = 0
*     I_SCREEN_END_LINE              = 0
*     IR_SALV_LIST_ADAPTER           =
*     IT_EXCEPT_QINFO                =
*     I_SUPPRESS_EMPTY_DATA          = ABAP_FALSE
*   IMPORTING
*     E_EXIT_CAUSED_BY_CALLER        =
*     ES_EXIT_CAUSED_BY_USER         =
    TABLES
      T_OUTTAB                       = gt_final
    EXCEPTIONS
      PROGRAM_ERROR                  = 1
      OTHERS                         = 2.

  IF SY-SUBRC <> 0.

    MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
            WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

  ENDIF.

endform.                    " display_alv_data

Retrieving data from the database tables into the internal table:


form retrieve_data .

  " For internal table 1
  SELECT ekbe~ebeln
         mseg~mblnr
         ekbe~belnr
         ekbe~ebelp
         ekbe~matnr
         ekbe~menge
         ekbe~dmbtr
         ekbe~werks
         mseg~lgort
         mseg~lifnr
         lfa1~name1
  FROM ekbe INNER JOIN mseg ON ekbe~ebeln = mseg~ebeln
            INNER JOIN lfa1 ON mseg~lifnr = lfa1~lifnr
  INTO CORRESPONDING FIELDS OF TABLE gt_1
  WHERE mseg~bwart = '101' AND      " Movement type: Goods Receipt
        ekbe~vgabe = '2' AND        " Transaction / event type for Invoice Verification Number
        ekbe~matnr IN s_m_num AND
        mseg~lifnr IN s_v_num.

  " For internal table 2
  SELECT ekbe~ebeln
         makt~maktx
         eket~eindt       		
  FROM ekbe INNER JOIN makt ON ekbe~matnr = makt~matnr
            INNER JOIN eket ON ekbe~ebeln = eket~ebeln
  INTO CORRESPONDING FIELDS OF TABLE gt_2
  WHERE eket~eindt IN s_d_date.

  " For internal table 3
  SELECT ekbe~ebeln
         ekko~bedat
         ekko~ekorg
         ekko~ekgrp
         ekko~bukrs
  FROM ekbe INNER JOIN ekko ON ekbe~ebeln = ekko~ebeln
  INTO CORRESPONDING FIELDS OF TABLE gt_3
  WHERE ekko~bedat IN s_p_date AND
        ekko~ekorg IN s_p_org AND
        ekko~ekgrp IN s_p_grp.

  " For the final internal table
  SORT: gt_1, gt_2, gt_3.

  LOOP AT gt_1.

    MOVE-CORRESPONDING gt_1 TO gt_final.
    READ TABLE gt_2 WITH KEY gfs_ebeln = gt_1-gfs_ebeln BINARY SEARCH.
    MOVE-CORRESPONDING gt_2 TO gt_final.
    READ TABLE gt_3 WITH KEY gfs_ebeln = gt_1-gfs_ebeln BINARY SEARCH.
    MOVE-CORRESPONDING gt_3 TO gt_final.
    APPEND gt_final.

  ENDLOOP.

endform.                    " retrieve_data

18 REPLIES 18

Former Member
0 Kudos

At the end of the FORM, in debug mode, do you see data in GT_FINAL?

Rob

0 Kudos

Rob,

I debugged my program and just discovered that there's no data even in the internal table gt_final.

What must I do now? Is there something wrong with the way I'm retrieving data from the database table?

0 Kudos

Now see if there's any data in gt_1. If not, the problem is in the first SELECT.

Rob

0 Kudos

Dear forumers,

I apologize for the rather late reply. The SAP server that I've been working on was down since Thursday evening and I wasn't able to debug much into the codes. Nevertheless, I really do appreciate all of your inputs and help here.

Rob,

I've just debugged my codes again and found out that in the first place, there is no data contained in the internal table gt_1 at all. My rough guess is because I've misused the INNER JOIN wrongly here (see code comments below):-


  SELECT ekbe~ebeln
         mseg~mblnr
         ekbe~belnr
         ekbe~ebelp
         ekbe~matnr
         ekbe~menge
         ekbe~dmbtr
         ekbe~werks
         mseg~lgort
         mseg~lifnr
         lfa1~name1  " this line should probably be commented out
  FROM ekbe INNER JOIN mseg ON mseg~ebeln = ekbe~ebeln
                    INNER JOIN lfa1 ON lfa1~lifnr = mseg~lifnr   " this line should probably be commented out - the table join here is not based on table ekbe at all
  INTO CORRESPONDING FIELDS OF TABLE gt_1
  WHERE mseg~bwart = '101' AND      
        ekbe~vgabe = '2' AND  
        ekbe~matnr IN s_m_num AND
        mseg~lifnr IN s_v_num.

Next, I commented out certain lines further and found that there is still no data contained in the internal table gt_1 again, as follows:-


  SELECT ekbe~ebeln
         mseg~mblnr
         ekbe~belnr
         ekbe~ebelp
         ekbe~matnr
         ekbe~menge
         ekbe~dmbtr
         ekbe~werks
         mseg~lgort
         mseg~lifnr
         " lfa1~name1
  FROM ekbe INNER JOIN mseg ON mseg~ebeln = ekbe~ebeln
                    " INNER JOIN lfa1 ON lfa1~lifnr = mseg~lifnr
  INTO CORRESPONDING FIELDS OF TABLE gt_1.
  " WHERE mseg~bwart = '101' AND      
        " ekbe~vgabe = '2' AND  
        " ekbe~matnr IN s_m_num AND
        " mseg~lifnr IN s_v_num.

There should be data contained in table ekbe here. What could have really gone wrong now?

ThomasZloch
Active Contributor
0 Kudos

The system punishes you for using global internal tables with headerlines (eeeks)

Did you make sure by debugging that gt_final actually contains any entries?

Thomas

0 Kudos

>

> The system punishes you for using global internal tables with headerlines (eeeks)

>

> Thomas

Huh? None of my reports uses tables with headerlines...even those using cl_gui_alv_grid or reuse_alv_grid_display

0 Kudos

Thomas,

Did you mean that I can't use headerlines for global internal tables?

But I can't think of a better way to append data into gt_final.

Any other ideas on how I can improvise here?

0 Kudos

> > The system punishes you for using global internal tables with headerlines (eeeks)

> >

> > Thomas

Huh? None of my reports uses tables with headerlines...even those using cl_gui_alv_grid or reuse_alv_grid_display

That's why I made that (satirical) remark. Deborah is using tables with headerlines, contrary to all recommendations to not use them anymore (ambiguous statements, not allowed in OO context etc.).

Thomas

0 Kudos

Hello Deborah

In order to fill a table type itab (i.e. w/o header line) simply define a corresponding work area which is used to fill the itab:


  DATA: ls_1      LIKE LINE OF gt_1,
             ls_final  LIKE LINE OF gt_final.

  LOOP AT gt_1 INTO ls_1.
 
    MOVE-CORRESPONDING ls_1 TO ls_final.
    "READ TABLE gt_2 WITH KEY gfs_ebeln = gt_1-gfs_ebeln BINARY SEARCH.
    "MOVE-CORRESPONDING gt_2 TO gt_final.
    "READ TABLE gt_3 WITH KEY gfs_ebeln = gt_1-gfs_ebeln BINARY SEARCH.
    "MOVE-CORRESPONDING gt_3 TO gt_final.
    APPEND ls_final TO gt_final.
 
  ENDLOOP.

I fully agree with Thomas and have mentioned this already several times in postings that header lines will mess up any program.

Regards

Uwe

0 Kudos

>

> I fully agree with Thomas and have mentioned this already several times in postings that header lines will mess up any program.

> Uwe

As far as I know the restriction on header lines is an OOPS restriction. It should cause no problems here.

Rob

0 Kudos

It indeed does not cause the described problem. I already regret pointing out the bad programming style, since it caused more confusion than I anticipated.

Still wondering how Deb's analysis on those table contents is doing.

Thomas

0 Kudos

>

> It indeed does not cause the described problem. I already regret pointing out the bad programming style, since it caused more confusion than I anticipated.

> Still wondering how Deb's analysis on those table contents is doing.

> Thomas

I figured as much. I was just trying to keep the thread on track

The problem seems to be in the first SELECT. If anything is returned, then both GT_1 and GT_FINAL should be populated. I ran that SELECT in our development system (with blank SELECT-OPTIONS) and it returned data.

So I think the problem is that the SELECT-OPTIONS are too restrictive.

Rob

0 Kudos

Dear forumers,

As for the internal tables with headerline issue, I will try to adjust my codes further.

Thanks for your inputs once again.

0 Kudos

Dear forumers,

I just managed to resolve the problem here.

I did a horrible (and embarassing) mistake by using the clause SELECT ... INTO CORRESPONDING FIELDS OF TABLE gt_1 when the fields in gt_1 here were first declared with different names than the fields in the database table.

Just using SELECT ... INTO TABLE gt_1 instead resolved the problem.

The same applies to internal tables gt_2 and gt_3 as well.

Sorry for all the troubles caused. And many, many thanks for all your help once again.

former_member194669
Active Contributor
0 Kudos

Possible reasons


  CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY'
    EXPORTING
      I_CALLBACK_PROGRAM             = w_prog " Hardcode your program name in CAPS
      IT_FIELDCAT                    = gt_field_cat[]
    TABLES
      T_OUTTAB                       = gt_final " Make it as gt_final[]
    EXCEPTIONS
      PROGRAM_ERROR                  = 1
      OTHERS                         = 2.

former_member188685
Active Contributor
0 Kudos

The problem is from the fieldcatalog. How you defined your fieldcatalog.

Did you mentioned the fieldnames in CAPS, and correctly. Mention the tabname also.

show your fieldcatalog population.

P561888
Active Contributor
0 Kudos

1. check the final table weather the records are appened or not.

2. check the filedcatlog what ever u have written in the program.

3. Give the fieldcatlog-fieldname in CAPS.

4.Append the filedcatlog properly...

Regards,

Bharani

Former Member
0 Kudos

Hi,

Define the Internal table with header line and move it to T_OUTTAB

Regards,

Nandha