My current SQL is as below:
CASE
WHEN PARENT.ASLNO IS NULL THEN SUBCATEGORIES.SUBCATEGORY_LIST
-- #5098
ELSE DECODE(ASL.CATEGORY_NAME, null,
NVL(SUBCATEGORIES.SUBCATEGORY_LIST,
SUBCATEGORIES_PARENT.SUBCATEGORY_LIST),
decode(SUBCATEGORIES.SUBCATEGORY_LIST,null,null,'N/A'))
-- End #5098
END AS SUPSPD_SUBCATEGORY_LIST
I am trying to change the following sql
DECODE(ASL.CATEGORY_NAME, null,
NVL(SUBCATEGORIES.SUBCATEGORY_LIST,
SUBCATEGORIES_PARENT.SUBCATEGORY_LIST),
decode(SUBCATEGORIES.SUBCATEGORY_LIST,null,null,'N/A'))
to
DECODE(ASL.CATEGORY_NAME, null,
DECODE(SUBCATEGORIES.SUBCATEGORY_LIST,
SUBCATEGORIES_PARENT.SUBCATEGORY_LIST),
decode(SUBCATEGORIES.SUBCATEGORY_LIST,null,null,'N/A'))
but I am getting ORA-00938 not enough arguments for function?
This:
NVL(SUBCATEGORIES.SUBCATEGORY_LIST,
SUBCATEGORIES_PARENT.SUBCATEGORY_LIST)
returns the parent subcategory list if the child's is null.
Decode needs at least three argumentsm but you're only supplied two; you have the first search value but no result, and no default either, which means you don't always get a value back.
The equivalent for your NVL would be:
DECODE(SUBCATEGORIES.SUBCATEGORY_LIST, NULL,
SUBCATEGORIES_PARENT.SUBCATEGORY_LIST, SUBCATEGORIES.SUBCATEGORY_LIS),
I'm not really sure why you'd want to make the statement longer and a bit harder to understand... for some consistency I might even be tempted to change
decode(SUBCATEGORIES.SUBCATEGORY_LIST,null,null,'N/A')
to
NVL2(SUBCATEGORIES.SUBCATEGORY_LIST, 'N/A', null)
You have changed:
NVL(SUBCATEGORIES.SUBCATEGORY_LIST, SUBCATEGORIES_PARENT.SUBCATEGORY_LIST)
to:
DECODE(SUBCATEGORIES.SUBCATEGORY_LIST, SUBCATEGORIES_PARENT.SUBCATEGORY_LIST)
DECODE needs at least 3 arguments.
Aside
I find it much easier to debug complex expressions like this by laying them out nicely just like any other code:
DECODE( ASL.CATEGORY_NAME
, null
, DECODE ( SUBCATEGORIES.SUBCATEGORY_LIST
, SUBCATEGORIES_PARENT.SUBCATEGORY_LIST
)
, decode ( SUBCATEGORIES.SUBCATEGORY_LIST
, null
, null
, 'N/A'
)
)
Related
I'm trying to write a conditional statement in Oracle. There's a table for customers' accounts.
The logic is: If the Account_Close_Date contains values, it means the account has been closed by the customer, so the 'Status' should be "closed". Otherwise, the 'Status' should be "Open".
I write something like this:
select
CASE Account_Close_Date WHEN null THEN 'Open'
ELSE 'Closed' END as Status,
Account_Close_Date
from customer_account_Table
However, it doesn't work. The "Status" is all "closed", even if there is no value in "Account_Close_Date".
CASE "statements" do exist, but only in PL/SQL, not in plain SQL. What you have in your SELECT statement is an example of a CASE expression.
CASE expressions have two syntactical forms: searched and simple. You have an example of a simple CASE expression, one where the conditions are equality conditions. Problem is, in the three-valued logic of SQL, nothing is ever equal to NULL. Your condition is "if so-and-so-date equals NULL, then..." which is never TRUE.
Instead, use the searched syntax (already shown in a comment under your question):
CASE WHEN so-and-so-date IS NULL THEN ... ELSE ... END as ...
Try to use brackets:
SELECT Account_Close_Date, (CASE WHEN Account_Close_Date IS NULL THEN 'Open' ELSE 'Closed' END) as status FROM customer_account_Table;
See http://sqlfiddle.com/#!4/186d47/9
this is my first post here, I'd like to ask for help on a theoretically simple query.
The current query I'm creating is to try and generate a random number, which will be identified as even or odd. Depending on that value, it should print either "M" as even, or "W" as odd. Though when I try using a case inside the select, I'm getting the "missing keyword" error. This is my following code:
select
case
when mod(round(dbms_random.value(1,100)),2) = 0 then dbms_output.put_line('M');
when mod(round(dbms_random.value(1,100)),2) = 1 then dbms_output.put_line('W');
end
from dual
I've tried checking the website for similar problems, and while I've found similar problems and people getting the solution correctly, I don't quite know what I'm missing here. When I run the select alone, I get the even or odd number I want to get, but not when I try to print out a result.
SELECT statement cannot PRINT, it can only RETURN something.
You may use query like
select
v,
case when mod(v, 2) = 0 then 'M' else 'W' end l
from
(select round(dbms_random.value(1, 100)) v from dual)
and process it's result as you wish (print, for example).
Why are you trying to embed dbms_output in a query? Just write:
select
case
when mod(round(dbms_random.value(1,100)),2) = 0 then 'M'
when mod(round(dbms_random.value(1,100)),2) = 1 then 'W'
end
from dual
Also you know, since you are calling dbms_random two different times, you get two different values in the same query. If you want one value to be compared, then use a WITH clause
with rand_value as
( select round(dbms_random.value(1,100)) val from dual
)
select
case
when mod(val,2) = 0 then 'M'
when mod(val,2) = 1 then 'W'
end
from rand_value
You get the error because of the semicolons.
Also you are calling the random function twice and thus get two different random values. I would use IF-THEN-ELSE instead of a SELECT statement, since the latter one cannot print.
IF mod(round(dbms_random.value(1,100)),2) = 0 THEN
dbms_output.put_line('M');
ELSE
dbms_output.put_line('W');
END IF;
I have an expression in my report in Report Builder that can have 0 for the sum but when it is displayed it shows "There are Job Reqs at this time." instead of "There are 0 (or 'no') Job Reqs at this time.". How can I get the 0 (or 'no') in this statement?
It's unclear what you are asking, but it sounds like if it is zero, it is actually returning blank. So doing something like this:
=IIF(
ISNOTHING(Fields!MightBeZeroValue.Value) OR
Fields!MightBeZeroValue.Value) = "",
"0",
Fields!MightBeZeroValue.Value)
This means that if the 'MightBeZeroValue' field is null or empty, display zero, otherwise display that field. Hope this helps.
If you can do this within the SQL, then even better:
SELECT
ISNULL(MightBeZeroValue.Value, 0) AS MightBeZeroValue
FROM
SomeTable
I have an SSRS report where there is a parameter that asks the user to include records where revenue is greater than zero, or records with revenue values that are just zero.
Since the query is not a stored procedure and it is not an option to put it into a procedure, I need to use some case logic for the embedded query. I need to do this in the where clause in the end.
I am trying to do something like this:
SELECT * FROM TABLE
WHERE MY_DATE BETWEEN D_START AND D_END
AND
CASE
WHEN :REVENUE = 1 THEN REV != 0
WHEN :REVENUE = 2 THEN REV = 0
END
However, when I run this query I get the following error:
ORA-00905: missing keyword
Is what I am doing not possible? Or is there an error that someone can see and help me with?
Please help. Thanks!
UPDATE: Just to clarify, the user is passing a value of 1 or 2. And the query should filter the data according to what value is passed to it. If 1 is passed in the parameter, then filter out all revenue not equal to zero. Else if two is passed, then filter so that only records where revenue is zero is returned.
You can write it better with a bit of boolean logic:
SELECT * FROM TABLE
WHERE MY_DATE BETWEEN D_START AND D_END
AND (
(:REVENUE = 1 AND REV != 0)
OR
(:REVENUE = 2 AND REV = 0 )
)
CASE is meant to extract different values based on conditions, so you can use it to check conditions, but you need to use it as a value to check against a condition
It's not necessary to use a CASE expression to get this particular result.
But it is possible to make use of one.
The problem in the original query is that Oracle is more strict than other databases (like MySQL) in that Oracle doesn't implicitly convert a boolean expression to a value, or convert a value into boolean.
I suspect that Oracle is choking in a couple of places. The error message is only showing us one of those.
The CASE expression returns a value, and Oracle is balking that he won't evaluate the value as a boolean.
To get that value evaluated as a boolean, we could do a comparison of the value to some other value.
If we fix that, I think Oracle is still going to choke on the expression following THEN. Oracle is expecting to return a value, and it's finding a comparison, which evaluates to a boolean.
Okay, so we know the CASE expression needs to return a value, and we need to use that in a boolean expression. If we move that conditional test into the WHEN part, and specify a value to be returned in the THEN, we can compare the return from the CASE expression to another value.
(As an aside... I strongly recommend that you qualify the column references in the SQL statement. That makes the intent more clear. Looking at the statement, it looks like MY_DATE, D_START and D_END are all column references. That's perfectly valid, it just seems a bit odd to me.)
As an example, we could do something like this with the CASE expression:
SELECT t.*
FROM TABLE t
WHERE t.MY_DATE BETWEEN t.D_START AND t.D_END
AND CASE
WHEN ( :REVENUE = 1 AND t.REV != 0 ) THEN 1
WHEN ( :REVENUE = 2 AND t.REV = 0 ) THEN 1
ELSE NULL
END = 1
The parens inside the CASE aren't necessary; I just included them to highlight the part that Oracle is evaluating in a boolean context.
So, does that work? If the value passed in for :REVENUE is 2, the condition in the first WHEN won't evaluate to TRUE (the result of first comparison is guaranteed to be FALSE). The condition in the second WHEN may evaluate to TRUE (first comparison will yield TRUE, the result from second comparison will depend on the value in the REV column.)
That CASE expression is either going to return a value of 1 or NULL. (We could just as easily use a 0 or a -1, or 999 in place of NULL if we wanted.)
Once the CASE expression is evaluated, the value returned will be compared to a literal value, as if we wrote e.g. val = 1. That comparison is evaluated as boolean. If it evaluates to TRUE, the row will be returned...
To get Oracle to behave similarly to other databases (like MySQL), we would need to make the conversion from boolean to value and value to boolean explicit. We would still need the return from the CASE compared to 1, like we did above. In place of REV != 0 we could use another CASE expression. I'm not recommending this, just shown here for illustration, converting a boolean to a value.
WHERE CASE
WHEN ( :REVENUE = 1 )
THEN CASE WHEN ( t.REV != 0 ) THEN 1 ELSE NULL END
WHEN ( :REVENUE = 2 )
THEN CASE WHEN ( t.REV = 0 ) THEN 1 ELSE NULL END
ELSE
NULL
END = 1
Note that the return from the outermost CASE expression is being compared to a value, so we get a boolean (where Oracle expects a boolean.)
All of the ELSE NULL in the statements above can be omitted for an equivalent result, since that's the default when ELSE is omitted.)
Again, it's not necessary to use a CASE expression. You can get equivalent results without it. For example:
SELECT t.*
FROM TABLE t
WHERE t.MY_DATE BETWEEN t.D_START AND t.D_END
AND ( ( :REVENUE = 1 AND t.REV != 0 )
OR ( :REVENUE = 2 AND t.REV = 0 )
)
In these queries that all return an equivalent result, the CASE expression doesn't buy us anything. But in some circumstances, it can have some advantages over a regular OR, because the CASE expression stops evaluation when a condition in a WHEN clause evaluates to TRUE.
The problem is that Oracle SQL does not have the boolean data type, so you cannot have columns of type boolean, pass boolean parameters to a query, have boolean expressions etc. So they have the somewhat unnatural concept of "condition" which is something that goes into logical conditions (like in the WHERE clause). Unfortunately, when they introduced the case EXPRESSION, which can be used wherever any other expression can be used (but this excludes boolean), they DID NOT introduce a "case CONDITION" - which could be used where other conditions can be used. This omission is odd, since the code for a case condition would probably use 95% of the code for the case expression. All the more weird since PL/SQL does have the boolean type, and the case expression there works seamlessly for Booleans.
In MongoDB I would like to use $gt and $lt comparision operators where the value could be null. When the operators did not work with null, I looked for documentation but found none. In both cases it returned no documents (even though $ne, $gte, and $lte did return documents; meaning there were documents that were both equal to and not equal to null).
I would expect $gt to essentially operate like $ne (as the null type Mongo comarison order is so low) and $lt to return nothing for the same reason.
I was hoping this would work as the value I pass to the query is variable (potentially null), and I don't want to have to write a special case for null.
Example of what I was expeccting, given the following collection:
{
id: 1,
colNum: null
}
{
id: 2,
colNum: 72
}
{
id: 3
}
I would expect the following query:
db.testtable.find( { "colNum" { $gt : null } } )
To return:
{
id: 2,
colNum: 72
}
However, nothing was returned.
Is there a reason that $gt and $lt don't seem to work with null, or is it a MongoDB bug, or is it actually supposed to work and there is likely a user error?
Nitty-Gritty Details
Reading through the latest Mongo source, there's basically 2 cases when doing comparisons involving null:
If the canonical types of the BSON elements being compared are different, only equality comparisons (==, >=, <=) of null & undefined will return true; otherwise any comparison with null will return false.
Note: No other BSON type has the same canonical type as null.
If the canonical types are the same (i.e., both elements are null), then compareElementValues is called. For null, this just returns the difference between the canonical type of both BSON elements and then carries out the requested comparison against 0.
For example, null > null would translate into (5-5) > 0 --> False because the canonical type of null is 5.
Similarly, null < null would translate into (5-5) < 0 --> False.
This means null can only ever be equal to null or undefined. Any other comparison involving null will always return false.
Is this a Bug?
Updated Answer:
The documentation for the comparison operators ($gt, $lt) references the documentation which you originally linked, which implies that the comparison operators should work with null. Furthermore, query sorting (i.e., db.find().sort()) does accurately follow the documented Comparison/Sort behavior.
This is, at the very least, inconsistent. I think it would be worth submitting a bug report to MongoDB's JIRA site.
Original Answer:
I don't think this behavior is a bug.
The general consensus for Javascript is that undefined means unassigned while null means assigned but otherwise undefined. Value comparisons against undefined, aside from equality, don't make sense, at least in a mathematical sense.
Given that BSON draws heavily from JavaScript, this applies to MongoDB too.