Identifier les tables à exclure des migrations

Certains objets de maintenance admissibles pour une migration peuvent contenir des tables enfants qui ne doivent pas être incluses dans la migration. Par exemple, si un objet contient des tables de journalisation, les entrées du journal doivent refléter les actions effectuées sur l'objet dans ce système et seront différentes entre le système source et le système cible. Si vous détenez un objet de maintenance personnalisé qui contient des tables que vous ne souhaitez pas faire migrer (telles qu'une table de journalisation), désignez cette table à l'aide de l'option Table non migrée de l'objet de maintenance. Tous les enregistrements enfants de cette table seront également ignorés au cours de la migration.

Un autre cas d'utilisation à envisager est celui d'une table "de n à n" enfant qui connecte deux objets administratifs et existe dans l'objet de maintenance des deux tables. La table enfant peut se trouver dans les deux objets de maintenance pour plus de commodité, mais il se peut que l'un des objets de maintenance soit plus considéré comme un objet "pilote" et l'autre plus comme un subordonné. Si vous effectuez une migration, pour laquelle vous souhaitez copier un sous-ensemble d'objets, vous pouvez uniquement copier l'objet pilote et ses enfants, ainsi que leurs données, mais pas les enfants de ceux-ci. Par exemple, un type de tâche inclut un ensemble de rôles de tâche valides et, à son tour, le rôle de tâche fait référence à ses types de tâche. Si une implémentation souhaite copier une seule tâche et inclure toutes ses informations connexes, y compris ses rôles de tâche, elle ne souhaite pas que la migration de chaque rôle de tâche copie à son tour tous ses types de tâche (et leurs données).