tables

[Former Member]

hi gurus,

why we need to declare tables in abap programm

as this

tables: mara, marc."why we declare this

data: begin of it occurs 0,

matnr like mara-matnr,

lgort like marc-matnr,

end of it.

i am new to abap,

plz help me its urgent.

thanks jayant.

[Former Member]

as of 4.7(i think) you don't need to declare tables.

your data statements are outdated.

you should use types instead.

types: begin of t_tab,
   matnr type matnr,
   lgort   type lgpro.
types: end of t_tab.

data: i_tab type standard table of t_tab,
        wa_tab like line of i_tab.

[Former Member]

Hello,

You use the statement TABLES to create an interface with the DDIC. When you use it, all the attributes of the ddic structures declared using it are recovered from the DDIC (like search help and so on).

But remember that's an obsolete command.

TABLES table_wa. 
Effect 
This statement is not allowed in classes and declares a data object table_wa as a table work area whose data type is adopted from the identically named structured data type table_wa from the ABAP Dictionary. table_wa must be defined as a flat structure in the ABAP Dictionary. You can specify database tables or Views for table_wa. 
Work table areas declared with TABLES are interface work areas and should only be declared in the global declaration section of a program for the following purpose: 
The statement TABLES is required for exchanging data between screen fields that were defined in a program screen when transferring from the ABAP Dictionary and the ABAP program. For the screen event PBO, the content of the table work area is transferred to identically named screen fields; for PAI, the system adopts the data from identically named screen fields. 
In executable programs, flat table work areas can be used for adopting data that were provided for the event GET table_wa from a linked logical database. TABLES is synonymous with the statement NODES for this purpose. 
Notes 
Work table areas declared with TABLES behave like the data declared with the addition COMMON PART, meaning the data are used by the programs of a program group. 
Table work areas declared with TABLES can be declared in subroutines and function modules. However, this is not recommended. A table work area declared in a procedure is not local but belongs to the context of a framework program. The table work area can be viewed starting from the declaration in the framework program and lives as long as the framework program. In contrast to normal program-global data, the content of the table work areas declared in subroutines and function modules is stored temporarily when these subroutines and function modules are called. Value assignments that were made during runtime of the procedure are preserved until the procedure is completed. When exiting the procedure, the table work areas are filled with the contents that they contained when the procedure was called. Table work areas declared in procedures behave like global data to which the statement LOCAL is applied in the procedure. 
The form TABLES * is obsolete. 

Regards.

[Former Member]

Hi

we declare that for default memory.

we can even use

TYPES : BEGIN OF st_kna1,

kunnr TYPE kna1-kunnr,

name1 TYPE kna1-name1,

END OF st_kna1.

DATA : it_kna1 TYPE STANDARD TABLE OF st_kna1.

[Former Member]

Jyothsna,

take a look at the revised code below. this is an easier way to declare your TYPE

TYPES : BEGIN OF st_kna1,

kunnr TYPE kunnr,

name1 TYPE name,

END OF st_kna1.

if you follow the data elements to their domains, kunnr & name in this case, you can type your variables like those.

[Former Member]

But what would happen in the (improbable) change of domain of kna1? What if kunnr stops using kunnr as a domain?

Maybe this is difficult in standard tables but pretty common in custom tables

[Former Member]

SAP changing the domain KUNNR is highly unlikely..

i see your point, but if the domain of a custom field in a Ztable is changing so far after it has been implemented that reports have already been produced, there was a design issue in the table - and you have bigger problems than changing the report code to reflect the new type - Data might get corrupted/truncated/concatenated... lots of things could happen.

And, yes, it would certainly be necessary to change the variable definition in the reports to reflect the new type.