問題タブ [dacpac]

SSDT2012 を使用してデータベース プロジェクトを展開しています。入力したい静的データがありますが、それは .csv ファイルにあります。プロジェクトに追加しましたが、サーバーの一時フォルダーなどにコピーする方法がわかりません。追加してみました

助けてくれてありがとう！

編集: Deployment Contributorsを見てきましたが、まだ解決策ではありません。実際に全員に Contributor を自分のマシンにコピーしてもらい、それを維持してバグを修正する必要があります。これは望ましいアプローチではありません。

SqlPackage.exeデータベースを更新するために実行しようとしている PowerShell スクリプトを使用しています。問題は、新しい CMD ウィンドウが生成され、出力を効果的にキャプチャできないことです。

これが私のスクリプトです：

どこでSqlPackage = "SQLPackage\SqlPackage.exe";。

不思議なことに、Windows 2008 R2 Web サーバーでスクリプトを実行すると、出力が PowerShell 出力と一致します。私の Windows 7 マシンでは、新しい CMD ウィンドウが生成されます。

出力を常に PowerShell ウィンドウにルーティングするか、少なくとも別のファイルにパイプするにはどうすればよいですか?

編集

プロセスが完了するのを待つ完全なソリューション:

今日、私は多くのリファクタリングとクライアント マシンへの公開を必要とする、非常に厄介な DB を持つプロジェクトを維持しています。

データベースのスクリプトだけを含むSQL Server データベースプロジェクトを追加し、.dacpacクライアント データベースを自動的に変更できるようにするファイルを作成できることはわかっています。

また、フォルダーに.mdfファイルを追加するだけで、そこにデータベースを作成できることも知っています。既に存在するため、SQL Server なしでソリューションを起動できると思いますApp_DataSolution_DatalocalDb

そして最後に、エンティティフレームワークが独自の移行とともに存在することを知っています。しかし、私はそれを使用したくありません。なぜなら、移行でインデックスを追加および変更することができず、困難な移行シナリオを説明する必要があるときに柔軟性が足りないからです。

私の目標：

1. クライアント DB への移行スクリプトを自動的に生成します。
2. プロジェクトに参加した新しいプログラマーが自分のマシンに SQL Server をインストールする必要さえないように、私のソリューションを自己完結型にします。
3. 1 ～ 2 回のクリックでローカル (開発) ベースを更新できます。
4. データベースの変更履歴をさかのぼることができます (私は TFS サーバーを持っています)
5. 最新の DB スキームを使用して、ソリューションにクリーンな (辞書またはルックアップ テーブルを使用する場合のみ) db を含めることができます。
6. さらに、DB モデル ( EFまたは.dbml) を自動的に、または非常に簡単な方法で更新できるようにしたいと考えています。

だから私は何を尋ねるべきか：

• 目標を達成したい場合、この 2 つのアプローチを使用することの長所と短所は何ですか?

• このツールを組み合わせて使用​​する必要があるのでしょうか。

• または、MS の他の既存のツールについて知りませんか?

• この DB からDALモデルを更新する方法はありますか?

DB または DB プロジェクトから生成された dacpac ファイルがあります。この dacpac にはもちろん、テーブル、ストアド プロシージャ、ビューなどが含まれています。

dacpac のすべてのオブジェクトではなく、一部のオブジェクトだけを使用して新しい DB を作成したいと考えています。私の場合、オブジェクト、テーブルのリストがあります。

dacpac オブジェクトから無視するか、オブジェクトのサブグループだけで別の dacpac を作成するか、またはターゲット オブジェクトの対応する SQL スクリプトを抽出するかを知りたいです。

これに関するアドバイスはありますか？ありがとう

以下は、ターゲット SQL インスタンスにデータベースをデプロイするために dacpac を作成している、私のデータベース プロジェクトの正確なシナリオです。

• データベース プロジェクトには、CLR アセンブリの参照があります。
• TFS ビルド サーバーを使用してプロジェクトをビルドします。
• TFS ビルド プロセス中に dacpac が作成される

– sqlpackage.exe を実行して dacpac (TFS ビルド プロセスで生成されたもの) を環境にデプロイしようとすると、次のエラーが表示されます –</p>

*** XXXX.XXXX.XXXX.dll を参照するためのファイルが提供されていません。デプロイが失敗する可能性があります。C:\Temp\Dacpac_testing\XXX.XXXXX.XXXX.dacpac が作成されたとき、元の参照ファイルは C:\BUILDS\1\XXXX\XXXX\SRC\XXXXXXXX\ASSEMBLIES\XXXX.XXXX.XXXX.dll にありました。

デプロイ環境で CLR アセンブリのパスを参照する dacpac を作成するにはどうすればよいですか (dacpac のビルド時に使用されたものではありません)。

これに関するヘルプは大歓迎です。

Microsoft の Release Management Server for Team Foundation Server 2013 v12.0.31101.0 を使用すると、エラーが発生し続けます (後述)。ただし、ローカル マシン、ビルド サーバー、およびターゲット SQL Server から sqlpackage コマンドを正常に実行できます。

実行した手順:

• dll と sqlpackage.exe を取得しC:\Program Files (x86)\Microsoft SQL Server\120\DAC\binて、デスクトップのフォルダーにコピーしました。
• Release Management で、次のコマンドを使用して新しいツールを作成しました。sqlpackage.exe /Action:Publish /SourceFile:__FileName__ /TargetDatabaseName:__DatabaseName__ /TargetServerName:__ServerName__
• 次に、前の手順で作成したフォルダーから dll と SqlPackage.exe を追加しました
• 保存して閉じます
• 次に、基本的にこのツールをラップするだけの新しいコンポーネントを作成しました (ビルド ドロップの場所は、dacpac がビルド フォルダーのルートにあることを示すバックスラッシュです)。
• 次に、作成したツールを選択すると、すべてが入力されました。コンポーネントを含めて使用するようにリリース テンプレートを更新しました

作成したフォルダーを任意のデスクトップに置くと、次のコマンドを実行でき、完全に実行されます

ローカル PC、ビルド サーバー、および SQL Server 自体からこれを実行しましたが、Release Management を使用するとエラーが発生します。

エラー:

更新 1: Release Management からのエラー メールで、SQL Server がコマンドで正しく指定されていたにもかかわらず、ターゲット サーバーが SQL Server ではなく Web サーバーであることに気付きました。Web サーバーのログを確認したところ、エラーが見つかりました。dll のフォルダーをデスクトップにコピーしてスクリプトを実行したところ、エラーを再現できました。コントロール パネルでインストールされているプログラムを確認したところ、インストールされている Transact-SQL ScriptDom のバージョンが 2012 用で、バージョン 11.0.2100.60 であることがわかりました。そこで、ここに SSDT をインストールしました。Visual Studio がインストールされていないため、インストールは失敗しましたが、12.0.2000.8 バージョンの Transact-SQL ScriptDom と関連する dll をインストールできました。スクリプトを再度実行すると、データベースが正常に公開されました。しかし、Release Management からビルドしようとすると、新しいエラーが発生しました。

更新 2 : この時点で失敗した理由は、ビルド サーバーが使用していたアカウントが SQL Server へのログイン アカウントを持っていなかったためであることを確認しました。アカウントを追加し、対象のデータベースで ddladmin および securityadmin 権限を付与しました。これにより、新しいユーザーを作成できないという新しいエラーが発生しますが、少なくとも近づいています。

最終更新: アカウントがログインを作成できるように、sysadmin も付与する必要がありました。これにより、RM での展開手順が成功しました。公開プロファイルまたはコマンド フラグを使用して、セキュリティ オブジェクトを使用して dacpac が作成されないようにし、最小限の特権で実行できるようにします。

RM を SQL 2014 に展開する際の問題は解決されました。主な問題はリリース テンプレートにあり、DACPAC コンポーネントを Web サーバーの残りのビルドとインラインで配置しました。これにより、DACPAC コマンドが Web サーバーから実行されます。これを機能させるには、SSDT を Web サーバーにインストールする必要がありました。私はこれが気に入らないので、おそらくリリース テンプレートを再配置して、Web サーバーと SQL サーバーが並列になるようにしますが、同じロールバックの下にネストされます。

Web アプリケーションを IIS にデプロイするたびに dacpac を自動的に公開する方法を検討しています。

これらの方法の 1 つは、dbDacFx プロバイダーを使用して、Web Deploy 自体を使用することです。参照: http://www.iis.net/learn/publish/using-web-deploy/dbdacfx-provider-for-incremental-database-publishing

2 つのデータベースを同期するために彼らが提供する例のいくつかは、次のようになります。

私の質問は、一体なぜこれに SqlPackage.exe を使用しないのでしょうか?

私が知る限り、Web Deploy はテーブルに新しいものをもたらしません。dbDacFx プロバイダーが存在するのはなぜですか?

私がすでに検討したこと：

• Web 配置の dbDacFx は、配置をトリガーするマシンではなく、アプリケーション サーバーで実行されます。
  • 管理者以外のデプロイは、wmsvc 委任ルールによって可能です (しかし、なぜ例では統合セキュリティの代わりに「sa」を使用しているのですか?)
• msdeploy.exe と SqlPackage.exe はどちらも、xml 構成によるパラメーター化をサポートしています。