Attn Bob Barrows

[John Burns]

Bob,
I've been reading some of your posts in google groups regarding
Paramaterizing SQL queries.

I'm trying to do things theright way, but having problems and thought you
might be able to help me out.

I'm opening an access database in an include file at the start of the asp
file.
Set MyConn = Server.CreateObject("ADODB.Connection")
MyConn.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=c:\testdb.mdb;"

So far so good.

I then tried saving a query in Access - its named 'qlogin' and consists of a
very simple:
SELECT *
FROM users
WHERE login=[formusername] And userpassword=[formpassword];

What lines of asp do I need to then get data from the record set, ie:
RS("login")

I am also interested in a method someone else brought up and you weren't too
keen on which used dynamic SQL but with the parameters in a @P1 type naming
convention. eg: SQL = "EXEC qry_Listings @P1" & varPI
How would I use this to return a recordset?

Thanking you in advance

John Burns

 

[Bob Barrows [MVP]]

Bob,
I've been reading some of your posts in google groups regarding
Paramaterizing SQL queries.

I'm trying to do things theright way, but having problems and thought
you might be able to help me out.

I'm opening an access database in an include file at the start of
the asp file.
Set MyConn = Server.CreateObject("ADODB.Connection")
MyConn.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data
Source=c:\testdb.mdb;"

So far so good.

I then tried saving a query in Access - its named 'qlogin' and
consists of a very simple:
SELECT *

Avoid selstar in production code (http://www.aspfaq.com/show.asp?id=2096).
Always name the fields you are returning.

FROM users
WHERE login=[formusername] And userpassword=[formpassword];

What lines of asp do I need to then get data from the record set, ie:
RS("login")

It couldn't be simpler. Let's assume you've put the values to be passed to
the query in variables called formusername and formpassword (I would use
shorter variable names myself, but that's just personal preference):

dim rs
set rs = createobject("adodb.recordset")
MyConn.qlogin formusername, formpassword, rs
if not rs.eof then
login = rs("login")
else
'query returned no records
end if

I am also interested in a method someone else brought up and you
weren't too keen on which used dynamic SQL but with the parameters in
a @P1 type naming convention. eg: SQL = "EXEC qry_Listings @P1" &
varPI
How would I use this to return a recordset?

dim sSQL
sSQL = "Exec qlogin '" & formusername & "','" & formpassword & "'"
Set rs = MyConn.Execute(sSQL,,1)

If you've read my posts about this, you should understand why I'm not keen
on this technique. Read up on SQL Injection.

Bob Barrows

 

[John Burns]

Bob,
Thankyou very much for your quick response.

I have a couple of more questions:
If I want to perform another SQL query within the script, do I need to
completely close the connection to the database and reopen it, or is there a
simpler way?

This definitely works, but looks like it's wasting resources.
MyConn.close
MyConn.Open "Provider=Microsoft.Jet.OLEDB.4.0; " & "Data
Source=c:\testdb.mdb"


Also, with regards to the method using @P1, etc. I actually thought this
was parametizing the data to protect against SQL injection. Maybe its the
method using ?. Do either of these work, or is the only way to define them
in access?

Once again, thanks in advance

John Burns

 

[Bob Barrows [MVP]]

Bob,
Thankyou very much for your quick response.

I have a couple of more questions:
If I want to perform another SQL query within the script, do I need to
completely close the connection to the database and reopen it,

Of course not. Just run the next query. One caveat: depending on the
cursortype, you may need to close an open recordset before opening a new one
(experiment with this), but you should be consuming the data from recordsets
as quickly as possible anyways. GetString and GetRows are good techniques
for sucking the data out of your recordset so the recordset can be closed
and discarded. Search www.aspfaq.com for the article on recordset iteration
(keywords: iteration getrows)

Also, with regards to the method using @P1, etc. I actually thought
this was parametizing the data to protect against SQL injection.
Maybe its the method using ?. Do either of these work, or is the
only way to define them in access?

Yes, you're thinking of the ? technique (called parameter markers). This
works with all data providers. See here for an example:
http://groups-beta.google.com/group/microsoft.public.vi.general/msg/0c76ae56f800dd59


ADO documentation can be found at http://msdn.microsoft.com/library. Look
under the Win32 and Com node in the TOC.

Bob Barrows

 

[John Burns]

Bob,
any reason off the top of your head why I would always get EOF=true on my
windows 2000 server machine when this code works perfectly on my WindowsXP
machine?
I have also confirmed that If I change a query back to a standard
concatenated query, it works perfectly in win 2000.

Regards

John

 

[John Burns]

A reboot did the job - pity, it was the 98th day of uptime. Back to 0
again.

 

[Bob Barrows [MVP]]

Bob,
any reason off the top of your head why I would always get EOF=true
on my windows 2000 server machine when this code works perfectly on
my WindowsXP machine?
I have also confirmed that If I change a query back to a standard
concatenated query, it works perfectly in win 2000.

Not without seeing the code.
I assume you are validating the inputs to verify that they contain what they
are expected to contain ...

Bob Barrows

 

[Bob Barrows [MVP]]

A reboot did the job - pity, it was the 98th day of uptime.

Exceedingly strange. Were you using data stored in Application or Session? I
see no other reason that a reboot would have affected this problem.

 

[John Burns]

Exceedingly strange. Were you using data stored in Application or Session?

I see no other reason that a reboot would have affected this problem.

Actually, after a reset, it broke again when I uploaded a new mdb file to
the server.
I justupgraded the MDAC to the latest version (5.8??) and it now seems fine.