SSIS: Passing parameter in OLE DB Source Editor to a table-valued function - sql-server-2005

How can I pass parameters in an OLE DB Source to call a table-valued function like:
select * from [dbo].[udf_test](?, ?)
When doing so, I am getting the error:
Parameters cannot be extracted from the SQL command. The provider might not help to parse parameter information from the command. In that case, use the "SQL command form variable" access mode, in which the entire SQL command is stored in a variable.
Syntax error, permission violation, or other nonspecific error (Microsoft SQL Native Client)
Is there another solution than "SQL command from variable"?
Sven

You can use the SQL Command from Variable, it is relatively straightforward. You could build the SQL statement to pass to the Source using a Script transform to edit the variable which holds the SQL. So for example you'd set up a variable called strSQL and make the value
select * from [dbo].[udf_test](?1, ?2)
And then in the script component, replace the ?1 and ?2 values with the parameters you want to pass using string manipulation methods.
It's a little more work in the package but works well in my experience.

This is a little bit of a workaround but it works pretty well. What we do is create a stored procedure called SetVar that will take an input parameter and assign it to a declared out parameter.
Create a procedure called SetVar in the OLE DB source database. It assigns #inputVar to #outVar
CREATE PROC SetVarInt
#inputVar INT ,
#outVar INT OUTPUT
AS
BEGIN
SELECT #outVar = #inputVar;
END
In the SSIS OLE DB source use this SQL:
DECLARE #param1 INT;
EXEC [dbo].[SetVarInt] #inputVar = ?, -- int
#outVar = #param1 OUTPUT -- int
SELECT * FROM [dbo].[GetByKey](#param1)
If nothing happens, the optimizer may have optimized the task away (check package execution log). In this case I will add the following to the end of the OLE DB source SQL, and connect this output to a RowCount task into a dummy variable.
SELECT 1 Done;

If you want to keep it simple, and just have the query in the OLDDB source without using other tricks, you can achieve that by writing the entire T-SQL code needed to get it done e.g.
declare #var1 as int = ?;
declare #var2 as datetime = ?;
select *
from [dbo].[udf_test](#var1, #var2);
Doing it like that you do not need to have a separate task in SSIS to build the query and assign the parameteres, it all stays in the same place, and therefore easier to write, and even more important easier to understand by the person who will need to support this after you.

Related

How to use SET OPTION within a DB2 stored procedure

I read (and tried) that I cannot use WITH UR in DB2 stored procedures. I am told that I can use SET OPTION to achieve the same. However, when I implement it in my stored procedure, it fails to compile (I moved around its location same error). My questions are:
Can I really not use WITH UR after my SELECT statements within a procedure?
Why is my stored procedure failing to compile with the below error
message?
Here is a simplified version of my code:
CREATE OR REPLACE PROCEDURE MySchema.MySampleProcedure()
DYNAMIC RESULT SETS 1
LANGUAGE SQL
SET OPTION COMMIT=*CHG
BEGIN
DECLARE GLOBAL TEMPORARY TABLE TEMP_TABLE AS (
SELECT 'testValue' as "Col Name"
) WITH DATA
BEGIN
DECLARE exitCursor CURSOR WITH RETURN FOR
SELECT *
FROM SESSION.TEMP_TABLE;
OPEN exitCursor;
END;
END
#
Error Message:
SQL0104N An unexpected token "SET OPTION COMMIT=*CHG" was found
following " LANGUAGE SQL
Here is code/error when I use WITH UR
CREATE OR REPLACE PROCEDURE MySchema.MySampleProcedure()
LANGUAGE SQL
DYNAMIC RESULT SETS 1
--#SET TERMINATOR #
BEGIN
DECLARE GLOBAL TEMPORARY TABLE TEMP_TABLE AS (
SELECT UTI AS "Trade ID" FROM XYZ WITH UR
) WITH DATA;
BEGIN
DECLARE exitCursor CURSOR WITH RETURN FOR
SELECT *
FROM SESSION.TEMP_TABLE;
OPEN exitCursor;
END;
END
#
line 9 is where the DECLARE GLOBAL TEMPORARY ... is
DB21034E The command was processed as an SQL statement because it was
not a valid Command Line Processor command. During SQL processing it
returned: SQL0109N The statement or command was not processed because
the following clause is not supported in the context where it is
used: "WITH ISOLATION USE AND KEEP". LINE NUMBER=9. SQLSTATE=42601
Specifying the isolation level:
For static SQL:
If an isolation-clause is specified in the statement, the value of that clause is used.
If an isolation-clause is not specified in the statement, the isolation level that was specified for the package when the package was bound to the database is used.
You need to bind the routine package with UR, since your DECLARE GTT statement is static. Before CREATE OR REPLACE use the following in the same session:
CALL SET_ROUTINE_OPTS('ISOLATION UR')
P.S.: If you want to run your routine not only 1 time in the same session without an error, use additional WITH REPLACE option of DECLARE.
If your Db2 server runs on Linux/Unix/Windows (Db2-LUW), then there is no such statement as SET OPTION COMMIT=*CHG , and so Db2 will throw an exception for that invalid syntax.
It is important to only use the matching Db2 Knowledge Centre for your Db2 platform and your Db2-version. Don't use Db2-Z/OS documentation for Db2-LUW development. The syntax and functionalities differ per platform and per version.
A Db2-LUW SQL PL procedure can use with ur in its internal queries, and if you are getting an error then something else is wrong. You have to use with ur in the correct syntax however, i.e in a statement that supports this clause. For your example you get the error because the clause does not appear to be valid in the depicted context. You can achieve the desired result in other ways, one of them being to populate the table in a separate statement from the declaration (e.g insert into session.temp_table("Trade ID") select uti from xyz with ur; ) and other ways are also possible.
One reason to use the online Db2 Knowledge Cenbtre documentation is that it includes sample programs, including sample SQL PL procedures, which are also available in source code form in the sample directory of your DB2-LUW server, in addition to being available on github. It is wise to study these, and get them working for you.

SQL reporting invalid syntax when run in Power BI

I have written an SQL script which runs fine when executed directly in SQL Management Studio. However, when entering it into Power BI as a source, it reports that it has an incorrect syntax.
This is the query:
EXEC "dbo"."p_get_bank_balance" '2'
However, the syntax is apparently incorrect? See Picture:
Any help is much appreciated.
EDIT ***
When the double quotes are removed (as per Tab Alleman's suggestion):
I found time ago the same problem online on power bi site:
http://community.powerbi.com/t5/Desktop/Use-SQL-Store-Procedure-in-Power-BI/td-p/20269
You must be using DirectQuery mode, in which you cannot connect to data with stored procedures. Try again using Import mode or just use a SELECT statement directly.
In DirectQuery mode, PowerBI automatically wraps your query like so: select * from ( [your query] ), and if you attempt this in SSMS with a stored procedure i.e.
select * from (exec dbo.getData)
You get the error you see above.
The solution is you have to place your stored procedure call in an OPENQUERY call to your local server i.e.
select * from OPENQUERY(localServer, 'DatabaseName.dbo.getData')
Prerequisites would be: enabling local server access in OPENQUERY with
exec sp_serveroption #server = 'YourServerName'
,#optname = 'DATA ACCESS'
,#optvalue = 'TRUE'
And then making sure you use three-part notation in the OPENQUERY as all calls there default to the master database
With "Import" data connectivity mode Stored Procedures work
With "Direct Query" data connectivity mode, the query syntax must be like below:
declare #sqlCommand varchar(100) = 'dbo.p_get_bank_balance'
declare #p1 int = 2
exec #sqlCommand #p1 = #p1
Remerber: max one data source connection with Direct Query. If you want to call much SP, only one can be in Direct Query mode, the others in Import mode
Try using Import instead of Direct Query. It may be showing error cause you are using Temp table in it. Create query using sub query and remove Temp table and try it. Or you can use as Import instead of Direct Query it will work.

SSIS Stored Procedure Call

I'm trying to call a simple stored procedure which would return a list of names in normal test format, all in a single line. I'm passing it two parameters, but no matter how i setup the call, either within a OLE DB Source Editor, or within an execute SQL task.
There must be something i'm missing with my SQL statement b/c i keep getting an error.
My SQL command text is
EXEC [dbo].[spGetEmployerIdCSV] ?, ?
The parameters I'm passing are listed exactly as they are declared in the stored procedure, #IDType and #IDNumber, which are mapped to predefined variables.
Every time I try to run it from either task type, I get a
The EXEC SQL construct or statement is not supported.
What is the best way to run a stored procedure within SSIS?
Thank you.
I cannot recreate your issue.
I created a control flow with the proc already in existence.
I have my execute sql task configured as
My parameters tab shows
When I click run, the package goes green.
My initial assumption was that you had signaled that you were using a stored procedure and were erroneously providing the EXEC part. I had done something similar with SSRS but even updating the IsQueryStoredProcedure to True, via Expression, I could not regenerate your error message.
If you are doing something else/different/in addition to what I have shown in the Execute SQL Task, could you amend your question to describe what all functionality the procedure should show.
Did you specify output parameters?
For 2 in / 1 out your SQL code will look like:
EXEC [dbo].[spGetEmployerIdCSV] ?, ?, ? OUTPUT
ResultSet has to be set to none!
I had the same problem.
When you execute the task check the 'Progress' tab; this will give you a 'fully fledged' error details.
In my case I didn't map the parameter which I created in the SQL Task to the actual one in the Stored Procedure.
So, double click the SQL Task, click on Parameter Mapping on the left hand side, then Create the parameters and their respective mappings. Here is a screenshot (in version 2012):
I faced with a similar issue after upgrading to SSDT for VS 2013 (the problem was with lookup element).
Fixed by using this answer:
EXEC ('dbo.MyStoredProcedure')
WITH RESULT SETS
(
(
MyIntegerColumn INT NOT NULL,
MyTextColumn VARCHAR(50) NULL,
MyOtherColumn BIT NULL
)
)
use the same command you use to run the stored procedure in MySQL workbench
call ();
USE this command in Execute SQL Task

Selecting data from a different schema within a stored procedure

Consider this:
CREATE PROCEDURE [dbo].[setIdentifier](#oldIdentifierName as varchar(50), #newIdentifierName as varchar(50))
AS
BEGIN
DECLARE #old_id as int;
DECLARE #new_id as int;
SET #old_id = (SELECT value FROM Configuration WHERE id = #oldIdentifierName);
SET #new_id = (SELECT value FROM Configuration WHERE id = #newIdentifierName);
IF #old_id IS NOT NULL AND #new_id IS NOT NULL
BEGIN
UPDATE Customer
SET type = #new_id
WHERE type = #old_id;
END;
END
[...]
EXECUTE dbo.setIdentifier '1', '2';
What this does is create a stored procedure that accepts two parameters which it then uses to update a Customer table.
The problem is that the entire script above runs within a schema other than "dbo". Let's just assume the schema is "company1". And when the stored procedure is called, I get an error from the SELECT statement, which says that the Configuration table cannot be found. I'm guessing this is because MS SQL by default looks for tables within the same schema as the location of the stored procedure, and not within the calling context.
My question is this:
Is there some option or parameter or switch of some kind that will
tell MS SQL to look for tables in the "caller's default schema" and
not within the schema that procedure itself is stored in?
If not,
what would you recommend? I don't really want to prefix the tables
with the schema name, because it would be kind of unflexible to do
that. So I'm thinking about using dynamic sql (and the schema_name()
function which returns the correct value even within the procedure),
but I am just not experienced enough with MS SQL to construct the
proper syntax.
It would be a tad more efficient to explicitly specify the schema name. And generally speaking, schema's are mainly used to divide a database into logical area's. I would not anticipate on tables schema-hopping often.
Regarding your question, you might want to have a look at the 'execute as' documentation on msdn, since it allows to explicitly control your execution context.
I ended up passing the schema name to my script as a property on the command line for the "sqlcmd" command. Like this:
C:/> sqlcmd -vSCHEMANAME=myschema -imysqlfile
In the SQL script I can then access this variable like this:
SELECT * from $(SCHEMANAME).myTable WHERE.... etc
Not quite as flexible as dynamic sql, but "good enough" as it were.
Thanks all for taking time to respond.

How to Parse and Append text to a stored procedure in SQL Server 2005 via a parameter

Does anyone know of a way to append text to a stored procedure from within another stored procedure? I would like to do something like the following in SQL Server 2005:
Declare str as Nvarchar(Max) = ''
set #spStr = dbo.spTest + 'Where testCol1 = ''Test'''
exec(#spStr)
I understand this may open some discussion about SQL injection attacks. I'm simply looking to see if syntax exsists to extend a stored procedure by passing it a where clause dynamically in the above manner.
There is no syntax like this available in Sql Server any version. You've got a couple of options:
You could obviously modify the procedure to include a parameter that the procedure code itself would handle as a filter in the final statement(s) that returned the result set from the procedure call. Though I'd advise against it, you could certainly have a parameter that was just a varchar/nvarchar data type which included the actual 'where' clause you want to add and have the procedure code append it to these final select statement(s) as well
Use the insert/exec syntax to populate a temp table with the results of the stored procedure execution and then simply run a filtered select against that temp table.
There are some options.
You can alter the actual SP using the metadata in INFORMATION_SCHEMA.ROUTINES (not really what I think you are wanting to be doing)
You can parameterize the SP - this should not be vulnerable to injection if the SP uses the variable directly and not to dynamically make SQL.
You might consider using a view or an inline or multi-step table-valued function instead, which can be used like a parameterized view (inline being more efficient) - SELECT * FROM udf_Test WHERE TestCol1 = 'Test'.
You can take the results of the SP and put them in a temporary table or table variable and query against that.