[ Oracle 10g ] Problème sur les identifiants lors de l'import d'un DUMP

Bonjour,

Je travaille sur Oracle 10g (niveau débutant...)

Je vous expose mon problème:

_ J'ai une application 1 qui me crée automatiquement un utilisateur/schéma (j'ai du mal à voir la différence), avec toutes les tables associées
_ J'ai une application 2 qui est une interface utilisateur pour rentrer des données dans les tables créées par l'application 1.

Nous venons de recevoir une nouvelle version des applications 1 et 2: on pourrait tout recommencer à zéro , ce serait le plus simple, mais les utilisateurs chez moi ont commencé à rentrer plein de données (alors qu'on est en phase de test, grrrr) et ne veulent pas recommencer toute leur saisie.

j'ai fait comme ça:

1/ Export de la base existante
Avec la commande exp file=C:\sauvegarde.dump full=y

2/ Je crée un nouveau schéma dans ma base Oracle
Création d’un nouvel utilisateur/schéma dans Oracle avec mon application 1

3/ Import de la base dans le nouveau schéma vide
Avec la commande imp file=C:\sauvegarde.dump fromuser=<old_schema> touser=<new_schema> ignore=y
Ca me permet de prendre uniquement ce qui m'intéresse dans mon fichier dump pour remplir le nouveau schéma vide, et le "ignore=y" est indispensable pour ne pas avoir un arrêt à cause du fait que les tables existent déjà


Ca marche bien en apparence (toutes les données sont copiées d’un schéma à l’autre) mais le problème est que l'import ne respecte pas les valeurs pour les colonnes correspondant aux identifiants (clés primaires) : lors de l’import, oracle reprend à 1 une numération incrémentale pour chaque ID, ce qui fait que les relations entre tables sont parfois rompues, et donc c’est le foutoir ensuite dans les données!!

Exemple: j'avais un table nommée "IMPROVEMENTS", avec 4 objets saisies dedans, qui portent le ID_IMPROVEMENTS (clé primaire): 1, 2, 4 et 6
(ces chiffres ne se suivent pas certainement parce que j'ai du supprimer les objets portant les ID 3 et 5...)
Et bien, après import, j'ai bien 4 lignes dans la table IMPROVEMENTS de mon nouveau schéma, mais les identifiants sont 1, 2, 3 et 4!! Un grand nombre de fonctions de mon application 2 est basée sur des liens entre les tables, avec utilisation de ID_IMPROVEMENTS comme clé étrangère, il n'y a donc plus rien qui marche...

Comment faire pour que l'import du Dump me génère des valeurs identiques pour TOUS les éléments de toutes mes tables, même pour ceux qui sont clés primaires?

Merci pour vos conseils
(j'espère avoir été clair...)

Utilise la commande EXPDP pour faire l'export et IMPDP pour faire l'import

Pour l'export

Code:

---

expdp user/password dumpfile=nomDeFichier.dmp full=Y

---

Pour l'import

Code:

---

impdp user/password dumpfile=nomDeFichier.dmp

---

A+

Merci d'essayer de m'aider: il y al'air d'y avoir plus d'options avec expdp/impdp qu'avec exp/imp

Toutefois ces lignes de commande seules ne suffisent pas à m'aider :( ... j'ai essayé le "impdp" avec les options suivantes:
REMAP_SCHEMA=<old_schema>:<new_schema>
TABLE_EXISTS_ACTION=APPEND

mais j'obtiens exactement le même résultat qu'avec les lignes de commande de mon message intial.

Peut-être en essayant le mot-clé EXCLUDE?
Quelqu'un a une idée??

Ça ressemble à une mauvaise conception du modèle de données qui n'assure pas l'intégrité des données.
Utilisez des foreign key ou clefs étrangères entre les tables parents / enfants pour conserver le lien entre ces données.
Est-ce que vous utilisez des déclencheurs avec séquences pour les clefs primaires?

Bonjour,
Si après import les ID ont changé, c'est probablement que l'appli a des triggers sur les inserts qui écrasent la valeur de l'ID en prenant celui de la sequence.
Il faudrait soit:
- désactiver les triggers avant l'import
- modifier les triggers pour qu'ils ne mettent une nouvelle valeur dans l'ID que si celle qui est passée par l'insert est NULL
Puis réactiver les triggers, et modifier les sequences pour qu'elle partent à partir du dernier numéro existant.
Cordialement,
Franck.

Merci pour vos réponses

Je viens de vérifier: il y a effectivement sur chaque table un trigger "before each row" déclenché par l'évènement "insert", donc vous devez avoir vu juste sur l'origine du problème.
Par contre, mon nouveau problème c'est qu'il y a au moins une centaine de tables, est-ce qu'il existe une commande pour désactiver puis réactiver tous les triggers d'un coup?

Merci encore pour votre aide

PS:Concernant le fait qu'il y ait eu une mauvaise conception du modèle, et des applis de manière générale, je suis tout à fait prêt à le croire: depuis le début nous sommes très mécontents des livraisons du prestataire qui nous fournit les applications en question...

Citation:

---

Envoyé par jc_13008

Par contre, mon nouveau problème c'est qu'il y a au moins une centaine de tables, est-ce qu'il existe une commande pour désactiver puis réactiver tous les triggers d'un coup?

---

http://oracle.developpez.com/sources...ers_hors_ligne