March 26, 2014 at 10:20 am
I am putting a SELECT statement together where I need to evaluate a results field, to determine how the color indicator will show on a SSRS report. I am running into a problem when I try to filter out any non-numeric values from a varchar field, using a nested CASE statement.
For example, this results field may contain values of '<1', '>=1', '1', '100', '500', '5000', etc. For one type of test, I need a value of 500 or less to be shown as a green indicator in a report, and any value over that would be flagged as a red. Another test might only allow a value of 10 or less before being flagged with a red.
This is why I setup a CASE statement for an IndicatorValue that will pass over to the report to determine the indicator color. Using CASE statements for this is easier to work with, and less taxing on the report server, if done in SQL Server instead of nested SSRS expressions, especially since a variety of tests have different result values that would be flagged as green or red.
I have a separate nested CASE statement that will handle any of the values that contain ">" or "<", so I am using the following to filter those out, and then convert it to an int value, to determine what the indicator value should be. Here is the line of the script that is erring out"
case when (RESULT not like '%<%') or (RESULT not like '%>%') then
CASE WHEN (CONVERT(int, RESULT) between 0 and 500) THEN '2'
ELSE '0'
The message I am getting is: Conversion failed when converting the varchar value '<1' to data type int.
I thought a "not like" statement would not include those values for converting to an int, but that does not seem to be working correctly. I did also try moving the not to show as "not RESULT like", and that did not change the message.
Does anyone have any suggestions on how I can filter out non-numeric values before converting the rest of the varchar field (RESULT) to int, so that it is only converting actual numbers?
March 26, 2014 at 10:31 am
Hi There
ISNUMERIC may help with this..
http://technet.microsoft.com/en-us/library/ms186272(v=sql.105).aspx
March 26, 2014 at 10:51 am
That worked. I changed my CASE statement to look like the following:
case when ISNUMERIC(SRESULT) = 1 then
CASE WHEN CONVERT(int, SRESULT) between 0 and 500 THEN '2' --Green
ELSE '0'
END
It is now only trying to convert those values that are only numeric. Thank you for the suggestion!!:-)
March 26, 2014 at 11:30 am
Be careful when using ISNUMERIC, it can give you unexpected results.
March 26, 2014 at 3:57 pm
miles_lesperance (3/26/2014)
That worked. I changed my CASE statement to look like the following:case when ISNUMERIC(SRESULT) = 1 then
CASE WHEN CONVERT(int, SRESULT) between 0 and 500 THEN '2' --Green
ELSE '0'
END
It is now only trying to convert those values that are only numeric. Thank you for the suggestion!!:-)
Be VERY aware that the definition of what is "numeric" encompasses a whole world of characters that you never imagined and that ISNUMERIC will allow many strange renditions of what "numeric" actually means that will blow up in your face. For example, what will ISNUMERIC return for the following?
SELECT ISNUMERIC(',,,,,'), ISNUMERIC('1E3'), ISNUMERIC('1D3'), ISNUMERIC('$')
I guarantee that each of those will cause a failure if you try to convert them to INT.
Please see the article that Luiz pointed you to. Don't ever use ISNUMERIC for an "IsAllDigits" function because it's not.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2014 at 3:04 am
They Say you learn something new every day...
I''m now off to change a couple of scripts which us ISNUMERIC to capture where I'm filtering numbers..
Thanks for pointing this out everyone.. :hehe:
March 27, 2014 at 10:45 am
(RESULT not like '%<%') or (RESULT not like '%>%')
will pass everything except NULLs to the convert as anything excluded by the first clause will be included by the second and vice versa - is this really what you want or are you after.
NOT ((RESULT like '%<%') or (RESULT like '%>%'))
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply