ABAPOPEN_CURSOR - OPEN CURSOR

CL_GUI_FRONTEND_SERVICES - Frontend Services   General Material Data  
This documentation is copyright by SAP AG.

OPEN CURSOR

Short Reference

OPEN CURSOR $[WITH HOLD$] @dbcur$|@DATA(dbcur) FOR
  $[WITH
    +cte1 AS ( SELECT subquery_clauses )$[,
    +cte2 AS ( SELECT subquery_clauses )
    ...$]$]
  SELECT mainquery_clauses
  $[UNION$|INTERSECT$|EXCEPT ...$]
  $[UP TO ...$] $[OFFSET ...$]
  $[abap_options$].

Addition:

... WITH HOLD

Effect

The statement OPEN CURSOR opens a database cursor for the result set of the main query defined after FOR and links a cursor variable dbcur with this database cursor. The result set of the main query can be read with the statement FETCH.

The main query is specified after FOR as follows:

• The main query is specified using the language element SELECT, and its clauses and additions mainquery_clauses define the result set.

• The language element UNION, INTERSECT, or EXCEPT can be used to combine the result sets of multiple queries. In this case, special rules query_clauses apply when specifying clauses.

• Finally, the optional additions UP TO, OFFSET, and abap_options can be specified.

• Optional common table expressions can be defined in the main query using the language element WITH. When defining and using common table expressions, the same applies as when using WITH to introduce a standalone statement.

The following can be specified for the cursor:

• A host variable dbcur declared with the special predefined data type cursor. A database cursor dbcur that has already been opened cannot be opened again.

• An inline declaration of a corresponding host variable dbcur. Only the declaration operator DATA is possible and must be prefixed with the escape character @. The declaration operator FINAL is not possible here.

A row of the result set is always assigned to an opened database cursor as a cursor position. After the statement OPEN CURSOR, the database cursor is positioned in front of the first row of the result set.

In a program, a maximum of 17 database cursors can be open simultaneously across the interface. If an attempt is made to open more than 17 database cursors, the runtime error DBSQL_TOO_MANY_OPEN_CURSOR occurs. An open database cursor can be closed using the statement CLOSE CURSOR. In addition, any open database cursors are closed by database commits or database rollbacks if these occur after the first use of the cursor in a FETCH statement.

If a cursor variable dbcur of an open database cursor is assigned to another cursor variable or passed as a parameter, the latter is linked with the same database cursor at the same position. A cursor variable of an open database cursor can also be passed to externally called procedures to access the database cursor from there.

Notes

• It is not recommended that cursor variables are assigned to each other and they should be set only using the statements OPEN CURSOR and CLOSE CURSOR.

• If write accesses are made on a DDIC database table for which a database cursor is open, the result set is database-dependent and undefined. This kind of parallel access should therefore be avoided.

• As well as explicit reads using OPEN CURSOR and SELECT loops, the interface also opens database cursors implicitly, such as when loading buffered tables. The runtime error DBSQL_TOO_MANY_OPEN_CURSOR can be avoided by not using explicit reads to exploit the maximum number of open database cursors.

• If a CDS view is defined as a replacement object for a DDIC database table or DDIC database view specified as a data source of the SELECT statement of OPEN CURSOR, the statement FETCH accesses the CDS view and not the DDIC database table or the DDIC database view.

• Host variables without the escape character @ are obsolete. The escape character @ must be specified in the strict modes of the syntax check from Release . The use of an inline declaration for dbcur activates the strict mode with release and higher. If a statement OPEN CURSOR is checked in accordance with the rules for the strict mode from Release , each statement FETCH that accesses the database cursor is also checked in strict mode. Conversely, the strict syntax check mode from Release also applies the strict mode for the associated statement OPEN CURSOR in the statement FETCH. A violation of the rules specified by FETCH in OPEN CURSOR raises an exception of the class CX_SY_DYNAMIC_OSQL_SEMANTICS.
  
  

Example

Opens two cursors for the DDIC database table SPFLI. For more information on how to use this function, see the example for FETCH.

Addition

... WITH HOLD

Effect

If the addition WITH HOLD is specified, the database cursor is not closed in a database commit executed using Native SQL.

The addition WITH HOLD can be used only in reads performed on the standard database. It cannot be specified together with the addition CONNECTION.

Notes

• A Native SQL database commit closes the database cursor only after the cursor is used in a FETCH statement. A Native SQL database commit between the statement OPEN CURSOR and the first FETCH statement does not close the cursor.

• The addition WITH HOLD is ignored by the following:

• Implicit database commits

• Commits made by the statement COMMIT WORK

• Any rollbacks

These always close the database cursor.

• A Native SQL database commit can be made explicitly using the statement COMMIT CONNECTION.
  
  

Example

The addition WITH HOLD prevents the database cursor from being closed using an explicit database commit with the statement COMMIT CONNECTION and hence prevents an exception from being raised in the second FETCH statement. An exception is, however, raised after the statement COMMIT WORK.

ROGBILLS - Synchronize billing plans   CL_GUI_FRONTEND_SERVICES - Frontend Services  
This documentation is copyright by SAP AG.

Length: 11115 Date: 20230206 Time: 102635     sap01-206 ( 157 ms )