An AMDP procedure implementation is indicated as an AMDP method in the implementation part of the class
using the addition BY DATABASE
PROCEDURE 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 USING.
If possible, the syntax check is performed on the basis of this information. When database tables defined
in ABAP Dictionary are accessed 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 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 and every optional parameter must have a replacement parameter declared using
DEFAULT. Only literals or constants can be specified as replacement parameters.
Parameter names cannot start with the characters "%_".
The parameter name connection can 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 client is reserved for future enhancements.
The parameter name endmethod is not permitted.
RAISING can 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 EXCEPTIONS.
The following restrictions apply to method implementation:
An AMDP method cannot be empty.
DDL statements are not permitted for creating, changing or deleting database objects.
Local temporary database objects cannot be accessed.
Executing transactional statements is not permitted. In particular, no
database commits and
rollbacks with 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.
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.