How Do You Make A Table Non Transportable In SAP?

In SAP, you make a table non-transportable by configuring the Table Maintenance Generator in transaction SE11. This involves changing the Recording Routine for the table's maintenance view to prevent automatic transport requests from being generated when data is maintained via the standard table maintenance transaction (SM30).

This method applies primarily to custom "Z" or "Y" tables with delivery class 'C' (Customizing). For tables with other delivery classes, such as 'A' (Application), this setting only affects standard maintenance, not manual transport. A more robust solution for making application tables non-transportable is to control the process through the table's delivery class and system-wide client settings.

Method 1: Changing the table maintenance recording routine

This is the most common and direct method for tables where data is maintained manually, such as through a generated maintenance view.

Step 1: Navigate to the Table Maintenance Generator

1. Go to transaction SE11 (ABAP Dictionary).
2. Enter your custom table name (e.g., Z_MY_CUSTOM_TABLE) and click "Display".
3. From the menu bar, choose Utilities > Table Maintenance Generator.

Step 2: Configure the recording routine

1. On the Table Maintenance Generator screen, locate the "Dialog Data Transport Details" box.
2. Under the "Recording Routine" section, select the radio button for "no, or user, recording routine".
3. Click the "Save" button to apply the changes. The system will prompt you for a transport request to save the change to the table's maintenance settings, not the table data itself. This single transport is required to move the setting to subsequent systems.
4. After saving, re-generate the table maintenance dialog if necessary by clicking the "Change" button and saving again.

Step 3: Verify the change

1. Go to transaction SM30 (Maintain Table Views).
2. Enter your table name and press "Maintain."
3. When you add or change entries in the table, the system should no longer prompt you for a transport request. The changes will be stored locally in the current client.

Method 2: Adjusting the table's delivery class

A table's delivery class is a fundamental property that dictates its transport behavior. This method is more powerful but requires careful consideration, as it changes the table's core definition.

Understanding delivery classes

• 'C' (Customizing table): The default for custom configuration. Table contents are transportable by default via table maintenance dialogs and are client-dependent.
• 'A' (Application table): Used for master and transactional data. Table data is not typically transported via standard table maintenance, as it's meant to be managed directly in each client.
• 'L' (Table for temporary data): Table data is never transported during client copies or system upgrades. This is a good option for tables storing local, non-critical data.

Step 1: Change the delivery class in SE11

1. Go to transaction SE11 and enter the table name.
2. Go to the "Delivery and Maintenance" tab.
3. Change the Delivery Class to a non-transportable option like 'A' or 'L'.
4. Activate the table.

Step 2: Adjust table maintenance settings

Depending on the new delivery class, you may still need to adjust the Table Maintenance Generator as described in Method 1 to ensure data changes are not recorded.

Method 3: Restricting transports via client settings (for Basis)

This is a more aggressive, system-wide approach typically used for production clients. It should be performed by the system administrators (Basis team).

Step 1: Use client maintenance settings (SCC4)

1. Go to transaction SCC4 (Client Maintenance).
2. Select the client you want to configure and click the "Change" button.
3. Find the "Changes and Transports for Client-Specific Objects" setting.
4. Set the value to "No change allowed" or "Changes allowed, but without automatic recording".
5. Save your changes.

Explanation: This will prevent any customizing changes from being recorded in a transport for this specific client, making all client-dependent customizing tables non-transportable by default.

Key considerations and warnings

• Impact on standard transport behavior: While these methods make a table non-transportable via standard maintenance tools like SM30, objects and their contents can still be manually added to a transport request using expert tools like SE01/SE03. Ensure that developers and administrators are aware of the table's intended non-transportable status.
• Delivery Class Implications: Changing the delivery class to 'A' (Application) on a table previously used for customizing ('C') can have unintended consequences. The system's behavior during client copies and upgrades is fundamentally altered. Always understand the full implications of a delivery class change.
• Local vs. Global Changes: The recording routine setting in the Table Maintenance Generator is a transportable change itself. This means that to set up a table as non-transportable in your Development system, you first need to capture that setting in a transport request and move it through your landscape. From that point on, data changes in the table will be local.
• Reversibility: All these methods are reversible. To make the table transportable again, you would simply reverse the steps—change the recording routine back to "Standard recording routine," or change the delivery class back to 'C'.
• Thorough Testing: After making a table non-transportable, always test the maintenance behavior in all relevant systems (Development, Quality Assurance, and Production) to ensure the changes behave as expected and no transport requests are generated for data changes.