working with internal tables without header lines

[Former Member]

Hello,

I am trying to write a program that uses tables without header lines. I hear that this is the perferred method. I am using the process of calling the forms with USING and CHANGING. I having a problem where I am trying to read a table and I am getting the error message -xxxx is a table without a header line and therefore has no component called xxxxx. I have copied some code pertaining to the table that I have trying to work with and the one causing the problem and I have attached it hoping that some could review it and let me know I am doing wrong. I am starting to get confused in this process. thanks in advance for the help.

TYPES: BEGIN OF ty_tvarv_date,

low TYPE TVARV_VAL, "start date

high TYPE TVARV_VAL, "end date

END OF ty_tvarv_date.

TYPES: ty_t_tvarv_date TYPE STANDARD TABLE OF ty_tvarv_date INITIAL SIZE 0,

DATA it_tvarv_date TYPE STANDARD TABLE OF ty_tvarv_date INITIAL SIZE 0.

FORM select_date_tvarv CHANGING p1_it_tvarv_date TYPE ty_t_tvarv_date.

• Select data from table

SELECT low high

FROM tvarv

INTO TABLE p1_it_tvarv_date

WHERE name EQ 'Z_SUBCONTRK_DATES'.

PERFORM select_data_mseg USING it_tvarv_date

it_tvarv_time

it_zfi_gl_subcontrk[]

CHANGING it_mseg.

FORM select_data_mseg USING p1_tvarv_date TYPE ty_t_tvarv_date

p1_tvarv_time TYPE ty_t_tvarv_time

p1_zfi_gl_subcontrk TYPE ty_t_zfi_gl_subcontrk

CHANGING p1_it_mseg TYPE ty_t_mseg.

DATA: t_tvarv_date TYPE STANDARD TABLE OF ty_tvarv_date INITIAL SIZE 0.

MOVE p1_tvarv_date TO t_tvarv_date.

• Select data from table

SELECT a~bukrs

a~mblnr

FROM mseg AS a INNER JOIN mkpf AS b ON a_{mblnr EQ b}mblnr

AND b~cpudt <= t_tvarv_date-high

AND b~cpudt >= t_tvarv_dateb-low

• CPUDT and CPUTM

INTO TABLE p1_it_mseg.

error message "T_TVARV_DATE" is a table without a header line and therefore has no component called "HIGH"

[Former Member]

Hi,

Declare your internal table as below.

DATA it_tvarv_date type ty_tvarv_date occurs 0 with header line.

your problem will be resolved.

thanks,

sksingh

[Former Member]

sksingh,

The ABAP help states that "with header line" is obsolete in ABAP objects so I am trying to learn to code table without header lines.

[Former Member]

make the correction as highlighted:

DATA: t_tvarv_date TYPE STANDARD TABLE OF ty_tvarv_date INITIAL SIZE 0.

<b>data: wa_tvarv type ty_tvarv_date.</b>

MOVE p1_tvarv_date TO <b>wa</b>_tvarv_date.

• Select data from table

SELECT a~bukrs

a~mblnr

FROM mseg AS a INNER JOIN mkpf AS b ON a_{mblnr EQ b}mblnr

where b~cpudt <= <b>wa</b>_tvarv_date-high

AND b~cpudt >= <b>wa</b>_tvarv_dateb-low

• CPUDT and CPUTM

INTO TABLE p1_it_mseg.

[Former Member]

Ravi

added the code - sample attached

FORM select_data_mseg USING p1_tvarv_date TYPE ty_t_tvarv_date

p1_tvarv_time TYPE ty_t_tvarv_time

p1_zfi_gl_subcontrk TYPE ty_t_zfi_gl_subcontrk

CHANGING p1_it_mseg TYPE ty_t_mseg.

• Internal table declaration for tvarv_date

DATA: t_tvarv_date TYPE STANDARD TABLE

OF ty_tvarv_date INITIAL SIZE 0.

data: wa_tvarv_date type ty_tvarv_date.

• Move the internal table p1_it_tvarv_date to local table t_tvarv_date

MOVE p1_tvarv_date TO wa_tvarv_date.

• Select data from table

SELECT a~bukrs

a~mblnr

FROM mseg AS a INNER JOIN mkpf AS b ON a_{mblnr EQ b}mblnr

AND b~cpudt <= wa_tvarv_date-high

AND b~cpudt >= wa_tvarv_date-low

• CPUDT and CPUTM

INTO TABLE p1_it_mseg.

new error message the type in "WA_TVARV_DATE" cannot be converted to the type in "P1_TVARV_DATE".

[uwe_schieferstein]

Hello Timothy

The reason for the syntax error is as following:

p1_tvarv_date is a <b>TABLE TYPE</b>, thus you could write:

READ TABLE p1_tvarv_date INTO wa_tvarv_date INDEX 1.
..
" do the select

Regards

Uwe

[Former Member]

I don't think it will work this way because p1_tvarv_time is a table and wa_tvarv_time is a line. Please try my way (see my other post) where you loop at p1_tvarv_time into work area w_tvarv_time.

- April King

[Former Member]

Since you have no header line, you need to read the table into a workarea. Try something like this:

DATA: w_tvarv_date TYPE ty_tvarv_date.

DATA: t_tvarv_date TYPE STANDARD TABLE OF ty_tvarv_date INITIAL SIZE 0.

MOVE p1_tvarv_date TO t_tvarv_date.

LOOP AT t_tvarv_date INTO w_tvarv_date.

• Select data from table

SELECT a~bukrs

a~mblnr

FROM mseg AS a INNER JOIN mkpf AS b ON a_{mblnr EQ b}mblnr

AND b~cpudt <= w_tvarv_date-high

AND b~cpudt >= w_tvarv_dateb-low

• CPUDT and CPUTM

INTO TABLE p1_it_mseg.

ENDLOOP.

I hope this helps.

- April King

[uwe_schieferstein]

Hello Timothy

The "solution" provided by Srinivas will indeed solve your current syntax problem but in the long term any application working with itabs having header lines will be a nightmare with respect to maintenance.

There are in pricipal two way to work with table types (= itabs WITHOUT (!!!) header lines):

(1) Defining tables types in the ABAP dictionary
(2) Using local table type definitions

Whereas (1) should be quite straightforward I give you an example for (2) adjusted to your current coding:

TYPES: BEGIN OF ty_s_tvarv_date.
TYPES:  low    TYPE tvarv_val.  " NOTE: I prefer to use the TYPES:... for each
TYPES: high    TYPE tvarv_val.  "  field in the definition although this is not necessary
TYPES: END OF ty_tvarv_date.
TYPES: ty_t_tvarv_date  TYPE STANDARD TABLE OF ty_s_tvarv_date
                                    WITH DEFAULT KEY.

DATA:
  ls_tvarv_date     TYPE ty_s_tvarv_date,
  lt_tvarv_date     TYPE ty_t_tvarv_date.

The rest of your coding is not always clear to me, mostly due to missing naming conventions.

I assume that somewhere in your coding you have the follwing statement:

PERFORM select_data_tvarv CHANGING it_tvarv_date.

If so then I would code the routine as following:

FORM select_date_tvarv 
                     CHANGING 
                         ct_tvarv_date TYPE ty_t_tvarv_date.
...
ENDFORM.

Here is your next PERFORM statement:

PERFORM select_data_mseg USING it_tvarv_date
it_tvarv_time
it_zfi_gl_subcontrk[]
CHANGING it_mseg.

Most likely you want to select the messages for all entries in your itab. Thus, the routine should look like this:

FORM select_data_mseg
                                USING
                                  VALUE(ut_tvarv_date)  TYPE ty_t_tvarv_date
                                  VALUE(ut_tvarv_time)  TYPE ty_t_tvarv_time
                                  VALUE(ut_zfi_gl_subcontrk)  TYPE ...
                              CHANGING
                                         ct_mseg     TYPE ty_t_mseg.

" If all values of the CHANGING parameter should come from the routine
" then I would add an initialization step:
  REFRESH: ct_mseg.

" Not required
*DATA: t_tvarv_date TYPE STANDARD TABLE OF ty_tvarv_date INITIAL SIZE 0.
" Not required
*MOVE p1_tvarv_date TO t_tvarv_date.

* Select data from table
IF ( ut_tvarv_date IS INIITIAL ).
ELSE.
  SELECT a~bukrs
  a~mblnr
  FROM mseg AS a INNER JOIN mkpf AS b ON a~mblnr EQ b~mblnr
  FOR ALL ENTRIES IN ut_tvarv_date  " added !!!
  AND b~cpudt <= ut_tvarv_date-high 
  AND b~cpudt >= ut_tvarv_dateb-low
  * CPUDT and CPUTM
  INTO TABLE ct_mseg.
ENDIF.

Is there any advantage of my "strange" naming conventions over yours? In your case any parameter (USING or CHANGING) begins with p1_. Thus, I cannot tell from the variable name which data are used as input and which are used as output.

Using my naming conventions I can immediately spot input and output of a routine without knowing the routine interface. On the contrary, I can tell from the variable names how the routine interface looks like.

<b>Final remark</b>: <u>naming conventions are as important as staying away from header lines for high-quality ABAP development</u>. Do not get confused by people telling you this is nonsense because they are wrong.

Regards

Uwe