in my current project I use a lot of stored procedures. In order to reduce the number of SPs I am thinking of putting several queries in one SQ, i. E.
enter code here#ArtQuery int = 0
/*
0 = SELECT
1 = INSERT
2 = UPDATE
3 = DELETE
*/
enter code hereAS
SET NOCOUNT ON;
SELECT
CASE
WHEN #ArtQuery = 0
--Select Statement
WHEN #ArtQuery = 1
--Insert Statement
Unfortunately that does not work. The select statement is accepted, the others aren't. Is that my mistake or isn't it possible having different queries in one SP?
I solved the problem by using IF clauses instead.
Related
I am facing an issue with the query in postgreSql. Below is the query.
UPDATE t_e20so1_fieldrulethen AS fthen
SET c_thenfieldid = t1.c_fieldschemaid
FROM t_sys_fieldschema AS t1
WHERE fthen.c_lyrathenfieldid = t1.c_lyraid
AND fthen.c_rulefor = 5
AND t1.c_fieldtype = 18
AND t1.c_tablegroupsid IN (
CASE
WHEN fthen.c_iffieldid = t1.c_id THEN (SELECT
c_targettableid
FROM t_sys_tablegroups
WHERE c_parentid = 'c0b2f85c-bc93-466b-a54d-b1330440db98')
ELSE (SELECT c_targettableid
FROM t_sys_tablegroups
WHERE c_parentid =
'c0b2f85c-bc93-466b-a54d-b1330440db98')
END );
As per above query, i am updating t_e20so1_fieldrulethen table from t_sys_fieldschema. One of the conditions to check is t_sys_fieldschema.c_tablegroupsid should be having specific values which are in and I am fetching them from table t_sys_tablegroups.
Above query gives me error as shown below:
ERROR: more than one row returned by a subquery used as an expression
SQL state: 21000
Here, if I remove case from the query (below is what I mean) it works properly.
UPDATE t_e20so1_fieldrulethen AS fthen
SET c_thenfieldid = t1.c_fieldschemaid
FROM t_sys_fieldschema AS t1
WHERE fthen.c_lyrathenfieldid = t1.c_lyraid
AND fthen.c_rulefor = 5
AND t1.c_fieldtype = 18
AND t1.c_tablegroupsid IN (SELECT c_targettableid
FROM t_sys_tablegroups
WHERE
c_parentid = 'c0b2f85c-bc93-466b-a54d-b1330440db98')
Now I have only one select query in the "IN" clause.
I've checked that kind of case statement(two nested selects) - and it cannot be done that way. You generate two separate lists in one CASE.
One list for all records where fthen.c_iffieldid = t1.c_id and the other for ELSE statement.
As I wrote many times never use nested selects in "IN" clause. It is killing performance and causing many problems. Use "EXISTS".
As your CASE seems to be redundant (both WHEN and ELSE returns same value) change it that way and it will be faster.
UPDATE t_e20so1_fieldrulethen AS fthen
SET c_thenfieldid = t1.c_fieldschemaid
FROM t_sys_fieldschema AS t1
WHERE fthen.c_lyrathenfieldid = t1.c_lyraid
AND fthen.c_rulefor = 5
AND t1.c_fieldtype = 18
AND exists (select from t_sys_tablegroups t2
where t1.c_tablegroupsid=t2.c_targettableid
and c_parentid = 'c0b2f85c-bc93-466b-a54d-b1330440db98');
I am creating a temporary table in some dynamic SQL. But when I call it it throws an "Invalid object name '#Settlement_Data_Grouped'" error.
I am assuming it's because dynamic SQL uses it's own seperate instance? So that it is dropped and not available to the outside SQL? It works when I use ##Settlement_Data_Grouped or create a table. But this doesn't help when multiple people are calling the sproc.
I'm thinking I could check if the table exists but that would mean I would have to delete contents and different users may require different outputs which would mean it would not work.
So does anyone have a solution/suggestion I can use where multiple people can be calling the same sproc?
IMHO you do not need the Dynamic SQL. You can change your code like something below and that will give you same result as you are trying to accomplish. Please check for any syntax error if any. I would have provided you full query but in your question you have screenshot instead of the code. So here it goes.
If you want to use Temp Tables:
SELECT
......
INTO #Settlement_Data_Grouped
FROM #Settlement_Data
WHERE (Payment_Date < Settlement_Date AND #outputType = 1) ---This will be true when you have #outputType = 1
OR #outputType = 0 ---This will be true when you have #outputType = 0
GROUP BY Part_No
,NAME
,Order_No
,Invoice_No
-------------
SELECT
......
FROM #Settlement_Data_Grouped
If you want to use CTE:
WITH Settlement_Data_Grouped
AS (
SELECT
......
FROM #Settlement_Data
WHERE (Payment_Date < Settlement_Date AND #outputType = 1) ---This will be true when you have #outputType = 1
OR #outputType = 0 ---This will be ture when you have #outputType = 0
GROUP BY Part_No
,NAME
,Order_No
,Invoice_No
)
SELECT
......
FROM Settlement_Data_Grouped
The problem is that the temp table only exists within the scope of the dynamic SQL execution context. The way around it would be to create the temp table outside of the dynamic SQL and then insert into it:
CREATE TABLE #Settlement_Data_Grouped (PartNo varchar(50) ......)
INSERT INTO #Settlement_Data_Grouped
EXEC(#selectSQL)
In the table below I am storing some conditions like this:
Then, generally, in second table, I am having the following records:
and what I need is to compare these values using the right condition and store the result ( let's say '0' for false, and '1' for true in additional column).
I am going to do this in a store procedure and basically I am going to compare from several to hundreds of records.
What of the possible solution is to use sp_executesql for each row building dynamic statements and the other is to create my own scalar function and to call it for eacy row using cross apply.
Could anyone tell which is the more efficient way?
Note: I know that the best way to answer this is to make the two solutions and test, but I am hoping that there might be answered of this, based on other stuff like caching and SQL internal optimizations and others, which will save me a lot of time because this is only part of a bigger problem.
I don't see the need in use of sp_executesql in this case. You can obtain result for all records at once in a single statement:
select Result = case
when ct.Abbreviation='=' and t.ValueOne=t.ValueTwo then 1
when ct.Abbreviation='>' and t.ValueOne>t.ValueTwo then 1
when ct.Abbreviation='>=' and t.ValueOne>=t.ValueTwo then 1
when ct.Abbreviation='<=' and t.ValueOne<=t.ValueTwo then 1
when ct.Abbreviation='<>' and t.ValueOne<>t.ValueTwo then 1
when ct.Abbreviation='<' and t.ValueOne<t.ValueTwo then 1
else 0 end
from YourTable t
join ConditionType ct on ct.ID = t.ConditionTypeID
and update additional column with something like:
;with cte as (
select t.AdditionalColumn, Result = case
when ct.Abbreviation='=' and t.ValueOne=t.ValueTwo then 1
when ct.Abbreviation='>' and t.ValueOne>t.ValueTwo then 1
when ct.Abbreviation='>=' and t.ValueOne>=t.ValueTwo then 1
when ct.Abbreviation='<=' and t.ValueOne<=t.ValueTwo then 1
when ct.Abbreviation='<>' and t.ValueOne<>t.ValueTwo then 1
when ct.Abbreviation='<' and t.ValueOne<t.ValueTwo then 1
else 0 end
from YourTable t
join ConditionType ct on ct.ID = t.ConditionTypeID
)
update cte
set AdditionalColumn = Result
If above logic is supposed to be applied in many places, not just over one table, then yes you may think about function. Though I would used rather inline table-valued function (not scalar), because of there is overhead imposed with use of user defined scalar functions (to call and return, and the more rows to be processed the more time wastes).
create function ftComparison
(
#v1 float,
#v2 float,
#cType int
)
returns table
as return
select
Result = case
when ct.Abbreviation='=' and #v1=#v2 then 1
when ct.Abbreviation='>' and #v1>#v2 then 1
when ct.Abbreviation='>=' and #v1>=#v2 then 1
when ct.Abbreviation='<=' and #v1<=#v2 then 1
when ct.Abbreviation='<>' and #v1<>#v2 then 1
when ct.Abbreviation='<' and #v1<#v2 then 1
else 0
end
from ConditionType ct
where ct.ID = #cType
which can be applied then as:
select f.Result
from YourTable t
cross apply ftComparison(ValueOne, ValueTwo, t.ConditionTypeID) f
or
select f.Result
from YourAnotherTable t
cross apply ftComparison(SomeValueColumn, SomeOtherValueColumn, #someConditionType) f
Consider the following query and notice the CALCULATE_INCENTIVE function:
SELECT EMP.* FROM EMPLOYEES EMPS
WHERE
EMP.STATUS = 1 AND
EMP.HIRE_DATE > TO_DATE('1/1/2010') AND
EMP.FIRST_NAME = 'JOHN' AND
CALCULATE_INCENTIVE(EMP.ID) > 1000
ORDER BY EMPS.ID DESC;
I was under the impression that Oracle uses the same (or similar) short-circuitry that .NET uses in its and/or logic. For example, if EMP.STATUS = 2, it won't bother evaluating the rest of the expression since the entire expression would return false anyway.
In my case, the CALCULATE_INCENTIVE function is being called on every employee in the db rather than only on the 9 records that the first three WHERE expressions return. I've even tried putting parenthesis around the specific expressions that I want to group together for short-circuit evaluation, but I can't figure it out.
Anyone have any ideas how to get the CALCULATE_INCENTIVE not to be evaluated if any of the previous expressions return false?
One way is to put the primary criteria into a subquery that Oracle can't optimize away, then put the secondary criteria into the outer query. The easiest way to ensure that Oracle doesn't optimize out the subquery is to include rownum in the select statement:
SELECT * FROM (
SELECT EMP.*, ROWNUM
FROM EMPLOYEES EMPS
WHERE
EMP.STATUS = 1
AND EMP.HIRE_DATE > TO_DATE('1/1/2010')
AND EMP.FIRST_NAME = 'JOHN')
WHERE CALCULATE_INCENTIVE(ID) > 1000
ORDER BY EMPS.ID DESC;
Oracle supports short-circuit evaluation in PL/SQL. In SQL, however, the optimizer is free to evaluate the predicates in whatever order it desires, to push predicates into views and subqueries, and to otherwise transform the SQL statement as it sees fit. This means that you should not rely on predicates being applied in a particular order and makes the order predicates appear in the WHERE clause essentially irrelevant. The indexes that are available, the optimizer statistics that are present, the optimizer parameters, and system statistics are all vastly more important than the order of predicates in the WHERE clause.
In PL/SQL, for example, you can demonstrate this with a function that throws an error if it's actually called.
SQL> ed
Wrote file afiedt.buf
1 create function throw_error( p_parameter IN NUMBER )
2 return number
3 as
4 begin
5 raise_application_error( -20001, 'The function was called' );
6 return 1;
7* end;
SQL> /
Function created.
SQL> ed
Wrote file afiedt.buf
1 declare
2 l_num NUMBER;
3 begin
4 l_num := 1;
5 if( l_num = 2 and throw_error( l_num ) = 2 )
6 then
7 null;
8 else
9 dbms_output.put_line( 'Short-circuited the AND' );
10 end if;
11 if( l_num = 1 or throw_error( l_num ) = 2 )
12 then
13 dbms_output.put_line( 'Short-circuited the OR' );
14 end if;
15* end;
16 /
Short-circuited the AND
Short-circuited the OR
PL/SQL procedure successfully completed.
In SQL, on the other hand, the order of operations is determined by the optimizer, not by you, so the optimizer is free to short-circuit or not short-circuit however it wants. Jonathan Gennick has a great article Subquery Madness! that discusses this in some detail. In your particular case, if you had a composite index on (FIRST_NAME, HIRE_DATE, STATUS) along with appropriate statistics, the optimizer would almost certainly use the index to evaluate the first three conditions and then only call the CALCULATE_INCENTIVE function for the ID's that met the other three criteria. If you created a function-based index on CALCULATE_INCENTIVE(id), the optimizer would likely use that rather than calling the function at all at runtime. But the optimizer would be perfectly free to decide to call the function for every row in either case if it decided that it would be more efficient to do so.
I have a SP with which I fetch a defined amount of rows. How can I change the value of a column in the fetched rows? Such as 'has been fetched' = 1.
Any advice?
EDIT:
The SP looks something like this
SET ROWCOUNT #numberOfRows
SELECT * FROM tableA where notSent = 1
I would like to change the 'notSent' colum for all the rows that i fetch. Is this possible?
1) Don't use Select * in a stored procedure - always specifically list the fields required as shown below - replace field1,2,3 etc with the actual fields you want returned.
OK - Modified answer:
2) Set a flag on the columns you want to select and update with a value that will not be otherwise programmatically set - e.g. -1 - Then select these records, then update them to set the final value required. Doing it this way will avoid the possibility that you will update a different set of records to those selected, due to inserts occurring half-way through the stored procedure's execution. You could also avoid this by use of locks, but the way below is going to be far healthier.
UPDATE Table set notSent = -1 WHERE notSent = 0
SELECT ... from Table where notSent = -1
UPDATE Table set notSent = 1 where notSent = -1