This program RDDKOR54 maintains customer namespace reservations for tables and views in the table TRESC. When you change the namespace reservations of views, the changes are made simultaneously to all affected tables.
You can maintain customer namespaces by using the Customer namespace definition function when you maintain tables and views in the Dictionary, by maintaining table TRESC, or by executing the report RDDKOR54.
Maintaining Namespace Reservations
You can only reserve customer namespaces for tables and views to which the following applies:
- The delivery class of the table or view must be E or G.
- The table or view must be in a transportable package. Local, private and test development classes are not allowed.
You can flag a table or view as not needing a namespace reservation. After you set this flag, no reservations can be made. If you do not set this flag, namespace reservations can be made for one or more key fields.
A key field must meet the following conditions:
- The key field cannot have one of the data types CLNT (client), LANG (language), DATS (date) or TIMS (time).
- The key field must be in characters. This means that its internal data type must be C, N, D, or T, and it must be in the character prefix of the key.
- The key field cannot begin after the 120th character (offset) in the key.
The following restrictions apply to the namespace definition:
- A namespace definition has a maximum length of 30 characters.
- A namespace definition is always in uppercase.
- If the key field that you want to reserve has a check table, then you must reserve the same namespace for this table (if this table has the delivery class E or G). A warning appears if the table has a different delivery class.
Namespaces for views are reserved as follows:
- Reservations are made automatically for the tables in the view that contain the same key fields, as long as these reservations do not already exist. This does not include the tables in the view that only have read access. The reservations generated in this way are flagged as Generated.
- When reservations are deleted, a check is made to see whether the delete reservations have any generated reservations of this type. If so, they are also deleted.
Namespace Reservation Functions:
Namespace reservations split up the entries in a table (with delivery class E or G) between SAP and the customer, according to the key of the entries. The following logic is used to assign a table key:
- If a table is flagged as not needing a namespace reservation, no assignment is made. The key can be used by both SAP and the customer. A new assignment can be made in the corresponding maintenance transaction for the table with a separate logic.
- If no reservation matches a key field, then the key belongs to SAP.
- If at least one reservation matches a key field, then the key belongs to the customer.
The assignment of a table key to SAP or to the customer has consequences in two places:
- When you use a maintenance transaction to change a table entry (create, change or delete) in a table with delivery class E or G, a check is made to see whether the key belongs to SAP (in an SAP System) or to the customer (in a customer system). If not, a warning appears.
- No table entries are transported from the reserved customer namespaces during an upgrade. An upgrade does not delete, insert or change table entries that belong to the customer.
Notes
Customer namespaces can only be maintained in an SAP System. Reservations can only be displayed in a customer system.
The function module CHECK_CUSTOMER_NAMES checks whether a table entry can be changed in a system.
This function module is called by default in the view and view cluster maintenance transactions (SM30 and SM34). Each individual transaction is responsible for using this function module to check change access to table entries.
