Dépannage des problèmes de projet, de génération et de déploiement de base de données

Article
08/21/2008

Mise à jour : novembre 2007

Vous pouvez rencontrer les problèmes suivants lorsque vous créez, modifiez, générez ou déployez des projets de base de données :

Erreurs lors de la création de projets de base de données
Erreurs lors de la tentative d'utilisation d'une base de données SQL Server 2000 pour la validation au moment du design
Erreurs dans les objets de base de données
Utilisation de nouveaux mots réservés dans Microsoft SQL Server 2005
Différences dans la génération à partir de la ligne de commande
Clés symétriques, clés asymétriques et certificats
Dépendances et scripts de mise à jour
Erreurs lorsque vous vous ajoutez comme utilisateur
Les identificateurs entre guillemets peuvent causer des problèmes lors du rechargement du projet
L'état interne de la base de données est incohérent avec son contenu
Recherche de texte intégral
Objets SQLCLR
Annulation de modifications en attente
Utilisateur ou groupe Windows NT introuvable
Noms d'objets en double et fichiers exclus
CREATE ASSEMBLY ne prend pas en charge la référence à un fichier
Problèmes de conversion de SQL Server 2000 en SQL Server 2005
Noms qualifiés par une base de données et un serveur
Prise en charge des propriétés étendues
Performances liées à l'importation du schéma de base de données
Navigation dans les erreurs de génération
Projets de base de données et paramètre TRUSTWORTHY
Serveurs liés et scripts d'importation
Erreurs de syntaxe lors de l'utilisation de références entre bases de données
Index XML avec des propriétés étendues
Problèmes liés aux autorisations avec Team Foundation Build
Avertissements de jeton inattendus pendant la génération
Échec du déploiement de ligne de commande à partir d'un ordinateur x64 sur un serveur de base de données distant

Erreurs lors de la création de projets de base de données

Un message d'erreur apparaît si vous créez un projet de base de données et que vous n'avez pas d'autorisations pour créer une base de données dans votre instance locale de Microsoft SQL Server utilisée pour la validation au moment du design.

Remarque :
Utilisez un outil, tel que SQL Server Management Studio, pour configurer vos autorisations pour votre instance de SQL Server. Si vous ne pouvez pas vous connecter avec des informations d'identification administratives, vous pouvez être amené à demander à votre administrateur de vous accorder des autorisations pour créer des bases de données dans SQL Server.

Vous devez vous assurer que le nom d'instance qui est spécifié pour votre base de données de validation au moment du design est correct. Pour plus d'informations, consultez Comment : spécifier l'instance locale de SQL Server à utiliser pour la validation au moment du design.

Si vous exécutez Visual Studio sans autorisations administratives, l'erreur « Autorisation CREATE DATABASE refusée dans la base de données 'master' » peut s'afficher. Pour résoudre cette erreur, un utilisateur disposant d'autorisations sysadmin doit exécuter le script suivant sur votre base de données de validation au moment du design :

USE master
GO
GRANT EXECUTE ON sp_detach_db TO public
GO

Erreurs lors de la tentative d'utilisation d'une base de données SQL Server 2000 pour la validation au moment du design

Une erreur apparaît si vous remplacez la base de données qui est utilisée pour la validation au moment du design par une instance de SQL Server 2000, puis essayez de créer ou de modifier un projet de base de données. L'erreur affiche un message similaire à « Syntaxe incorrecte proche de 'ENABLE BROKER' ». La base de données de validation au moment du design utilise des fonctionnalités de SQL Server 2005.

Remarque :
Vous devez spécifier une instance valide d'une base de données SQL Server 2005 comme base de données de validation au moment du design. Pour plus d'informations, consultez Comment : spécifier l'instance locale de SQL Server à utiliser pour la validation au moment du design.

Erreurs dans les objets de base de données

Lorsqu'un objet de base de données contient une ou plusieurs erreurs de syntaxe, l'icône de cette base de données affiche l'icône d'erreur (un « ! » rouge) et les messages d'erreur associés s'affichent dans la fenêtre Liste d'erreurs. Le numéro de ligne correct est rapporté pour les erreurs retournées pendant la validation au moment du design par l'instance locale de SQL Server. Toutefois, le numéro de colonne rapporté est toujours le numéro un. La ligne et la colonne sont toutes deux correctes pour les erreurs de syntaxe SQL.

Remarque :
Le message d'erreur qui apparaît dans la fenêtre Liste d'erreurs doit fournir des informations sur les actions possibles pour corriger l'erreur. Après avoir corrigé l'erreur et enregistré l'objet de base de données, l'état par défaut de l'icône de cet objet de base de données est rétabli.

Utilisation de nouveaux mots réservés dans Microsoft SQL Server 2005

Les éléments suivants sont de nouveaux mots clés réservés dans SQL Server 2005: EXTERNAL, PIVOT, REVERT, TABLESAMPLE et UNPIVOT. Une erreur apparaît dans la fenêtre Sortie si vous utilisez ces mots clé réservés comme noms d'objets de schéma dans un projet de base de données qui est ciblé pour SQL Server 2000.

Remarque :
Pour contourner la restriction, vous pouvez mettre les noms d'objets de schéma entre guillemets. Par exemple, vous pouvez utiliser "CREATE TABLE [External] (c1 INT)".

Différences dans la génération à partir de la ligne de commande

Si vous exécutez une génération à partir de la ligne de commande lorsque le projet est ouvert dans Visual Studio, vous pouvez ne pas recevoir toutes les erreurs de génération que vous recevez lorsque vous procédez à la génération dans l'interface utilisateur.

Remarque :
Pour contourner le problème, fermez le projet de base de données dans Visual Studio avant d'exécuter une génération à partir de la ligne de commande.

Clés symétriques, clés asymétriques et certificats

Dans Visual Studio Team System Database Edition, vous ne pouvez pas créer de clés symétriques, de clés asymétriques ni de certificats comme objets de base de données. Lorsque vous importez un schéma de base de données, les commentaires d'espace réservé sont placés dans le script de prédéploiement avec les noms des clés et certificats. Vous devez modifier le script de prédéploiement pour créer ces objets. De la même façon, lorsque vous comparez des schémas de base de données, le script de mise à jour du schéma ne contient pas les commandes Transact-SQL (T-SQL) nécessaires à la création de clés symétriques, clés asymétriques ou certificats manquants. Vous devez exporter le script de mise à jour vers l'éditeur et ajouter des instructions pour créer ces objets.

Dépendances et scripts de mise à jour

Pour générer l'ordre correct des objets dans un script de mise à jour, la comparaison de schémas examine les dépendances d'objet. Par exemple, si une vue dépend d'une table, la table doit être créée avant la vue. Si l'objet qui dépend du deuxième objet n'utilise pas de nom qualifié par un schéma, la dépendance peut ne pas être identifiée et l'ordre des instructions peut être incorrect dans le script de mise à jour ou de création. Cette différence peut provoquer des erreurs lorsque vous mettez à jour une cible pour qu'elle corresponde à une source ou déployez des modifications vers une base de données. Ce problème s'applique également aux scripts de compilation de base de données.

Remarque :
Pour contourner ce problème, assurez-vous de qualifier par un schéma les noms des objets qui sont impliqués dans des relations dépendantes. Dans l'exemple suivant, vous pouvez garantir que la dépendance sera correctement identifiée si vous modifiez la fin de l'instruction pour qu'elle fasse référence à [dbo].[KeysTable] et non à KeysTable uniquement :

CREATE VIEW [NewUser].[ViewReferencingScalarFunction] AS SELECT Column2, dbo.SimpleMultiplyParamByTwo(PK_Column) AS [Function] FROM KeysTable

Erreurs lorsque vous vous ajoutez comme utilisateur

Si vous êtes un membre du rôle sysadmin et que vous essayez de vous ajouter comme utilisateur, l'erreur suivante apparaît : « L'ouverture de session a déjà un compte sous un nom d'utilisateur différent ». Cette erreur se produit, car vous êtes le propriétaire de la base de données de validation au moment du design, ce qui signifie que vous êtes également l'utilisateur dbo dans cette base de données. Par conséquent, vous ne pouvez pas vous ajouter à nouveau comme utilisateur de la base de données.

Les identificateurs entre guillemets peuvent causer des problèmes lors du rechargement du projet

Des erreurs s'affichent lorsque vous enregistrez des objets ou chargez une base de données qui contient des identificateurs entre guillemets si la case à cocher SET QUOTED_IDENTIFIER est désactivée dans les propriétés de base de données. Cette situation peut se produire si vous importez un schéma de base de données à partir d'une base de données qui a utilisé des identificateurs entre guillemets.

Remarque :
Pour contourner le problème, vous avez deux possibilités. Vous pouvez modifier les définitions d'objets afin d'utiliser des crochets et non des guillemets. Par exemple, vous pouvez remplacer "My Table" par [My Table]. Vous pouvez également ouvrir le menu Projet, cliquer sur Propriétés deProjetBaseDeDonnées, sur l'onglet Propriétés de la base de données, puis activer la case à cocher SET QUOTED_IDENTIFIER.

Pour contourner le problème, vous avez deux possibilités. Vous pouvez modifier les définitions d'objets afin d'utiliser des crochets et non des guillemets. Par exemple, vous pouvez remplacer "My Table" par [My Table]. Vous pouvez également ouvrir le menu Projet, cliquer sur Propriétés deProjetBaseDeDonnées, sur l'onglet Propriétés de la base de données, puis activer la case à cocher SET QUOTED_IDENTIFIER.

L'état interne de la base de données est incohérent avec son contenu

Vous pouvez recevoir le message d'erreur suivant lorsque vous utilisez Database Edition : "L'état interne du projet de base de données est incohérent avec son contenu. Déchargez le projet, puis rechargez-le pour résoudre le problème. ». Cette erreur indique que, pour une raison quelconque, le projet qui gère une liste des fichiers qu'il est supposé contenir n'est plus synchronisé avec l'état des fichiers. La cause la plus courante de cette erreur est la suppression de l'un des fichiers de votre projet du disque alors que le projet de base de données n'est pas ouvert. L'erreur peut également résulter de problèmes qui surviennent lorsque vous importez un schéma de base de données.

Remarque :
Pour contourner le problème, vous devez décharger et recharger le projet de base de données. Pour cela, cliquez dessus dans l'Explorateur de solutions. Ouvrez le menu Projet et cliquez sur Décharger le projet. Une fois le projet déchargé, ouvrez le menu Projet et cliquez sur Recharger le projet.

Recherche de texte intégral

Recherche de texte intégral et base de données de validation au moment du design

Si vous désactivez la recherche de texte intégral dans votre base de données de validation au moment du design et que vous importez un schéma à partir d'une base de données qui comprend des objets indexés de texte intégral, les objets seront importés. Toutefois, des erreurs apparaîtront dans la fenêtre Liste d'erreurs pour tous les objets qui utilisent des index de texte intégral. Les mêmes erreurs s'afficheront si, après avoir importé les objets, vous désactivez la recherche de texte intégral dans votre base de données de validation au moment du design.

Remarque :
Pour contourner ce problème, vous devez activer la recherche de texte intégral dans la base de données de validation au moment du design. Pour plus d'informations, consultez « Recherche de texte intégral » sur le site Web Microsoft.

Actions sp_fulltext_table dans les définitions d'index de texte intégral

Seule l'action CREATE est autorisée dans la définition de votre index de texte intégral. Si vous voulez effectuer une action telle qu'ACTIVATE, vous devez l'effectuer dans le script de post-déploiement de la base de données. Si vous ajoutez d'autres actions, l'erreur suivante s'affiche : « Le lot principal ne peut pas avoir d'instruction de langage de manipulation de données (DML) de niveau supérieur. Supprimez cette instruction et retentez l'opération. »

Remarque :
Pour contourner ce problème, vous devez déplacer l'instruction sp_fulltext_table vers votre script de post-déploiement ou vers un script inclus dans votre script de post-déploiement. Pour plus d'informations sur les scripts de post-déploiement, consultez Comment : spécifier des scripts de prédéploiement ou de post-déploiement.

Objets SQLCLR

Par défaut, l'intégration SQLCLR est désactivée dans Microsoft SQL Server 2005. Si vous importez un schéma à partir d'une base de données qui comprend des objets SQLCLR et que l'intégration SQLCLR est désactivée dans votre base de données de validation au moment du design, les erreurs n'apparaîtront pas dans la fenêtre Liste d'erreurs. Toutefois, vous recevrez des erreurs si vous essayez d'exécuter ces objets.

Remarque :
Pour contourner le problème, vous devez exécuter l'éditeur Transact-SQL à partir de Database Edition ou un outil comme SQL Server Management Studio, et vous connecter au serveur en tant qu'administrateur système. Par la suite, dans une fenêtre de requête, exécutez la ligne suivante :

exec sp_configure 'clr enabled', 1
reconfigure

Annulation de modifications en attente

La vue Schéma ne s'actualise pas automatiquement après l'utilisation de la commande Annuler les modifications en attente de votre système de contrôle de version. Si, par exemple, vous renommez une table ou une colonne, puis que vous rétablissez les modifications apportées, le message « Modification du fichier externe, resynchronisation requise... » s'affiche dans Vue Schéma.

Remarque :
Pour contourner ce problème, vous devez cliquer sur Synchroniser dans la barre d'outils Vue Schéma.

Utilisateur ou groupe Windows NT introuvable

Si votre projet de base de données référence une connexion qui n'est pas disponible, l'erreur « Utilisateur ou groupe Windows NT 'NomDomaine\NomConnexion' introuvable. Vérifiez une nouvelle fois le nom. » s'affiche. Ce problème peut se produire si vous travaillez sur un ordinateur qui se trouve dans un autre domaine que la base de données dont le schéma a été importé, par exemple. Cette situation survient généralement si vous travaillez à la maison sur un projet de base de données qui a été créé ailleurs. Dans ce cas, vous ne pouvez pas générer ou déployer le projet de base de données.

Remarque :
Il n'existe aucune solution permettant de résoudre ce problème. Vous pouvez générer et déployer un projet de base de données uniquement là où les connexions référencées sont valides.

Noms d'objets en double et fichiers exclus

Si votre projet de base de données contient des noms d'objets en double (par exemple deux tables appelées Orders), une erreur apparaît dans la fenêtre Liste d'erreurs. Même si vous résolvez le problème en excluant le fichier qui contient la définition de l'un des objets, le message d'erreur ne disparaît pas immédiatement.

Remarque :
Pour contourner ce problème, vous pouvez cliquer sur Actualiser, ou modifier le fichier qui contient la définition de l'objet, renommer ce dernier et enregistrer le fichier.

CREATE ASSEMBLY ne prend pas en charge la référence à un fichier

Vous pouvez ajouter un assembly CLR à une instruction Transact-SQL (T-SQL) CREATE ASSEMBLY soit en incluant le code binaire dans l'instruction, soit en spécifiant un chemin d'accès au fichier d'un assembly. Database Edition ne prend pas en charge cette dernière méthode. Si vous essayez d'utiliser cette syntaxe, l'erreur suivante s'affiche : L'instruction CREATE ASSEMBLY ne peut avoir que des éléments binaires dans sa clause FROM.

Remarque :
Il n'existe aucune solution permettant de résoudre ce problème.

Problèmes de conversion de SQL Server 2000 en SQL Server 2005

Lorsque vous convertissez un projet de base de données de SQL Server 2000 en SQL Server 2005, les menus contextuels des objets SQL Server 2005 ne s'affichent pas dans la vue Schéma.

Remarque :
Pour contourner ce problème, fermez et rouvrez votre projet de base de données après l'avoir converti en SQL Server 2005.

Noms qualifiés par une base de données et un serveur

Lorsque vous créez un objet dans Team Edition for Database Professionals, cet objet est nommé selon la convention d'affectation des noms [schéma].[objet].[enfant]. Si vous souhaitez faire référence à un objet dans une autre base de données ou sur un autre serveur, vous pouvez inclure le nom de la base de données et le serveur de la façon suivante : [serveur].[base de données].[schéma].[objet].[enfant]. Si vous créez une procédure stockée ou une vue référençant un objet qui requiert un nom qualifié par une base de données ou un serveur, un avertissement s'affiche.

Remarque :
Pour résoudre l'avertissement, vous devez définir une référence entre bases de données. Pour plus d'informations sur les références entre bases de données, consultez Vue d'ensemble des références entre bases de données et Comment : créer des références entre bases de données.

Remarque importante :
Le déploiement échouera si votre projet contient des avertissements non résolus relatifs à des noms qualifiés par une base de données ou un serveur et que vous activez la case à cocher Considérer les avertissements comme des erreurs sous l'onglet Générer des propriétés du projet de base de données. Cet échec est dû au fait que les noms qualifiés par une base de données ou un serveur génèrent des avertissements. Vous devez désactiver la case à cocher Considérer les avertissements comme des erreurs si vous utilisez des noms qualifiés par une base de données ou un serveur.

Le déploiement échouera si votre projet contient des avertissements non résolus relatifs à des noms qualifiés par une base de données ou un serveur et que vous activez la case à cocher Considérer les avertissements comme des erreurs sous l'onglet Générer des propriétés du projet de base de données. Cet échec est dû au fait que les noms qualifiés par une base de données ou un serveur génèrent des avertissements. Vous devez désactiver la case à cocher Considérer les avertissements comme des erreurs si vous utilisez des noms qualifiés par une base de données ou un serveur.

Prise en charge des propriétés étendues

Cette version de Database Edition ne prend pas en charge les propriétés étendues sur les groupes de fichiers, noms de fichiers et contraintes de fonctions. Si vous importez un schéma de base de données ou un script, les propriétés étendues sur ces types d'objets sont ignorées.

En outre, les propriétés étendues qui stockent une valeur de type TinyInt, SmallInt, UniqueIdentifier ou Bit sont ignorées et placées dans le fichier ScriptsIgnoredOnImport.sql.

Remarque :
Pour contourner ce problème, vous devez créer manuellement les propriétés étendues dans un script de post-déploiement. Pour plus d'informations, consultez Comment : spécifier des scripts de prédéploiement ou de post-déploiement.

Performances liées à l'importation du schéma de base de données

Si vous importez un schéma de base de données pendant que la fenêtre Explorateur de tests ou Affichage de tests est ouverte, l'exécution de l'opération d'importation prendra considérablement plus de temps. Ce ralentissement se produira à la fois dans l'Assistant Nouveau projet de base de données (si vous avez choisi d'importer un schéma de base de données) et pendant l'opération d'importation du schéma de base de données. Le problème se produit même si vous fermez la fenêtre Explorateur de tests et Affichage de tests avant d'importer le schéma de base de données.

Remarque :
Pour contourner ce problème, vous devez fermer la fenêtre Explorateur de tests et Affichage de tests, arrêter et redémarrer Visual Studio, puis importer le schéma de base de données. Pour les petits schémas, il est possible que vous n'ayez pas à exécuter ces étapes. Pour l'exemple de base de données AdventureWorks, l'opération d'importation du schéma a pris 27 secondes avec la fenêtre Explorateur de tests fermée et 48 secondes avec la fenêtre Explorateur de tests ouverte.

Pour contourner ce problème, vous devez fermer la fenêtre Explorateur de tests et Affichage de tests, arrêter et redémarrer Visual Studio, puis importer le schéma de base de données. Pour les petits schémas, il est possible que vous n'ayez pas à exécuter ces étapes. Pour l'exemple de base de données AdventureWorks, l'opération d'importation du schéma a pris 27 secondes avec la fenêtre Explorateur de tests fermée et 48 secondes avec la fenêtre Explorateur de tests ouverte.

Si le déploiement échoue, vous ne pouvez pas corriger l'erreur en mettant à jour le script de compilation généré. Vous devez corriger le fichier source qui est utilisé pour générer ce script de compilation. Si vous double-cliquez sur une erreur de déploiement dans la fenêtre Liste d'erreurs, le script de compilation apparaît dans l'éditeur, en affichant la ligne qui a provoqué l'erreur.

Remarque :
Pour contourner ce problème, vous devez examiner le script de compilation pour déterminer la cause de la défaillance, mais vous devez ensuite modifier le fichier source dans le projet de base de données qui contient l'erreur. Par exemple, si le script de post-déploiement Permissions.sql contient une erreur, vous devez modifier Permissions.sql au lieu du script de compilation.

Projets de base de données et paramètre TRUSTWORTHY

Vous devez avoir des autorisations d'administrateur système pour activer le paramètre TRUSTWORTHY pour un projet de base de données ou ouvrir un projet de base de données pour lequel le paramètre TRUSTWORTHY est activé.

Remarque :
Pour contourner ce problème, si le paramètre TRUSTWORTHY ne doit pas être activé, demandez à votre administrateur de désactiver le paramètre pour le projet de base de données. Si le paramètre TRUSTWORTHY doit être activé, tous les développeurs qui travaillent sur le projet de base de données doivent recevoir les autorisations d'administrateur système sur cette base de données. Si chaque développeur travaille dans un environnement de développement isolé, chacun d'eux a une copie privée de la base de données et peut être ajouté en toute sécurité au rôle sysadmin pour cette base de données.

Pour contourner ce problème, si le paramètre TRUSTWORTHY ne doit pas être activé, demandez à votre administrateur de désactiver le paramètre pour le projet de base de données. Si le paramètre TRUSTWORTHY doit être activé, tous les développeurs qui travaillent sur le projet de base de données doivent recevoir les autorisations d'administrateur système sur cette base de données. Si chaque développeur travaille dans un environnement de développement isolé, chacun d'eux a une copie privée de la base de données et peut être ajouté en toute sécurité au rôle sysadmin pour cette base de données.

Serveurs liés et scripts d'importation

Une erreur peut s'afficher lorsque vous déployez un projet de base de données si vous avez importé plusieurs scripts dans un projet de base de données. Cette situation peut se produire si le même serveur lié a été défini plusieurs fois entre ces scripts.

Remarque :
Pour contourner ce problème, vous pouvez ajouter l'instruction T-SQL suivante avant chaque appel sp_addlinkedserver dans le script de prédéploiement LinkedServers.sql :

IF NOT EXISTS (SELECT * FROM master.dbo.sysservers WHERE srvname = N'<serverName>')

Erreurs de syntaxe lorsque vous utilisez des références entre bases de données

Une ou plusieurs erreurs de syntaxe peuvent s'afficher lorsque vous enregistrez une définition d'objet qui contient une référence à un objet d'une autre base de données. Par exemple, vous pouvez ajouter une référence au projet de base de données, définir des variables nommées RefServer et RefDatabase, puis leur assigner des valeurs. Vous pouvez ensuite définir une vue comme suit :

CREATE VIEW [dbo].[MyView]
AS
SELECT * FROM $(RefServer).$(RefDatabase).dbo.TableName

Lorsque vous enregistrez cette définition, un ou plusieurs messages d'erreur qui indiquent une syntaxe incorrecte peuvent s'afficher. Les messages d'erreur peuvent référencer le nom de votre base de données de validation au moment du design, ce qui peut prêter à confusion.

Remarque :
Pour résoudre ce problème, vous devez placer les noms de variables entre crochets. Pour corriger cet exemple, modifiez-le comme suit :

CREATE VIEW [dbo].[MyView]
AS
SELECT * FROM [$(RefServer)].[$(RefDatabase)].dbo.TableName

Index XML avec des propriétés étendues

Une ou plusieurs erreurs de syntaxe peuvent survenir lorsque vous enregistrez une définition d'objet pour un index XML qui contient les définitions d'une ou de plusieurs propriétés étendues. Ce type d'erreur se produit parce que SQL Server 2005 ne supprime pas les propriétés étendues lorsqu'un index XML est supprimé et recréé. Lorsque cette situation se produit, l'erreur suivante peut apparaître : "TSD4001: Impossible d'ajouter la propriété. La propriété 'ExtendedPropertyName' existe déjà pour 'XMLIndexName'. (erreur SQL = 15233".

Remarque :
Pour résoudre ce problème, vous devez déplacer la définition de la ou des propriétés étendues vers le script de post-déploiement, et ajouter immédiatement les instructions suivantes avant la définition :

IF NOT EXISTS (SELECT * FROM fn_listextendedproperty('ExtendedPropertyName', 'SCHEMA', N'SchemaName', 'TABLE', N'TableName', 'INDEX', N'XMLIndexName')

Problèmes liés aux autorisations avec Team Foundation Build

Une erreur d'autorisation peut s'afficher lorsque vous générez et déployez votre projet de base de données à l'aide de Team Foundation Build. Par défaut, le compte de service de Team Foundation Build utilise le compte Service réseau. Le compte Service réseau ne dispose pas des autorisations requises pour l'instance de SQL Server sur l'ordinateur de build.

Remarque :
Pour résoudre ce problème, vous devez accorder au compte Service réseau des autorisations supplémentaires ou remplacer le compte de service sous lequel s'exécute Team Foundation Build par le compte possédant les autorisations requises. Pour plus d'informations, consultez Autorisations requises dans Database Edition.

Avertissements de jeton inattendus pendant la génération

Des avertissements de jeton inattendus peuvent apparaître lorsque vous générez votre projet de base de données à l'aide de MSBuild. Si vous substituez le DefaultDataPath sans spécifier deux barres obliques inverses de fin, la séquence \" est interprétée comme un échappement du guillemet. Vous recevez des avertissements de génération et le script de compilation généré risque d'être incomplet.

Remarque :
Pour résoudre ce problème, vous devez spécifier une double barre oblique inverse à la fin du chemin d'accès. Pour plus d'informations, consultez Vue d'ensemble de la génération et du déploiement d'une base de données.

Échec du déploiement de ligne de commande à partir d'un ordinateur x64 sur un serveur de base de données distant

Si vous ne spécifiez pas explicitement de connexion cible pour le projet de base de données, les valeurs de groupe de fichiers et d'emplacement de fichier sont définies selon la structure de répertoires sur l'ordinateur x64 local. Le déploiement échoue sauf si le serveur de base de données distant exécute également un système d'exploitation x64 et une version 32 bits de SQL Server.

Remarque :
Pour résoudre ce problème, vous devez spécifier explicitement une connexion à la base de données cible dans les propriétés du projet de base de données avant de déployer la base de données. Pour plus d'informations, consultez Comment : configurer des projets de base de données pour la génération et le déploiement.

Voir aussi

Partager via