I run code SELECT ISNUMERIC('121212,12') in level 80 in SQL Server 2008 R2, but it return 1, not 0.
I read in page Microsoft this code will return 0 in level 80 and return 1 in level 90. Link reference
SELECT ISNUMERIC('121212,12')
Why it return 1 in level 80?
The ANSI/ISO SQL standard (and SQL Server) uses . as a decimal separator, not comma, so this ISNUMERIC class test will fail. As to why this works in 80 (SQL 2000 compatibility level), the more strict behavior for ISNUMERIC was a change introduced in SQL 2005. In SQL Server 2000 and compatibility level 80, commas are ignored entirely so even an egregiously invalid value will return 1, such as ISNUMERIC(',123,,45678.89,,,') whereas this will return 0 in later levels.
The compatibility table in the old SQL Server 2005 documentation regarding this behavior is incorrect, with the 80 and 90 behavior listed backwards, which may have led to your question. Below is the actual behavior and how it should have been documented.
+-------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+
| Compatibility-level setting of 80 | Compatibility-level setting of 90 |
+-------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+
| In SELECT ISNUMERIC('<string>'), embedded commas within <string> are ignored. | In SELECT ISNUMERIC('<string>'), embedded commas within <string> are significant. |
| For example, the following SELECT ISNUMERIC('121212,12') query returns 1. | For example, the following SELECT ISNUMERIC('121212,12') query returns 0. |
| This indicate that the string 121212,12 is numeric. | This indicates that the string 121212,12 is not numeric. |
+-------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+
Also, be aware that ISNUMERIC will return 1 for values you may not want to consider as numeric (e.g. empty string, '1E', etc.). Consider using an alternate method. Unfortunately, the more robust TRY_CONVERT and TRY_CAST functions are not available until SQL Server 2012 so you need to use a technique such as LIKE if you need more strict parsing in earlier versions. Importantly, SQL Server 2008 R2 support ends next month (along with compatibility level 80) so an upgrade would be the best long-term solution, allowing the use of TRY_PARSE/TRY_CONVERT.
Related
A few of the columns in the source sql view has column length greater than 4000 characters. These are columns which contain some user comments and needs to be inclided in my Tabular SSAS Model.
But whenever the character length is greater than 4000 characters, I am getting error while processing the model.
I found out that Tabular does not support column length greater than 4000 characters.
Is there any way to bypass this issue ?
In Visual Studio 2017 in compatibility level 1400 (SQL 2017 and Azure Analysis Services) I was able to import this query both in legacy data source mode (regular SQL driver) and in the new Power Query mode.
select cast(replicate(cast('A23456789' as varchar(max)),1000) as varchar(max)) as str,
len(cast(replicate(cast('A23456789' as varchar(max)),1000) as varchar(max))) as len
What are you doing differently? Are you using an older compatibility level or something?
I also would question the analytical value of importing huge text strings into an SSAS Tabular model. Can you explain the value of those columns? Can you possibly parse out the relevant pieces of info from the long strings?
I looked though the forum but I couldn't find a issue like mine.
Essentially I have a table called [p005_MMAT].[dbo].[Storage_Max]. It has three columns Date, HistValue and Tag_ID. I want to make all the values in 'HistValue' column to have 2 decimal places. For example if a number is 1.1, I want it to be 1.10 or if its 1 then also I want it to look like 1.00.
Here is the sql update statement I am using
update [p005_MMAT].[dbo].[Storage_Max]
set [HistValue] = cast([HistValue] as decimal (10,2))
where [Tag_ID] = 94
After executing the query it says 3339 rows affected but when I perform a simple select statement it appears the column had no affect of. I have used that cast function in select statement and it adds two decimal places.
Please advice.
The problem is the datatype and SQL Server. Float or real will not have the trailing zeros. You either have to change the datatype of the column or just deal with it and handle the formatting in your queries or application.
You could run something like the following
select
cast([HistValue] as decimal (10,2))
from [p005_MMAT].[dbo].[Storage_Max]
where [Tag_ID] = 94
I was doing some tests on Postgres using the tinyint extension when I came across something surprising regarding its range. On typing select -128::tinyint it gave me an ERROR: tinyint out of range message which was not what I was expecting at all.
Assuming negative numbers should be 1 greater (or is it less) than the positive maximum (127 for single byte integers) I thought it was a bug with the extension, however on trying this with non-extended numbers I found exactly the same thing was happening.
select -32768::smallint -> out of range
select -2147483648::integer -> out of range
select -9223372036854775808::bigint -> out of range
Referring to the numeric data type documentation (https://www.postgresql.org/docs/current/datatype-numeric.html)
these numbers should all be possible - all negative numbers one less -32767, -2147483647, -9223372036854775807 work correctly so I am curious as to why this is happening, or does this even happen with other peoples copies.
I tried using both postgresql 10 and postgresql 11 on a ubuntu 16.x desktop.
I think this is because the cast operator :: has a higher precedence that the minus sign.
So -32768::smallint is executed as -1 * 32768::smallint which indeed is invalid.
Using parentheses fixes this: (-32768)::smallint or using the SQL standard cast() operator: cast(-32768 as smallint)
I am using the SQL Server 2008 R2 function ISNUMERIC() to determine if a string is a decimal or not.
It is returning '1' when the decimal as a comma or comma and period. I can fix for those issues but this query is part of a SSRS Report that will be distributed among many users and I cannot correct of all problems.
What can I use instead of ISNUMERIC() to determine if the string is a correctly formed decimal? I cannot use TRY_PARSE() because that is available in SQL SERVER 2012 and I am on 2008 R2.
UPDATE
I want to replace ISNUMERIC() with PATINDEX() to identify decimals.
Both of these examples return 0
SELECT PATINDEX('9,0', '%[0-9]%.%[0-9]%')
SELECT PATINDEX('9.0', '%[0-9]%.%[0-9]%')
What am I doing wrong?
Your parameter values for PATINDEX are reverse. This should work for you...
SELECT PATINDEX('%[0-9]%,%[0-9]%', '9,0')
SELECT PATINDEX('%[0-9]%.%[0-9]%', '9.0')
Noel
after several years of using Cognos, we are in process of testing conversion of Cognos Reports (8.3) to SSRS 2008 reports. we use Oracle database version 10g. in many of our reports we are converting we pass multiple values in parameters, however i cannot get this working in SSRS pointing to the Oracle datasource.
i have created parameter and set it to allow multiple values. these columns are integer types. the SQL filter is set as follows for example, where vendor_id IN (:Vendor_id). yet when I test the SQL, i get errors. i enter parameter values as comma-seperated for example, 102, 105, 107. errors as follows.
ORA-01722: invalid number
i've tried wrapping value in single, double quotes with same result. is there a different format to meet oracle syntax requirement? does multiple values only work for SQL server databases?
thanks in advance.
joe
As pointed out in this post, multi value parameters are concatenated and used as follows:
Select * from Table WHERE column1 in (:CommaSeparatedListOfValues)
http://consultingblogs.emc.com/stevewright/archive/2009/08/14/14763.aspx
So Vendor_id has to be Varchar2. I guess you have the data type of Vendor_id as integer?.