Here's my stored procedure...
alter PROCEDURE ReplyToEmailConfirmation
#uniqueKey varchar(36)
AS
BEGIN
Print 'Hello World!'
END
Here's the code...
Set cmd = Server.CreateObject("ADODB.Command")
With cmd
.ActiveConnection = getConfigValue("ASPClassicConnectionString")
.CommandType = adCmdStoredProc
.CommandText = "[ReplyToEmailConfirmation]"
.Parameters.Append .CreateParameter("#uniqueKey", adVarChar, adParamInput, 36, "dc8d8bfd-ea3a-4ad9-9f2d-92831eb2655a")
End With
cmd.Execute
Here's the error...
ADODB.Command error '800a0bb9'
Arguments are of the wrong type, are out of acceptable range, or are
in conflict with one another.
How do I get this to work? The intention is to use adGUID, but I figured I'd try adVarChar to narrow down the error.
If you read the documentation for CreateParameter() all becomes clear;
If you specify a variable-length data type in the Type argument, you must either pass a Size argument or set the Size property of the Parameter object before appending it to the Parameters collection; otherwise, an error occurs.
As you are passing a VARCHAR which is a "variable-length" data type you have to specify Size when calling CreateParameter().
Dim cmd
Set cmd = Server.CreateObject("ADODB.Command")
With cmd
'Let the cmd deal with the connection.
.ActiveConnection = getConfigValue("ASPClassicConnectionString")
.CommandText = "[ReplyToEmailConfirmation]"
.CommandType = adCmdStoredProc
Call .Parameters.Append(.CreateParameter("#uniqueKey", adVarChar, adParamInput, 100))
.Parameters("#uniqueKey") = "dc8d8bfd-ea3a-4ad9-9f2d-92831eb2655a"
End With
Call cmd.Execute()
'Tidy up memory
Set cmd = Nothing
Also included CommandType of adCmdStoredProc which tells ADO to interpret this command as a Stored Procedure call, without it the default is adCmdUnknown which means ADO has to attempt to workout what the command is, which however small adds an unnecessary overhead.
Also not a big fan of instantiating the ADODB.Connection object just to execute a ADO.Command object which then means you have to manage closing the ADODB.Connection yourself. Instead let the ADODB.Command do it for you, by passing a connection string letting it create the connection and destroy it itself. Assuming getConfigValue("ASPClassicConnectionString") returns a connection string you can pass it directly to ActiveConnection and the ADODB.Command will instantiate the connection and dispose of it.
Useful Links
A: Passing Parameters to a Stored Procedure using ASP (Explains how to use METADATA to include Named Constants)
I didn't include adovbs.inc for the adCmdStoredProc, adVarChar and adGUID constants. Doh.
Related
i have a stored procedure in Sybase ASE with date params in it, so when i created a OLE DB Connection and passing the date parameters to the OLE DB Command,And we are mapping to the parameter with OLEDBType.DBTimeStamp type, datetime param type in stored procedure is smalldatetime.
Here is the sample code.
OLEDBConnection con = new OLEDBConnection(connectionstring);
con.open;
OLEDBCommand cmd = new OLEDBCommand(con);
cmd.QueryString = "dbo.job_xb_new"
cmd.QueryType = "Stored Procedure";
cmd.Parameters.Add("#signoff",OLEType.DBTimeStamp);
cmd.Parameters("#signoff").Value = Datetime.now;
cmd.executeNonQuery(); -----------> ERROR HERE
while executing the store-procedure i am receiving the error.
"Conversion failed because the DateTime data value overflowed the type specified for the DateTime value part in the consumer's buffer" ?
Please help!!!
With the only information given there may be a solution to try.
Change the datatype of your input value to the stored proc to a char/varchar
create procedure dbo.myProc
#inDate varchar(20)
AS
BEGIN
..
END
Perform internal conversion from that with CONVERT before passing to your query.
SET #inDate = CONVERT(datetime,#inDate,[style parameter number])
For troubleshooting, just comment out everything in the procedure and SELECT #inDate first to determine what the data coming in from the OLE DB app looks like. You may be in for a surprise there...
Say:
let x = // some operation
type t = SomeTypeProvider<x>
Is this valid?
No.
Since the types must be generated at compile-time, the parameter to the type provider needs to be a constant.
In other words, the code you marked // some operation can evaluate to a literal, but cannot be a value returned by a runnable function:
let arg = "foo"
type t = SomeTypeProvider<arg> // okay
let [<Literal>] arg = """{"name":"foo","value":42}"""
type t = SomeTypeProvider<arg> // okay
let arg = x.ToString()
type t = SomeTypeProvider<arg> // Boom! arg is not a Literal
It depends on your application, but one of the most common cases is the following:
You have a database-related Type Provider, and the connection string needs to be retrieved in runtime, from some sort of config file or something. So a developer mistakenly thinks they need a runnable code to retrieve the connection string first and then pass it to the Type Provider.
The correct approach is the following:
Keep two databases: one locally stored in a constant location (just for schema), and another one for the runtime purposes.
Pass the first one (a constant!) to your Type Provider. Don't worry about the hardcoded paths; it is only used for schema retrieval.
// Use a fixed sample file for schema generation only
type MyCSVData = CsvProvider<"dummy.csv">
// Load the actual data at runtime
let data = MyCSVData.Load(RetrieveFileNameFromConfig())
In this article it shows how to use the SqlCommandProvider type. The sample code has this:
use cmd = new SqlCommandProvider<"
SELECT TOP(#topN) FirstName, LastName, SalesYTD
FROM Sales.vSalesPerson
WHERE CountryRegionName = #regionName AND SalesYTD > #salesMoreThan
ORDER BY SalesYTD
" , connectionString>(connectionString)
what does the <... ,...> before the type constructor name mean and why the the
first parameter have to be a string literal? It looks like a generic but it's taking variables not types. The constructor seems to be taking in a connection string already in the <> section.
The angle brackets are the configuration for a type.
In your example, you are defining a type and creating an instance at the same type. It's clearer when the steps are separated.
Define a type.
type SalesPersonQuery = SqlCommandProvider<query, connectionString>
But to actually have an instance of the type you have to create it:
let command = new SalesPersonQuery()
Now you can use the command.Execute() rather then SalesPersonQuery.Execute().
The reason there is a constructor is because later on (at run-time) you can change the connection string to a different then the one provided in the definition, so for instance:
let command = new SalesPersonQuery(differentConnectionString)
You can find that in the documentation in configuration section:
Connection string can be overridden at run-time via constructor optional parameter
First parameter can be a path to a SQL script or a SQL query. I suppose that's the reason it's a string: how else would you like to define a SQL query?
Again, from the documentation:
Command text (sql script) can be either literal or path to *.sql file
Using Historian 5.5 and SQL Server 2012.
I have a stored procedure in SQL Server called perfEng_RWtopits and I want to call this procedure from within a calculation tag in Historian Administrator.
The stored procedure returns one float value.
I have the following code so far:
Dim sql
Dim con
Dim cmd
Dim value
sql = "perfEng_RWtopits"
Set con = CreateObject("ADODB.Connection")
con.ConnectionString = "myconnectionstring"
con.Open
Set cmd = CreateObject("ADODB.Command")
cmd.ActiveConnection = con
cmd.CommandText = sql
value = cmd.Execute
con.close
Set cmd = Nothing
Set con = Nothing
When I test the calculation I get a value of zero and a quality of bad. If I execute the stored procedure within SQL Server I get 17.123554 (which is correct). Also if I add the following to the end.
Result = value
I get the following error message.
Can anyone help?
You have an error in your vb script. To bad that we can't debug that in Historian Administrator in calcullation tab.
When using a parameterless function you can execute it by writing:
FunctionName
or
FunctionName(), but when you want to pass the result to a variable then you must use () like this value = FunctionName().
You are using function cmd.Execute without () and returning the result to value. Just fix the line
value = cmd.Execute
to
value = cmd.Execute()
If you have a stored procedure that executing multiple queries, doesn't return values and doesn't have error-handling in it, how can you ascertain whether the stored procedure ended successfully when calling from VB code?
For example, if the stored procedure is something like:
create stored procedure some_procedure
Insert into ...
delete ...
update ...
end
... and the VB code is like this:
Cmd.ActiveConnection = cn
Cmd.CommandText = "some_procedure"
Cmd.CommandType = adCmdStoredProc
Set rs = Cmd.Execute
Debug.Print rs(0)
... then how can I get a return value that is 0 for success or 1 for failure?
I believe passing the optional RecordsAffected parameter with the Execute statement will work for you. Since you're so scarce on the details you'll have to try it, but this has worked for me with SQL, and FoxPro OLEDB providers. Also, why no error handling? IMHO not having an error handler in code that has a good possibility of producing an error is asking for trouble.
...
Dim lngRecsAffctd As Long
Cmd.ActiveConnection = cn
Cmd.CommandText = "some_procedure"
Cmd.CommandType = adCmdStoredProc
Cmd.Execute lngRecsAffctd, ,adCmdStoredProc 'why set to a recordset when the sproc doesn't return anything?
Debug.Print lngRecsAffctd
...
The complete details of the Execute command and the RecordsAffected parameter can be found at msdn.microsoft.com/en-us/library/ms681559%28v=vs.85%29.aspx