Description
This program maintains customer namespace reservations for tables andviews in the table TRESC.
When you change the namespace reservations of views, the changes aremade simultaneously to all affected tables.
You can maintain customer namespaces by using the Customernamespace definition function when you maintain tables and views inthe Dictionary, by maintaining table TRESC, or by executing the reportRDDKOR54.

Maintaining Namespace Reservations
You can only reserve customer namespaces for tables and views to whichthe 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 setthis flag, namespace reservations can be made for one or more keyfields.
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 ofthe 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 thedelivery class E or G). A warning appears if the table has a differentdelivery 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 notalready exist. This does not include the tables in the view that onlyhave read access. The reservations generated in this way are flagged asGenerated.

• When reservations are deleted, a check is made to see whether the
delete reservations have any generated reservations of this type. Ifso, they are also deleted.

Namespace Reservation Functions:
Namespace reservations split up the entries in a table (with deliveryclass E or G) between SAP and the customer, according to the key of theentries. 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. Anew assignment can be made in the corresponding maintenance transactionfor 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 hasconsequences 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 ismade to see whether the key belongs to SAP (in an SAP System) or to thecustomer (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 tableentries 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 tableentry can be changed in a system.
This function module is called by default in the view and view clustermaintenance transactions (SM30 and SM34). Each individual transactionis responsible for using this function module to check change access totable entries.