In a stored procedure, I've to build my own SQL request(because tables names and some properties names are known only at execution time(parameters)).
So Basically I've something like this
EXECUTE IMMEDIATE WITH RESULT SET OFF 'My custom query which select one data'
Usually, I would use the INTO commands, but my parameter is recognized inside the Execute immediate, which seems logic.
(Before you ask: I cannot return this in a result set, the result set is used for another data(and the result of this EXECUTE IMMEDIATE will determine which query I will run(and must be returned)).
How would you approach this problem? I guess it's the same problem on SQL Server-... but I didn't tested on it
You could create a table in compiled Sql and then the dynamic Sql populates it, so that the compiled sql statement after the dynamic part can read the results and update them onto your output params.
Related
I have a Stored Procedure: myProcedure returning 2 different resultset in the end like:
select * from #alldata where <condition1>
and
select * from #allData where <condition2>
Please note that I am not allowed to modify the SP.
What I need is to get the second (last) result set returned from the SP and save it in a temp table in SSIS 2012.
I managed to do is by using a script task including the line:
DataSet ds = db.ExecStoredProcedureDataSet("[myProcedure]", sqlFilters).Tables[1];
I wonder if there is a way to handle it by using "Execute SQL Task" instead.
When I check the topic below, it seems it would be possible if the SP returned one resultset only, but couldn't find a way in my situation where the SP returns multiple resultset and I need the last one saved in a temp table only. Any help would be appreciated.
Insert results of a stored procedure into a temporary table
Edit: It is not duplicate of the indicated topic, I need a solution that would work in Execute SQL Task process in the Control flow of SSIS.
From the docs:
If the Execute SQL task uses the Full result set result set and the
query returns multiple rowsets, the task returns only the first
rowset. If this rowset generates an error, the task reports the error.
If other rowsets generate errors, the task does not report them.
So, SSIS Execute SQL Task cannot access multiple result sets from a single proc. Only the first can be accessed.
I'm writing a stored procedure which checks for the existence of various tables in various databases, as well as the permissions that the user executing the stored procedure has on those tables. The stored procedure itself resides within a user database (i.e. it's not in the Master db).
To perform my checks, my stored procedure contains lots of SELECT statements. Each of those obviously returns a record set. What I would like is to somehow suppress these record sets so that they are not returned by the stored procedure, and instead return my own, single record set which is just a collection of messages relating to each check the stored procedure performs.
I think the obvious answer is to use a table-valued function instead, but I've not been able to recreate my tests successfully in a Function as they appear in the stored procedure. For starters, I'm having to use temporary tables (not possible in a function) and dynamic SQL (not very compatible with table parameters).
I think I've basically got two choices:
Rewrite my stored procedure as a function and figure out how to do the checks a different way.
Continue using my stored procedure and use an OUTPUT parameter to return my result messages, probably as a delimited string, and in the associated ASP.NET application just ignore all the record sets the stored procedure returns .
Neither of these solutions is very satisfactory. Before I spend any more time pursuing either one, is there a way to discard the record sets produced by the SELECT statements in a stored procedure and explicitly define what record I want it to return?
Hmm, I only can speculate here...
Are you using something like
SELECT ...;
IF ##rowcount > 0
BEGIN
...
END;
?
Then you can rewrite it using something like
IF EXISTS (SELECT ...)
BEGIN
...
END;
or
DECLARE #variable integer;
SELECT #variable = count(*) ...;
IF #variable > 0
BEGIN
...
END;
In general point the results of your queries to a target (variable, table, expression, ...), then they don't get outputted.
And then just execute the query for your desired result in the end.
In my opinion, here is almost no reason to have stored procedures produce record sets. That is what stored functions are for. On occasion, it is needed, because of the use of dynamic SQL or other stored procedures, but not as a general practice. Much, much too often, I see stored procedures being used where stored functions or views are more appropriate.
What should you do? Even SELECT statement in the stored procedure should be one of the following:
Setting (local) variables.
Saving the results in a temporary table or table variable.
The logic for the stored procedure should be working on the local variables. The results should be returned using OUTPUT parameters.
If you need to return rows in a tabular format, you can do that using tables explicitly (such as a global temporary table or real table). Or, you can have one SELECT at the end that does return a single result set. However, if you need this and can phrase the stored procedure as a function, that is better in my opinion.
I have a procedure, based on the parameters, the where condition would differ.
The OUT parameters have to be INTO clause so that I can return the columns from the procedure.
Rather than having SQL condition for each if condition, what is the efficient way of doing this.
It looks to me more like a design question.
So it depends on what you need to achieve and how you want to organize your code.
Possibilities
1- your "if" chain of queries in the same procedure
2- one procedure for each query
3 - if the differencies between the "where" parts are not so big use sql constructs, including unions, case , and\or etc to let coexist different cases in one query
4- build sql dynamically and use execute immediate
Usually i don't like the 1, i would try with 3 or 4, then proceed with 2 if i can't.
EDIT
With dynamic sql, for getting out results you can do
EXECUTE IMMEDIATE stmt into o_total_count,o_total_sum,o_hold_status,o_normal_status;
In case you have input params for the query, you have to mark them with : and then add the USING clause with the appropriate input param.
Example
EXECUTE IMMEDIATE 'select count(*) from departments where department_id=:id' INTO l_cnt USING l_dept_id;
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.
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.