I'm trying to ROUND() or not the selected value. The query looks likes this:
SELECT b.Series,
CASE
WHEN Series = 'DMS' THEN ROUND(b.Quantity,0)
ELSE ROUND(b.Quantity,2)
END AS Quantity
FROM bill b
I also tried
CASE Series
WHEN 'DMS' THEN ROUND(b.Quantity,0)
ELSE ROUND(b.Quantity,2)
END AS Quantity,
and
IF(b.Series = 'DMS', ROUND(b.Quantity,0), ROUND(b.Quantity,2)) AS Quantity,
Every time I get the 2 decimals at the end.
When the Series is 'DMS' Quantity should be like an integer (without decimals), in the other cases Quantity should have two decimals.
In a result set, the data type is an attribute of the column for the entire result set.
For any given column in a result set, the value in that column for each row must necessarily be of the same data type.
The data type of the returned column for this query will, by necessity, be set by the server to something along the lines of DECIMAL(11,2) in order to accommodate all the possible values.
I would anticipate that what you are seeing is actually correctly rounded, but with an "unexpected" .00 at the end.
CAST(CASE ... END AS CHAR) AS Quantity would -- potentially -- get you a result that looks more like you're expecting, by casting everything to a string.
That's obviously some very sloppy type-handling, but it's no more unreasonable than expecting different types to emerge in the same column... which can't be done.
The more correct solution is to return them as two different columns, with two CASE expressions or IF().
ROUND(IF(Series = 'DMS',b.Quantity,NULL),0) AS dms_quantity,
ROUND(IF(Series = 'DMS',NULL,b.Quantity),2) AS non_dms_quantity
Note that both IF() tests evaluate the same expression and have their arguments reversed rather than the second one using != with the arguments the same, so that NULL values for series, if possible, are handled correctly by the second test. (Anything != NULL cannot evaluate to true; the third argument to IF() is used for both FALSE AND NULL results).
Related
I have a simple CASE query, however I noticed something I find surprising - the type of data that the query returns changes depending on what data type is in the unused (not chosen) branch.
Let's consider two case queries:
A1:
SELECT
CASE 1
WHEN 3 THEN '7'
ELSE 'text answer' END
FROM SomeDatabase
B1:
SELECT
CASE 1
WHEN 3 THEN '7'
ELSE float_attribute END
FROM SomeDatabase
The A1 query will return 'the same'
The B1 query will return the value of float_attribute (which is of the float type - important!)
So far so good...
The issue I have is if we change these queries so that the condition is fullfilled
A2:
SELECT
CASE 1
WHEN 1 THEN '7'
ELSE 'the same' END
FROM SomeDatabase
B2:
SELECT
CASE 1
WHEN 1 THEN '7'
ELSE float_attribute END
FROM SomeDatabase
Now here is where my confusion starts:
Query A2 returns 7
Query B2 returns 7.000000
Despite both queries containing the same chosen branch WHEN 1 THEN '7'
the queries return a value of a different type.
Clearly, the type depends on the type of the value/attribute that's in the second branch, even when it isn't chosen.
WHY IS THAT?? Is that normal SQL behaviour?
This is not surprising at all. A CASE expressions returns a single value. That value has a specified type.
The rules for determining the type of the return value have a preference for numbers and dates over strings. So if any of the return values is a number, then the overall value is a number. This is an easy way to get conversion errors, in some databases.
This is standard behavior. I'm pretty sure every data documents this as part of the explanation of the CASE expression.
The CASE statement Returns the highest precedence type from the set of types in result_expressions and the optional else_result_expression. For more information, see Data Type Precedence (Transact-SQL). Reference
In your case, string is lower than float.
I am sure it would be an aggregate function because it is going to count a collection of data.
However, how does any COUNT() function operate in MySQL to perform its respective actions?
Not 100% clear what you are looking for, but for selecting a count of null values in a column, I use something like this:
SELECT SUM(CASE WHEN columnname IS NULL THEN 1 ELSE 0 END) FROM tablename;
When the value is NULL, it is assigned the value 1 otherwise 0, then summed over whatever aggregate you need.
The COUNT(*) is an aggregate function. In the SELECT list, the expression COUNT(*) will return a count of rows. Without a GROUP BY clause, all rows will be collapsed into a single row, and the COUNT(*) aggregate will contain a non-negative integer value representing the number of rows that were collapsed... a "count" of the number of rows.
As you seem to be aware, other expressions involving the COUNT() aggregate operate a little differently, with respect to NULL values.
In the SELECT list, an expression COUNT(expr) operates exactly like COUNT(*) except for rows with values of expr that evaluate to NULL are not included in the count.
This all operates according to the specification.
As far as the non-existent COUNTNULL() function, it depends what you want that to achieve. If you wanted to get a count of the rows that had a NULL value for an expression, you could perform a conditional test, and return a non-NULL value, and use the existing COUNT aggregate, for example:
SELECT COUNT(CASE WHEN expr IS NULL THEN 1 ELSE NULL END) AS `COUNTNULL`
FROM ...
I don't remember where I learned this technique, but arguably the most elegant -- or at least minimalistic -- way to invert the logic of COUNT() is with this expression, which admittedly gives a first impression that black magic may somehow be involved... but it's perfectly legitimate:
COUNT(column1 IS NULL OR NULL)
...this correctly counts only the rows where column1 is null, because it is equivalent to the following expression...
COUNT( (column1 IS NULL) OR (NULL) )
It's a boolean expression that can only ever evaluate to 1 ("true," when column1 is null, and this row is thus counted), or NULL (otherwise, so the row will not be counted).
Logically, it's equivalent to the CASE expression offered by #spencer7593.
I have amounts stored as a varchar in my table.
When attempting to sum them it always returns 0.00.
Below is an example using only one record from the db.
SELECT col1, SUM(CAST(col2 AS DECIMAL(20,2))) derived1
FROM table
WHERE col3 = 'FIT'
AND col1 = '6211195'
GROUP BY col1
This returns one row with a 0 value.
By removing the SUM and CAST from the query, I can see that it is pulling the value as it should, but I can not sum or cast it, adding either of those breaks it and returns 0 again.
I have also tried converting the field to a decimal type and it just zeros all the values.
EDIT:
Ughh, I just ran a REGEX query to detect anything that isnt an alphanumeric value or a decimal point. It appears that there are non ascii characters in the field that I cant see, messing with the type casting. Will continue to update as I learn more.
Show some sample values of col2. A string that really is a number is treated as a number. Hence '1' will become 1.
However, if the string does not start with a digit, '-', or '+' (after leading spaces), then it will be 0 (in most cases). So 'A1' will be 0. And so on. As will '$100'.
The lesson is: If a column contains numbers, store them as numbers. Really simple.
We have a series of reports which return a set of values for a parameter based on the userID. This works and we're happy with the way it works.
Now we need to implement a default parameter setting. The logic being
If there is only one value in the parameters available dataset, then set that as the default.
If there is more than one value in the parameters available dataset, then leave the parameter blank.
This is what I have so far - I know I have the following issues:
-Parameters cannot read fields, therefore I need the expression to look at the dataset as a whole.
-I'm unsure what my then statement should be to allow the user to review all available values without them being selected.
=IIf(CountDistinct(Fields!storekey.Value, "UserStoreVerification")) = 1, First(Fields!storekey.Value, "UserStoreVerification")," ")
You can create a separate dataset to populate the "default values" for the parameter. In this dataset you can add logic to count the number of rows that would be returned by the other dataset that provides the parameter values. If there are greater than 1 values returned by the first query then the second dataset just returns NULL (i.e. no default values are selected).
Example
If your original dataset for parameter values (e.g. "dsParamProduct") used a query like this:
SELECT ProductNumber
FROM dbo.Product
WHERE Available = 'Yes'
Then the dataset query for the default values (e.g. "dsParamProductDefault") could be something like this:
DECLARE #ValueCount INT
SELECT #ValueCount = COUNT(*)
FROM
(
SELECT ProductNumber
FROM dbo.Product
WHERE Available = 'Yes'
) vals
IF #ValueCount = 1
SELECT ProductNumber
FROM dbo.Product
WHERE Available = 'Yes'
ELSE
SELECT NULL
Supplying "NULL" as the default value when there is more than one value will mean none of the available values are selected and therefore the user will have to manually select them (assuming that NULL isn't a valid value for your parameter - if it is then make sure the default query will return something else that is definitely not valid). If there is only one possible value then the default value query just returns the same result as the parameter values dataset, which means that the parameter value will be selected.
Set up another parameter that is dependent on the first, same type but slightly different name, and do your code at bottom with one suggested change:. Change " " at the end before the parenthese end to be 'NOTHING' instead. I believe this is interpreted by SQL as NULL which is what you want.
Now you should be getting population of the parameter so I would debug and check it by just dragging and dropping it to the design surface and it should be black if you have more than one default value. You can optionally make this parameter 'hidden' once you can confirm it works.
Now you trick your main dataset with a nifty predicate (or else use some other logic if it suits you better)
Where value = isnull(#DependentParam, value)
Basically this is stating "if the parameter is not null use it, else equate the clause to be everything as it will assume value = value".
Can anyone help me understand or post any ideas concerning this where clause?
sql was here
I've changed the table name, but other than that, any idea what the developer was trying to do here?
There is nothing else after that, that's the where clause.
If (table.date_field = (select max(table2.exit_date) from table as table2)) is null the it'll return 1=1, which basically means there's no where clause at all.
Now let's look into that nasty expression. I can only assume that if "a = b" is not true then that's also equivalent to null, otherwise it seems like the first branch would always happen. It looks like it's trying to say "if the latest exit date is equal to the date field, select those, otherwise have no where clause". However, I don't think that this will work at all. It really looks like either way, each row will be selected.
The MySQL ifnull function returns the first argument if it is not null, otherwise the second argument. This looks like it tries to compare table.date_field to the max(table2.exit_date), and return true if the comarison was not possible due to nulls.
It looks to me like he is trying to find the row where table.date_field is equal to the maximum of table.exit_data. There is a check for null which I think would happen in any of these cases:
table is empty
all rows in table have exit_data set to NULL
table.date_field is NULL for the row in question
In any of these three cases, the row will be returned. I don't understand why he uses the string '1=1' instead of, to give some examples: 1=1, 1 or true, but it appears to work fine. In the first case I assume that there will be no rows in the result set anyway (depending on the rest of the query) so he was probably trying to handle one of the other two cases - I'd guess the last one.
This is only an explanation of what is happening. To understand why he is doing this, it would help if you gave a little more context.
MySQL is nonstandard in that true is really equal to the numeric value 1. Any expression that evaluates to true, or any nonzero value, satisfies the condition.
mysql> CREATE TABLE foo AS SELECT 1=1 AS f;
mysql> SHOW CREATE TABLE foo;
CREATE TABLE `foo` (
`f` INT NOT NULL DEFAULT '0'
) ENGINE=MyISAM DEFAULT CHARSET=latin1
So the following WHERE clause is legal in MySQL, but not in most other SQL databases:
... WHERE 1;
Some people use 1=1 as a placeholder condition meaning true, but putting it in a string is meaningless because SQL expressions have no equivalent to an eval() function as other languages have. In this case, the leading character 1 in the string is implicitly cast to a numeric value 1, which is interpreted as true in MySQL. So it probably works as intended, but kind of by accident.
The use of IFNULL() is so that if either date_field or MAX(exit_date) is NULL, it returns the row. If you didn't use this function, then anything = NULL would evaluate as unknown, which means the row would not be returned.
It says basically if table.date_field = max exit date or if max exit_date is null or table.date_field is null return true. Will return false if max exit_date is not null and table.date_field is not null but they do not equal.