0

先週、新しい問題に出くわしました。私のプロジェクトの性質と利用可能な予算のために、私が取り組んできた小さなイントラネット 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)
4

3 に答える 3

1

dev データベースのユーザー名とパスワードを変更します。問題が解決しない場合は、知らない場所に接続文字列が設定されている可能性があります。

于 2009-02-20T00:24:54.783 に答える
0

IIS を介して異なるアプリケーション プールで 2 つのアプリケーションを実行する価値があるかもしれません (まだまたはコースでない場合)。これにより、アプリケーション レベルでのテスト サイトと本番サイト間の同時実行の問題が解消されます。

共有テスト/運用環境の個別のアプリ プールを使用した IMHO は、いつでも良い方法です。

于 2009-02-20T00:19:41.507 に答える
0

ソリューション内のすべてのファイルを検索して、どこかにハードコードされたデータベース名がないことを確認します。多分デザイナーファイルに？

于 2009-02-20T00:27:47.633 に答える