DSN different notation

[bvahan5]

i have a problem with moving ASP scripts from one local web server to another remote at Godaddy

my old notations were like this (#1)

strProvider="DSN=access_DB1"
set objConn = server.createobject("ADODB.Connection")
objConn.Open strProvider
set rst = Server.CreateObject("ADODB.recordset")

qry="SELECT recs FROM field1"
rst.Open qry, strProvider
recs=rst(0)
rst.close

Godaddy requires the following notation (#2):

dsn_name = "access_DB1"
sDSNDir = Server.MapPath("/_dsn")
connectstr = "filedsn=" & sDSNDir & "\" & dsn_name
set oConn = Server.CreateObject("ADODB.Connection")

qry = "SELECT recs FROM field1"
oConn.Open connectstr
Set oRS = oConn.Execute(qry)
recs=oRs.Fields("recs")
oRS.close

Both ways work fine:
#1 - for local server
#2 - for remote

The problems are:

(a) I don't want to make too many changes in the scripts
Is there a way to minimize the changes?

(b) I would like to be able to run same web site at local server (it means that I don't want too many changes to make, i.e. only in the initial settings;
also its OK for me to switch to a notation #2 on the local server as well, but I don't know how to do that - where to put/declare DSN ( Server.MapPath("/_dsn") )


Thanks for advices.

 

[DotNetGnat]

create a include file in which you declare the other two variables that you require...then you can include that file in all your asp pages...

-DNG

 

[bvahan5]

Each way # 1 and #2 has 2 parts.
Let's call the first part - a declaration.

The main problem is not a declaration change, but a second part.

I have hundreds of scripts with dozens of sql requests. It is a lot to change. Is there a way to make a new declaration so, that I will keep all (many hundreds) sql requests without change?

 

[Tarwn]

The second part isn't really necessary. They have no way of requiring for you to use the Connection.Execute method instead of Recordset.Open without actually looking through all of your code. They likely only includd that so that they wouldn't have to continually answer questions on how to get the recordset back after opening the connection.

That being said, the method they are using in their examople is actually more efficient. It is possible they siggest that method because it is the more efficient of the two. While there is no real requirement for you to change from using recordset.Open to Connection.Execute, you should consider usingthat method going forward as well as maybe changing any of your larger or longer running queriesto that method. There is a lot of overhead that is cut out of the picture when you let the connection object execute a query rather than let the recordset object handle it behind the scenes.

-T

 

[Sheco]

The default styles of DSN are "system" and "user" and with these the database connection information was historically stored in a file named ODBC.ini but now in modern systems it is stored in a registry key of that same name.

There is another type known as a "File DSN" and in this type all of the connection info is saved in a separate little text file.

As you can imagine, GoDaddy and other ISPs do not want the headache of maintaining your site's data in their system registry. It is easier to hit 99.9% up time if they are able to transparantly move user data from a malfunctioning physical server machine to a good one... so this is much easier when they can just copy all the files and not have to go searching the system for other dependencies.

So GoDaddy wants you to use a File DSN instead of a System or User DSN because they can manage the DSN file just like any other file.

You could also just use an ADO connection string instead of any DSN... for more info see

http://www.connectionstrings.com