PUT Syntax diagram

PUT

Variants:

1. PUT node.

2. PUT <node>.

Effect

This statement is only allowed in the access program of a logical database in whose structure node node occurs. It is used to pass the data read by the logical database to the user of the logical database. Such a user is either a started program of type 1 (a "report") that has the logical database in its program attributes or a program that calls function module LDB_PROCESS.
In the first case (program of type 1), "PUT node." or " PUT <node>." triggers event "GET node." in the started report. In the second case the callback routine passed to the function module is called and the data of work area node or <node> is passed to the routine. The PUT subroutines of the nodes that follow immediately are called if the user is interested in the subordinate nodes. Event " GET node LATE." is then triggered if it is specified in the report or if the corresponding callback routine is called.

Note

Which of the two variants is used depends on the type of node.

Variant 1

PUT node.


Effect

This is the standard variant that is valid for all nodes whose type is not "dynamic Dictionary type". In this case the data object that is subordinate to the node (with the name node of the node) has a fixed type and is created globally in the database program. This data object must be filled by the logical database before the PUT statement is processed. If a report has been started, the work area of this data is used by both the database program and the report. The contents of node are thus available automatically at the time of the PUT statement for the corresponding GET event. If a logical database is used with LDB_PROCESS, database object node is passed to the callback routine by the PUT statement.

Variant 2

PUT <node>.


Effect

This variant must be used for all nodes that have type "dynamic Dictionary type". In this case the statement NODES node. in the database program not only globally creates database object node with the static type defined in the logical database (this data object is also available for the report), but also a field symbol <node>. The logical database can get the runtime data type of the node defined by the user from internal table DYN_NODE_TYPES, which is generated by the system (without header, line type DYN_NODES consisting of the fields NODE and TYPE). This type must belong to the list of types reserved for the node by the logical database (Transaction SE36). In the database program, a data object of this type must be assigned to field symbol <node> (language element ASSIGN). This data object must be filled before the PUT statement is processed. " PUT <node>" behaves just like "PUT node" in non-dynamic cases. The only difference is that <node> is passed to the user instead of node.

Example

NODES CHARLY.    " static dictionary type SPFLI
NODES DYNNODE.   " Dynamic dictionary type, static type SFLIGHT

...

FORM PUT_CHARLY.
  SELECT * FROM SPFLI INTO CHARLY WHERE ...
    PUT CHARLY.
  ENDSELECT.
ENDFORM.

FORM PUT_DYNNODE.
  STATICS L_DYN_NODES TYPE DYN_NODES.
* First Time: assign field-symbol.
  IF L_DYN_NODES-TYPE IS INITIAL.
    READ TABLE DYN_NODE_TYPES WITH KEY NODE = 'DYNNODE'
         INTO L_DYN_NODES.
    IF SY-SUBRC NE 0.
      ...
    ENDIF.
    CASE L_DYN_NODES-TYPE.
      WHEN 'SFLIGHT_DYN1'.
        ASSIGN SFLIGHT_DYN1 TO .
      WHEN 'SFLIGHT_DYN2'.
        ASSIGN SFLIGHT_DYN2 TO .
    ENDCASE.
  ENDIF.

  CASE L_DYN_NODES-TYPE.
    WHEN 'SFLIGHT_DYN1'.
      SELECT * FROM SFLIGHT_DYN1
          WHERE ...
        PUT .
      ENDSELECT.
    WHEN 'SFLIGHT_DYN2'.
      SELECT * FROM SFLIGHT_DYN2
          WHERE ...
        PUT .
      ENDSELECT.
  ENDCASE.


Related

GET, CHECK, REJECT

Additional help

Edit Database Program