[thelist] storing connection strings in application variables

Warden, Matt mwarden at mattwarden.com
Thu Jan 24 10:01:23 CST 2002


On Jan 24, Chris Blessing had something to say about [thelist] storing...

>Forgive me if this is a rather complicated question.  Just to preface you
>I'm running IIS4/NT4 and using ASP/SQL Server.
>
>What I have is a development server and a live server.  Because the machines
>are different I have stored the connection string as an application-level
>variable (application("connStr")).  Depending on the serverNode application
>var (I have this stored in each server's global.asa), this connection string
>is setup with a different IP for the data source.  Within the db server
>we're using two databases, one called "orders" and one called "products".  I
>sometimes need to switch from one to the other depending on the page (like
>one page shows our products and one shows your order history, for example)
>and some pages end up using both.  I do this by calling a function I wrote
>to manipulate the "initial catalog" portion of the connection string and
>then opening the connection object as necessary.
>
>Now the issue I face is this:  should I be doing this on an application
>variable level?  If one user comes to the site while another user is on the
>site and requests an order page at the same time as the other user requests
>a product page, wouldn't that cause a "conflic of interest" in updating the
>connStr?  One person might get the page they want while the other gets an
>error (since the data source wasn't updated and that page explicitly uses
>that data source).  If I was to store the connection string in a session
>variable that would keep things separate on a user-by-user basis and
>eliminate this problem of cross-updating the connection string correct?

you're updating the same application variable on a per-user basis?

if so, yeah, that's no good. rudy might pipe up here and ask why you're
using two databases, so I'll leave that to him.

Now, I dont think session variables are the answer either. Try this on for
size:

/include/dataconn.asp
<%
function getConnString(p_iServerNumber)
	if (p_iServerNumber = 1) then
		getConnString = "...."
	elseif (p_iServerNumber = 2) then
		
	else
		getConnString = "invalid server"
	end if
end function
%>

then, you can do something like this:

oConn.open getConnString(1)

or, if you think it's more readable, change the argument to a string and
do something like this:

oConn.open getConnString("server1")

... but I was trying to avoid calling functions like lcase() to ensure a
good comparison

let me know if that doesn't do it for you or if i misunderstood your
situation.

hth,

--
mattwarden
mattwarden.com 
=





More information about the thelist mailing list