Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Stored Procs

25 views
Skip to first unread message

"@hotmaildotcom >

unread,
Nov 25, 2003, 4:08:29 PM11/25/03
to
What are the different ways to fire stored procedures in a SQL 2000
server? Which is better? I have seen simply:

set rs = conn.execute("sproc")

and I have also seen massive command.parameter ... bla bla ...


Foo Man Chew

unread,
Nov 25, 2003, 4:25:19 PM11/25/03
to
> What are the different ways to fire stored procedures in a SQL 2000
> server? Which is better?

Depends on how you define "better"...


"@hotmaildotcom >

unread,
Nov 25, 2003, 4:50:57 PM11/25/03
to Foo Man Chew
Faster. Most efficient. Or even just why one is used instead of the other.

"@hotmaildotcom >

unread,
Nov 25, 2003, 4:51:22 PM11/25/03
to Foo Man Chew
Faster. Most efficient. Or even just why one is used instead of the other.

Bob Barrows

unread,
Nov 25, 2003, 5:01:29 PM11/25/03
to

There are several alternatives.

1. Use the technique described here:
http://www.aspfaq.com/show.asp?id=2201

Personally, I don't like this technique since:
a. You have to worry about preventing hackers from injecting SQL into
your code (there are ways to prevent this - see the SQL Injection FAQ at
www.sqlsecurity.com)

b. You have to correctly delimit your parameter values, just as if you
were creating a dynamic SQL statement (actually, that is exactly what
you are doing here). You also have to correctly handle string values
that contain literal characters that are normally used as delimiters.
While I've done this enough times so that it is second nature to me now,
in the beginning this was the largest stumbling block to my learning how
to create strings containing dynamic SQL statements.

c. There is some performance-impairing overhead involved with both the
concatenation of the SQL statement that ultimately runs the stored
procedure, and the preparation of the statement on the SQL Server box,
which happens before the statement is actually executed.

d. It forces you to return data only by recordsets: no output or return
values can be used with this technique. Recordsets require substantial
resources, both on the SQL Server which has to assemble the resultset
and pass it back to the client, and on the web server which has to
marshal the resultset and transform it into an ADO recordset. This is a
lot of overhead when we're talking about returning one or two values to
the client.

However, a lot of people do like this technique because:
a. They have no problem knowing when and how to concatenate delimiters
into the SQL statement, and how to handle string parameters that contain
literal characters that are normally used as delimiters
b. They have taken the necessary steps to prevent SQL Injection
c. You can assign the statement to a variable and, if there's an error
during the debug process, you can response.write the variable to see the
actual statement being sent to the SQL Server. If the statement has been
created correctly, you can copy and paste it from the browser window
into Query Analyzer and further debug it
d. They are aware of the performance hit, and consider it to be too
minor to worry about. (To be fair, in many cases, this perfomance hit is
relatively minor)

The alternatives I prefer completely eliminate objection b from above.

1. If you have output parameters, or you are interested in using the
Return value from your procedure, use an explicit ADO Command object.
Now, this can be tricky, especially if you do it the correct way
(manually create the Parameters collection using CreateParameter instead
of using Parameters.Refresh which involves an extra time-consuming trip
to the database). However, there are many stored procedure code
generators out there that vastly simplify this process, including the
one I wrote which is available here:
http://www.thrasherwebdesign.com/index.asp?pi=links&hp=links.asp&c=
&a=clear

2. The technique I use most often is the
"procedure-as-connection-method" technique. With ADO 2.5 and higher,
stored procedures can be called as if they were native methods of the
connection object, like this:
conn.MyProcedure parmval1,...,parmvalN
This completely avoids the need to worry about delimiters, literal or
otherwise. Plus it turns out that this technique also causes the
procedure to be executed in a very efficient manner on the SQL Server
box.

You can also use this technique if your procedure returns a recordset:
set rs=server.createobject("adodb.recordset")
'optionally, set the cursor location and type properties
conn.MyProcedure parmval1,...,parmvalN, rs

This technique does not work in ADO.Net, so if you are considering
porting to dotnet, then you should avoid this technique.

HTH,
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.


Foo Man Chew

unread,
Nov 25, 2003, 9:26:56 PM11/25/03
to
> otherwise. Plus it turns out that this technique also causes the
> procedure to be executed in a very efficient manner on the SQL Server
> box.

Can you elaborate? Maybe show some benchmarks?


Bob Barrows

unread,
Nov 26, 2003, 7:06:18 AM11/26/03
to

If you use SQL Profiler to trace your server activity during the execution
of a procedure, you will see the intervention of several system procedures,
sp_preparesql, etc., when using the dynamic sql and explicit Command object
techniques, that you will not see when using the
"procedure-as-connection-method" technique. In his book "ADO Examples and
Best Practices", Bill Vaughn reported a substantial improvement in
performance. This has not been borne out by my own (and others') testing: I
saw a slight improvement. So, I will say tha it does not make a great deal
of difference, but if you're trying to squeeze the last millisecond of
performance out of your app ...

Many people do not like this technique because they liken it to
late-binding, which can be a performance killer in VB. However, in vbscript,
late-binding is all we do (all variables being variants ... ).

Another factor to consider is that vbscript is not a compiled language. This
means that if you have a lot of parameters, it may take more time to compile
and execute a bunch of CreateParameter statements than it would to use
Parameters.Refresh even. YMMV

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"


ko...@aerocrs.com

unread,
Mar 8, 2017, 9:10:16 AM3/8/17
to
Hi Bob,

Your method works great for me but i have one issue that i can't resolve.

I need to change the cursor type when getting the result set of the SP in order to build the UI dynamically while peeking at the next rows data. kind of like arr[i+1] in higher level language.
i'm trying to use moveprevious but it's not working (movenext works), or even AbsolutePosition = i+1, but no success with the CursoeType of 0

I'm trying to use different CursorType before opening the object but it has no affect.

Any idea how to change the CursorType when calling a stored procedure?

Thanks :)
0 new messages