09-25-2008 4:43 PM
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
09-25-2008 4:47 PM
At the end of the FORM, in debug mode, do you see data in GT_FINAL?
Rob
09-26-2008 1:40 AM
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?
09-26-2008 2:50 AM
Now see if there's any data in gt_1. If not, the problem is in the first SELECT.
Rob
09-29-2008 2:47 AM
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?
09-25-2008 4:47 PM
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
09-25-2008 7:42 PM
>
> 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
09-26-2008 1:43 AM
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?
09-26-2008 8:13 AM
> > 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
09-26-2008 8:38 AM
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
09-26-2008 2:15 PM
>
> 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
09-26-2008 2:18 PM
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
09-26-2008 3:06 PM
>
> 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
09-29-2008 3:02 AM
Dear forumers,
As for the internal tables with headerline issue, I will try to adjust my codes further.
Thanks for your inputs once again.
09-29-2008 4:42 AM
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.
09-25-2008 4:49 PM
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.
a®
09-25-2008 6:51 PM
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.
09-25-2008 7:18 PM
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
09-26-2008 2:22 PM
Hi,
Define the Internal table with header line and move it to T_OUTTAB
Regards,
Nandha