3

ここSqlPackage.exeで説明したように、Visual Studio 2012 の Microsoft SSDT からデータベースを同期するために使用できるので、SQL Server データベース プロジェクトに格納されている というソース データベース オブジェクトと一致するように、 というターゲット データベースを同期するために使用しています。TargetDbDbProject

コマンドのアクション/a:PublishによりSqlPackage.exe、DbProject の .dacpac ファイルを TargetDb に同期できますが、デフォルトの引数は、 DbProject に存在しない TargetDb のオブジェクトをドロップしません。

フラグ/p:DropObjectsNotInSource=trueをオンにするとこれは解決しますが、奇妙な動作も作成されます

  1. このフラグ/p:DropObjectsNotInSource=trueは、TargetDb にユーザー/ログイン オブジェクトをドロップしますが、これはまったく予期されていません! 私が見つけることができる最も近いものは です/p:DropRoleMembersNotInSource=false /p:DropPermissionsNotInSource=falseが、それらはあまり役に立ちません。
  2. フラグはフラグ/p:DropObjectsNotInSource=trueを壊します/p:BlockOnPossibleDataLoss=true。つまり、データ損失が発生した場合、更新アクションはブロックされません。それは私が望んでいるものではありません。

現在、TargetDb で「ゴミ箱」/冗長オブジェクトを受け入れる必要があります:(

私をそこに連れて行くために使用するより良いフラグは何ですか?

4

4 に答える 4

1

/p:DoNotDropObjectTypeソースにないドロップするタイプを指定できるパラメーターを使用してみてください。つまり、 DropObjectsNotInSourcetrue の場合

于 2016-09-02T12:18:35.220 に答える
1

私はここで同様の質問をし、データベース アップグレードのデプロイ後にユーザーを再作成するために、デプロイ後のスクリプトとしてユーザーをスクリプト化することになりました。

プロパティは/パーミッション DropPermissionsNotInSourceにのみ適用されます。役割のメンバーシップのためだけです。GRANTDENYDropRoleMembersNotInSource

DropObjectsNotInSource残念ながら、プロパティが true に設定されている場合、ドロップされるオブジェクトからユーザーを除外するオプションはありません。

また、デプロイ前のスクリプトで特定の変更 (列の種類の変更など) を行いBlockOnPossibleDataLossます。これにより、変更によってデータが失われない場合でも、デプロイを防ぐことができます。慎重すぎるより、慎重すぎる方がいいと思います。

于 2014-01-16T17:09:43.110 に答える