ABAP Keyword Documentation → ABAP - Reference → Creating Objects → CREATE DATA
CREATE DATA - AREA HANDLE
Other versions: 7.31 | 7.40 | 7.54
Syntax
CREATE DATA dref AREA HANDLE handle ... .
Effect
This statement creates an anonymous data object as a
shared object in the
area instance version of the
shared memory, which is bound to the
area handle referenced by handle.
handle expects an object reference variable whose static type is CL_ABAP_MEMORY_AREA or one of its subclasses
(area class). When the statement is executed, handle must refer to an
area handle and the area
handle must be associated to an area instance version with a change lock. To create such a reference, you can do either of the following:
- Inherit the return value of the methods ATTACH_FOR_WRITE or ATTACH_FOR_UPDATE of an area class created using transaction SHMA.
- Inherit the return value of the GET_HANDLE_BY_OREF method of any area class.
-
Inheritthe return value of the method GET_IMODE_HANDLE of the predefined class CL_IMODE_AREA.
The latter is a reference to an area handle for the current
internal mode and
the statement CREATE DATA acts like without the addition AREA HANDLE.
Restrictions
The creation of anonymous data objects as shared objects is subject to the following restrictions for data references in the shared objects memory: The storage of data references in closed area instance versions of the shared objects memory is restricted to such dynamic types that are known when loading a program into an internal mode.
Therefore, the following data types cannot be used to create anonymous data objects in the shared object memory, if these are to be preserved in a closed area instance version:
GENERATE SUBROUTINE POOL.
CREATE DATA.
CREATE DATA.
Points 3 and 4 include the statement CREATE DATA with the addition AREA HANDLE itself. Exceptions to the restrictions listed under points 2 to 4 are:
-
The restrictions are not valid for data type
p. -
The restrictions are not valid for data types
c,n, andxas long as the storage requirements do not exceed 100 bytes.
If a data reference variable that is stored in the shared objects memory refers to an anonymous data object of a dynamic type that is subject to the restrictions, the exception of the class CX_SHM_EXTERNAL_TYPE is raised when the DETACH_COMMIT method is executed.
The following can be used without restriction:
- All visible data types of global interfaces and classes.
- Data elements, structures, and database tables and table types from ABAP Dictionary.
- Data types from type groups.
-
Bound data types of anonymous data objects created at program runtime to which a static type with a static length was assigned when they were created with
CREATE DATA. -
Bound data types of anonymous data objects created at program runtime to which a fully specified dynamic type was assigned when they were created with
CREATE DATA. -
All data types that were created statically in the same program with declarative statements. However, you should note that you can no longer access existing area instances once you changed the creating program.
The additions REF TO
and TABLE OF can be used
until the specified types fulfill above requirements. This also applies for the addition
HANDLE, that means the type object must have been created with methods of the RTTI from allowed types.
Notes
- The only shared object that can be addressed directly from an ABAP program after a connection to an area instance version is the instance of the area root class. All other objects have to be referenced in this instance. In particular, there is no direct access to anonymous data objects possible. Instead, the instance of the area root class must contain references to these anonymous data objects, which can also be indirect.
-
We recommend that you only use global data types with
AREA HANDLE. As an occasional replacement for the direct reference to data elements and table types from ABAP Dictionary, you can create the respective types in global interfaces, classes, or even type groups.
Example