web-dev-qa-db-ja.com

2013 SQLServerデータベースプロジェクトでログイン用のユーザーを作成する方法

SSDTデータベースプロジェクトにログインしたユーザーを作成しようとしています。ログインはターゲットサーバーにすでに存在します。次のSQLを使用します。

CREATE USER [MyLogin]
        FOR LOGIN [MyLogin]
        WITH DEFAULT_SCHEMA = dbo

GO

エラーが発生します：

エラー1SQL71501：ユーザー：[MyLogin]にログイン[MyLogin]への未解決の参照があります。

2つの解決策を見つけましたが、どちらも2013では機能しません。

1）ログインを参照するサーバープロジェクトを作成します。これは、SSDT/VS2013の現在のバージョンではオプションではありません

2）スキーマチェックを無効にします。 2013年にはこのオプションがありません（Options -> Database Tools -> Schema Compareだったと思います）

visual-studio-2013sql-server-data-tools
17
Turch

標準のT-SQL構文を使用して、SQLServerデータベースプロジェクト内にサーバーレベルのログインを実際に作成できます。

CREATE LOGIN [Login_Name] WITH PASSWORD = '<Password>';

注：データベースプロジェクトを右クリックして[新しいアイテムの追加]を選択し、[SQL Server]> [セキュリティ]（テンプレートダイアログ内）に移動して[ログイン（SQLServer）]を選択することもできます。

これにより、SQL71501エラーが解決され、（展開にSQLPackage.exeを使用していると仮定して）SQLPackage.exeは、展開と公開が行われる前にセキュリティオブジェクトをターゲットデータベースと比較できるようになります。

お役に立てば幸いです:)

34
Matt Woodward

サーバーにログインすることが保証されている場合、最善の策はマスターdacpacファイルを微調整することです。ここにこれを行う方法に関するいくつかの指示があります： http://sqlproj.com/index.php/2013/02/how-to-add-objects-to-master-dacpac

または、SSDT部分からログインへの参照を削除し、デプロイ後のスクリプトで処理することもできます。さまざまなサーバー（開発、QA、本番）にさまざまなアクセス許可を適用する必要がある環境がある場合は、それがより適切なオプションになる可能性があります。私はここでこれについてブログを書きました： http://schottsql.blogspot.com/2013/05/ssdt-setting-different-permissions-per.html

うまくいけば、それらの1つが役立つでしょう。私は実際に最初のオプションを使用して、EXECUTE ASを使用する必要があるという問題を回避しました。これには、ユーザーがプロジェクトに参加している必要があります。正確なXMLを取得するのは少し難しいですが、そのログインだけで空のプロジェクトを作成し、ビルドして、XMLをdacpacからマスターdacpacにコピーすることで回避しました。

2
Peter Schott