Passing Parameters to a Stored Procedure using ASP
Asked Answered
T

3

2

I'm trying to pass some parameters to a SQL stored procedure in my classic ASP. I've seen several posts on this and not sure what I'm doing wrong as I don't seem to see my discrepancy.

set conn = CreateObject("ADODB.Connection") 
conn.open ("DSN=SERVER;UID=username;PWD=pwd;Database=MyDatabase")

 set cmd = Server.CreateObject("ADODB.Command")
 set cmd.ActiveConnection = conn
 cmd.CommandType = adCmdStoredProc
 cmd.CommandText = my_proc
 cmd.Parameters.Refresh
 cmd.Parameters(1) = "MyParam"

set rs = cmd.execute

I'm getting the error

Arguments are of the wrong type, are out of acceptable range, or are in conflict 
with one another.

on the line cmd.CommandType = adCmdStoredProc. I also tried to do it the following way with the same error

set conn = CreateObject("ADODB.Connection") 
conn.open ("DSN=SERVER;UID=username;PWD=pwd;Database=MyDatabase")

 set cmd = Server.CreateObject("ADODB.Command")
 set cmd.ActiveConnection = conn
 cmd.CommandType = adCmdStoredProc
 cmd.CommandText = my_proc
 cmd.Parameters.Refresh
 cmd.Parameters.Append cmd.CreateParameter("@MyParam, adVarWChar, adParamInput, 50, "test")

set rs = cmd.execute
Tierell answered 5/11, 2014 at 19:51 Comment(0)
R
-1

You use ADO through late binding, which means that the constants like adCmdStoredProc, adParamInput etc. are unknown to your code (so they are always 0).

You can either look them up and define the ones you need as a constant in your code (or use the numbers directly, but that's not well readable if you edit the code again later).

Or take a look here on msdn - you may find a file that defines all the constants at
c:\Program Files\Common Files\System\ado\adovbc.inc.

Radiotelegraphy answered 5/11, 2014 at 20:6 Comment(1)
@doby48 No don't do this, using adovbc.inc is a poor substitute for META Type Library references. Added the META Type Library reference is a once only (as it's added to the global.asa in your Classic ASP application), whereas adovbc.inc has to be included in every page or set in another #include file to apply it globally.Originally
O
1

@KekuSemau is correct but let me a suggest a more efficient and manageable approach then using the adovbs constants file.

METADATA allows you to define a reference to the DLLs constants even if your using Late Binding as is the case in a Classic ASP environment. It's probably worth mentioning that you can add METADATA references in individual pages but then again why would you?

To use it simply add the METADATA tag to your global.asa file (should be located in the root of your Web Application).

<!-- 
METADATA TYPE="typelib" FILE="C:\Program Files\Common Files\System\ADO\msado20.tlb"
-->

Depending on the system the ADO Type Library maybe different, adjust the FILE attribute accordingly.

I use this approach in all my applications mainly for referencing constants in the ADO and CDO Type Libraries.

ADO Type Library

<!--
METADATA 
TYPE="typelib" 
FILE="c:\program files\common files\system\ado\msado15.dll"
-->

CDO Type Library

<!-- 
METADATA 
TYPE="typelib" 
UUID="CD000000-8B95-11D1-82DB-00C04FB1625D" 
NAME="CDO for Windows 2000 Library"
-->

These are examples of my own personal references, file locations maybe different whereas UUID attributes should be exactly the same.

IMPORTANT:

Remember to remove any references to adovbs constant include file (adovbs.inc or adovbs.asp commonly) when using METADATA approach in your global.asa or you will get a

Name redefined error

Also METADATA is only available in IIS 4.0 and above.


Useful Links

Originally answered 6/11, 2014 at 9:45 Comment(2)
Also for ADO <!--METADATA TYPE="typelib" NAME="Microsoft ActiveX Data Objects 2.8 Library" UUID="{2A75196C-D9EB-4129-B803-931327F72D5C}" VERSION="2.8"-->Proliferation
@AlexK. Yep, you can use either FILE or UUID to reference the Type Libraries.Originally
R
-1

You use ADO through late binding, which means that the constants like adCmdStoredProc, adParamInput etc. are unknown to your code (so they are always 0).

You can either look them up and define the ones you need as a constant in your code (or use the numbers directly, but that's not well readable if you edit the code again later).

Or take a look here on msdn - you may find a file that defines all the constants at
c:\Program Files\Common Files\System\ado\adovbc.inc.

Radiotelegraphy answered 5/11, 2014 at 20:6 Comment(1)
@doby48 No don't do this, using adovbc.inc is a poor substitute for META Type Library references. Added the META Type Library reference is a once only (as it's added to the global.asa in your Classic ASP application), whereas adovbc.inc has to be included in every page or set in another #include file to apply it globally.Originally
E
-1

I think there is only a very small piece that you are doing wrong:

set conn = CreateObject("ADODB.Connection") 
conn.open ("DSN=SERVER;UID=username;PWD=pwd;Database=MyDatabase")

set cmd = Server.CreateObject("ADODB.Command")
set cmd.ActiveConnection = conn
cmd.CommandType = 4 ' adCmdStoredProc constant is not defined in your context
cmd.CommandText = my_proc
cmd.Parameters.Refresh
cmd.Parameters(1).value = "MyParam"

set rs = cmd.execute

The ADO constants are probably undefined, and also (but not sure) the parameter should be assign via its value property.

Entity answered 5/11, 2014 at 20:8 Comment(4)
This will not work as the Parameters(1) has not been defined in the collection (Use .CreateParameter() to define it), also the .Parameters collection is ordinal starting at 0.Originally
.Refresh gets the parameters from the server and adds them to the .Parameters collectionEntity
Sorry missed that. I've had mixed results with Refresh in the past prefer to declare them myself.Originally
Also worth noting that Refresh is not recommended for production environments due to it requiring another round trip to the server to complete the call and pull back the parameter definitions.Originally

© 2022 - 2024 — McMap. All rights reserved.