sur la table "A" dépend de 30 autres tables via FK à "A.ID".
Pour les tests d'intégration, je dois laisser tomber la table et le recréer pour créer un état défini. En raison des objets dépendants, leur semble ne pas être un moyen de supprimer et de recréer la table. Le message d'erreur est:
ne pouvait pas laisser tomber objet 'dbo.a' parce qu'il est référencé par un étranger Contrainte clé
question (s):
Comment puis-je déposer et recréer la table "A" ? - (ou) Y a-t-il une façon de tourner les dépendances de schéma au niveau mondial?
- (ou) existe-t-il un moyen de sauvegarder (toutes!) dépendances avant de supprimer et de restaurer la table "A" et de restaurer toutes les dépendances par la suite?
6 Réponses :
Dans Management Studio, vous pouvez cliquer avec le bouton droit de la souris sur la table et le script de la création et de la chute qui inclura toutes les clés étrangères.
Pour être plus précis, cela vous donnera toutes les contraintes sur lesquelles votre table dépend. Cependant, il ne vous donne pas la liste des clés étrangères qui dépendent de cette table. Ainsi, en plus des scripts que vous généreriez en cliquant avec le bouton droit de la souris sur la table dans SMS, vous devez rechercher et script toutes les clés étrangères. Pour obtenir une liste d'entre eux, vous pouvez exécuter une requête comme suit: pour chacune d'entre elles, vous devrez scripter de créer et de tomber. Vous appendez les gouttes au sommet de votre script de goutte et la création à la fin de votre script Créer.
Cela ne contient pas les dépendances de référencement, qui sont le problème.
Que veux-tu dire? SMS créera un script qui déposera toutes les clés étrangères à la table en cours de chute, puis à la fin, déposez la table. De plus, la création créera toutes les clés étrangères.
Hmm, j'ai dact essayé ceci .. Vous avez un script avec beaucoup: "Si existe (SELELLE * SYSTES.CHECK_CONSTAINTINGS Où" ... Mais quand je l'exécute, je reçois toujours: "Impossible de laisser tomber l'objet 'dbo.a' Parce qu'il est référencé par une contrainte de clé étrangère. "C'est vraiment étrange!
Mes excuses. Je vois le problème. Vous devez trouver tous les FKS qui pointent sur la table que vous souhaitez laisser tomber. Je vais modifier ma réponse.
Développez la table dans SQL Server Management Studio, développez le dossier Contraintes.
Écrivez toutes les contraintes que vous avez pour que vous puissiez les recréer. Supprimez les contraintes et déposez la table. Reconstruire la table et recréer vos contraintes.
J'ai également pensé à cela aussi, mais depuis que de nombreuses tables ont de nombreuses contraintes et dépendances, cela sera beaucoup de travail. (Et beaucoup de travail, c'est ce que j'essaie d'éviter :-))
Oui, je souhaite que Mirccosoft faciliterait la tâche de réaliser cette tâche. Chaque fois que je dois le faire, je me plains fort. ;-)
Utiliser une transaction. À la fin du test - Rollback It.
Bonne idée, mais je ne peux pas obtenir la prise de la connexion SQL - il n'ya donc aucun moyen de contrôler la transaction (?).
explorer le avec ceci, ou une variation là-bas, vous pouviez Découvrez les clés étrangères, déposez-les, faites vos affaires, puis de recréer les clés étrangères. Je devrais ajouter que je sais que cela fonctionne sur SQL2005 et SQL2008. Je ne sais pas vraiment si cela fonctionnera sur SQL2000 / MSDE. sys.coreign_key_columns Table système. Voici un exemple que j'avais plongé autour de celui-ci, étant donné une table, vous indique lequel de ses colonnes est clé en une autre table:
Allez à la base de données dans SSMS et clic droit. Choisissez des tâches, générez des scripts. Ensuite, passez à travers les options et définissez-les comme vous le souhaitez (probablement choisissez uniquement des clés étrangères dans la table et créez des objets à charge, déposer et recréer, ne pas les options devant moi, mais vous les verrez ensuite. Choisissez ensuite les tables que vous avez Voulez-vous scripter le script et les script à un fichier. Ouvrez le fichier et séparez les instructions DROP dans un fichier et dans les clayses de création dans un autre. Maintenant, vous avez des fichiers tweo que vous pouvez exécuter faire de manière automatique ce que vous voulez quand vous avez exécuté Un test. Je vous suggérerais de recréer les fichiers avant d'exécuter le premier test (au cas où ils ont changé depuis les derniers tests de la dernière fois) mais pas pour chaque test individuel.
Merci, je suis très reconnaissant. C'est ce qui a fonctionné le mieux pour moi!
envisagez peut-être de maintenir un serveur virtuel avec votre base de données dans sa configuration de test d'initialisation. Démarrez la machine virtuelle, effectuez vos tests, puis jetez le VM modifié.
Non, il n'y a pas de restauration du tout. Il faudrait une minute ou deux pour démarrer la machine virtuelle lorsque vous le vouliez, c'est tout.
Pourquoi n'utilisez-vous pas une DB distincte pour les tests d'intégration où l'état entier est généré à partir de zéro à chaque fois?
La base de données est juste trop grande (une centaine de tables avec de nombreux objets dépendants). En allant de cette façon, chaque test d'intégration prendrait environ 45 secondes + x juste pour le temps de démarrage et sans aucun test réel. De plus, certaines tables contiennent des données. (Le dépotoir total de la base de données sans données personnalisées est d'environ 35 Mo). Nous aurons beaucoup de tests d'intégration , que nous souhaitons exécuter à chaque enregistrement, à l'aide du serveur d'intégration.
Chaque état d'intégration nécessite-t-il le même état initial de la DB ou pouvez-vous payer la pénalité de démarrage une fois et que chaque test annulerait-il les modifications transitoires qu'il aurait pu faire à l'état?
Payer la pénalité de démarrage une fois l'idée. "Rembobiner" les changements L'idée est de recréer la table + un ensemble défini de données. (Son énorme application héritée et c'est le mieux que nous venons jusqu'à présent. L'objectif est des tests unitaires, mais ce que nous pouvons atteindre actuellement ne sont que des tests d'intégration.)