AMDP - Procedure Implementations
An AMDP procedure implementation is an AMDP method for implementing a database procedure. It is declared in an AMDP class like a regular static method or instance method in any visibility section. An AMDP procedure implementation cannot be identified as an AMDP method in the declaration part of the class.
An AMDP function implementation is indicated as an AMDP method in the implementation part of the class
using the addition BY DATABASE
FUNCTION of the statement
METHOD. At the same time, the database
system where the method is used and the programming language of the database system used to implement
the method are also defined. The database objects of the current database schema accessed in the AMDP
method must be declared using an addition
If possible, the syntax check is performed on the basis of this information. When database tables defined
in ABAP Dictionary are accessed (and the access is known statically), the AMDP framework makes sure
that the order of the fields defined in the dictionary is respected (this may be different from the order on the database).
The following restrictions apply, however, with respect to the parameter interface of an AMDP procedure implementation:
- The typing of the parameters cannot be generic. Only elementary data types and table types with a structured row type can be used. The row type of a tabular type can only contain elementary data types as components
- A parameter cannot have an enumerated type and cannot have a component with an enumerated type.
- A parameter cannot be typed with a data type that references one of the obsolete built-in data types DF16_SCL or DF34_SCL in ABAP Dictionary.
- Only input parameters can be flagged as optional parameters.
- Each elementary optional input parameter must have a replacement parameter declared using
DEFAULT. Only literals or constants can be specified as replacement parameters.
- Unlike in regular methods, a literal specified as a replacement parameter must be convertible to the data type of the input parameter. If not, a syntax error occurs.
- Input parameters of the types
decfloat34cannot have replacement parameters and hence cannot be optional.
- An optional tabular input parameter cannot have any replacement parameters and must be made optional instead using
- Parameter names:
- Parameter names cannot start with the characters "%_".
- The parameter name
connectioncan only be used for an input parameter of type DBCON_NAME, if the name of the database connection can be passed to the input parameter.
- The parameter name
clientis reserved for future enhancements.
- The parameter name
endmethodis not permitted.
RAISINGcan be used to specify the the exceptions specified under AMDP -Exception Classes to handle these classes for a call. Other exceptions cannot be handled. No non-class-based exceptions can be created using the addition
The following restrictions apply to method implementation:
- An AMDP method must not be empty.
- DDL statements are not permitted for creating, changing or deleting database objects.
- No statements are allowed that are only possible in database tables and not in views, such as TRUNCATE TABLE or LOCK TABLE.
- Local temporary database objects cannot be accessed.
- Executing transactional statements is not permitted. In particular, no database commits and database rollbacks using COMMIT and ROLLBACK statements are allowed. This also applies to called procedures. LUWs should always be handled in the ABAP program, to ensure data consistency between procedures.
- Writes cannot be performed on database tables where table buffering is switched on, since SQLScript accesses are ignored by buffer synchronizations.
- AMDP methods do not have any implicit enhancement options.
Further restrictions may apply depending on the programming language of the database system and these are discussed in the corresponding sections:
- L for the SAP HANA Database (used internally at SAP only)
7.31 | 7.40 | 7.54
- It is strongly recommended that only the character set 7-bit-ASCII is used when implementing an AMDP method.
- The use of dynamic programming techniques is strongly discouraged, even if supposedly permitted by the programming language of the database system.
- The existence of other database objects cannot be checked or guaranteed when they are accessed dynamically. This is particularly relevant when other AMDP methods are called.
- When database tables in ABAP Dictionary are accessed dynamically, the AMDP framework cannot respect the order of the fields defined here and the order of fields on the database (which might be different) is used instead. This can produce the wrong values when making assignments to ABAP data objects declared with respect to ABAP Dictionary.
- In dynamic accesses, it is not possible to prevent writes from being performed on database tables with activated table buffering and this can cause inconsistencies in buffer synchronizations.
- Dynamic accesses can be the cause of SQL injections related to input from outside.
- When passed to an actual parameter, a null value is passed to its type-dependent initial value.