Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
roypython
Starting Member
7 Posts |
 Posted - 2008-05-13 : 18:06:56
|
| Hello,You help is very much appreciated.I have an Intranet environment that contains tens of apps that use a specific database.I want to create an Intranet test environment (which will use a test database), by basically copying the existing Intranet environment to a new location. * I cannot change the connection strings in the applications level since each app stores it differently (some store it in Web.Config, some hard coded, etc....).Then, have a layer that sits between the Intranet Apps and SQL SERVER (or inside SQL SERVER itself), that will intercept the connections requests.Once intercepted, the code will check if the connection request comes from Intranet Test environemnt, and if so, change the connection string on the fly to point to the test database.The question:Is there a way in SQL SERVER 2005, to intercept connections, and then, based on the application that requested the connection, modify the connection on the fly (so that if the calling app is from test_Intranet – intercept the connection and change it to point to a test database, otherwise leave the connection as it is (live database).Thank you,Roy |
|
|
rmiao
Master Smack Fu Yak Hacker
7266 Posts |
Posted - 2008-05-14 : 23:29:31
|
| You need middleware for that, sql server will not validate connection string. |
 |
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2008-05-15 : 02:03:47
|
| so, let me see if i have the idea here. You want to create a new test environment that consists of clones of your prod environment. You can't go in and modify web.configs or DSNs or whatnot to adjust for a new database location for some unknown reason. So you need a way to prevent the test environment from inadvertently modifying real prod data. so, basically this is bad all around. you realize that of course (i hope). Your proposed solution sounds complicated and hard to maintain if you could even implement it.One way to kinda solve your problem would be to create SQL Aliases on each of the web/app servers that will in essence redirect a request from SERVER-A to SERVER-B. look into the cliconfg utility or the SQL Server Configuration manager to create aliases.the problem is what if you forget to create an alias on one of your test environments. Or someone changes it, or the server is re-imaged and the alias is forgotten, etc. Then you are potentially jacking up your prod environment because your database redirection doesn't work.Maybe you could put some filters in place on your routers or a firewall or something to prevent your test subnet from being able to connect to the production databases. this becomes a pain though if you need to run a query or something between the environments.the best scenario with something like this is to have your landscape setup so that each tier is named appropriately so that there is no confusion with which system you intend to connect to. Also, the ability to easily change connection strings in your apps is a must. Your situation is a recipe for disaster otherwise.-ec |
|
|
|
|
|
|
|
|
Intercepting connections requests