June 7, 2012 at 11:07 am
Hi,
I have to convert varchar result values in my table to decimal for charting purposes, and I filter the values as isnumeric(value)=1
but i keep getting the error
Arithmetic overflow error converting numeric to data type numeric. Any ideas to fix that ?
thanks
June 7, 2012 at 11:13 am
There may be data with symbols like $ or e or . . ISNUMERIC is not a 100% solution for finding is the values are INTERGER-convertible.
June 7, 2012 at 11:53 am
IsNumeric should actually be called something like CanBeConvertedToSomeNumericdataType
IsNumeric('123,234') returns 1, but it can't be converted to numeric, only money
Try casting to float if the accuracy isn't a problem, it's a little more flexible than numeric. Other than that, see what that column contains other than pure numbers and post some examples here
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 7, 2012 at 12:36 pm
Any ideas?? thanks
June 7, 2012 at 12:38 pm
SQL_path (6/7/2012)
Any ideas?? thanks
Well, since we can't see from here what you see there, not really. Maybe if you provided us with the DDL for the table, some sample data, your query, we might be able to help you better.
June 7, 2012 at 12:40 pm
SQL_path (6/7/2012)
Any ideas?? thanks
Yes
GilaMonster (6/7/2012)
Try casting to float if the accuracy isn't a problem, it's a little more flexible than numeric. Other than that, see what that column contains other than pure numbers and post some examples here
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 7, 2012 at 12:42 pm
If you have IsNumeric in the Where clause, you can get some odd behavior, where it tries to convert out-of-range or invalid values to your numeric format, then filter them, instead of the other way around. The usual way to get around that is to use IsNumeric() = 1 to dump the valid rows into a temp table, then do the rest of your process from there.
But also keep in mind, as Gail mentioned, IsNumeric isn't always the best bet for determining the validity of numeric data. For example, you can't convert "1D3" to an integer, but IsNumeric('1D3') will return a 1 because it can be converted to a scientific-notation version of 1,000.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 8, 2012 at 12:56 am
You might want to select out all the rows based on a PATINDEX that allows only numerics. Then you can examine what's actually in the data and what might be causing you problems.
Maybe you can then do the conversion after doing some simple REPLACEments or something.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
June 9, 2012 at 2:03 pm
dwain.c (6/8/2012)
You might want to select out all the rows based on a PATINDEX that allows only numerics. Then you can examine what's actually in the data and what might be causing you problems.Maybe you can then do the conversion after doing some simple REPLACEments or something.
The trick with using PatIndex for that kind of thing, is that you might end up with contradictory rules. If, for example, you only allow characters 0-9, then 1.5 won't show as a number, but if you allow 0-9 and ".", then 1.1.1900 shows as a "number". If your data might have European sources, then you have to watch out for the inversion of commas and periods, compared to US numbers; 1.000 = 1-thousand in some notations, and 1 in others, and 1.000.000 is 1-million in EU notation, while 1,000,000 is in the US. 1,000.00 is a legit number in one notation, and not in the other, and 1.000,00 is the same number or error.
So PatIndex, which just checks for existence of allowed characters, can be easily fooled into allowing false positives, or blocking false negatives.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 9, 2012 at 3:38 pm
SQL_path (6/7/2012)
Any ideas?? thanks
Yes... to repeat what the others have said but from the diaphram, please see the following article which explains a way to find postive integer values sans any possible $ signs, etc., and why ISNUMERIC() should never be used as an "IsAllDigits" function.
http://www.sqlservercentral.com/articles/IsNumeric/71512/
--Jeff Moden
Change is inevitable... Change for the better is not.
June 12, 2012 at 8:00 am
Thank you Everyone. Greatly Appreciate it. Learned a lot.
Thanks.
June 17, 2012 at 8:20 pm
I use this trick - adding e0
For example,
Select ISNUMERIC('10,000')
--> 1
Select Convert(float, '10,000')
-->
Msg 8114, Level 16, State 5, Line 2
Error converting data type varchar to float.
So adding e0
Select ISNUMERIC('10,000' + 'e0')
--> 0
Select ISNUMERIC('10000' + 'e0')
--> 1
But it is not 100%. It doesn't work if this alrady contain e?. 🙂
June 18, 2012 at 4:54 pm
Maybe use
FROM WhereEver WHERE CHARINDEX ( 'E0', MyColumn ) = 0
to not catch those guys who already have E0 in them? Not foolproof either. And you don't want to look for just an 'E'
Regards,
Jan
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply