先週、新しい問題に出くわしました。私のプロジェクトの性質と利用可能な予算のために、私が取り組んできた小さなイントラネット Web アプリケーションは、テスト サーバーとライブ サーバーの両方であり、ページを提供し、SQL サーバーでもあります。これは、少なくともプロジェクトが主要な開発サイクルを終了するまで続きます。プロジェクトには実際のユーザーがいますが、開発を続けています。データベースを複製して、ビジネス データと Web サイトの開発コピーに混乱を引き起こさない安全なコピーを作成しました。
サイトのテスト コピーで異常を発見するまではすべて順調でした。SQL データソースを使用するものはすべて、テスト データベースからデータを適切に取得していましたが、コード ビハインドでトリガーされたストアド プロシージャからデータを取得するものはすべて、それを取得していました。ライブデータベースからのデータ。
私の混乱は、すべてのストアド プロシージャと SQL データソースが、接続先を知るために web.config ファイル内の同じ接続文字列設定を最終的に指すという事実に起因しています。最新の変更をテスト サイトまたはライブ サイトにアップロードするかどうかに応じて、データベース名の名前を変更するだけです。
私の質問は、各サイトに 1 つの接続文字列があると、テスト サイトが一方のデータベースからデータを取得し、もう一方のデータベースからデータを取得する方法でデータにアクセスするのはなぜですか?
これが私の接続文字列です。名前/パスワードはもちろん明らかな理由で変更されますが、構造はそのままです。
<add name="db_Connection" connectionString="Data Source=SERVERNAME;Initial Catalog=DATABASE_live;Persist Security Info=False;User ID=USERID;Password=password" providerName="System.Data.SqlClient"/>
データベース接続の名前を参照するキーを appsettings に追加したので、必要に応じて名前を簡単に変更でき、SProc 呼び出しの背後にあるコード用に何十ページも編集する必要がありませんでした。
<add key="defaultDB" value="db_Connection" />
私が気付いていない規則に違反しているのでしょうか、それとも、アクティブなサイトを開発し続けるときに真のテスト環境を用意できるように、認識して変更する必要がある何かが起こっているのでしょうか?
EDITこのプロジェクトは ASP.NET 2.0 VB で、コード表示を修正しました。
解決策が見つかりました 解決策を追跡しました。ポインターのおかげで、他の場所を探すことができました。テストのためにサイトを別の場所にコピーしたとき、サイトの場所の appsetting キーを更新するのを忘れていました。これにより、ストアド プロシージャの呼び出しの次の部分が明らかにライブ サイトの web.config からデータを取得しました。
System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(pubvar_webConfig)