GET

Basic form 1

GET dbtab.

Additions

1. ... LATE
2. ... FIELDS f1 ... fn

Effect

Processing event.

Gets the table dbtab for processing while the logical database is running. You can address all the fields from dbtab in the subsequent processing. You can also refer to fields from tables in the logical database on the access path to the table dbtab .

Note

You can use the event " GET dbtab. " only once in the report.

Example

The program uses the logical database F1S which has a structure where the table BOOKING appears below the table FLIGHT .


TABLES: SFLIGHT, SBOOK.

GET SFLIGHT.
  WRITE: SFLIGHT-CARRID,
         SFLIGHT-CONNID,
         SLFIGHT-FLDATE,
         SFLIGHT-PLANETYPE.

GET SBOOK.
  WRITE: SBOOK-BOOKID,
         SBOOK-CUSTOMID,
         SBOOK-ORDER_DATE.

Addition 1

... LATE.

Effect

Executes the code following " GET dbtab LATE. " only when all the subordinate tables have been read and processed.

Example

Count the smokers among the bookings already made.


TABLES: SFLIGHT, SBOOK.
DATA SMOKERS TYPE I.

GET SFLIGHT.
  ULINE.
  WRITE: / SFLIGHT-SEATSMAX,
           SFLIGHT-SEATSOCC.
  SMOKERS = 0.

GET SBOOK.
  CHECK SBOOK-SMOKER <> SPACE.
  ADD 1 TO SMOKERS.

GET FLIGHT LATE.
  WRITE SMOKERS.

Addition 2

... FIELDS f1 ... fn

Effect

Performance option. Addresses only the fields f1, ..., fn of the tabelle dbtab (also possible with a dynamic ASSIGN ). Since only these fields have to be assigned values by the logical database, this can improve performance considerably.

Notes

The addition (for GET dbtab or GET dbtab LATE ) is allowed only for tables intended for field selection by the logical database (SELECTION-SCREEN FIELD SELECTION FOR TABLE dbtab ).
When executing the events GET dbtab , GET dbtab LATE or GET dbtab_2 for a subordinate table dbtab_2 in the database hierarchy, the contents of all all fields of dbtab apart from f1, ..., fn are undefined.
If both GET dbtab FIELDS f1 ...fn and GET dbtab LATE FIELDS g1 ...gm occur in the program, values are assigned to all the fields f1, ..., fn, g1, ..., gm .
In addition to the specified fields, values are also assigned to the key fields of dbtab .
If you use the FIELDS addition, you access only the specified fields. Any external PERFORM calls should be taken into account here.
A special rule applies for tables which are intended for field selection by the logical database, for which neither a GET dbtab nor a GET dbtab LATE event exists in the program, yet for which there is a subordinate table dbtab_2 with GET dbtab_2 or GET dbtab_2 LATE in the program.

If the table is declared with TABLES dbtab in the program, the work area of dbtab exists for GET dbtab_2 or GET dbtab_2 LATE and is can therfore receive values. Also, if a restricted field selection is sufficient for dbtab , you can achieve this with a GET dbtab FIELDS f1 ... fn statement (without subsequent processing).

If the program contains no TABLES dbtab statement, the system assumes no access to the work area of dbtab . In this case, therefore, only the key fields of dbatab are assigned values. If, however, you want to fill the work area of dbtab completely (e.g. for an external PERFORM call), you must include the TABLES dbtab statement in the program.
The field lists are made available to the report and the logical database in an internal table SELECT_FIELDS .

The exact definition of the object SELECT_FIELDS is stored in the TYPE-POOL RSFS and reads:

TYPES: BEGIN OF RSFS_TAB_FIELDS,
TABLENAME LIKE RSDSTABS-PRIM_TAB,
FIELDS LIKE RSFS_STRUC OCCURS 10,
END OF RSFS_TAB_FIELDS.

...

TYPES: RSFS_FIELDS TYPE RSFS_TAB_FIELDS OCCURS 10.

DATA SELECT_FIELDS TYPE RSFS_FIELDS.

SELECT_FIELDS is thus an internal table. Each line of this internal table contains a table name ( TABLENAME ) and another internal table ( FIELDS ) which contains the desired table fields ( TABLENAME ).

Neither the TYPE-POOL RSFS nor the declaration of SELECT_FIELDS have to be in the report. Both are automatically included by the system, if required. If, for some reason, you need to assign values to more fields, you can manipulate this table under INITIALIZATION or START-OF-SELECTION .

Examples

Specify the necessary fields under GET . Both SFLIGHT and SBOOK must be defined for field selection.


TABLES: SFLIGHT, SBOOK.

GET SFLIGHT FIELDS CARRID CONNID FLDATE PLANETYPE.
  WRITE: SFLIGHT-CARRID,
         SFLIGHT-CONNID,
         SFLIGHT-FLDATE,
         SFLIGHT-PLANETYPE.

GET SBOOK FIELDS BOOKID CUSTOMID ORDER_DATE.
  WRITE: SBOOK-BOOKID,
         SBOOK-CUSTOMID,
         SBOOK-ORDER_DATE.

In the above 'smoker' example, you can also specify the required SFLIGHT fields under 'GET SFLIGHT LATE':


TABLES: SFLIGHT, SBOOK.
DATA SMOKERS TYPE I.

GET SFLIGHT.
  ULINE.
  WRITE: / SFLIGHT-SEATSMAX,
           SFLIGHT-SEATSOCC.
  SMOKERS = 0.

GET SBOOK FIELDS SMOKER.
  CHECK SBOOK-SMOKER <> SPACE.
  ADD 1 TO SMOKERS.

GET SFLIGHT LATE FIELDS SEATSMAX SEATSOCC.
  WRITE SMOKERS.

Only fields from SBOOK are output. No TABLES SFLIGHT statement exists. Then, for the table SFLIGHT , only the key fields are read (regardless of whether the FIELDS addition is used with GET SBOOK or not).


TABLES: SBOOK.

GET SBOOK FIELDS BOOKID CUSTOMID ORDER_DATE.
  WRITE: SBOOK-BOOKID,
         SBOOK-CUSTOMID,
         SBOOK-ORDER_DATE.

Only fields from SBOOK are output, but SFLIGHT is declared by TABLES SFLIGHT . In this case, all the fields of table SFLIGHT are read (regardless of whether the FIELDS addition is used with GET SBOOK or not).


TABLES: SFLIGHT, SBOOK.

GET SBOOK FIELDS BOOKID CUSTOMID ORDER_DATE.
  WRITE: SBOOK-BOOKID,
         SBOOK-CUSTOMID,
         SBOOK-ORDER_DATE.