Table sharing upgrade logic - preventing data corruption

The table sharing upgrade logic is designed to ensure that transitions between shared and unshared tables in the Table Sharing Modeler (TSM) are safe, reliable, and free from data corruption. This logic addresses the risks that arise when tables are unshared after being shared with another company, particularly when data definitions have changed during the sharing period. Without proper handling, reverting to an outdated physical table can result in data definition (DD) mismatches and errors, such as error 512.

By automating the removal and recreation of physical tables during maintenance and enforcing user validation steps, data corruption is prevented and only valid, up-to-date tables can be used after unsharing.

Upgrade logic

Immediate removal of former physical tables: When a table sharing configuration is updated and certain tables are no longer used (i.e. shared), the former physical tables are immediately removed from the database. This prevents outdated tables from being reused, which could otherwise lead to corruption if their structure no longer matches the current data definition.
Automatic creation of new tables during the maintenance window: During the scheduled tenant maintenance window, new physical tables are automatically created for the new package combination. If a table already exists, it is removed and recreated to ensure its structure aligns with the latest data definition. This process also applies to tables that are unshared, ensuring consistency and preventing error 512.

Note: Table creation and recreation happen only during the maintenance window. If table sharing is updated by making a Table Sharing Set actual outside of this window, table creation is not performed at that time. Therefore, safeguards against corruption are tied to the scheduled maintenance process, not to ad-hoc updates.

By removing unused former tables and recreating new ones during maintenance, only up-to-date tables are available. This approach eliminates the risk of corruption that can occur if outdated tables are reused after unsharing.

User actions and validation steps

Removing physical tables that still contain data can lead to unintended data loss. To protect important information, safeguards and warning mechanisms are in place that alert users and require confirmation before any data is deleted. These measures ensure that users are fully informed and can take appropriate action to preserve any necessary data before the maintenance window starts.

These sessions are used to validate data:

Verify Shared Logical Tables (tltsm1201m000): When running this session on a table sharing set, a check is performed to determine whether any tables scheduled for removal still contain data. Exceptions are logged, and users must either accept these exceptions (acknowledging potential data loss) or clear the tables if the data does not need to be retained.
Make Table Sharing Set Actual (tltsm0210m000) or Update OCM and TSM single step (ttocm0202m000): Any tables scheduled for removal that still contain data are listed in a report for review. The table sharing update only proceeds after user confirmation. This process also applies when registering a next table sharing set as to be made actual for a new package combination.; Note: When a next table sharing set is made actual for a new package combination, checks are performed at that time for tables that will become logical.
Preliminary Update Check (ttmtm4554m000): All tables that will be removed and contain data are included in the report of this check. Users must take action to safeguard any necessary data, as it will be lost after the tenant upgrade.
Logical Tables (ttaad4120m000): If a relation is added to this session, the former physical table is removed if it does not exist or is empty. If the table contains data, adding the relation is blocked to prevent accidental data loss. If a module must be shared but certain tables should remain unshared, add those tables first by assigning the same physical company number to the corresponding logical company.