Se rendre au contenu

ORA-02291 « parent key not found » en migration IFS : la référence d'entité oubliée sur vos custom tabs

15 juin 2026 par
ORA-02291 « parent key not found » en migration IFS : la référence d'entité oubliée sur vos custom tabs
Correction rapide : ORA-02291 … parent key not found en migrant un custom tab signifie qu'un de vos champs porte une référence d'entité (Entity Reference) : IFS n'attend pas la valeur brute, mais l'objkey de l'enregistrement référencé. Vérifiez le champ sur la page Entity Configuration, puis, dans le Source Mapping, récupérez l'objkey de l'entité référencée à partir de vos valeurs au lieu de passer la valeur telle quelle.

ORA-02291 parent key not found en migration IFS : la référence d'entité à résoudre en objkey — ERP Control

Vous migrez des données vers un custom tab IFS (ex. une table d'interchangeabilité d'articles). Le job échoue avec :

ORA-02291 : integrity constraint (IFSAPP.C_PART_INTERCHANGE1_CRK) violated - parent key not found

Vos valeurs sont pourtant correctes : l'article existe, les codes sont bons. Le blocage est ailleurs.

La cause

Contrairement aux ORA-20xxx (erreurs applicatives IFS), ORA-02291 est une contrainte Oracle brute : une clé étrangère pointe vers un parent introuvable. Sur les custom tabs, le suffixe _CRK de la contrainte trahit une Custom Reference Key — c'est-à-dire un champ custom configuré avec une référence d'entité.

Le mécanisme : quand un attribut custom référence une entité (ex. part_noPartCatalog), IFS ne stocke pas votre valeur métier, mais l'objkey de l'enregistrement référencé. Si le job passe la valeur brute (PART-001), Oracle cherche un parent avec cette valeur comme clé → introuvable → ORA-02291. Passer l'objkey récupéré « à la main » depuis le parent ne suffit pas non plus si le mapping n'utilise pas le format de résolution attendu.

Cas réel de la communauté IFS (migration vers un custom tab d'interchangeabilité) : « cette erreur survient quand des attributs ont des références d'entité. Vérifiez sur la page Entity Configuration ; si un champ migré porte une référence d'entité, il faut récupérer l'objkey en passant les valeurs dans le format prévu. » Résolu et confirmé par l'auteur.

Comment corriger

  • Ouvrez la page Entity Configuration de votre entité custom.
  • Pour chaque champ migré, vérifiez s'il porte une Entity Reference (ex. part_nopart_catalog).
  • Pour ces champs, ne mappez pas la valeur brute : construisez le mapping pour résoudre l'objkey de l'enregistrement référencé à partir de vos valeurs (fonction de résolution dans le Source Mapping).
  • Relancez : la contrainte _CRK trouve son parent, l'insert passe.

Comment l'éviter

  • Avant de migrer un custom tab, listez les références d'entité dans Entity Configuration : chaque référence = un champ à résoudre en objkey, pas une valeur à copier.
  • Si vous créez vous-même des custom fields destinés à être migrés, documentez leurs références — celui qui fera la reprise vous remerciera.
  • Testez sur une ligne : ORA-02291 se manifeste dès le premier insert.

Erreurs de migration IFS liées

Le même type de blocage se joue sur d'autres codes — tous décortiqués dans notre guide pilier Migration de données IFS Cloud:

  • ORA-01400 « cannot insert NULL into ROWKEY » — l'autre piège des custom fields : le paramètre OBJID_ mal référencé.
  • ORA-20111 / FND_RECORD_NOT_EXIST — un prérequis contextuel manquant (parents avant enfants).
  • ORA-20112 FND_RECORD_EXIST — le job tente d'INSÉRER une ligne qui existe déjà.
  • SE_UNAUTHORIZED — la projection du job non accordée à l'exécutant : un problème de permissions de migration .

Migrer les custom tabs sans résoudre les objkeys à la main

ORA-02291 sur un custom tab, c'est la mécanique interne des personnalisations IFS qui remonte à la surface : objkeys, références d'entité, contraintes _CRK. Le module CRIM d'ERP Control migre les personnalisations (custom fields, custom tabs) et leurs données entre environnements en résolvant ces références automatiquement, en no-code — sur vos environnements CFG · UAT · TRN · PROD.

Découvrez comment ERP Control migre vos personnalisations IFS — voir le module CRIMFait partie de notre guide pilier :

Migration de données IFS Cloud — le guide complet 2026 Migration de données IFS Cloud — le guide complet 2026Fait partie de notre guide pilier :

FAQ

Pourquoi une erreur Oracle brute et pas un message IFS ?

Parce que la validation échoue au niveau de la contrainte de base de données (clé étrangère _CRK), avant toute logique applicative IFS. C'est le signe distinctif des références d'entité non résolues.

Comment savoir quels champs portent une référence d'entité ?

Page Entity Configuration de l'entité custom : chaque attribut y affiche sa référence éventuelle (ex. part_nopart_catalog).

J'ai récupéré l'objkey du parent et je le passe directement — ça échoue encore. Pourquoi ?

Le mapping doit utiliser le format de résolution prévu (récupération de l'objkey à partir des valeurs métier dans le Source Mapping), pas une valeur collée en dur : l'objkey diffère d'un environnement à l'autre.

Sources

Cas réel issu de la communauté IFS (solution validée sur le thread) :

ORA-20124 : NULLVALUE « field is mandatory » en migration IFS — quand le champ obligatoire n'est même pas vide