Im trying to write a case statement (Or use any statement)in MySQL that will print out a value if the variable = true.
Basically, in my select statement, if the value in one table is 10, then display a value within a new column
I was thinking to use something like this:
CASE (table1.payment WHEN 10 THEN table2.type END) AS plan
The above does not work and has syntax errors. What can I do to achieve my desired results?
In your case I think it is optimal to use IF, because it is one option to check (it is 10 or not) and IF is faster for such a check.
IF(table1.payment=10,table2.type,table1.payment) AS plan
https://www.w3schools.com/sql/func_mysql_if.asp For more information.
Option using case looks like:
(CASE
WHEN table1.payment=10 THEN table2.type
ELSE table1.payment
END) AS plan
https://www.w3schools.com/sql/func_mysql_case.asp For more information.
Execution time comparison for ONE check IF and CASE queries:
Bigger result
Smaller result
Related
I have my new Spring Boot project with SQL Server and I need to replace my MySQL native query on the Repository method in my old project with SQL Server native query. It's a complex query with the case when expression in where condition. When I try testing that query in SQL Server Management Studio it shows errors like the image below.
enter image description here
And here's my old native query use with MySQL on the Repository method I want to replace it with SQL Server
enter image description here
Please help me to find the solution.
Thank you in advance!!
This is what you have and what you should have posted as text within your question. As text it becomes searchable and copyable by people trying to help YOU.
case when #num = 1 then p.merchant_name = #query else 1=1 end
CASE is an expression in TSQL. It is not a control-of-flow construct like it is in many other languages. To use an "optional" filter, you need to construct a boolean expression using CASE which handles the "optional" attribute correctly. Often this is done with a bit more complexity using CASE like this:
case when #num = 1 and p.merchant_name <> #query then 0 else 1 end = 1
So here, CASE is used to return a value that can be tested in a comparison. There is no magic in using 0 or 1. Use any values of any type.
When #num is 1 and the values do NOT match, the THEN branch (0) is returned.
When #num is 1 and the values match, the ELSE branch (1) is returned.
When #num is anything but 1, the ELSE branch (1) is returned.
So when the CASE expression returns 0 (really - anything but 1), the row is ignored (removed from the resultset).
Given that your query is actually constructed in an application, you should considering dynamically building the query and adding parameters as needed. That will likely generate a more efficient query that can be better optimized by the database engine. Alternatively you can review this kitchen sink discussion and Erland's discussion of dynamic search conditions. TBH it looks like someone used #num as a kludge to avoid adding parameters for the eight specific filter values. If I want to filter on both merchant name and store name, I can't with this approach.
I'm simply trying to write an sql query to sum a group of fields.
I have 2 columns, one of which is Account Name, the other is Amount
I'd only like to sum two of the account names:
=sum(case when [Account Name] like Salaries or 'Other Income', Fields!Amount.Value)
the following works fine,
=sum(Fields!Amount.Value)
but I'm trying to narrow down the number of account names that are included in the sum. I'm trying to figure out how to use a case statement then group by that case statement.
I'm going to take a stab in the dark here because I think from your example that you're using SQL Server Reporting Services (SSRS), and the syntax is quite different to T-SQL or ANSI SQL, which is what most people think of when you say "SQL".
If that's the case, and I have no experience with this so this may be completely wrong, I'm guessing you might need to try something using either iif or switch like this:
=sum(iif(Fields![Account Name].Value = 'Salaries'
or Fields![Account Name].Value = 'Other Income', Fields!Amount.Value, 0))
I have a column in MySQL table which has 'messy' data stored as text like this:
**SIZE**
2
2-5
6-25
2-10
26-100
48
50
I want to create a new column "RevTextSize" that rewrites the data in this column to a pre-defined range of values.
If Size=2, then "RevTextSize"= "1-5"
If Size=2-5, then "RevTextSize"= "1-5"
If Size=6-25, then "RevTextSize"="6-25"
...
This is easy to do in Excel, SPSS and other such tools, but how can I do it in the MySQL table?
You can add a column like this:
ALTER TABLE messy_data ADD revtextsize VARCHAR(30);
To populate the column:
UPDATE messy_data
SET revtextsize
= CASE
WHEN size = '2' THEN '1-5'
WHEN size = '2-5' THEN '1-5'
WHEN size = '6-25' THEN '6-25'
ELSE size
END
This is a brute-force approach, identifying each distinct value of size and specifying a replacement.
You could use another SQL statement to help you build the CASE expression
SELECT CONCAT(' WHEN size = ''',d.size,''' THEN ''',d.size,'''') AS stmt
FROM messy_data d
GROUP BY d.size
Save the result from that into your favorite SQL text editor, and hack away at the replacement values. That would speed up the creation of the CASE expression for the statement you need to run to set the revtextsize column (the first statement).
If you want to build something "smarter", that dynamically evaluates the contents of size and makes an intelligent choice, that would be more involved. If was going to do that, I'd do it in the second statement, generating the CASE expression. I'd prefer to review that, befor I run the update statement. I prefer to have the update statement doing something that's easy to understand and easy to explain what it's doing.
Use InStr() to locate "-" in your string and use SUBSTRING(str, pos, len) to get start & End number. Then Use Between clause to build your Case clause.
Hope this will help in building your solution.
Thanks
I'm trying to learn how to use CASE/WHEN in SQL more specifically, mySQL.
I have two tables: adhoc_item and adhoc_vulnerability. ahdoc_item has one adhoc_vulnerability related to it. now adhoc_vulnerability may or may not have a vulnerability (original_vulnerability_id) attached to it.
In case it doesn't, then I want to return the name on itself.
The tables: (or relevant parts thereof)
ADHOC_ITEM
ADHOC_VULNERABILITY
This is my query:
SELECT adi.name as item, CASE ahv.original_vulnerability_id
WHEN ISNULL(ahv.original_vulnerability_id) THEN ahv.name
ELSE 'foo'
END NAME
FROM adhoc_item adi
JOIN adhoc_vulnerability ahv ON ahv.id = adi.adhoc_vulnerability_id
and these are the results!
Now I know this is a little bit complex but i've been thinking about it for about 2 hours and found no explanation on why that last item (which has an adhoc_vulnerability with NULL as original_vulnerability_id) shows the value that is supposed to appear precisely when that attribute is not null!
Thanks in advance.
The problem is that when ahv.original_vulnerability_id is NULL, the ISNULL() function returns TRUE (which is MySQL is the same as 1 but this is irrelevant). So, instead of comparing the column with NULL, you are comparing it with TRUE.
Rewrite the CASE expresion as:
CASE
WHEN ISNULL(ahv.original_vulnerability_id) THEN ahv.name
ELSE 'foo'
END NAME
or as:
CASE
WHEN ahv.original_vulnerability_id IS NULL THEN ahv.name
ELSE 'foo'
END NAME
According to the MySQL documentation:
As a general rule, you should never assign a value to a user variable and read the value within the same statement. You might get
the results you expect, but this is not guaranteed.
http://dev.mysql.com/doc/refman/5.6/en/user-variables.html
However, in the book High Perfomance MySQL there are a couple of examples of using this tactic to improve query performance anyway.
Is the following an anti-pattern and if so is there a better way to write the query while maintaining good performance?
set #last = null;
select tick, count-#last as delta, #last:=count from measurement;
For clarification, my goal is to find the difference between this row and the last. My table has a primary key on tick which is a datetime column.
Update:
After trying Shlomi's suggestion, I have reverted back to my original query. It turns out that using a case statement with aggregate functions produces unexpected behavior. See for example:
case when (#delta := (max(measurement.count) - #lastCount)) AND 0 then null
when (#lastCount := measurement.count) AND 0 then null
else #delta end
It appears that mysql evaluates the expressions that don't contain aggregate functions on a first pass through the results, and then evaluates the aggregate expressions on a second (grouping) pass. It appears to evaluate the case expression during or after that second pass and use the precalculated values from the first pass in that evaluation. The result is that the third line #delta is always the initial value of #delta (because assignment didn't happen until the grouping pass). I attempted to incorporate a group function into the line with #delta but couldn't get it to behave as expected. So I ultimately when back to my original query which didn't have this problem.
I would still love to hear any more suggestions about how to better handle a query like this.
Update 2:
Sorry for the lack of response on this question, I didn't have a chance to investigate further until now.
Using Shlomi's solution it looks like I had a problem because I was using a group by function when I read my #last variable but not when I set it. My code looked something like this:
CASE
WHEN (#delta := count - #last) IS NULL THEN NULL
WHEN (#last:= count ) IS NULL THEN NULL
ELSE (CASE WHEN cumulative THEN #delta ELSE avg(count) END)
END AS delta
MySQL appears to process expressions that don't contain aggregate functions in a first pass and ones that do in a second pass. The strange thing in the code above is that even when cumulative evaluates to true MySQL must see the AVG aggregate function in the ELSE clause and decides to evaluate the whole inner CASE expression in the second pass. Since #delta is set in an expression without an aggregate function it seems to be getting set on the first pass and by the time the second pass happens MySQL is done evaluating the lines that set #delta and #last.
Ultimately I seem to have found a fix by including aggregate functions in the first expressions as well. Something like this:
CASE
WHEN (#delta := max(count) - #last) IS NULL THEN NULL
WHEN (#last:= max(count) ) IS NULL THEN NULL
ELSE (CASE WHEN cumulative THEN #delta ELSE avg(count) END)
END AS delta
My understanding of what MySQL is doing is purely based on testing and conjecture since I didn't read the source code, but hopefully this will help others who might run into similar problems.
I am going to accept Shlomi's answer because it really is a good solution. Just be careful how you use aggregate functions.
I've researched this issue in depth, and wrote a few improvements on the above.
I offer a solution in this post, which uses functions whose order can be expected. Also consider my talk last year.
Constructs such as CASE and functions such as COALESCE have known underlying behavior (at least until this is changed, right?).
For example, a CASE clause inspects the WHEN conditions one by one, by order of definition.
Consider a rewrite of the original query:
select
tick,
CASE
WHEN (#delta := count-#last) IS NULL THEN NULL
WHEN (#last:=count ) IS NULL THEN NULL
ELSE #delta
END AS delta
from
measurement,
(select #last := 0) s_init
;
The CASE clause has three WHEN conditions. It executes them by order until it meets the first that succeeds. I've written them such that the first two will always fail. It therefore executes the first, then turns to execute the second, then finally returns the third. Always.
I thus overcome the problem of expecting order of evaluation, which is a real and true problem, mostly evident when you start adding more complex clauses such as GROUP BY, DISTINCT, ORDER BY and such.
As a final note, my solution differs from yours in the first row on the result set -- with yours' it returns NULL, with mine it returns the delta between 0 and count. Had I used NULL I would have needed to change the WHEN conditions in some other way -- making sure they would fail on NULL values.