Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 6 months ago.
The community reviewed whether to reopen this question 6 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I am using these statements in a postgres function.
Select count(*) into V_check
from employee
where employee_name like 'Raj%';
if V_check == 0
then
update exception set exception_found = 'Raj';
end if;
I get this error :
ERROR: operator does not exist: integer == integer
LINE 1: SELECT V_check == 0
You should use = instead of ==.
Here is a list of the different comparison operators that you can use:
Operator Description
= Equal
<> Not equal. Note: In some versions of SQL this operator may be written as !=
> Greater than
< Less than
>= Greater than or equal
<= Less than or equal
BETWEEN Between an inclusive range
LIKE Search for a pattern
IN To specify multiple possible values for a column
As pointed out, the comparison operator for equality is = not ==. However, you should write the condition as:
if not exists (select 1 from employee where employee_name like 'Raj%')
then
update exception
set exception_found = 'Raj';
end if;
This saves you a declaration. Also, not exists is faster than count(*) -- because not exists can stop at the first matching row.
Or dispense with the conditional entirely:
update exception
set exception_found = 'Raj'
where not exists (select 1 from employee where employee_name like 'Raj%');
Related
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 1 year ago.
Improve this question
Context: I have a scalar function that returns a formatted string. The type of formatting performed depends on the length LEN() of the string passed - this is handled with a T-SQL CASE statement.
Question: why am I getting a syntax error when setting variable, #LengthOfString, equal to a number?
Error:
Incorrect syntax near '='
Relevant code:
CREATE OR ALTER FUNCTION FormatString
(#PassedString varchar(255) NULL)
...
DECLARE #FormattedString varchar(255)
DECLARE #LengthOfString int = LEN(#PassedString)
SET #FormattedString = (SELECT
CASE #LengthOfString
WHEN #LengthOfString = 5
THEN RETURN Format(<formatting>)
WHEN ...
Remove #LengthOfString next to the CASE
That statement should look like this:
SET #FormattedString = (SELECT CASE
WHEN #LengthOfString = 5 THEN RETURN Format(<formatting>)
WHEN ...
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 1 year ago.
Improve this question
I am trying to check whether an entered number is odd or even I am getting an error
declare
num:=:num
if(num mod 2=0) then
dbms_output.put_line(num|| 'is even');
else
dbms_output.put_line(num||' is odd');
end if;
end;
The documentation for the modulo function is here which tells you the syntax is MOD(n1, n2) and not n1 MOD n2 and you are missing the BEGIN statement:
You want:
declare
num:=:num
begin
if mod(num, 2)=0 then
dbms_output.put_line(num|| 'is even');
else
dbms_output.put_line(num||' is odd');
end if;
end;
You can simplify it by removing the intermediate variable and just using the bind variable throughout and can remove the IF statement and multiple output statements and use a single CASE (and handle NULL values):
BEGIN
DBMS_OUTPUT.PUT_LINE(
:num || CASE MOD(:num, 2)
WHEN 0 THEN ' is even'
WHEN 1 THEN ' is odd'
ELSE ' is neither odd nor even.'
END
);
END;
/
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 4 years ago.
Improve this question
I am getting Divide by zero error for the following statement.
select ((((57151130.0000000000)+(57612530.0000000000))/2)/((12548020.0000000000)-(34321580.0000000000)+(21773560.0000000000)))*366
The fact that you are supplying literal values is a little odd, however, one method of avoiding a divide by 0 error is using NULLIF (Transact-SQL).
NULLIF takes 2 parameters. If the values of the 2 expressions for the parameters are the same value, then NULLIF returns NULL, otherwise it returns the value of the first expression. For example (in literal terms):
SELECT NULLIF(1,0), NULLIF('a' + 'b' + 'c','abc');
This returns the values 1 and NULL. For your query, the format would therefore be:
SELECT (((57151130.0000000000+57612530.0000000000)/2)/NULLIF(12548020.0000000000-34321580.0000000000+21773560.0000000000,0))*366
Note I have removed several of the parenthesis as there's no need to wrap every value/expression in a pair. Doing so will likely lower readability.
Then, if the expression under the divisor has the value 0, the value NULL will be returned instead. Considering that NULL represents an unknown value, and {expr}/0 is certainly an unknown value as well, the value would be the most appropriate.
If you then need to represent the NULL value in a particular way, you can wrap the whole expression in a further ISNULL.
In addition, you can use CASE to check zero values statement:
select (
(((57151130.0000000000)+(57612530.0000000000))/2)
/
CASE WHEN((12548020.0000000000)-(34321580.0000000000)+(21773560.0000000000)) = 0 THEN NULL
ELSE ((12548020.0000000000)-(34321580.0000000000)+(21773560.0000000000))
END
)*366
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 4 years ago.
Improve this question
scenario:
In Oracle Database, This SQL it's much slower:
SELECT *
FROM TBL_MAIN A, TBL_CHILD_1 B, TBL_CHILD_2 C, TBL_CHILD_3 D, TBL_CHILD_4 E
WHERE A.ID_MAIN = B.ID_MAIN
AND A.ID_MAIN = C.ID_MAIN
AND A.ID_MAIN = D.ID_MAIN
AND A.ID_MAIN = E.ID_MAIN;
than that:
SELECT *
FROM TBL_MAIN X, TBL_CHILD_1 B, TBL_CHILD_2 C, TBL_CHILD_3 D, TBL_CHILD_4 E
WHERE X.ID_MAIN = B.ID_MAIN
AND X.ID_MAIN = C.ID_MAIN
AND X.ID_MAIN = D.ID_MAIN
AND X.ID_MAIN = E.ID_MAIN;
In other words, When I have 3 or more tables joined if I use "A" as an aliasing for "TBL_MAIN" table, it results in a slower query.
It becomes worst when I added more tables in an inner join with table "TBL_MAIN" AS "A".
What is happening?
Yes it is. It is part of unary collection operator "IS A SET". In Oracle it is bit complicated, in order to guarantee backward compatibility Oracle has "reserved words" and "keywords". One of them can not be used as identifiers, while others might have special meaning is some contexts - but still can be used as identifiers.
For example you can still use SQL like
select * from commit;
or
select * from join where X is a set;
words like commit, join, model can still be used as identifiers.
Of course this can not have influence on speed of SQL evaluation. Especially when cursor is reused. It might only slow down speed of parsing.
I found that X is actually faster than A, but Z is even slower:
Alias A 60.257 seconds
Alias X 57.747 seconds
Alias Y 58.383 seconds
Alias Z 62.157 seconds
To be honest, these differences are to small to prove a difference between the names of the aliases.
I tested it with 5 large tables (tbl_main 22 million, tbl_child 17 million etc). And I changed SELECT * into SELECT COUNT(*) to make sure all rows are processed. The first execution is ignored to warm the caches. The next three runs are averaged.
DECLARE
FUNCTION test1(c VARCHAR2) RETURN NUMBER IS
time1 NUMBER; time2 NUMBER; stmt VARCHAR2(3000); n NUMBER;
BEGIN
stmt := q'!
SELECT count(*)
FROM tbl_main #, tbl_child1 B, tbl_child2 C, tbl_child3 D, tbl_child4 E
WHERE #.geb_id = B.geb_id
AND #.geb_id = C.geb_id
AND #.geb_id = D.geb_id
AND #.geb_id = E.geb_id
!';
stmt := REPLACE(stmt, '#', c);
--dbms_output.put_line(stmt);
time1 := dbms_utility.get_time();
EXECUTE IMMEDIATE stmt INTO n;
time2 := dbms_utility.get_time();
return (time2-time1)/100;
END test1;
PROCEDURE test3(c VARCHAR2) IS
ignore NUMBER; seconds NUMBER;
BEGIN
ignore := test1(c);
seconds := (test1(c)+test1(c)+test1(c)) / 3;
DBMS_OUTPUT.PUT_LINE('Alias '||c||' '||round(seconds,3)||' seconds');
END test3;
BEGIN
test3('A');
test3('X');
test3('Y');
test3('Z');
END;
/
Yes. It is in 12c.
SELECT KEYWORD
FROM V$RESERVED_WORDS
WHERE KEYWORD = 'A'
;
Short answer no. A is not a reserved word. If it would be a reserved word, it would raise an error. However to analyze your performance problem, you would need to post the metrics for query execution.
The problem solved itself!
Now the two SQL has the same time, just a little faster like #wolφi said.
This scenario was going on for two days, but now its normal.
I believe after a shutdown the database became normal.
An interesting thing about this is when the problems were happening, SQL Tuning Advisor suggested an execution plan for the SQL who make work normal (99,9 % faster). unfortunately, I didn't save recommendation report in that time to show here.
but now without any SQL profile active, the SQL's are with the same time.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
I am querying part numbers from an Oracle (JDE) database. If I use the clause WHERE Item LIKE 'AS-%', it correctly returns all the items that begin with 'AS-'. However, when I try to narrow that set by instead using the clause WHERE Item LIKE 'AS-%A' in order to find all parts matching the pattern and ending with an 'A', I get no results, even though they do exist!
What gives?
When you think that your query is misidentifying rows based on your understanding of the rows' values, examine the values using the DUMP() function.
This will tell you the exact contents of the cell, including any characters that you cannot see on the display.
I doubt if there is some space or non printable character present at the end of column values.
'AS-%A' must work if value actualy start with AS- and ends with A
To check, try to query using trim(Item) like 'AS-%A'
Perhaps some control characters at end of the data that you cannot see. Try using regexp_like:
with x as (
select 'AS-123B' as col from dual
UNION
select 'AS-456A' as col from dual
UNION
select 'AS-789A' || chr(0) as col from dual
)
select * from x
where regexp_like (col, 'AS-(.*)A[[:cntrl:]]?')
Output:
COL
AS-456A
AS-789A