2

私はこの状況を緩和するための最良の方法を見つけようとしています。私のプロジェクトチームは、それぞれ独自のSSRSインスタンスがインストールされている3人の開発者で構成されています。2台の外部SSRSサーバーがあり、お客様が確認してテストするために更新をプッシュする必要があります。3台目の外部サーバーがオンラインになり、管理されません。

共有データソースを、それが存在するシステムに関係なく現在の環境に設定する方法を見つけようとしています。ReportServerアドレスの一般的な命名規則だけで十分だと思っていましたが、運用サーバーとテストサーバーで一貫性がないことがすでにわかっています。次の試みは、ODBC接続を指定し、各ユーザーが接続情報を使用してシステムDSNを作成できるようにすることでしたが、1日中それをいじってエラーが発生し続けた後、それが正しい方法であるとは確信していません。(最新のエラーは「指定されたDSNにドライバーとアプリケーション間のアーキテクチャの不一致が含まれています」です)。Windows ODBC DSN mscを使用してDSNを作成しようとしましたが、Report Builder 3.0を使用してDSNを作成しようとしましたが、どちらも機能しないようです。

したがって、この時点で質問する必要があると思いますが、これを実行するためのベストプラクティスはありますか?レポートビルダー内の[実行]ボタンを使用してローカル開発とテストを行い、ファイルをレポートマネージャーにアップロードして、レポートサーバーのURLに関係なく機能させるようにします。

4

1 に答える 1

2

共有データソースのプロパティ(connectionstringなど)がサーバー上であまり変更されない場合は、次のことが機能する可能性がありOverwriteDataSources = Falseます。適切な構成に設定されたプロジェクトのプロパティ。必要に応じて、データソースを変更するために一時的にのみtrueに設定します。

そうすれば、個人の環境に合わせてローカルで何か(接続文字列など)を変更した場合でも、開発者はデータソースに影響を与えることなく、サーバーに安全にデプロイできます。

最適なソリューションではありませんが、セットアップは比較的簡単です。

于 2012-08-29T11:55:43.577 に答える