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: 

Why we use Tables statement in case of using SELECT-OPTIONS:

Former Member
0 Kudos

hi all,

Why we use Tables statement in case of using the following coding in an ABAP program ...

tables: vbak.

SELECT-OPTIONS: s1 for vbak-vbeln.

.

.

here if we dont provide the tables statement why it does not work ????

pls answwer ....???

1 ACCEPTED SOLUTION

RichHeilman
Developer Advocate
Developer Advocate
0 Kudos

The SELECT-OPTIONS is a little funny like that, it needs a specific type associated with it. The TABLES statement gives you this ability to assign the type, but it can also be handled other ways.

For example, you can use a DATA statement.



data: xvbak type vbak.

SELECT-OPTIONS: s1 for xvbak-vbeln.

Regards,

Rich Heilman

6 REPLIES 6

RichHeilman
Developer Advocate
Developer Advocate
0 Kudos

The SELECT-OPTIONS is a little funny like that, it needs a specific type associated with it. The TABLES statement gives you this ability to assign the type, but it can also be handled other ways.

For example, you can use a DATA statement.



data: xvbak type vbak.

SELECT-OPTIONS: s1 for xvbak-vbeln.

Regards,

Rich Heilman

0 Kudos

what u said is ok ... i.e

data: xvbak type vbak .

select-options: s1 for xvbak-vbeln.

the above part is ok .. but my question is ultimately u have to define the table in the program..

parameters: p1 like vbak-vbeln ( it works fine w/o tables stat. or declaring any variables)

but why we require to include the table in the program or to include the variable within program ?---> that was my question ?

0 Kudos

what u said is ok ... i.e

data: xvbak type vbak .

select-options: s1 for xvbak-vbeln.

the above part is ok .. but my question is ultimately u have to define the table in the program..

parameters: p1 like vbak-vbeln ( it works fine w/o tables stat. or declaring any variables)

but why we require to include the table in the program or to include the variable within program ?---> that was my question ?

0 Kudos

Hi

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.

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.

0 Kudos

Hi

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:

reward if usefull

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.

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.

Former Member
0 Kudos

Hi

in parameters you are refering to a perticular field in a table

where a sin selet-option your

SELECT-OPTIONS: s1 <b>for</b> vbak-vbeln

this for refers to the whole data base table

so you need to define tables for this

reward if usefull