Correct coding when parent path is disabled

[Dresden]

Hi all

I've moved from a dedicated server to a shared platform and now my includes for database connections don't work. I have lines like this:

<!--#include file="../connection.asp") -->

I've tried replacing it with all of these:

<!--#include file="/connection.asp") -->

<!--#include file="http://mywebsite.com/connection.asp") -->

and even:

<!--#include file=<%Server.MapPath("connection.asp")%> -->

- but nothing works. How can I reference a file in a different folder?

Grateful thanks for any help.

Paul

[awasson]

Hi Paul,
Find out if the host can provide a "data" folder and path for you. I've got an ASP site that has the data folder off of the wwwroot but I can still access it.

If that fails get them to set up DSN for the database. It won't be as quick as a physical path and you'll have to re-jig your connection screen but I'm pretty sure all Windows hosts provide DSN connections for MS Access.

Cheers,
Andrew

[Dresden]

Hi Andrew

Many thanks for your reply. I don't seem to have a problem with the connection string - that references the data file via Server.MapPath; it's just that I have a website with various parts in different folders, all referencing an Excel file in the root via an include called connection.asp. It was simple before to reference it with ../, but now this is not available, the alternative given by Microsoft should work (include virtual="/connection.asp"). trouble is, it doesn't.

I'm not sure how a data file outside the site would work; surely I'd still have to reference it upwards somehow?

I've worked around the problem for the time being by copying the database and the connection file into each folder! Crude, but effective...

Thanks again.

Paul

[awasson]

Yes, I've had trouble's with servers when they don't allow parent paths but I've usually been able to get the host to enable parent paths and everything is ok. Every site I've done with ASP requires parent paths for one reason or another so that is definitely a show stopper.

What I was referring to with DSN is the following. DSN stands for Data Source Name and it is basically a connection object that you can call instead of using a connection string that you would usually use to connect to a database.

The advantage of DNS is that it doesn't matter where the database is, you have a token that you can use to connect to it that doesn't rely on paths of any sort... The dissadvantage is that it is slower than a connection that relies on the physical path.

The following is a comparison of the two connection methods.... You would be creating recordsets and stuff after making the initial connections and then destroy the connection object once you've done whatever you need to do:

rem ------------------------------------------------
rem ---- TYPICAL DSN-LESS CONNECTION -----
rem ------------------------------------------------

connStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Server.MapPath("../../data/") & "/admin.mdb;Persist Security Info=False"
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open connStr

rem ------------------------------------------------
rem ---- TYPICAL DSN-TYPE CONNECTION -----
rem ------------------------------------------------

dsnStr = "DSN=DSNName" ' DSNName is the name that you or the web host associated with that database  
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open dsnStr

I don't know if this will help but if you can't get them to turn on parent paths, you could change the connection string to DSN and then rewrite the Connections to use DSN. The sure fire winning method would be for them to just configure parent paths though.

Andrew

[Doug G]

It sounds like you may need to use "include virtual="

http://www.w3schools.com/asp/asp_incfiles.asp

[itHighway]

Mostly servers allow Parent Path if requested by user.
If not that use

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

[siteguru]

and even:

<!--#include file=<%Server.MapPath("connection.asp")%> -->

Just posting to say that the above approach will never work ... #include directives are executed before any ASP code is parsed, so the <%...%> part will just look like an invalid address string.