問題タブ [data-tier-applications]

序文

データ層アプリケーションプロジェクトとSQLCLRデータベースプロジェクトを使用して、アプリケーションのデータベース部分を管理しています。
データベース部分をインストールする必要がある3つの異なるマシン（ローカル、dev / ci / qa、およびそれに応じてpreprod / prodデプロイメント環境用）があります。
PostDeploymentスクリプトで、CLRストアドプロシージャ（アセンブリを使用）とログインおよびユーザーを作成します。
ログインとユーザーは、構成によって異なる必要があります。

問題

変数の使用に問題があります。これが私が試したPostDeploymentスクリプトです

と

ログイン、ユーザー（AddLoginsUsersRolesDev.sql）を追加する方法は次のとおりです。

PostDeployment.sqlの場合、アクションはPostDeployであり、SQLCMDモードがオンになっています。インクルードスクリプトの場合、アクションはビルドに含まれていません。
「SQL実行エラー：致命的なエラーが発生しました。変数MSBuildProjectDirectoryが見つかりませんでした」で展開が失敗しました。
私がデータベースプロジェクトで知っている限り、私はこの目的のためにDatabase.sqlcmdvarsを使用することができます。この問題をどのように解決すればよいですか？

アップデート

私は追加しました

.dbprojファイルに追加し、Database.sqlcmdvarsを作成しました。

これは機能しません。

私は追加しました

これも機能しません。

私は追加しました

これも機能しません（どこかで、可能性のあるMSBuild変数がsqlcmdと同じ名前で存在するはずだと読んだことがあります）。

PostBuildEventセクションの前にSqlTask​​s.targetsプロジェクトのインポートを移動しました。
前：

後：

これも機能しません。

ありがとう。

Visual Studio のデータ層プロジェクトで新しい SQL Server ツールを使用しています。スナップショット (.dacpac) を作成し、それを管理スタジオの SQL Server インスタンスにデプロイしようとしましたが、次のエラーが発生します。手がかりはありますか？

私の dacpac ファイルと SQL Server はすべてローカルです。

VS2010 SP1データ層アプリケーションプロジェクトを使用して、次のような最も単純なデータベースを作成しました。

CREATE TABLE [dbo].[Table1] ( column_1 int NOT NULL, column_2 int NULL )

次に、.dacpacを正常にビルドし、SSMS 2008R2を使用してローカルSQLExpressインスタンスに展開することで検証しました（すべて正常に機能しました）。

次に、SSMS 2008 R2を使用して、.dacpacをSQLAzureサーバーに展開してみました。ウィザードはすべてのステップ（データベースの作成とスキーマの作成を含む）をなんとか完了しましたが、最後のステップである「DACメタデータへのDACの登録」でIndexOutOfRangeException（以下を参照）で失敗しました。

これを、既存のSQL Azureサーバー、新しいSQL Azureサーバー（どちらも同じ例外で失敗する）、および同じ名前の空のデータベースを持つSQL Azureサーバー（これはSSMSランタイム例外で失敗する）に対して実行しようとしました。 ）。

私は今アイデアがありません。.dacpacsをSQLAzureに展開する方法に関するアイデアをいただければ幸いです。

System.IndexOutOfRangeException：インデックスが配列の範囲外でした。Microsoft.SqlServer.Management.Smo.SqlPropertyMetadataProvider.PropertyNameToIDLookupWithException（String propertyName、PropertyAccessPurpose pap）at Microsoft.SqlServer.Management.Smo.SqlSmoObject.GetDbComparer（Boolean inServer）at Microsoft.SqlServer.Management.Smo.SqlSmoObject.InitializeStringComparer（）at Microsoft.SqlServer.Management.Smo.SmoCollectionBase.get_InternalStorage（）のMicrosoft.SqlServer.Management.Smo.SimpleObjectCollectionBase.InitInnerCollection（）のMicrosoft.SqlServer.Management.Smo.AbstractCollectionBase.get_StringComparer（） SmoCollectionBase.GetObjectByKey（ObjectKeyBase key）at Microsoft.SqlServer.Management.Smo.DatabaseCollection.get_Item（String name）atMicrosoft.SqlServer。

アプリケーションデータ層では、データ交換のためにストアドプロシージャとWebサービスに完全に依存しています。ストアドプロシージャを実行するために、ページのロードで以下のようなコードを使用します

上記のコード（クラスファイル内にある）を何らかの形式の構成ファイルに削除する方法を探しています

1. 取得（読み取り、解析など）と保存（書き込み、変更など）が非常に高速なファイルストレージ形式を探しています

2. その上にセキュリティレイヤーを実装できます

3. 多くの手間や既存のコードへの大きな変更なしにこれを達成します。

DAC Fx と宣言型データベース開発の使用に飛躍することに興奮しています。私にとっての大きな障害は、複数の異なるバージョンのスキーマ間で複雑なデータ移行を処理する方法です。以前は、すべてのアップグレード スクリプトを順番に実行するだけで済み、データ移行時にスキーマが正しい状態にあることが保証されていました。アップグレード パスが動的な場合、これはどのように機能しますか?

たとえば、既存のインスタンスにいくつかのバージョンのスキーマ (DACPAC1-4) があるとします。

• DACPAC1: tableA が存在し、重要なクライアント データが含まれています
• DACPAC2: tableA は廃止され、tableB と正規化された tableC に置き換えられました。新しい tableD を追加します
  • 配置後スクリプト: データを tableA から新しい tableB および tableC に移動します。ドロップテーブルA
• DACPAC3: tableC に新しい null 許容 columnX がある
  • デプロイ後スクリプト: tableD に基づいて null 許容列を設定します
• DACPAC4: tableC.columnX は null 非許容です

DACPAC1 ～ 3 サーバーの最新の DACPAC4 へのアップグレードをサポートできるようにする必要がある場合、どの DACPAC が現在ターゲット上にあるかを検出し、データ移行を正しく処理するのに十分なほど巧妙な方法で、展開前および展開後のスクリプトを作成する必要があります。順番にステップします。さらに、最初に作成した単純なデプロイ後のスクリプトを単純に再利用することはできません。これらのスクリプトはスキーマの中間バージョンに依存しているためです。

アドバイスをよろしくお願いします！

SQL Azure データベースにデプロイするときのデータ層アプリケーション (DACPAC) のアップグレードに関して質問があります。ウィザード UI を使用して DACPAC を手動でアップグレードする場合、データ損失警告レポートを確認し、アクション レポートを HTML ファイルに保存する手順があります ( 「アップグレード計画ページの確認」の下のこちらを参照してください)。[アクション] 列には、アップグレードを実行するために実行される Transact-SQL ステートメントなどのアクションが表示されます。関連付けられたアクションによってデータが削除される可能性がある場合は、[データ損失] 列に警告が表示されます。

現在、Powershell を使用してデータベースのアップグレード プロセスを自動化していますが、これはこれまでのところ問題なく動作しています。残念ながら、同じデータ損失警告レポートを生成する方法が見つかりませんでした。

私の Powershell アップグレード スクリプトの抜粋を以下に示します。

によって生成されたDatabaseChanges.txt出力ファイルGetDatabaseChanges()はあまり参考になりませんでした。そのため、アップグレード ウィザードを手動で実行した場合と同じレポート ファイルを取得する方法があるかどうか疑問に思っています。このレポートは、展開チームがデータ移行の問題を解決する際に非常に役立ちました。実際の運用データベースに展開するときに手動で調査できるようにしたいと考えています。

MSDN のドキュメントを検索しましたが、うまくいきませんでした。この機能が Powershell 展開でサポートされているかどうかは誰にもわかりませんか? これは近い将来サポートされる予定ですか？

事前にご協力いただきありがとうございます。

SQL Server を使用したデータ中心のアプリケーションがあります。それが展開される環境は私たちの管理下になく、そこには DBA がいません (彼らはすべて中小企業です)。そのため、各アプリケーション/データベースの更新の配布プロセスを可能な限り自動化する必要があります。

アプリケーションのバージョン間の通常の変更 (予測できない場合があります) に加えて、各バージョンで新しいシード データを配布する必要があることは既にわかっています。このシード データは、システム内の他のデータに関連する場合があります。たとえば、v2 から v3 への更新プロセス中に一部のマスター データの 2 つの新しい行を挿入し、v5 から v6 への更新プロセス中に他の 5 行を挿入する必要があるかもしれません。

EF

Entity Framework Db Migrations (4.3.1 リリース以降の Code-First のない既存のデータベースで利用可能) を確認しました。これは、従来のシーケンシャル スクリプトをより自動化され制御された方法 (Fluent Migrations など) で表します。

SSDT

一方、別の考え方で、SSDT とその dacpacs、スナップショット、デプロイ前後のスクリプトを確認しました。

質問は次のとおりです。

1. これらの技術/哲学のうち、説明されているケースにより適切なものはどれですか?

2. 他に使用できるテクノロジー/哲学はありますか?

3. 他にアドバイスはありますか？

前もって感謝します。

VS 2010 用の SQL Server 2012 データ層アプリケーション テンプレートはありますか? 私が使用しているテンプレートのバージョンでは、SQL Server 2008R2 のみが許可されます。

SQL Server 2012 で管理コンソールを開いて DAC パッケージを抽出すると、それが機能し、パッケージが作成されます。ただし、VS はパッケージのインポートを許可しません。次のエラーが表示されます。「指定したファイルは、有効なデータ層アプリケーション ファイルではありません。有効なファイルを指定してください。」

DacUpgradeOptions.IgnoreDataLoss自動データ層アプリケーション (DACPAC) アップグレードでプロパティを設定するベスト プラクティスは何ですか?

MSDN のドキュメント (リンク) に基づいて、IgnoreDataLossがTrueの場合、一部の操作でデータが失われた場合でもアップグレードが続行されます。Falseの場合、これらの操作によってアップグレードが終了します。たとえば、現在のデータベースのテーブルが新しい DAC のスキーマに存在しない場合、True が指定されている場合、そのテーブルは削除されます。このデフォルト値はTrueです。

ただし、すべてのデータベースの変更が自動的にパイプライン (CI -> テスト -> UI-テスト) に展開され、最終的に運用環境に展開される継続的デリバリーの環境では、設定する安全対策IgnoreDataLossはFalseであるように思われます。本番データベースでデータの損失やドリフトが発生することは望ましくありません。がFalseIgnoreDataLossで、開発者がデータ損失をもたらすデータベース変更をコミットすると、CI/テスト ビルドは失敗し、この変更が本番環境に到達する前にこれをキャッチできます。

ただし、データの損失が意図的に行われる場合があるため、このアプローチには問題があります。たとえば、使用されなくなった特定のテーブルを削除する必要がある場合があります。IgnoreDataLossがFalseの場合、ビルドは失敗し、DACPAC の変更は適用されません。これは、潜在的なデータ損失が検出されるためです (そのような損失が意図的であっても)。このシナリオでは、 TrueIgnoreDataLossになりたいと思います。

特に、継続的かつ自動的に展開している環境では、これに対するベスト プラクティスは何でしょうか。どんな提案でも大歓迎です。ありがとう！

DAC のバージョンの追跡に問題があります。データベースの現在のバージョンを確認できませんでした。幸いなことに、次の投稿を見つけました: SQL Server データ層アプリケーションの現在のバージョンを見つけるにはどうすればよいですか?

2 番目の回答でうまくいきました。現在、SQL ステートメントを使用して現在のバージョンを確認できます。

これで、現在のバージョンと新しい dacpac のバージョンを確認できますが、非常に醜い方法です。私はまだいくつかの質問/不確実性があります.

1. 何らかの理由で、SSMS の管理下にデータ層アプリケーションが表示されません。私は SQL 2008 R2 についてこれに関する議論を始めただけなので、SQL 2012 で放棄されたのか、何か間違ったことをしたのかはわかりません。

2. SSMS でデータ層アプリケーションをアップグレードする場合、アップグレード ウィザードの概要ステップに到達したときに dacpac バージョンしか表示されません。[パッケージの選択] ステップで新しい dacpac を選択すると、選択した dacpac のバージョンと説明が以下のウィザードに表示されるはずですが (多数のチュートリアルで説明されているように)、何も表示されません。要約ステップでも、これらのチュートリアルで見つけた画像によると、2008 R2 の場合の現在の DAC データベースのバージョンを確認できません。

3. 現在のバージョンと新しいバージョンを同じ場所に表示するなど、これよりも少し優れたバージョン比較を処理する方法はありますか? dacpac を使用して同じバージョン番号またはそれより低いバージョン番号でアップグレードしようとしている場合に警告を表示する方法はありますか?

どうも

マルコ