DevMax: Conflict Analysis check analyses a transport request against the target system and checks for conflicts before importing changes into that system. This is mainly used in the merge processing to identify objects changes in the merge target system that are also contained on the transport request being analysed.
This should be switched on and made mandatory for all merge target systems in Transport Expresso.
If any conflicts are found the details of the source system and merge target system transports are displayed along with the list of conflicting objects.
Parameters:
CHECK_CONF_FLAG : If set, the analyser will only consider targets in the analysis that have the “remote import analysis” flag set.
GLOBALMERGECHECK: By default, only transports that originate in the target system are checked for conflicts. If this flag is switched on, then all transports in the target are checked, regardless of their original system. There is a potential performance downside to having this functionality active.
SHOW_CONFLICTING_OBJ_KEYS: If set, the Analysis Check will show the actual table entires that are in conflict. This is purely display but can still 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.
USE_CACHE: If set, the analyser uses cached results, otherwise it is always recalculated.
USE_CURRENT: By default, if the transport is past the import queue, the conflict analysis will be done in the successor target. If this is set, we can force it to run it on the current one even in this case.
Post your comment on this topic.