Overtake and Regression Checks (0031)

The Overtake and Regression checks are used to ensure that transports and changes are approved and imported in the correct sequence.

• Overtake: This is where newer changes, for example an emergency bug fix, are being moved before existing in-progress changes to the same objects. In this case there is a risk of deploying a partial change with the big fix that is incomplete and not yet ready.
  A check is made to see if the transport(s) contains a newer version of any objects that also appear on older transports that have not yet been imported into the target system?
  If so, when the older request is imported in future you risk overwriting the target system objects with old out of date versions.

• Regression: This is where older changes overwrite newer ones that have been deployed out of order. Here there is the risk of losing the latest changes and unexpectedly regressing the system to a previous version
  A check is made to see if the transport(s) contains an older version of any objects that have been previously imported into the target system?
  If so you risk overwriting the target system objects with old out of date versions.

In both cases all objects are checked across SAP transports including, but not limited to, development and configuration objects.

In the case of configuration changes checks are done for:

• Table configuration entries (TABU). Includes the identification of overlapping table key entries so that, for example, a conflict would only be identified if the actual table key contents overlap (including wildcards)
• View Cluster Maintenance: Data (CDAT). Includes the expansion of the associated tables for conflict checking
• Customizing: Table Contents (TDAT). Includes the expansion of the associated tables for conflict checking
• View Maintenance: Data (VDAT). Includes the expansion of the associated tables for conflict checking
  

Parameters:

KEY_NO_RELATED_VIEWS: By default, when transporting table entries, views that use the same table in key fields will be considered a conflict. This behaviour can be turned off with this flag.

KEY_NO_WILDCARDS: If this flag is set, wildcards are not considered when searching for conflicting table entries.

NO_CACHE: Turn off conflict cache (always recalculate the conflicts from the actual object lists).

SHOW_CONFLICTING_OBJ_KEYS: Show the actual table entries that are in conflict. (This is not purely display but can have performance implications since when you don’t show the keys, you can stop at the first conflict, but otherwise it needs to go on.)