Conn as session var?

[Des Perado]

I have just tried this, and it works:

Global.asa contains:

sub Session_OnStart
set Session("conn")=Server.CreateObject("ADODB.Connect ion")
dsntemp="driver={sql Server}; server=master1; database=db1; uid=sa; pwd=;
dsn=;"
session("conn").Open dsntemp
end sub

and in any asp:

sql="select * from table1"
set rs=session("conn").execute(sql)

As I say, it works.

But is there any reason we shouldn't do this? Is it bad?

TIA

[Bob Barrows [MVP]]

Des Perado wrote:

I have just tried this, and it works:

Global.asa contains:

sub Session_OnStart
set Session("conn")=Server.CreateObject("ADODB.Connect ion")
dsntemp="driver={sql Server}; server=master1; database=db1; uid=sa;
pwd=; dsn=;"
session("conn").Open dsntemp
end sub

and in any asp:

sql="select * from table1"
set rs=session("conn").execute(sql)

As I say, it works.

But is there any reason we shouldn't do this? Is it bad?

Extremely.

http://www.aspfaq.com/2053

Bob Barrows

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[Des Perado]

"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcom> wrote in message
news:u3**************@TK2MSFTNGP10.phx.gbl...

But is there any reason we shouldn't do this? Is it bad?

Extremely.

http://www.aspfaq.com/2053

Bob Barrows

Whoops! I see.
Many thanks Bob.

[Bob Barrows [MVP]]

Des Perado wrote:

I have just tried this, and it works:

Global.asa contains:

sub Session_OnStart
set Session("conn")=Server.CreateObject("ADODB.Connect ion")
dsntemp="driver={sql Server}; server=master1; database=db1; uid=sa;

This is also bad for two reasons:
1. Never use the sa account for you applications. The sa account is an
administrative account with many abilities that should not be granted to
application users. Protect the sa account as if your job depended on it (it
probably does). Create a login account with limited permissions for your
application to use. Also, it your sa account really has no password, go
right now and assign a password to it. Several internet worms target sql
servers whose sa account has no password.

2. The OLEDB Provider for ODBC has been deprecated. You are advised to use
the native OLEDB Provider for SQL Server instead. Your connection string
should look like this:
dsntemp="Provider=SQLOLEDB; Data Source=master1;" & _
"Initial Catalog=db1;User ID=xxxx;Password=xxxx"

Bob Barrows

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

[Ray Costanzo [MVP]]

I applaud you for this. Most people would just stop at "it works."
Instead, you thought, "Hmm, this works, but just because something works
doesn't mean it's right. Let me see if I can get some opinions about this."
That's very cool. I wish that the people I worked with thought that way!
:]

Ray at work

"Des Perado" <de*@per.ado> wrote in message
news:2r*************@uni-berlin.de...

I have just tried this, and it works:

Global.asa contains:

sub Session_OnStart
set Session("conn")=Server.CreateObject("ADODB.Connect ion")
dsntemp="driver={sql Server}; server=master1; database=db1; uid=sa; pwd=;
dsn=;"
session("conn").Open dsntemp
end sub

and in any asp:

sql="select * from table1"
set rs=session("conn").execute(sql)

As I say, it works.

But is there any reason we shouldn't do this? Is it bad?

TIA

[Des Perado]

"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcom> wrote in message
news:u1**************@TK2MSFTNGP15.phx.gbl...

This is also bad for two reasons:
1. Never use the sa account for you applications. The sa account is an
administrative account with many abilities that should not be granted to
application users. Protect the sa account as if your job depended on it (it probably does). Create a login account with limited permissions for your
application to use. Also, it your sa account really has no password, go
right now and assign a password to it. Several internet worms target sql
servers whose sa account has no password.
I don't normally Bob, that was just a quick cut 'n' paste from the test
script I wrote on my local machine! But thanks for the advice of course.

2. The OLEDB Provider for ODBC has been deprecated. You are advised to use
the native OLEDB Provider for SQL Server instead. Your connection string
should look like this:
dsntemp="Provider=SQLOLEDB; Data Source=master1;" & _
"Initial Catalog=db1;User ID=xxxx;Password=xxxx"

Thank you. I will have a play with that.

[Des Perado]

"Ray Costanzo [MVP]" <my first name at lane 34 dot commercial> wrote in
message news:OB**************@TK2MSFTNGP11.phx.gbl...

I applaud you for this. Most people would just stop at "it works."
Instead, you thought, "Hmm, this works, but just because something works
doesn't mean it's right. Let me see if I can get some opinions about this." That's very cool. I wish that the people I worked with thought that way!
:]

Ray at work

It's kind of you to say that Ray. I should add - and intended to in my
first message - that I did Google for the answer but, as with many similar
concepts, selection of the exact search term was tricky, and I didn't
actually find anything! I felt I needed some expert advice because I
thought there HAD to be a tradeoff if we were saving so much time by not
repeatedly opening a connection to the server with every page - it all
seemed to good to be feasible.