Ignorer les mappages de connexion pendant le comparaison DACPAC
Nous essayons d'automatiser le déploiement de bases de données via le développement, les tests et la production. Notre approche, utilisant SSDT, est de comparer les DACPACS à partir de l'environnement différent pour générer des scripts de mise à jour et une étape finale, cartographier les connexions de Windows correctes aux utilisateurs corrects.
/ P: IGNOREUSERLOGINMAPPINS
En regardant la documentation pour sqlpackage.exe Il existe une propriété IgnoreUserLoginMappings qui semble impliquer que cela ignorerait les mappages, de sorte qu'ils ne soient pas inclus dans le DACPAC et ne sont donc pas mis à jour pendant la Comparaison et génération de script. Mais, lorsque nous utilisons cette propriété lors de notre extrait, les utilisateurs générés sont sans connexion, comme celui-ci dans le DACPAC:
<Element Type="SqlUser" Name="[Domain\Account]">
<Property Name="IsWithoutLogin" Value="True" />
<Relationship Name="DefaultSchema">
<Entry>
<Annotation Type="PersistedResolvableAnnotation" Name="[Domain\Account]">
<Property Name="TargetTypeStorage" Value="SqlSchema" />
</Annotation>
</Entry>
</Relationship>
</Element>
ce qui n'est pas ce que nous voulons! La mise à jour générée par la suite ressemble à ceci:
CREATE USER [Domain\Account] WITHOUT LOGIN
WITH DEFAULT_SCHEMA = [Domain\Account];
Est-ce que nous faisons quelque chose de mal ou est-ce un bogue, j'ai cherché et que vous ne pouvez pas voir beaucoup d'informations sur cette propriété, est-ce que quelqu'un l'utilise qui peut aider, ou existe-t-il une autre approche?
Question connexe : ICI
J'ai trouvé avec SQLPackage.exe ne déposera pas d'objets de sécurité.
J'avais aussi le même problème. À l'avenir, nous allons déployer des modifications de la base de données à l'aide de DACPACS. Nous avons besoin d'un moyen d'exclure les utilisateurs, les rôles et les connexions du processus de mise à jour afin qu'ils ne soient pas supprimés du serveur SQL cible.
Notre base de données est installée sur des centaines de sites clients et de nombreuses installations SQL Server ont eu leur configuration de sécurité par le DBAS à cette entreprise. Ils ajouteront souvent leurs propres connexions et utilisateurs de domaine et, dans certains cas, serrez les rôles plus que nos valeurs par défaut.
J'ai remarqué que lors du choix de la possibilité de "mettre à niveau une application de Data-Tier" dans SQL Server Management Studio 2012, je n'avais pas la possibilité d'ignorer les objets de sécurité. L'examen a réellement déclaré qu'il allait abandonner les utilisateurs et les rôles.
Mais quand j'ai utilisé sqlpackage.exe, il n'a pas laissé tomber les objets de sécurité. En effet, le paramètre "DropObjectsNoSource" est défini sur FALSE par défaut.
"C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\SqlPackage.exe" /Action:Publish /SourceFile:.\bin\debug\SandBox.dacpac /TargetServerName:sandboxserver /TargetDatabaseName:SandBox
Le seul inconvénient est que si vous souhaitez supprimer des objets obsolètes de la base de données, vous devez ajouter les gouttes au script de déploiement post.
J'espère que Microsoft ajoutera cette fonctionnalité à l'avenir. Ces objets sont souvent gérés par des DBA et non des développeurs.