Conflict Analysis check (0005) 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. 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.
|If set, the analyser will only consider targets in the analysis that have the “remote import analysis” flag set.
|if set, the analyser will ignore any conflicts before last merge. Ie exclude any Transport that has already been merged.
|if set, the analyser will ignore any conflicts with Transport of Copies. This includes both Merge TOCs and also Dev>QA testing TOCs; basically any TR where the function = ‘T’
|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.
|If set, the analyser will show the actual table entries 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.
|If set, the analyser will also indicate in the results whether the conflicting transport is released or not.
|If set, the analyser uses cached results, otherwise it is always recalculated.
|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.