2

構成タイプが (間接 XML 構成ファイル) であるパッケージ構成をセットアップしました。C:\SSIS\MasterConfig\MasterConfig.dtsConfig環境変数がファイルを指している場所。

これはうまく機能し、テストから UAT、本番環境への簡単な移行を可能にします。

問題は、各開発者が独自の DB を持つ開発環境にあります。エージェント ジョブがマスター構成ファイルをオーバーライドする各開発者用のエージェント ジョブを設定しようとしています。エージェント ジョブのコマンド ラインは次のとおりです":

/FILE "C:\SSIS\Packages\Developer1\LoadPackage.dtsx" /CONFIGFILE "C:\SSIS\Packages\Developer1\Developer1_Config.dtsConfig" /X86 /CHECKPOINTING OFF /REPORTING E

2008 R2 を使用しています。

C:\SSIS\MasterConfig\MasterConfig.dtsConfig ファイルの代わりに /CONFIGFILE "C:\SSIS\Packages\Developer1\Developer1_Config.dtsConfig" が使用されることを期待していました。

マスター構成ファイルのみが使用されています。何か案は？

4

2 に答える 2

0

発生している問題は、Integration Services パッケージの構成アプローチの定義で説明されています。基本的に、コマンド ライン構成は適用されますが、設計時の値によって上書きされます。

あなたの解決策がどうなるかはわかりません。ここでは、複数インスタンス化されたボックス (dev と test が物理ホストを共有) を処理する必要があったことを除いて、ほぼ同様の状況です。これを回避するために、環境変数ビットをスキップし、設計時の値が常に dev を指すようにしました。テスト、UAT、および PROD は SQL エージェント経由でのみパッケージを実行するため、ジョブは構成リソースへの接続文字列を明示的に定義します。あなたのシナリオは逆のシナリオですが、設計時の値は開発以外のどこでも問題ありません。

于 2012-05-30T19:05:41.653 に答える
0

これが私たちの仕事です。

すべての変数は、Production、QA、Dev (またはローカル) を指しているかどうかに関係なく、同じ名前が付けられています。変更するのは、構成ファイルを指す変数値です。

各ボックスの適切な接続情報をすべて含む構成ファイルを作成します。そのため、データベースごとに少なくとも 3 つの個別の構成ファイルを用意します。DB_Prod.config、DB_QA.config、DB_Dev.config、DB_Joe_local.config という名前を付けます (ローカル db.config を指す名前が必要な場合)。

次に、変数を適切な環境に設定する .bat ファイルを作成します。QA 用、開発用、ローカル環境用の 3 つの異なるものがあります。

環境変数は、DB1_adonet、DB1_ole、AS400 などのように名前が付けられています。QA、prod などは示されていません。

設定するのは少し面倒ですが、使い始めると、唯一の問題は、自分がどの環境に設定したかを思い出すことです. また、値がキャッシュされるため、環境の変更間で dev studio を開いたり閉じたりする必要があることを覚えておく必要があります。また、たまたまパッケージ localy を実行すると、実行元のボックスではなく、環境変数の値が使用されます。

最後に、すべての構成ファイルを TFS にチェックインしました。ファイルの配布を容易にします。

于 2012-05-31T23:41:39.093 に答える