DataAnalyst011 (6/27/2013)
From time to time I need to check if a column is completely numeric (or usually, check for the row contain something other than numeric). I've read the ISNUMERIC has problems. I've used LIKE '%[0-9]%'? successfully, but even after reading around in several places I still don't understand how it works. And I don't want to use anything I can't support. Would someone mind giving me a blow by blow explanation of what each "thing" is doing here? (And if the statement needs to be improved please do so. I've seen some use a ^ in the statement before).
Based on the word "ISNUMERIC" and the description above, I believe you're looking for an "IsAllDigits" solution. The following article will help with that.
http://www.sqlservercentral.com/articles/IsNumeric/71512/
I also recommend that you lookup "LIKE" in Books Online (the "help" system that comes with SQL Server). There will also be a popup when you search for "LIKE" in Books Online with the title "Pattern Matching in Search Conditions". That would be very good to study, as well.
--Jeff Moden
Change is inevitable... Change for the better is not.
Solomon Rutzky (7/27/2013)
23847234872893475983479583749583749573945739 is all digits, is a valid number, but is NOT convertible to any SQL Server number types as it is larger than 38 digits ...
You can convert it to float (with lose of some precision ;-))
select cast('23847234872893475983479583749583749573945739' as float)
Eugene Elutin (7/29/2013)
Solomon Rutzky (7/27/2013)
23847234872893475983479583749583749573945739 is all digits, is a valid number, but is NOT convertible to any SQL Server number types as it is larger than 38 digits ...
You can convert it to float (with lose of some precision ;-))
select cast('23847234872893475983479583749583749573945739' as float)
Considering that FLOAT only has 15 digits of precision, it'll be a pretty big loss.
--Jeff Moden
Change is inevitable... Change for the better is not.
Jeff Moden (7/29/2013)
Eugene Elutin (7/29/2013)
Solomon Rutzky (7/27/2013)
23847234872893475983479583749583749573945739 is all digits, is a valid number, but is NOT convertible to any SQL Server number types as it is larger than 38 digits ...
You can convert it to float (with lose of some precision ;-))
select cast('23847234872893475983479583749583749573945739' as float)
Considering that FLOAT only has 15 digits of precision, it'll be a pretty big loss.
I wouldn't call 1.32% a such "big loss" :hehe:
However you are right! It does depend! If this loss constitutes my interest in £ - I would probably die from heart-attack
Eugene Elutin (7/29/2013)
Jeff Moden (7/29/2013)
Eugene Elutin (7/29/2013)
Solomon Rutzky (7/27/2013)
23847234872893475983479583749583749573945739 is all digits, is a valid number, but is NOT convertible to any SQL Server number types as it is larger than 38 digits ...
You can convert it to float (with lose of some precision ;-))
select cast('23847234872893475983479583749583749573945739' as float)
Considering that FLOAT only has 15 digits of precision, it'll be a pretty big loss.
I wouldn't call 1.32% a such "big loss" :hehe:
However you are right! It does depend! If this loss constitutes my interest in £ - I would probably die from heart-attack
Heh... absolutely agreed but wasn't talking about the loss in "value" of the number. Was talking about the number of digits that would be lost when trying to determine if a long string could be checked for "IsAllDigits".
--Jeff Moden
Change is inevitable... Change for the better is not.
Jeff Moden (7/29/2013)
Eugene Elutin (7/29/2013)
Jeff Moden (7/29/2013)
Eugene Elutin (7/29/2013)
Solomon Rutzky (7/27/2013)
23847234872893475983479583749583749573945739 is all digits, is a valid number, but is NOT convertible to any SQL Server number types as it is larger than 38 digits ...
You can convert it to float (with lose of some precision ;-))
select cast('23847234872893475983479583749583749573945739' as float)
Considering that FLOAT only has 15 digits of precision, it'll be a pretty big loss.
I wouldn't call 1.32% a such "big loss" :hehe:
However you are right! It does depend! If this loss constitutes my interest in £ - I would probably die from heart-attack
Heh... absolutely agreed but wasn't talking about the loss in "value" of the number. Was talking about the number of digits that would be lost when trying to determine if a long string could be checked for "IsAllDigits".
Hmm. I thought I had tested that one using CONVERT and that it errored, but I tried again and it worked. Thanks for mentioning that.
I agree that the loss of precision (i.e. rounding up) is non-ideal but seems to happen with the decimal types: MONEY, SMALLMONEY, DECIMAL / NUMERIC. So not a true conversion in the sense of being able to convert it back to the exact same string, but technically it does fit into the datatype. So it still fits into what I was saying regarding the need to determine if the value expressed in the string is really a number with respect to the end purpose of that number.
Take care,
Solomon..
SQL# — https://SQLsharp.com/ ( SQLCLR library ofover 340 Functions and Procedures)
Sql Quantum Lift — https://SqlQuantumLift.com/ ( company )
Sql Quantum Leap — https://SqlQuantumLeap.com/ ( blog )
Info sites — Collations • Module Signing • SQLCLR
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply