views:

134

answers:

3

I ran across a new problem in the last week. Due to the nature of my project and available budget a small intranet web application I've been working on is both the testing and live server, as well as serves up the pages and is the sql server. This will last at least until the project is out of the major development cycle. Now that the project has real users but I am continuing development I duplicated the database to have a safe copy to mess with that won't cause havoc to live business data and a development copy of the website.

All was well until I discovered an anomoly on the test copy of the site, anything that uses a sql datasource was properly pulling it's data from the test database, but anything that gets it's data from a stored procedure triggered in the code behind was pulling it's data from the live databse.

My confusion comes from the fact that all stored procedures and sql datasources ultimately point back to the same connectionstring setting in the web.config file to know where to connect to. I just rename the database name depending on if I'm uploading the latest changes to the test or live site.

My question comes down to, why would with one connection string in each site would my test site accessing data one way get it from one database and accessing the other get it's data from the other database?

Here's my connection string they all point back to, names/passwords of course change for obvious reasons, but the structure is intact.

<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"/>

I added a key to the appsettings to reference the name of the database connection so I could easily change it's name if need be without having to edit dozens of pages for the code behind SProc calls.

<add key="defaultDB" value="db_Connection" />

Am I violating some rule I'm unaware of or is there something else going on that I need to be aware of and change so I can have a true test environment as I continue to develop an active site?

EDIT This project is in ASP.NET 2.0 VB, fixed the code display.

solution found I have tracked down the solution, thanks for the pointers, they got me looking elsewhere. When I copied the site to a different location for testing I forgot to update my appsetting key for the site's location, this caused the following part of the call for stored procedures to grab data from the live site's web.config aparently.

System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(pubvar_webConfig)
A: 

It may be worth running the two applications in different app pools via IIS (if you aren't already or course!). This should eliminate any concurrency issues between the test and production sites at the application level.

IMHO with a shared test / production environment seperate app pools is good practice at any time.

CodeBadger
+1  A: 

Change the username and password on the dev database. If your problem persists then you might have a connection string set somewhere else that you don't know about.

metanaito
A: 

I would search all of the files in your solution to make sure you don't have one of the database names hard coded some place. Maybe in the designer files?

David
Thanks for the suggestion, got me searching and caused me to realize I hadn't made one other needed change.

related questions