## Explanation of LIKE '%[0-9]%'?

 Author Message Eugene Elutin Hall of Fame Group: General Forum Members Points: 3054 Visits: 5478 [b]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)` _____________________________________________"The only true wisdom is in knowing you know nothing""O skol'ko nam otkrytiy chudnyh prevnosit microsofta duh!":-D(So many miracle inventions provided by MS to us...)How to post your question to get the best and quick help Jeff Moden SSC-Forever Group: General Forum Members Points: 45486 Visits: 39948 Eugene Elutin (7/29/2013)[b]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 ModenRBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.Although change is inevitable, change for the better is not.Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:How to post code problemsHow to post performance problemsForum FAQs Eugene Elutin Hall of Fame Group: General Forum Members Points: 3054 Visits: 5478 Jeff Moden (7/29/2013)Eugene Elutin (7/29/2013)[b]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" However you are right! It does depend! If this loss constitutes my interest in £ - I would probably die from heart-attack :-D _____________________________________________"The only true wisdom is in knowing you know nothing""O skol'ko nam otkrytiy chudnyh prevnosit microsofta duh!":-D(So many miracle inventions provided by MS to us...)How to post your question to get the best and quick help Jeff Moden SSC-Forever Group: General Forum Members Points: 45486 Visits: 39948 Eugene Elutin (7/29/2013)Jeff Moden (7/29/2013)Eugene Elutin (7/29/2013)[b]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" However you are right! It does depend! If this loss constitutes my interest in £ - I would probably die from heart-attack :-DHeh... 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 ModenRBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.Although change is inevitable, change for the better is not.Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:How to post code problemsHow to post performance problemsForum FAQs Solomon Rutzky Say Hey Kid Group: General Forum Members Points: 666 Visits: 2943 Jeff Moden (7/29/2013)Eugene Elutin (7/29/2013)Jeff Moden (7/29/2013)Eugene Elutin (7/29/2013)[b]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" However you are right! It does depend! If this loss constitutes my interest in £ - I would probably die from heart-attack :-DHeh... 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# - http://www.SQLsharp.com/