SSRS Parameters. Allowing "All" or "Null" - tsql

SSRS parameters are a pain. I want to be able to re-use reports for many different needs by allowing the users access to many different parameters and making them optional.
So, if I start out with code such as:
Select * from mytable myt
where myt.date between '1/1/2010' and '12/31/2010'
and year(myt.date) = '2010'
and myt.partnumber = 'XYZ-123'
I want those parameters to be optional so my first attempts were to make the parameters default to null such as:
and (myt.partnumber = (#PartNumber) or (#PartNumber) is null)
That has problems because if the database fields in question are nullable then you will drop records because null does not equal null.
I then used code such as this:
DECLARE #BeginDate AS DATETIME
DECLARE #EndDate AS DATETIME
DECLARE #PartNumber AS VARCHAR(25)
SET #Year = '..All'
SET #BeginDate = '1/1/2005'
SET #EndDate = '12/31/2010'
SET #PartNumber = '..All'
SET #Year = '..All'
Select * from mytable myt
where (myt.date between (#BeginDate) and (#EndDate))
and (year(myt.date) = (#Year) or (#Year) = '..All' )
and (myt.partnumber = (#PartNumber) or (#PartNumber) = '..All')
That doesn't work because Year(myt.date) is an integer and #Year is not.
So, here are my questions.
How can I make my dates optional? Is the best way to simply default them to dates outside of a practical range so I return all values?
What is the best way to handle the null or '..All' options to make my queries as readable as possible and allow my users to have optional parameters for most data types? I'd rather not use null for

Go ahead and allow nulls, which indicates the filter should not be applied. Then, you can use the following:
SELECT *
FROM mytable myt
WHERE COALESCE(myt.date, '1/1/1900') between COALESCE(#BeginDate, myt.date, '1/1/1900') and COALESCE(#EndDate, myt.date, '1/1/1900')
AND COALESCE(YEAR(myt.date), -1) = COALESCE(#Year, YEAR(myt.date), -1)
AND COALESCE(myt.partnumber, -1) = COALESCE(#PartNumber, myt.partnumber, -1)
In summary, if any variable value is NULL, then compare the column value to itself, which effectively ignores the condition. More specifically, when testing myt.date, if #BeginDate is NULL then set the lower range value equal to the myt.date value. Do the same substitution with the #EndDate value. Even, if both #BeginDate and #EndDate are NULL, the condition will be true.
A similar approach is used for YEAR(myt.date) and myt.partnumber. If the variable value is NULL, then compare the column value to itself, which is always true.
UPDATE:
Added a default value to each COALESCE to handle the situation where the column value is NULL.

I like your third code block. It seems like your WHERE clause could be corrected to work with a non-int value. The AND clause for the year line would look like this--not my best T-SQL, but it should get you pointed in the right direction:
and 1 = CASE #Year WHEN '..All' THEN 1 ELSE CASE WHEN year ( myt.date ) = CONVERT ( int, #Year ) THEN 1 ELSE 0 END END
This will allow you to have a string value of '..All' or an int value. Either will match correctly. You can do the same with partnumber.

try it like this, the key is to fix your null parameters values to surrogate nulls, also since sql server supports short circuit evaluation, putting the null check should generally perform better.
Select * from mytable myt
where (myt.date between (#BeginDate) and (#EndDate))
and (#Year IS NULL OR COALESCE(myt.date,'1900') = #Year)
and (#PartNumber IS NULL OR ISNULL(myt.partnumber, '<NULL>') = (#PartNumber)

Related

Understanding COALESCE in postgres

Precise question.
Table ROW
value1 a
value2 b
value3 null
value4 d
Function parameters
CREATE OR REPLACE FUNCTION "GetValues"(
"#value1" VARCHAR(50),
"#value2" VARCHAR(50),
"#value3" VARCHAR(50),
"#value4" VARCHAR(50)
)
BEGIN
RETURN QUERY SELECT(
t."value1",
t."value2",
t."value3",
t."value4",
)
FROM "table" as t
WHERE t."value1" = COALESCE("#value1", c."value1")
AND t."value2" = COALESCE("#value2", c."value2")
AND t."value3" = COALESCE("#value3", c."value3")
AND t."value4" = COALESCE("#value4", c."value4");
END;
If I use the above function and only provide the following:
('a', null, null, 'd')
It will return [] even if 'a' and 'd' are found and I found that this only happens if I provide a parameter to search for something that is null and the value of the row is also null.
OLD DESCRIPTION BELOW
I have setup a get which uses COALESCE successfully to search by multiple or 1 parameter(s). However, if any one of those params that are not provided (so default to NULL) are actually NULL in the db because I haven't updated that field before, then it will always return an empty array, even though one of the provided params will successful match to a row in the table.
I just want to know if I need a new system all together to complete this search or if it is just an unfortunate effect of COALESCE?
Below is the relevant snippet.
FROM "table" as t
WHERE t."value1" = COALESCE("#value1", c."value1")
AND t."value2" = COALESCE("#value2", c."value2")
AND t."value3" = COALESCE("#value3", c."value3")
AND t."value4" = COALESCE("#value4", c."value4");
In the above, if I provide value1 and it matches but value4 is NULL in that row, then it will return [].
The return is a table with each of those 4 values.
Should this be a simple row comparison (give out all rows which have the same values as the input parameters)?
This could simply be achieved by the row comparator (documentation):
WHERE row(t.*) IS NOT DISTINCT FROM row("#value1", "#value2", "#value3", "#value4")
demo: db<>fiddle
If NULL as function input parameter should be a wildcard then #kurkle's solution works well.
You could do it like this:
FROM test as t
WHERE ("#value1" IS NULL OR t."value1" = "#value1")
AND ("#value2" IS NULL OR t."value2" = "#value2")
AND ("#value3" IS NULL OR t."value3" = "#value3")
AND ("#value4" IS NULL OR t."value4" = "#value4");
db<>fiddle

Update with ISNULL and operation

original query looks like this :
UPDATE reponse_question_finale t1, reponse_question_finale t2 SET
t1.nb_question_repondu = (9-(ISNULL(t1.valeur_question_4)+ISNULL(t1.valeur_question_6)+ISNULL(t1.valeur_question_7)+ISNULL(t1.valeur_question_9))) WHERE t1.APPLICATION = t2.APPLICATION;
I know you cannot update 2 tables in a single query so i tried this :
UPDATE reponse_question_finale t1
SET nb_question_repondu = (9-(COALESCE(t1.valeur_question_4,'')::int+COALESCE(t1.valeur_question_6,'')::int+COALESCE(t1.valeur_question_7)::int+COALESCE(t1.valeur_question_9,'')::int))
WHERE t1.APPLICATION = t1.APPLICATION;
But this query gaves me an error : invalid input syntax for integer: ""
I saw that the Postgres equivalent to MySQL is COALESCE() so i think i'm on the good way here.
I also know you cannot add varchar to varchar so i tried to cast it to integer to do that. I'm not sure if i casted it correctly with parenthesis at the good place and regarding to error maybe i cannot cast to int with coalesce.
Last thing, i can certainly do a co-related sub-select to update my two tables but i'm a little lost at this point.
The output must be an integer matching the number of questions answered to a backup survey.
Any thoughts?
Thanks.
coalesce() returns the first non-null value from the list supplied. So, if the column value is null the expression COALESCE(t1.valeur_question_4,'') returns an empty string and that's why you get the error.
But it seems you want something completely different: you want check if the column is null (or empty) and then subtract a value if it is to count the number of non-null columns.
To return 1 if a value is not null or 0 if it isn't you can use:
(nullif(valeur_question_4, '') is null)::int
nullif returns null if the first value equals the second. The IS NULL condition returns a boolean (something that MySQL doesn't have) and that can be cast to an integer (where false will be cast to 0 and true to 1)
So the whole expression should be:
nb_question_repondu = 9 - (
(nullif(t1.valeur_question_4,'') is null)::int
+ (nullif(t1.valeur_question_6,'') is null)::int
+ (nullif(t1.valeur_question_7,'') is null)::int
+ (nullif(t1.valeur_question_9,'') is null)::int
)
Another option is to unpivot the columns and do a select on them in a sub-select:
update reponse_question_finale
set nb_question_repondu = (select count(*)
from (
values
(valeur_question_4),
(valeur_question_6),
(valeur_question_7),
(valeur_question_9)
) as t(q)
where nullif(trim(q),'') is not null);
Adding more columns to be considered is quite easy then, as you just need to add a single line to the values() clause

Return empty string for no match on DateTime

Table [docSVdate]
PK sID, fielID
value DateTime not null
If there is no row for a given PK (sID, fieldID) I need to return an empty string
This is the best I could come up with
Does anyone have something more efficient?
select isnull(convert(varchar,[docSVdate].[value]), '')
from [docSVsys] as [pholder] with (nolock)
left join [docSVdate]
on [docSVdate].[sID] = [pholder].[sID]
and [docSVdate].[fieldID] = 117
where [pholder].[sID] = 6485
If you convert the datetime to a varchar in SQL, you are introducing the language and culture settings of your SQL Server into the date string. You might also be losing precision, depending on exactly what format is being used. And there's potential for error if the application code parses the string differently than SQL produced it.
So the simple answer is - don't do this. Just return it as a datetime. Let the calling application use it directly without converting to a string. Check for null if necessary in the calling application.
If you really want to do this, then there are many techniques that might work, including the join you showed, and the variable the Luis showed in his answer. Here is another technique, which uses a nested query. Perhaps this is what you are looking for:
SELECT ISNULL(
(select convert(varchar, [value])
from [docSVDate]
where [sID] = 6485 and [fieldID] = 117
), '') as [value]
Please be aware that conversion from datetime to varchar involves formatting, whether you like it or not. If you don't specify anything, you get the defaults for whatever system you are running on. For me, running on a database with US English settings, my default format looks like "Jul 21 2013 4:41PM" But if I had different language settings, I might get a completely different result. You should probably pass a format specifier to indicate what format you are looking for. Please reference the Date and Time Styles remarks in the MSDN reference for cast/convert.
if it's just one row...
INNER JOIN?
I'm not sure what the execution plan will show
DECLARE #Value VARCHAR(50)
SET #Value = ''
SELECT #Value = convert(varchar,[docSVdate].[value])
FROM [docSVsys] as [pholder] with (nolock)
INNER JOIN [docSVdate]
ON [docSVdate].[sID] = [pholder].[sID]
AND [docSVdate].[fieldID] = 117
WHERE [pholder].[sID] = 6485
SELECT #Value as Value
Does not need a join at all.
At most one row as the where is the PK,
DECLARE #Value VARCHAR(50)
SET #Value = ''
SELECT #Value = convert(varchar,[docSVdate].[value])
FROM [docSVdate]
WHERE [docSVdate].[sID] = 6485
AND [docSVdate].[fieldID] = 117
SELECT #Value as Value

SQL invalid conversion return null instead of throwing error

I have a table with a varchar column, and I want to find values that match a certain number. So lets say that column contains the following entries (except with millions of rows in real life):
123456789012
2345678
3456
23 45
713?2
00123456789012
So I decide I want all the rows which are numerically 123456789012 write a statement that looks something like this:
SELECT * FROM MyTable WHERE CAST(MyColumn as bigint) = 123456789012
It should return the first and last row, but instead the whole query blows up because it can't convert the "23 45" and "713?2" to bigint.
Is there another way to do the conversion that will return NULL for values that can't convert?
SQL Server does NOT guarantee boolean operator short-circuit, see On SQL Server boolean operator short-circuit. So all solution using ISNUMERIC(...) AND CAST(...) are fundamentally flawed (they may work, but hey can arbitrarily fail later dependiong on the generated plan). A better solution is using CASE, as Thomas suggests: CASE ISNUMERIC(...) WHEN 1 THEN CAST(...) ELSE NULL END. But, as gbn pointed out, ISNUMERIC is notoriously finicky in identifying what 'numeric' means and many cases where one would expect it to return 0 it returns 1. So mixing the CASE with the LIKE:
CASE WHEN MyRow NOT LIKE '%[^0-9]%' THEN CAST(MyRow as bigint) ELSE NULL END
But the real problem is that if you have millions of rows and you have to search them like this, you'll always end up scanning end-to-end since the expression is not SARG-able (no matter how we rewrite it). The real issue here is data purity, and should be addressed at the appropriate level, where the data is populated. Another thing to consider is if is possible to create a persisted computed column with this expression and create a filtered index on it which eliminates NULL (ie. non-numeric). That would speed up things a little.
If you are using SQL Server 2012 you can use the 2 new methods:
TRY_CAST()
TRY_CONVERT()
Both methods are equivalent. They return a value cast to the specified data type if the cast succeeds; otherwise, returns null. The only difference is that CONVERT is SQL Server specific, CAST is ANSI. using CAST will make your code more portable (although not sure if any other database provider implements TRY_CAST)
ISNUMERIC will accept empty string and values like 1.23 or 5E-04 so could be unreliable.
And you don't know what order things will be evaluated in so it could still fail (SQL is declarative, not procedural, so the WHERE clause probably won't be evaluated left to right)
So:
you want to accept value that consist only of the characters 0-9
you need to materialise the "number" filter so it's applied before CAST
Something like:
SELECT
*
FROM
(
SELECT TOP 2000000000 *
FROM MyTable
WHERE MyColumn NOT LIKE '%[^0-9]%' --double negative rejects anything except 0-9
ORDER BY MyColumn
) foo
WHERE
CAST(MyColumn as bigint) = 123456789012 --applied after number check
Edit: quick example that fails.
CREATE TABLE #foo (bigintstring varchar(100))
INSERT #foo (bigintstring )VALUES ('1.23')
INSERT #foo (bigintstring )VALUES ('1 23')
INSERT #foo (bigintstring )VALUES ('123')
SELECT * FROM #foo
WHERE
ISNUMERIC(bigintstring) = 1
AND
CAST(bigintstring AS bigint) = 123
SELECT *
FROM MyTable
WHERE ISNUMERIC(MyRow) = 1
AND CAST(MyRow as float) = 123456789012
The ISNUMERIC() function should give you what you need.
SELECT * FROM MyTable
WHERE ISNUMERIC(MyRow) = 1
AND CAST(MyRow as bigint) = 123456789012
And to add a case statement like Thomas suggested:
SELECT * FROM MyTable
WHERE CASE(ISNUMERIC(MyRow)
WHEN 1 THEN CAST(MyRow as bigint)
ELSE NULL
END = 123456789012
http://msdn.microsoft.com/en-us/library/ms186272.aspx
SELECT *
FROM MyTable
WHERE (ISNUMERIC(MyColumn) = 1) AND (CAST(MyColumn as bigint) = 123456789012)
Additionally you can use a CASE statement in order to get null values.
SELECT
CASE
WHEN (ISNUMERIC(MyColumn) = 1) THEN CAST(MyColumn as bigint)
ELSE NULL
END AS 'MyColumnAsBigInt'
FROM tableName
If you require additional filtering, for numerics which are not valid to be cast to bigint, you can use the following instead of ISNUMERIC:
PATINDEX('%[^0-9]%',MyColumn)) = 0
If you need decimal values instead of integers, cast to float instead and change the regex to '%[^0-9.]%'

How can I query 'between' numeric data on a not numeric field?

I've got a query that I've just found in the database that is failing causing a report to fall over. The basic gist of the query:
Select *
From table
Where IsNull(myField, '') <> ''
And IsNumeric(myField) = 1
And Convert(int, myField) Between #StartRange And #EndRange
Now, myField doesn't contain numeric data in all the rows [it is of nvarchar type]... but this query was obviously designed such that it only cares about rows where the data in this field is numeric.
The problem with this is that T-SQL (near as I understand) doesn't shortcircuit the Where clause thus causing it to ditch out on records where the data is not numeric with the exception:
Msg 245, Level 16, State 1, Line 1
Conversion failed when converting the nvarchar value '/A' to data type int.
Short of dumping all the rows where myField is numeric into a temporary table and then querying that for rows where the field is in the specified range, what can I do that is optimal?
My first parse purely to attempt to analyse the returned data and see what was going on was:
Select *
From (
Select *
From table
Where IsNull(myField, '') <> ''
And IsNumeric(myField) = 1
) t0
Where Convert(int, myField) Between #StartRange And #EndRange
But I get the same error I did for the first query which I'm not sure I understand as I'm not converting any data that shouldn't be numeric at this point. The subquery should only have returned rows where myField contains numeric data.
Maybe I need my morning tea, but does this make sense to anyone? Another set of eyes would help.
Thanks in advance
IsNumeric only tells you that the string can be converted to one of the numeric types in SQL Server. It may be able to convert it to money, or to a float, but may not be able to convert it to an int.
Change your
IsNumeric(myField) = 1
to be:
not myField like '%[^0-9]%' and LEN(myField) < 9
(that is, you want myField to contain only digits, and fit in an int)
Edit examples:
select ISNUMERIC('.'),ISNUMERIC('£'),ISNUMERIC('1d9')
result:
----------- ----------- -----------
1 1 1
(1 row(s) affected)
You'd have to force SQL to evaluate the expressions in a certain order.
Here is one solution
Select *
From ( TOP 2000000000
Select *
From table
Where IsNumeric(myField) = 1
And IsNull(myField, '') <> ''
ORDER BY Key
) t0
Where Convert(int, myField) Between #StartRange And #EndRange
and another
Select *
From table
Where
CASE
WHEN IsNumeric(myField) = 1 And IsNull(myField, '') <> ''
THEN Convert(int, myField) ELSE #StartRange-1
END Between #StartRange And #EndRange
The first technique is "intermediate materialisation": it forces a sort on a working table.
The 2nd relies on CASE ORDER evaluation is guaranteed
Neither is pretty or whizzy
SQL is declarative: you tell the optimiser what you want, not how to do it. The tricks above force things to be done in a certain order.
Not sure if this helps you, but I did read somewhere that incorrect conversion using CONVERT will always generate error in SQL. So I think it would be better to use CASE in where clause to avoid having CONVERT to run on all rows
Use a CASE statement.
declare #StartRange int
declare #EndRange int
set #StartRange = 1
set #EndRange = 3
select *
from TestData
WHERE Case WHEN ISNUMERIC(Value) = 0 THEN 0
WHEN Value IS NULL THEN 0
WHEN Value = '' THEN 0
WHEN CONVERT(int, Value) BETWEEN #StartRange AND #EndRange THEN 1
END = 1