Comment générer DELETE en PL/SQL, sur la base des tableaux FK relations?

Est-il possible via un script ou un outil pour générer des authomatically de nombreux delete sur la base des tableaux fk relations, à l'aide de Oracle PL/SQL?

Dans l'exemple: j'ai la table: POULET (CHICKEN_CODE NOMBRE) et il y a 30 tables avec fk références à son CHICKEN_CODE que j'ai besoin de supprimer; il y a aussi d'autres 150 tables de clé étrangère liée à celle de 30 tables que j'ai besoin de supprimer en premier.

Est-il un outil ou un script PL/SQL que je peux courir dans le but de générer tout le nécessaire de les supprimer consolidés sur la base de la FK relations pour moi?

(en passant, je sais à propos de supprimer en cascade sur les relations, mais attention: je ne PEUX PAS l'UTILISER DANS MA BASE de données de PRODUCTION, parce que c'est dangereux!)

Je suis en utilisant la Base de données Oracle 10G R2.

S'il vous plaît prêter attention à ceci:

Générer de l'Instruction Delete à Partir des Relations de Clé Étrangère SQL 2008?

Un autre utilisateur a juste écrit-il dans SQL SERVER 2008, toute personne est en mesure de convertir vers Oracle 10G, PL/SQL?
Je ne suis pas capable de... 🙁

Veuillez supposer que V_CHICKEN et V_NATION sont les critères pour sélectionner le POULET à supprimer à partir de la racine de la table: la condition est: "où COD_CHICKEN = V_CHICKEN ET COD_NATION = V_NATION" à la racine de la table.

  • Ce que vous proposez est un manuel de mise en œuvre de la CASACDE SUPPRIMER. Je ne vois pas comment cela pourrait être moins dangereux. De toute façon, la question essentielle est celle-ci: vous allez zap tous les enregistrements de POULET, ou seulement certains (un)?
  • Dans ma situation, j'ai besoin de ZAPPER un seul enregistrement de la poule de la table... Mais a partir de cette simple enregistrement par le biais de l'intégrité référentielle, nous descendons à de nombreuses personnes et de nombreux tableaux en fonction de ça... je peux compter une env profondeur de niveau 7 (!!).
  • J'ai mis à jour ma réponse avec un script pour vous d'essayer. Aucune garantie que...
  • Je suis en train d'essayer le script. Peut-être qu'il ne gère pas la propagation de la intégrités référentielles à d'autres utilisateurs, comment puis-je résoudre ce problème? Dans l'intervalle, le script vient de générer plus de 3129 SUPPRIMER l'INSTRUCTION que j'étais attendue à écrire à la main! 🙂
  • Merci de m'aider à comprendre pourquoi la procédure stockée est cyclying toujours sur le même 39 delete.....
  • Vous savez quoi, je ne pense pas que c'est pas aussi dur que je le pensais. Je pourrais être en mesure de le corriger si j'ai du temps aujourd'hui.
  • J'ai mis à jour ma réponse avec un nouveau script. Cela fonctionne pour moi mais je suspecte qu'il pourrait y avoir des problèmes si vous avez des relations complexes. Essayez-le et laissez-moi savoir comment ça se passe. 🙂
  • Pourquoi êtes-vous à la programmation en "mode découverte"? C'est comme "je n'ai aucune idée de quel type de base de données, c'est, ni comment les tables sont disposées et connecté, je sais juste que j'ai besoin de supprimer une ligne dans l'un d'eux". Vous n'avez pas une bonne couche d'accès aux données de cette base de données?
  • ... OP sez: "effacer en cascade sur les relations ...je ne PEUX PAS l'UTILISER DANS MA BASE de données de PRODUCTION, parce que c'est dangereux!". Et vous pensez que l'obtention d'un script à partir de l'internet (OK, DONC) et en cours d'exécution sur votre base de données de production est moins dangereux? En fin de compte, vous allez comprendre quelque soit la solution que vous accepter dans le détail parce que c'est ta peau en jeu.
  • Je vous demande de vous rendre clair, je ne comprends pas votre dernière phrase.
  • "Je vais comprendre quelque soit la solution que j'accepte dans le détail parce que c'est ma cacher en jeu"???? ÇA VEUT DIRE QUOI? Je comprends les mots, mais pas le sens de la phrase complète.
  • Il signifie que lorsque votre bout est sur la ligne (de votre travail est à risque), vous allez ASSUREZ-vous que le code que vous utilisez est sûr, indépendamment de l'endroit où vous l'avez obtenu.
  • Merci pour la traduction, Charles 🙂 je n'ai jamais vu/entendu l'expression "ton cul est sur la ligne" 🙂 Mais maintenant, c'est clair. J'ai essayé de nombreuses fois de votre procédure et il fonctionne très bien, bien sûr, je ne décolle pas de la supprimer sans avoir au préalable soigneusement les lire!!! 😉 Je utiliser pour stocker la suppression dans une table temporaire, puis les enregistrer dans un fichier, et puis j'ai lu attentivement eux à l'aide d'UltraEdit ou le CRAPAUD de l'Éditeur SQL.

InformationsquelleAutor UltraCommit | 2010-04-20
  1. 21

    (Ma première réponse est devenu trop long et difficile à modifier, et il a obtenu de la Communauté Wikified, ce qui est vraiment gênant. Voici la dernière version du script.)

    Ce script tente d'effectuer une suppression en cascade à travers la récursivité. Il devrait éviter les boucles infinies quand il y a des références circulaires. Mais il exige que toutes les circulaires des contraintes référentielles ont ON DELETE SET NULL ou ON DELETE CASCADE.

    CREATE OR REPLACE PROCEDURE delete_cascade(
table_owner          VARCHAR2,
parent_table         VARCHAR2,
where_clause         VARCHAR2
) IS
/*   Example call:  execute delete_cascade('MY_SCHEMA', 'MY_MASTER', 'where ID=1'); */
child_cons     VARCHAR2(30);
parent_cons    VARCHAR2(30);
child_table    VARCHAR2(30);
child_cols     VARCHAR(500);
parent_cols    VARCHAR(500);
delete_command VARCHAR(10000);
new_where_clause VARCHAR2(10000);
/* gets the foreign key constraints on other tables which depend on columns in parent_table */
CURSOR cons_cursor IS
SELECT owner, constraint_name, r_constraint_name, table_name, delete_rule
FROM all_constraints
WHERE constraint_type = 'R'
AND delete_rule = 'NO ACTION'
AND r_constraint_name IN (SELECT constraint_name
FROM all_constraints
WHERE constraint_type IN ('P', 'U')
AND table_name = parent_table
AND owner = table_owner)
AND NOT table_name = parent_table; -- ignore self-referencing constraints
/* for the current constraint, gets the child columns and corresponding parent columns */
CURSOR columns_cursor IS
SELECT cc1.column_name AS child_col, cc2.column_name AS parent_col
FROM all_cons_columns cc1, all_cons_columns cc2
WHERE cc1.constraint_name = child_cons
AND cc1.table_name = child_table
AND cc2.constraint_name = parent_cons
AND cc1.position = cc2.position
ORDER BY cc1.position;
BEGIN
/* loops through all the constraints which refer back to parent_table */
FOR cons IN cons_cursor LOOP
child_cons   := cons.constraint_name;
parent_cons  := cons.r_constraint_name;
child_table  := cons.table_name;
child_cols   := '';
parent_cols  := '';
/* loops through the child/parent column pairs, building the column lists of the DELETE statement */
FOR cols IN columns_cursor LOOP
IF child_cols IS NULL THEN
child_cols  := cols.child_col;
ELSE
child_cols  := child_cols || ', ' || cols.child_col;
END IF;
IF parent_cols IS NULL THEN
parent_cols  := cols.parent_col;
ELSE
parent_cols  := parent_cols || ', ' || cols.parent_col;
END IF;
END LOOP;
/* construct the WHERE clause of the delete statement, including a subquery to get the related parent rows */
new_where_clause  :=
'where (' || child_cols || ') in (select ' || parent_cols || ' from ' || table_owner || '.' || parent_table ||
' ' || where_clause || ')';
delete_cascade(cons.owner, child_table, new_where_clause);
END LOOP;
/* construct the delete statement for the current table */
delete_command  := 'delete from ' || table_owner || '.' || parent_table || ' ' || where_clause;
-- this just prints the delete command
DBMS_OUTPUT.put_line(delete_command || ';');
-- uncomment if you want to actually execute it:
--EXECUTE IMMEDIATE delete_command;
-- remember to issue a COMMIT (not included here, for safety)
END;
    • Poulet: si cela a été d'aucune aide à tous, j'aimerais avoir une upvote; peut-être même accepté de répondre? 🙂 (Sur ce réponse, que je ne peux pas gagner tous les rep pour le premier parce qu'il est maintenant wiki de la communauté).
    • VoteUp nécessite 15 réputation, donc je ne peux pas vous donner un upvote... mais dans l'avenir, bien sûr 😉
    • J'ai cliqué pour accepter la réponse.
    • J'ai gagné la scolar badge bronze pour l'acceptation de votre réponse 😉
    • Je souhaite que je pourrais voir votre base de données afin que je puisse (peut-être) obtenir cette chose à travailler pour vous!
    • Imaginez la sortie de votre procédure stockée: il est composé de 145 DELETE! 🙂 La longueur maximale de la DELETE est: 1556 caractères! 🙂
    • Bien SÛR, je vais voter pour votre réponse: je n'ai qu'à attendre le 15e réputation (à l'heure actuelle, mon score de réputation est de 13).
    • NOTE: Mon patron me demanda d'écrire MANUELLEMENT ces 145 delete........... C'est pourquoi j'ai demandé de l'aide!!! 🙂
    • Je pense que vous êtes le premier pour avoir écrit un procédure stockée!! 🙂 Toutes les bases de données référentielle intégrités, et un problème commun est souvent à supprimer les anciens enregistrements en respectant les clés étrangères, et en évitant de laisser "sale" données de la DB!
    • MICROSOFT WORD statistiques de la sortie de la procédure stockée: Pages: 25 Mots: 7860 Caractères (sans espaces): 68745 Caractères (avec espaces): 76.460 Paragraphes: 141 Lignes: 1011
    • 1556 caractères, wow 🙂 Combien de niveaux de profondeur est-elle (combien de ")" sont à la fin de l'énoncé)? J'ai appris une leçon importante de cette... Si jamais j'ai de la conception d'une base de données importante, je pense que je vais faire toutes les contraintes reportable. 🙂
    • L'instruction DELETE avec une longueur de 1556 caractères se termine avec six consécutifs à droite de la parenthèse )))))) 🙂
    • Enfin je peux voter pour votre réponse UTILE, mon score de réputation est maintenant âgé de 23 ans et plus 13 🙂
    • Je ne Partisan badge bronze de vote jusqu'à votre question! 😉
    • Ces longs (niveau 6) supprime peut prendre un certain temps à s'exécuter si les tables sont grandes (dépend de l'index existent bien sûr). Avez-vous exécuté le supprime sur votre base de données de production encore?
    • Je recommande le montage de votre question pour le rendre plus simple maintenant - peut-être supprimer les exemples de code et il suffit de laisser le texte de la question afin que toute personne lisant dans l'avenir ne sera pas confus.
    • J'aurais dû utiliser des jointures au lieu de les sous-requêtes imbriquées... peut-être que peut être la version 2.0. 🙂
    • Bonjour Charles, le 6-niveau-les suppressions sont vraiment rapide, parce qu'ils impliquent un peu d'enregistrements. Le plus imbriqué condition est liée à une seule ligne, et est une condition qui utilise un index construit sur les deux champs de l'état: c'lignes de références à l'enfant des tables impliquant pas plus de 30 à 40 dossiers totalement.
    • J'ai suivi votre suggestion, l'édition, la question de quitter mon MAUVAIS exemples 😉
    • Je pense que votre solution avec les sous-requêtes imbriquées est de plus en plus clair que la solution avec des jointures 😉
    • Si tu parles de la sortie, je pense que vous avez raison à ce sujet. Les instructions de suppression avec les requêtes imbriquées sont très facile à lire (une fois formaté gentiment). Mais énorme se Joint à tous ceux Padn en serait vraiment moche!
    • J'utilise "Formateur de Plus" par Quest Software, afin de format bien les requêtes 😉
    • Moi aussi (Crapaud) 🙂
    • J'utilise Toad pour Oracle Xpert 10.1.1.8 🙂
    • Charles, pourriez-vous m'aider avec ma deuxième question a trait à SQL Plus? stackoverflow.com/questions/2735942/...

    InformationsquelleAutor Igby Largeman
  2. 3

    Le problème est que si le haut niveau de la colonne de la clé n'est pas propagées tout le chemin vers le bas.
    Si vous pouvez faire SUPPRIMER à PARTIR d'un petit-enfant OÙ parent_id = :1, c'est bien.
    Si vous avez à faire, 

    DELETE FROM grandchild
WHERE child_id in (SELECT id FROM child WHERE parent_id = :1)

    puis de descendre six ou sept profonde va vous donner moche (et probablement lente) des requêtes.

    Alors que vous avez dit que vous ne pouvez pas faire les contraintes CASCADE, pouvez-vous leur faire reportable initally immédiate ? De cette façon, code existant ne doit pas être touchés. Votre 'supprimer' session ferait toutes les contraintes différé. Puis supprimez de la mère, de supprimer de l'enfant, là où le disque n'est pas dans le parent, supprimer de l'enfant où il n'y a pas de correspondance dans l'enfant, etc...

    • Je ne peux pas les contraintes de la CASCADE, parce que je ne peux pas modifier la base de données: je ne peux INSÉRER, SUPPRIMER, SÉLECTIONNER et de mettre à JOUR, sans modification de la base de données à l'aide de Langage de Définition de Données des déclarations.
    InformationsquelleAutor Gary Myers
  3. 2

    C'est un excellent exercice pour le développement de vos PL/SQL compétences et général de l'Oracle de la connaissance!

    Vous devez identifier toutes les contraintes de colonnes de toutes les tables avec des relations décroissant à partir de votre tableau de maître. Vous pouvez obtenir toutes les informations dont vous avez besoin à partir de deux points de vue: ALL_CONSTRAINTS et ALL_CONS_COLUMNS. (Si toutes les tables sont dans le même schéma que l'utilisateur qui exécute le script, vous pouvez utiliser USER_CONSTRAINTS et USER_CONS_COLUMNS si vous préférez)

    Cette requête trouvera toutes les contraintes de clé étrangère qui renvoie à une table donnée (CUSTOMER dans cet exemple):

    SELECT constraint_name, table_name, constraint_type
FROM all_constraints
WHERE constraint_type = 'R'
AND r_constraint_name IN (SELECT constraint_name
FROM all_constraints
WHERE constraint_type IN ('P', 'U')
AND table_name = 'CUSTOMER');
CONSTRAINT_NAME                C
------------------------------ -
CUSTOMER_FK1                   R
CUSTOMER_FK4                   R
CUSTOMER_FK5                   R
CUSTOMER_FK3                   R
CUSTOMER_FK2                   R

    Maintenant, pour chacun des résultats à partir de cette requête, vous pouvez utiliser le CONSTRAINT_NAME colonne pour obtenir une table et le nom de la colonne que vous pouvez utiliser pour écrire des instructions de SUPPRESSION pour supprimer toutes les lignes enfants dans toutes les tables enfants.

    Cet exemple renvoie la table et de colonne nom pour une contrainte appelé CUSTOMER_FK1

    SELECT table_name, column_name
FROM user_cons_columns
WHERE constraint_name = 'CUSTOMER_FK1'
TABLE_NAME                    COLUMN_NAME                       
----------------------------- ------------------------------------
RESERVATION                   CUSTOMER_UID

    De sorte que vous pouvez faire, par exemple:

    DELETE FROM reservation
WHERE customer_uid = 00153464

    ou

    DELETE FROM reservation
WHERE customer_uid IN (SELECT customer_uid
FROM customer
WHERE customer_type = 'X')

    Mais votre enfant des tables aussi demander à l'enfant de tables, donc bien sûr, vous devrez supprimer ceux lignes enfants (appel de leur petit-enfant de lignes) en premier. Supposons qu'il y est une table appelée reservation_detail qui a une relation de clé étrangère avec de la réservation de votre commande supprimer pour reservation_detail pourrait ressembler à:

    DELETE FROM reservation_detail 
WHERE reservation_uid in (SELECT reservation_uid     
FROM reservation 
WHERE customer_uid IN (SELECT customer_uid
FROM customer
WHERE customer_type = 'X')

    Et si reservation_detail a aussi des enfants... vous voyez l'idée. Bien sûr, vous pourriez utiliser des jointures au lieu de requêtes imbriquées, mais le principe est le même: les niveaux plus profonds de vos dépendances, plus complexe votre supprimer des commandes.

    Donc, maintenant vous savez comment le faire, le défi est d'écrire un générique PL/SQL script pour supprimer toutes les lignes enfants, petits-enfants lignes, arrière-petit-enfant de lignes ... (à l'infini) d'une table, de bas en haut. Vous devrez employer la récursivité. Devrait être un programme amusant à écrire!

    (Dernière édition: supprimé le script; voir mon autre réponse pour la solution finale.)

    • S'il vous plaît aider! J'ai essayé d'écrire la procédure sans succès. J'ai besoin de cette procédure dans un délai de quelques jours... Mon intégrités référentielles sont de 5 pages, format A3,.... à l'aide!!
    • Quand j'ai le temps je vais vous écrire un peu de code. Pendant ce temps, essayez de google... quelqu'un doit avoir écrit déjà.
    • Je suis en train d'essayer avec Google depuis 3 ou 4 jours sans résultats intéressants.... Bien sûr, j'ai toujours trompé de mots-clés... j'ai essayé avec: code, de génération, de supprimer l'état, de l'intégrité référentielle, dba_constraints, et ainsi de suite... je serais reconnaissant si vous pouviez m'aider, car je ne suis pas en mesure de remplir cette tâche. En attendant, je vais continuer à chercher avec Google.
    • Je voudrais essayer: oracle, pl/sql, de supprimer, de table, des données, des enfants, des récursive, la récursivité. J'ai eu un coup d'oeil rapide et ne rien voir du tout évident que.
    • Par ailleurs, le script que j'ai fournis ci-dessus peut potentiellement ouvrir un grand nombre de curseurs si vous avez des relations sur plusieurs niveaux de profondeur. En fonction de vos paramètres du serveur, vous pouvez aller en OPEN_CURSORS limite.
    • Tout d'abord, je vous remercie beaucoup pour votre aide! 😉 Maintenant, je suis en train d'essayer le script, veuillez noter que les intégrités référentielles se propagent aussi dans d'autres 5 schémas... j'espère que le script s'occupera de cette affaire, aussi.
    • Le nombre de dossiers augmente, et augmente, mais DISTINCTS de supprimer les déclarations ne sont que 39..... Ai-je rencontré une boucle???
    • 9527 dossiers écrit dans le RESULT_TABLE (j'ai écrit les instructions de suppression dans une table temporaire, au lieu de les afficher à l'écran avec dbms_output.put_line), mais les différents enregistrements sont de 39, et ça marche maintenant...
    • J'ai arrêté le script en cours, dans le référentiel intégrités il y a des boucles, comment puis-je gérer???
    • J'ai 3 supprimer des règles sur les intégrités référentielles: CASCADE, PAS d'ACTION et de DÉFINIR la valeur NULL. J'ai modifié le CURSEUR de l'extraction de seulement AUCUNE ACTION intégrités référentielles, est-il correct? CURSEUR cons_cursor EST (....omissis....) ET delete_rule = "AUCUNE ACTION"; j'ai noté que les BOUCLES ont toujours l'option CASCADE.
    • Je viens de remarquer que le IMBRIQUÉS les conditions seront perdues: il sera conservé seulement à la condition de niveau 1.
    • Je ne suis pas sûr de ce que vous me dites... Cependant, j'ai réalisé que mon script n'est pas bon. Il serait de supprimer tout de toutes les tables enfants... Stupide; c'est ce qui arrive quand je code en hâte. 🙁 Désolé, mais c'est une question difficile. Je doute que je vais avoir du temps à se fissurer.
    • Ne vous inquiétez pas, ami, c'est tous les jours que je suis de l'étude de votre programme... 😉 C'est à 90% parfait, mais il ne gère pas le cas où les conditions lors de l'invocation de la récursivité: il ne conserve que la "surface" dans la condition where. Je n'ai pas trouvé la solution, j'ai seulement pensé à un deuxième paramètre qui est une chaîne incrémenté annonce à chaque récursion... mais maintenant, je vais avoir des problèmes avec la "PLS-00306: mauvais nombre ou les types d'arguments dans l'appel à "DELETE_CASCADE", et je ne sais pas pourquoi..... À l'aide!! 🙂
    • Droit - tous les SUPPRIMER comprend une sous-requête dans son où l'article. Ce que j'ai oublié était, que la sous-requête a aussi besoin d'un où l'article: il suffit de supprimer les lignes qui sont les enfants de l'lignes pour être supprimé à partir de sa table parent. Pour construire cette où l'article, nous avons besoin de savoir quelles lignes, nous allons les supprimer de la table parent, mais de savoir que nous avons aussi besoin de savoir quelles lignes seront supprimées à partir du parent parent... et ainsi de suite. Donc, à partir du haut (de la table de maître) vers le bas de l'arbre, chaque supprimer plusieurs les sous-requêtes imbriquées (plus vous allez, plus les sous-requêtes imbriquées). Il pourrait devenir laid.
    • Si vous avez de la PLS-00306, il doit être causé par votre changement de scénario... en quelque sorte, vous êtes l'appeler sans passer dans tous les paramètres. (Je ne pense pas que c'était possible d'obtenir cette erreur avec mon script d'origine)
    • J'ai tourné la procédure stockée dans une fonction, de sorte qu'il sera plus facile de fusionner les cordes avec des appels récursifs.... Maintenant, je suis en cours d'exécution à nouveau, mais je ne suis pas satisfait pour ce que je suis de voir... (aide)
    • Ci-dessus j'ai posté le code de la fonction stockée...
    • J'ai corrigé mon script. Bonne chance. 🙂
    • Demain matin, quand je vais revenir à mon bureau, je vais essayer de nouveau votre script, je suis sûr à 99% qu'il fonctionne très bien! 😉 Merci encore pour votre aimable, rapide, de rapide à l'aide!! 😉
    • J'espère que ça fonctionne... je serai vraiment impressionné si c'est le cas!
    • Charles, maintenant, je suis en cours d'exécution de votre nouvelle version..... 🙂
    • Bien sûr, au lieu de l'EXÉCUTION IMMÉDIATE de votre commande, je la stocke dans un tableau appelé RIS, afin d'éviter des problèmes 😉
    • J'ai ajouté la condition: ET DELETE_RULE = "AUCUNE ACTION" afin d'éviter la suppression en cas d'intégrités référentielles de type "CASCADE" et de type "SET NULL'. Êtes-vous d'accord??
    • CURSEUR cons_cursor EST de SÉLECTIONNER propriétaire, constraint_name, r_constraint_name, table_name DE all_constraints OÙ constraint_type = 'R' ET r_constraint_name DANS (SÉLECTIONNEZ constraint_name DE all_constraints OÙ constraint_type DANS ('P', 'U') ET table_name = parent_table ET propriétaire = table_owner) ET DELETE_RULE = "AUCUNE ACTION";
    • Votre script est PARFAIT, mais mon idée d'ajouter le code: ET DELETE_RULE = "AUCUNE ACTION" est FAUX. Maintenant, je lance le script à nouveau, sans mon code ajouté. Dans ma base de données il y a quelques tables de référence eux-mêmes, avec les mêmes champs......
    • Oh, non, maintenant je obtenir l'erreur suivante!! 🙁 ORA-01461: peut se lier à une valeur de type LONG seulement pour l'insertion dans une LONGUE colonne
    • Le problème ce sont les intégrités référentielles auto-référentielle, comme je l'ai écrit ci-dessus... Comment puis-je détecter les boucles??
    • SÉLECTIONNEZ propriétaire, constraint_name, r_constraint_name, table_name DE all_constraints OÙ constraint_type = 'R' ET r_constraint_name DANS (SÉLECTIONNEZ constraint_name DE all_constraints OÙ constraint_type DANS ('P', 'U') ET table_name = parent_table ET propriétaire = table_owner) ET table_name != parent_table; j'ai ajouté la condition TABLE_NAME != PARENT_TABLE pour éviter les BOUCLES...
    • Maintenant, je ré-exécuter tous!! 🙂
    • Ma condition TABLE_NAME != PARENT_TABLE évite SEULEMENT les boucles de profondeur = 1. Je n'ai pas que des cas comme suit: le TABLEAU A => l'INTÉGRITÉ RÉFÉRENTIELLE => TABLEAU d'UN ... mais j'ai aussi des cas comme suit: le TABLEAU A => TABLEAU B => TABLEAU C => TABLEAU D => TABLEAU d'UN ... comment puis-je résoudre ce problème??? À l'AIDE!
    • Oh la la, des références circulaires. Ce n'est pas bon! Laissez-moi réfléchir...
    • Je suis en supposant que votre circulaire de référence sont basées sur les contraintes Uniques sur nullable colonnes. Cela signifie que le script sera également besoin de générer de la mise à JOUR des déclarations de définir le parent colonnes NULL avant de l'lignes parent peut être supprimé... Pas la mention de la condition de boucle, il doit gérer.
    • Maintenant, j'essaie de copier le script de création d'une table avec des références circulaires, afin de vous montrer la situation critique.
    • Sont vos contraintes reportable? Ne select * FROM all_constraints et de regarder la REPORTABLE colonne des contraintes sur l'ensemble de vos tables.
    • ALTER TABLE DU CERCLE AJOUTER ( CONTRAINTE FK000001 CLÉ ÉTRANGÈRE (COD_CHICKEN, COD_NATION, NUMERICAL_CODE) RÉFÉRENCES MONSTRE (COD_CHICKEN,COD_NATION, NUMERICAL_CODE) ON DELETE SET NULL, CONSTRAINT FK000002 CLÉ ÉTRANGÈRE (COD_TRTT, NUM_ANN_SRI, TIP_FORM_TRTT) LES RÉFÉRENCES DE LA TOUR (COD_TRTT,NUM_ANN_SRI,TIP_FORM_TRTT) ON DELETE SET NULL, CONSTRAINT FK000003 CLÉ ÉTRANGÈRE (COD_CHICKEN1) RÉFÉRENCES DU POULPE (COD_CHICKEN) ON DELETE SET NULL, CONSTRAINT FK000004 CLÉ ÉTRANGÈRE (COD_BRK) RÉFÉRENCES PONT (COD_BRK) ON DELETE SET NULL, (... CONTINUER ...)
    • CONTRAINTE FK000005 CLÉ ÉTRANGÈRE (TIP_CIRCLE) RÉFÉRENCES TYPE_CIRCLE (TIP_CIRCLE), CONTRAINTE FK000006 CLÉ ÉTRANGÈRE (COD_CHICKEN_TYPE) RÉFÉRENCES TYPE_MODE (COD_CHICKEN_TYPE), CONTRAINTE FK000007 CLÉ ÉTRANGÈRE (COD_DVS) RÉFÉRENCES DVD_CDROM (COD_DVD), CONTRAINTE FK000008 CLÉ ÉTRANGÈRE (COD_AFF) RÉFÉRENCES AFFERMATION (COD_AFFERMATION) ON DELETE SET NULL, CONSTRAINT FK000009 CLÉ ÉTRANGÈRE (COD_CHICKEN, COD_NATION, COD_CIRCLE, COD_VRN_CIRCLE) RÉFÉRENCES CERCLE (COD_CHICKEN,COD_NATION,COD_CIRCLE,COD_VRN_CIRCLE) ON DELETE CASCADE);
    • Mes contraintes ne sont PAS non urgente 🙁
    • TOUJOURS pas reportable.
    • Je ne suis pas autorisé à les rendre non urgent (bien sûr).
    • Est FK000009 sur le CERCLE ou d'une autre table? Si c'est sur le CERCLE, ça ne serait pas complètement inutile? Comment une contrainte de référence, les mêmes colonnes dans une table?
    • Si l'ensemble de la circulaire contraintes SUR DELETE SET NULL, ce serait vraiment de l'aide. À partir de l'exemple que vous avez posté ci-dessus, il semble que cela pourrait être le cas.
    • Je ne sais pas comment une contrainte de référence, les mêmes colonnes de la même table, mais dans un environnement de production, de sorte qu'il est 🙂 Merci de supposer que toutes les circulaires des contraintes SUR DELETE SET NULL.
    • Je ne suis pas sûr que toutes les circulaires des contraintes SUR DELETE SET NULL, veuillez supposons donc... j'ai difficile à écrire les scripts de création, parce que je ne peux pas publier les vrais noms (bien sûr).
    • Maintenant, j'essaie de poster un exemple, afin que vous puissiez voir si notre hypothèse (on delete set null) est correct.
    • ALTER TABLE AUTO_MOTO_PRP AJOUTER ( CONTRAINTE FK000013 CLÉ ÉTRANGÈRE (COD_CHICKEN, COD_PRP, PROGRESS_CODE_PRP) RÉFÉRENCES MOV_PRP (COD_CHICKEN,COD_PRP,PROGRESS_CODE_PRP), CONTRAINTE FK000014 CLÉ ÉTRANGÈRE (COD_CHICKEN, COD_LIV_OGZ) RÉFÉRENCES LIV_OGZ (COD_COMP_PTF,COD_LIV_OGZ), CONTRAINTE FK000015 CLÉ ÉTRANGÈRE (COD_CHICKEN, COD_GRU_ARZ) RÉFÉRENCES GRU_ARZ (COD_CHICKEN,COD_GRU_ARZ) ON DELETE SET NULL, CONSTRAINT FK000016 CLÉ ÉTRANGÈRE (COD_CHICKEN0, COD_NATION, PROGRESS_CODE) RÉFÉRENCES AUTO_MOTO (COD_CHICKEN,COD_NATION,PROGRESS_CODE) ON DELETE SET NULL);
    • ALTER TABLE AUTO_MOTO AJOUTER ( CONTRAINTE FK000022 CLÉ ÉTRANGÈRE (COD_CHICKEN, COD_NATION, PROGRESS_CODE) RÉFÉRENCES MOV (COD_CHICKEN,COD_NATION,PROGRESS_CODE), CONTRAINTE FK000023 CLÉ ÉTRANGÈRE (COD_CHICKEN, COD_LIV_OGZ) RÉFÉRENCES LIV_OGZ (COD_COMP_PTF,COD_LIV_OGZ), CONTRAINTE FK000024 CLÉ ÉTRANGÈRE (COD_CHICKEN, COD_GRU_ARZ) RÉFÉRENCES GRU_ARZ (COD_CHICKEN,COD_GRU_ARZ) ON DELETE SET NULL, CONSTRAINT FK000025 CLÉ ÉTRANGÈRE (COD_CHICKEN0, COD_PRP, PROGRESS_CODE_PRP) RÉFÉRENCES AUTO_MOTO_PRP (COD_CHICKEN,COD_PRP,PROGRESS_CODE_PRP) ON DELETE SET NULL);
    • Dans ce dernier cas, nous avons traversé deux tableaux, qui font référence à eux-mêmes.
    • J'ai ajouté une nouvelle version du script. SI tous vos circulaire contraintes SUR DELETE SET NULL, ce qui devrait éviter la boucle infinie problème. Essayez-le et laissez de trouver le prochain problème... 🙂
    • Oh, j'ai oublié la référence à lui-même des contraintes. Vous devrez probablement modifier le curseur pour ceux à nouveau.
    • J'essaie tout de suite!! 🙂 J'ai ajouté de nouveau la condition: TABLE_NAME != PARENT_TABLE comme avant.
    • J'ai essayé de passer à la critique des tables, sans à partir de la racine. La procédure n'a pas de boucle (!!!). Maintenant, je fais le mondial exécuter, puis essayez de le lancer dans l'environnement de test (ne vous inquiétez pas pour les données de production).
    • MONDIAL RUN EST EN COURS D'EXÉCUTION! 🙂
    • Quelque chose s'est mal passé: la critique de tables n'ont PAS une INSTRUCTION DELETE... Est-ce normal? Puis-je essayer dans l'environnement de test?
    • J'ai juste ajouté AND delete_rule = 'NO ACTION', c'est plus simple.
    • Vous dites qu'il n'y a pas de supprimer l'instruction générée pour certaines tables? Peut-être que mon changement causé... mais ma tête va exploser à essayer de comprendre pourquoi!
    • ORA-01407: impossible de mettre à jour ("TITULAIRE"."CERCLE"."COD_CHICKEN") NULL ORA-06512: à ligne 4490
    • Bien sûr, le CERCLE est l'auto-intégrité-table référencée... je remplacer TABLE_NAME != PARENT_TABLE avec votre suggestion: ET DELETE_RULE = "AUCUNE ACTION".
    • ORA-01407 signifie que vous avez une contrainte SUR DELETE SET NULL, mais la contrainte de colonne est une colonne not NULL. Ce serait une situation ridicule!
    • Je sais... mais je n'ai pas conçu la base de données 😉 Avec votre suggestion, la procédure est actuellement en cours...
    • Maintenant, il est beaucoup plus lent... soyez patient...
    • (l'or, le commentateur de badge est bien sûr la mienne 🙂 )
    • 44 delete écrit jusqu'à maintenant
    • Oh oh.. c'est incroyablement lent!
    • Ne vous inquiétez pas... Le seul problème est que je ne vois pas la critique tables de supprimer l'instruction...
    • 77 delete écrit..... il est en cours d'exécution....
    • Rappelez-vous de ne pas supprimer des lignes d'une table jusqu'à ce que TOUTES les personnes à charge ont été supprimés. Peut-être qu'il n'en sommes pas là.
    • C'est normal qu'il est incroyablement lent, parce que l'imprimé graphique de la intégrités référentielles acquitte de 5 pages au format A3!
    • Sans l'auto-référencé-intégrités, nous avons résolu le problème! Mais dans mon cas, nous avons.....
    • 111 delete écrit.............
    • L'auto-référencement, les contraintes sont encore de causer des ennuis? Cela signifie que certains d'entre eux ne doit PAS être de l'ACTION. Nous avons besoin de modifier le curseur à ignorer l'auto-référencement des contraintes.
    • Je ne vois pas de cycle dans l'instruction delete: tous les delete obtenus sont UNIQUES.
    • Si elle passe en boucle sur un auto-référencement de contrainte, mettre and table_name <> parent_table de retour dans la requête.
    • Le seul problème est que maintenant, la procédure n'entre PAS dans la boucle, il évite à tout... FINI!!! Il a fini de s'exécuter! Maintenant, je copie les instructions de suppression pour UltraEdit, les transformer en PL/SQL bloc, puis essayez d'exécuter.
    • 133 delete à tous.
    • Combien de tables sont là? Vous devez avoir au moins que beaucoup de delete, probablement beaucoup plus.
    • Je suis désolé 🙁 ORA-01407: impossible de mettre à jour ("TITULAIRE"."CERCLE"."COD_CHICKEN") NULL ORA-06512: à ligne 1302 je déclare qu'une instruction delete pour le CERCLE de table n'existe pas dans la sortie de la procédure.
    • Je peux voir que la procédure ne permet PAS d'entrer dans la boucle, parce que les tables impliquées dans la boucle ne sont pas présents. Il évite les boucles sans courir sur eux pour qu'une seule fois.
    • Le FK sur le CERCLE des tables de donner des problèmes...
    • Il est complètement fou d'avoir un on DELETE SET NULL contrainte d'une colonne not NULL! Cela signifie que vous DEVEZ supprimer l'enfant avant que le parent, ce qui est impossible si vous avez affaire à une référence circulaire où le "parent" est vraiment l'enfant (ou descendant) de "l'enfant". La seule façon que vous pourriez jamais supprimer le "parent" de CERCLE est si vous avez une étrange série ou des contraintes comme ceci : C -> B -> A -> C où TOUTES les contraintes sont SUR DELETE SET NULL, et le C->B et B->Une des contraintes sur les valeurs null colonnes.
    • (suite) Mais alors, vous auriez supprimer dans cet ordre: A, C, B. (Dans cet exemple est Un CERCLE, et C est la table qui est en train de jeter l'ORA-01407). Si c'est ce que votre base de données est mis en place, je ne pense pas avoir le temps ou l'énergie pour écrire un script pour gérer. Je vous suggère d'en parler à l'administrateur de la base sur la suppression de ces stupides FK est. Désolé 🙁
    • SI votre base de données est mis en place comme je l'ai décrit ci-dessus (ce qui semble peu probable), alors vous devriez être en mesure de faire tous les supprime avec DEUX passes. Ignorer toutes les exceptions dans le premier passage (mais continuer), et ensuite la seconde étape serait de gérer tous ces tableaux.
    • Proposez-vous pour exécuter votre procédure deux fois, est-il juste?
    • Mon problème est que je ne peut pas commettre lors de l'exécution: à la fin de la procédure, le liquidateur peut décider de valider ou d'annuler.
    • Ne laissez pas ma procédure d'exécution de toutes les commandes; je pensais que l'on pouvait prendre la sortie de ma procédure (la série de Suppressions) et de l'exécuter tous les deux, persiste au-delà de toutes les exceptions. Mais je ne sais pas si ça marcherait, et il exige que vos contraintes sont mis en place dans l'étrange façon dont je l'ai décrit ci-dessus.
    • Incroyable! J'ai résolu de cette façon: j'ai exécuté la procédure pour la sous-table qui donne de problème, puis j'ai obtenu quelques DELETE lequel j'ai inséré manuellement AVANT le point critique dans le script avec 133 delete: ÇA marche!!!! 🙂
    • Peut-être, il y a deux types de l'auto-référentielle des contraintes d'intégrités: le premier type a EFFACER en CASCADE, et il résout de lui-même. Le deuxième type a SUR DELETE SET NULL, et n'est PAS autoresolving. La solution est de lancer votre procédure PARFAITE dans la sous-boucle, puis l'insérer manuellement les quelques delete, ainsi obtenu, dans le TOTAL de script.
    • Je dois observer, comme vous le suggérez, que dans ma base de données il y a les contraintes de non-sens, cela signifie que j'ai SUR DELETE SET NULL avec la référence à un NON-NULLABLE champ (COD_CHICKEN). Absurde.
    • Bien fait!! Maintenant, savoir qui a conçu votre base de données et de leur demander ce qu'ils pensaient. 🙂
    • ah ah ah 🙂 Vous avez raison!!!

    InformationsquelleAutor