I'm working with an ASP Classic legacy code base attempting to call an existing SQL Server stored procedure that declares output parameters with an XML data type.
However, every time I try to execute the stored proc I get this error:
0x80040e14 - Microsoft OLE DB Provider for ODBC Drivers: [Microsoft][ODBC SQL Server Driver][SQL Server]Implicit conversion from data type xml to varchar is not allowed. Use the CONVERT function to run this query.
I've experimented with a list of ADODB types, trying to find one that works, and haven't had any luck. I've also grepped our legacy code base for examples of other stored procs with xml output parameters being called, but wasn't able to find any.
Is there a way around this without updating the stored procedure to not use an XML type for its output parameter? For example, could it be possible to declare a null output parameter type or just ignore this parameter?
Thanks for any suggestions.
Related
I am trying to copy the send email assembly from one database to another. I clicked on script assembly as create to and created it in the new db.
When I try to send an email with the function in the newer db I get the following error:
The parameter 'fileName' cannot be an empty string. Parameter name: fileName
How can I copy the assembly across databases?
Some details:
Both DBs are on the same instance
Both DBs are owned by the same login
Using SQL Server 2016
Assembly is marked as UNSAFE in both DBs
Both DBs have TRUSTWORTHY enabled
T-SQL wrapper object is a scalar function / UDF
Function is being called the same way in both DBs
How can I copy the assembly across databases?
So far I am not seeing how this is a SQLCLR issue. You clearly copied the Assembly and the T-SQL wrapper object else you would be getting T-SQL errors instead of a .NET error.
I clicked on script assembly as create to and created it in the new db.
Given that you scripted out the T-SQL wrapper object and you are getting an error related to an input parameter, you might be running into a bug that causes defaults for NVARCHAR parameters to not script out correctly:
SSMS scripting CLR stored procedure NVARCHAR parameter NULL default as N'' (empty string)
Execute the following in both old and new DBs to make sure that all parameter definitions are the same, including any potential default values (paying close attention to rows that have a 1 for [has_default_value]):
SELECT [name], [user_type_id], [max_length], [is_output],
[has_default_value], [default_value]
FROM sys.parameters prm
WHERE prm.[object_id] = OBJECT_ID(N'dbo.ObjectName')
ORDER BY prm.[parameter_id];
If you find any differences, you will need to update your CREATE statement to include the correct default value(s). For example, if you have:
#SomeParam [nvarchar](1 - 4000) = N``
Then you will need to update that part of your T-SQL script to instead be:
#SomeParam [nvarchar](1 - 4000) = NULL
And then re-run the CREATE (you might need to either first DROP the existing T-SQL wrapper object, or change the CREATE to be ALTER).
Please vote for that Feedback bug report that I linked above. Thanks!
For more info on working with SQLCLR in general, please visit: SQLCLR Info
Concat function requires two arguments is the error generated when i paste the code in ssis. But when i run the query in SQL Management studio i am able to fetch the results
The CONCAT function does require 2, or more strings to work. You likely have a query in SSIS that looks like
SELECT CONCAT('ABC', #[User::MyVariable) AS MyConcatColumn;
That's a common misunderstanding for how SSIS works. If the concatenation work is to be done in TSQL, then you need to parameterize your query - which is dependent upon the database connectivity provider (ODBC vs OLE vs ADO).
Assuming OLEDB, you'd revise the above to
DECLARE #TSQLVariable nvarchar(4000) = ?;
SELECT CONCAT('ABC', #TSQLVARIABLE) AS MyConcatColumn;
and then click the Parameters button/tab (depends on the component) and map the SSIS variable #[User::MyVariable] into ordinal position 0.
I open a TFDConnection for MS SQL Server with parameters:
DriverID=MSSQL
Password=test
User_Name=test
Server=VS2003-2008
Database=test
Single Connection=TRUE
Max Cursors=256
USE OLEDB=TRUE
I then create a TFDQuery (run time), set its connection to the above, fill it with an parameterized INSERT query:
insert into TT_ACT (TT_ACT_ID,TT_PARENT_ID,TT_FROMDATE,TT_TODATE,TT_NAME,TT_NR,TT_CODE,TT_GROUP...)
values (:TT_ACT_ID,:TT_PARENT_ID,:TT_FROMDATE,:TT_TODATE,:TT_NAME,:TT_NR,:TT_CODE,:TT_GROUP,...)
I then call Prepare for the query and get:
[FireDAC][Phys][MSSQL]-335 Parameter [TT_ACT_ID] data type is unknown.
Hint: Specify TFDParam.DataType or Assign TFDParam.Value before Prepare/Execute call
If I do the same for a FireBird database there are no issues.
I guess it has something to do with using OLEDB. There is no native MS SQL client on the machine.
There is no FDPhysMSSQLDriverLink on the datamodule where the TFDConnection resides, but adding one makes no difference.
Table TT_ACT exists.
What am I forgetting to make this work?
I would follow help here and avoid calling Prepare before parameters are defined (their data types are fully specified). You haven't missed anything but this note from help:
It is recommended to setup parameters before the Prepare call.
For common ODBC drivers (you are still talking to an ODBC driver, no matter if they internally uses OLE DB to communicate with the DBMS), FireDAC doesn't determine parameter data types for the prepared command. Instead, it prepares command statement on the target DBMS and tries to bind existing ones from the Params collection. That's how the Prepare method is implemented (Tokyo).
ODBC API provides the SQLDescribeParam function to obtain parameter details for the prepared command, but FireDAC doesn't use it anywhere (at this time). Instead, it leaves building parameter collection manually. Which is not wrong, because in the end, it is the developer who needs to know which value to assign to a certain command parameter so as to know this value type.
Set each of your parameters DataType property, and then you can call Prepare ie:
qry.ParamByName('foo').DataType := TFieldType.ftString;
qry.ParamByName('bar').DataType := TFieldType.ftInteger;
qry.Prepare;
The DataType property is of type Data.DB.TFieldType, here is a list of all possible values
I'm working on a quick ASP Classic form that calls a TSQL proc. The first one that I created works great since it doesn't send any values in. Now I'm working on my second one and it looks a bit like this:
exec update_allocation(#Anum='164360',#mTeam='5',#Team='9',#Perc='14',#Bill=140000,#Mons=164360)
Also tried as:
exec update_allocation('164360','5','9','14',140000,164360)
First one gives me an error of:
Microsoft OLE DB Provider for SQL Server error '80040e14' Incorrect
syntax near '#Anum'.
The second gives me:
Microsoft OLE DB Provider for SQL Server error '80040e14' Incorrect
syntax near '164360'.
I'm not sure what to make of these errors. The issue must be the parameters, but not sure how they should be sent in.
The comments are correct but here is a bit of explanation as to why that is the case.
Both errors;
Microsoft OLE DB Provider for SQL Server error '80040e14' Incorrect syntax near '#Anum'.
and
Microsoft OLE DB Provider for SQL Server error '80040e14' Incorrect syntax near '164360'.
are actually quite descriptive and pinpoint where the issue is. Usually in a situation like this an error is highlighting a problem just before the word or phrase in an error description in these cases the #Anum parameter and the 164360 value. If we follow this through the previous character in both cases is an open bracket (.
Unlike functions in T-SQL, Stored Procedures do not require brackets around their parameters and doing so will raise an error (like the ones above) to correct this remove the brackets from both statements.
With named parameters;
EXEC update_allocation #Anum='164360', #mTeam='5', #Team='9', #Perc='14', #Bill=140000, #Mons=164360
Without named parameters;
EXEC update_allocation '164360', '5' ,'9' ,'14' ,140000 ,164360
Either method is acceptable syntax but personally I find it more useful to use the named parameter approach as that allows you to pick and choose what parameters to pass and even exclude ones that have defaults. You can still do this with the nameless approach but ordinal position of the values is more important.
#sean-lange makes a valid point here about SQL Injection vulnerability, consider using the ADODB.Command object to execute stored procedures rather then just calling the Execute() method on a ADODB.Connection object.
Here is an example of calling Stored Procedures using Classic ASP and the ADODB.Command object.
Answer to Using Stored Procedure in Classical ASP .. execute and get results
Answer to How to use ASP variables in SQL statement
Using Visual Studio 2008 and SQL Server 2008.
Using OLE DB Source to OLE DB Destination, I have a stored procedure that has several parameters using specific IDs (e.g. #BUSINESS_AREA_ID = '32'). If you would like to bring in all IDs you can use -1 (e.g. #BUSINESS_AREA_ID = '-1').
OLE DB SOURCE
Properties
These variables are set up as VARCHAR(MAX). When I run this using -1 in SQL Server it works completely fine and returns thousands of records, but when I set up the stored procedure in SSIS, it runs very quickly (everything is green) but it writes 0 rows.
I checked the data viewer and there are no return values, so I'm thinking the problem lies with the -1 variable. I have tried setting up the variable using every data type (string, Int32, etc.), using single quotes and not using them, conversion or truncation is not an issue, etc....I'm stuck. I have set up many more stored procedures and they all work great, but they do not use the -1 feature. Does anyone have any idea what might be wrong?
Thanks all.
It looks like you are passing a string '-1' rather than a -1 int so make sure your variable is set as a string.
Once that is set up, make sure you are correctly mapping the variable to the parameters you are passing to the stored procedure in the OLE DB Source. Make sure to follow this format and change the stored procedure, parameter and variable names.
In the set query parameters dialogue, under the parameters column, change all the parameter names to:
0
1
2
3
etc...
and make sure that the variables are assigned to the placeholders in the order that they appear in your query. In other words, parameter 0 is the first parameter in your query, so assign the appropriate variable to it.