Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Include files

Status
Not open for further replies.

elpanther

Programmer
Jun 28, 2004
4
US
We have a bit of an issue that we need to find a work around for. We have 2 environments on the same server (Dev, Test). Since they are on the same server the db connection names are different (putting the environments on different servers is not an option). The issue is that we have to change the virtual includes to match the connection every time we transfer a file. As you can imagine this could cause some issues.
Does anyone know of a way to dynamically change the include file or any other work around for this issue. We can't be the only ones (I hope).


"The difference between genius and stupidity is genuis has a limit!
 
by environment do you mean sub-domains ?

dev.hostname.tld & test.hostname.tld

I don't quite see why you need to change virtual includes to match the connection? do you not use relative addresses and the same structure on both sites

why do the connection names have to be different? if you are looking at different databases for each site you simply have one include file on each site (named the same) and the different DB details in those files. That way the db info is correct for either site with no editing needed.


I guess some code is needed to actually see what you are doing.

Chris.

Indifference will be the downfall of mankind, but who cares?
Woo Hoo! the cobblers kids get new shoes.
People Counting Systems

So long, and thanks for all the fish.
 
If I understand you correctly:

Seems to me you can write up 2 different include files, one that contains the connection string for the developement environment and the other for the test environment.

just have an 'if' at the top of each page that needs a connection that can distinguish between what environment you are in. (There has to be something different)

pseudocode example:

Code:
if in test environment
   test connection string
else
   developement connection string

As long as each connection string and recordset have the same variable names, there should be no problem.




[monkey][snake] <.
 
not even that complex, no if then logic needed

inc_db_conn.asp (on dev site)
Code:
<%
dbConn = devConnString or devDSN
dbPass = "devPassword"
dbUser = "devUser"
%>

inc_db_conn.asp (on test site)
Code:
<%
dbConn = testConnString or testDSN
dbPass = "testPassword"
dbUser = "testUser"
%>

main pages (on either site)
Code:
<%
dim dbConn
dim dbPass
dim dbUser
%>

<!--#include virtual="/path/inc_db_conn.asp" -->

<% 
'more code to use the database etc

%>

No need to edit anything when you upload a page it simply includes the correct DB details for the site it is on.
Use the same method for any thing that is common but different to each site

but maybe we've got the wrong tree to be barking up and it's something completely different :D



Chris.

Indifference will be the downfall of mankind, but who cares?
Woo Hoo! the cobblers kids get new shoes.
People Counting Systems

So long, and thanks for all the fish.
 
I guess I didn't explain it correctly. Here is some additional detail:
There are 2 different DB on the same server. Dev_db and Test_db. Since they are on the same server the ODBC connection names have to be different.
In the code we have something like:
include virtual="/web_root_dev/connections/conn.asp"
for the dev environment and
include virtual="/web_root_test/connections/conn.asp"
for the test.

The problem is that when we transfer from dev to test we have to change the /web_root_XXX/ directory.
Putting an if statement in the conn.asp page doesn't solve the issue.
The problem is that we have to start at the root folder to navigate to the actual file. Depending on the server that folder is different. We need to account for that somehow.
Hope that makes better sense.



"The difference between genius and stupidity is genuis has a limit!
 
Putting an if statement in the conn.asp page doesn't solve the issue.

The if statement would be put in every asp file that uses the include file 'conn.asp', not put in conn.asp itself.

I know this works, its just a matter of if you want to go through every asp file that includes conn.asp and changing it accordingly.

[monkey][snake] <.
 
or how to make things difficult.
for dev, production & test servers the folder structure should be identical otherwise you are going to run into problems like this all the time.

I run several live sites and dev sites all running the same code on the same server looking at different databases on a different server and use the method I outlined in my second post with no problem whatsoever.

otherwise you are left with using the if...then construct and having a global include (or an application variable in global.asa, bit of overkill there though) that sets a constant to determine which site the code is in.
But even there if the structures are different that cannot work either.

You cannot use variables in include paths because of the way ASP works.
So it's either carry on as you are or make the folder structure help you.
BTW Future maintenance will be a real pig if you carry on as you are.


Chris.

Indifference will be the downfall of mankind, but who cares?
Woo Hoo! the cobblers kids get new shoes.
People Counting Systems

So long, and thanks for all the fish.
 
I'm in no way saying your way does not work ChrisHirst. In fact, it's a way better suggestion than I said. I just wanted elpanther to understand what I said.

[monkey][snake] <.
 
It's good this isn't it

My post about it making it difficult wasn't for your answer, it was for the OP in the post above yours

Both methods are equally useful and appropriate, I use the method I outlined because I test the same script code side by side on different sub domains on my dev server looking at different DB servers, so I often need a very quick way of dropping edited scripts into a different DB environment without needing to change anything else.


Chris.

Indifference will be the downfall of mankind, but who cares?
Woo Hoo! the cobblers kids get new shoes.
People Counting Systems

So long, and thanks for all the fish.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top