I have a package which is deployed using SQL server agent.
I am executing the SQL server agent by calling a stored procedure.
i have declared some variables inside the ssis package ,i want to use these variables as parameter in stored procedure.
any body Please help me.
Thanks in advance.
If you are allowed to use xp_cmdshell you could use dtexec to execute the package from a stored procedure . Passing a parameter can be done like this:
exec xp_cmdshell 'dtexec /f "c:demo\demo.dtsx" set \package.configurations[Configuration1].properties[Variable].value;int-002'
This is not a best practice. I would prefer to use my stored procedure to write my variables to a table first and then read from that table in SSIS with an Execute SQL statement as you can read here Populate an SSIS variable using a SQL statement
Related
I am trying to get output messages from SP into SSIS variable inside Execute SQL Task. I am able to get messages if stored proc execute successfully, but in case stored procedures raise errors, then variables remain empty as below-
Now in case sp execute completed successfully then ssis variables got data,
but in case of sp execute with errors then ssis variables remain empty and execute SQL task component fails (which is desired behaviour).
Please guide. Thankyou!
If execute SQL task fails, output variables are not populated.
Best option is to change your stored procedure and wrap all the code in the try/catch block. This way you will be able to always populate variables, just be sure to fail SSIS package if you receive internal errors.
If you use RAISERROR in the stored procedure, only information available to SSIS is the error message withing the RAISERROR statement. You can retrieve this information by creating OnError handler in SSIS and then it will be available in the system variable: "System::ErrorDescription"
I'm trying to build a transformation in Kettle that gets FIELDS from a SQL Server Stored Procedure and inserts it in a MySql table.
The problem is that I can't find a way to get stored procedure "fields". I understand that Call DB Procedure task expects in/out params, and that's not my case, so I'm trying to use "Execute SQL Statements" with the following SQL:
exec credisfera.dbo.sp_insere_parcelas #dt_ref = '2016-05-03'
Is there a way to achieve this?
Simply put the exec statement in a Table input step. Upon execution (or "Output fields...", PDI will get the metadata from the JDBC driver.
I am presently updating a procedure with multiple EXEC lines such as:
EXEC databasename.tablename.pr_sys_drop_Object 'zt_Staging_of_class'
yet nowhere have I found the definition of EXEC in this context.
If it's a full three part name where the middle part is not the name of a table but of a schema a kind of SQL namespace. So in that context pr_sys_drop_Object is a stored procedure in a separate schema.
If you look in the named database, in the named schema you'll probably find a stored procedure called pr_sys_drop_Object.
Execute is a sql server keyword see the docs here for more details. It is used to execute stored procedures or raw sql.
In your case it seems to be executing the procedure databasename.tablename.pr_sys_drop_Object and passing in 'zt_Staging_of_class' as a parameter to that procedure.
I want to execute a stored procedure using a SSIS package.
The output that generates from this stored procedure will also a script, so I want to execute that script output too. Can I schedule this SSIS package using SQL Server Agent?
You can execute a stored procedure in an Execute SQL Task in SSIS and send the output to a variable. You can then read the content of that variable in a second Execute SQL Task.
And yes, you can schedule the package to execute via a SQL Server Agent job. See this link for details.
Cheers -
In SSIS Execute SQL Task currently I am calling a stored procedure and inside the procedure I have a MERGE statement.
Is there any difference if I call that query (T-SQL MERGE) directly in the Execute SQL Task?
(are there any differences like Log will create if we used SP?)
Please reply me...
Thanks in advance
Stored procedure will provide you with a more maintainable solution as you will be able to leverage code reuse and there will be no need to change / re-release the package if your query logic changes
A stored procedure is also likely to provide you with the fastest execution time as it will be compiled and the execution plan will be reused on subsequent runs