Importer dans un projet de base de données
Vous pouvez utiliser la fonction Importer pour remplir un projet avec de nouveaux objets provenant d'une base de données active ou d'un fichier .dacpac, ou pour mettre à jour des objets existants dans votre projet avec une nouvelle définition d'un script. Il convient de noter plusieurs différences de comportement entre ces trois choix, comme décrit ci-dessous.
Menu Importer
Sections de cette rubrique
Source d’importation : base de données ou application de la couche Données (*.dacpac)
Source d’importation : script (*.sql)
Importer la source : base de données ou application de la couche Données (*.dacpac)
La possibilité d'importer un schéma depuis une base de données ou un fichier .dacpac n'est disponible que si aucun objet de schéma n'est encore défini dans le projet. Cela n'inclut pas les fichiers RefactorLogs ni les scripts de prédéploiement et de post-déploiement.
Lors de l’importation, les définitions d’objet sont écrites via un script dans les fichiers de projet à l’aide des valeurs organisationnelles par défaut de SSDT pour les nouveaux objets : nouveaux fichiers pour les objets de niveau supérieur, enfants hiérarchiques définis dans le même fichier que le parent, contraintes de table/colonne définies en ligne lorsque cela est possible. Pour disposer d'un meilleur contrôle et d'une visibilité ciblée pour chaque objet, utilisez Comparaison de schémas au lieu d'Importer.
Si la source d'importation contient des scripts de prédéploiement et de post-déploiement, des fichiers RefactorLogs ou des définitions de variable SQLCMD, ils seront importés dans le projet. Si le projet contient déjà l’un de ces artefacts, les fichiers importés seront ajoutés à un dossier Ignoré lors de l’importation dans le projet.
Dossier Ignoré lors de l’importation
Importer la source : script (*.sql)
Tous les objets de la source d’importation qui n’existent pas encore dans le projet seront ajoutés, et tous les ceux qui existent déjà remplaceront la définition des objets dans le projet.
Notes
Il existe deux bogues connues dans cette méthode. Elles seront corrigées dans une prochaine version :
- Si les contraintes de table/colonne sont définies à l’extérieur de l’instruction CREATE TABLE dans la définition de la table du projet, l’importation remplace la définition de la table de sorte que cette contrainte soit inline. Toutefois, elle laisse la contrainte hors ligne, ce qui se traduit par des contraintes en double dans le projet.
- Toutes les clés principales ou les clés de chiffrement de base de données de votre script source qui existent déjà dans le projet sont dupliquées lors de l'importation. Supprimez ces doublons afin de pouvoir générer le projet.
Le processus d'importation à partir d'un script ne comprend pas les scripts de prédéploiement et de post-déploiement, les variables SQLCMD ni les fichiers RefactorLog. Ces éléments, ainsi que toutes les autres constructions non prises en charge qui sont détectées lors de l’importation, seront placés dans un fichier ScriptsIgnoredOnImport.sql au sein d’un dossier Scripts dans votre projet.
Importer les objets chiffrés
Lors de l'importation d'objets chiffrés dans un projet de base de données, le corps entier de la définition d'objet ne peut pas toujours être récupéré depuis le serveur. De ce fait, le comportement d'importation peut varier lorsque cette classe d'objets doit être gérée.
Lorsqu'il n'est pas possible de récupérer la définition du corps entier, l'en-tête/le pied de page de l'objet, ainsi qu'un corps factice, sont écrits dans un script. Attendez-vous à rencontrer ce comportement lorsque vous effectuez une importation ou utilisez une comparaison de schémas dans laquelle la source est une base de données active ou un fichier .dacpac extrait d'une base de données.
Script avec un corps factice
Dans le cas où la définition complète de l'objet est disponible et peut être récupérée, les processus d'importation et de comparaison de schémas permettent de la rétablir dans le projet dans son intégralité. Cela se produit lors de la mise à jour du projet à partir d'un script, d'un fichier .dacpac créé à partir d'un projet de base de données ou d'un autre projet de base de données.
Commentaires
https://aka.ms/ContentUserFeedback.
Prochainement : Tout au long de l'année 2024, nous supprimerons progressivement les GitHub Issues en tant que mécanisme de retour d'information pour le contenu et nous les remplacerons par un nouveau système de retour d'information. Pour plus d’informations, voir:Soumettre et afficher des commentaires pour