I have uploaded my product to Azure and SQL Server, but I found really interesting issue working with Azure. Azure by default provides RTM version of SQL Server, which is creating this issue.
The RTM version image for calculation - the screenshot shows how calculation outputs the value.
The second screenshot is my local SQL Server 2014 - so why does the RTM version have this issue? Is there any settings or solution for this to return proper value like in SQL Server 2014?
Decimal 0.00750 is value 7.4999999999999997E-3 when cast to float (although SSMS will show 0.0075). Using SQLCMD, you can see the actual value:
sqlcmd -Q"DECLARE #c float = 0.00750;SELECT #c as float,ROUND(#c, 3) AS rounded;"
Results:
float rounded
------------------------ ------------------------
7.4999999999999997E-3 7.0000000000000001E-3
If you change the database compatibility level to 120 (SQL 2016) of the database (on-prem, Azure SQL Database Managed Instance, or Azure SQL Database):
ALTER DATABASE YourDatabase SET COMPATIBILITY_LEVEL = 120;
and repeat the same query, then the result is incorrectly rounded like your SQL 2016 instance:
float rounded
------------------------ ------------------------
7.4999999999999997E-3 8.0000000000000002E-3
Remember that float is approximate and cannot exactly represent all decimal values. So Azure SQL Database is the correct rounding behavior but the behavior can be controlled with the database compatibility level to provide backwards compatibility, if needed.
Related
I'm seeing SSN masked on PROD and it is not masked on DEV with same exact code. I looked up the stored procedures it is calling and it is simple select statement. I inquired DB admin and he said they are not doing any masking, since they are using SQL server 2012 he is pretty sure it is not happening on sql server side(sql server 2016 and up year can do masking on DB).
I need suggestions what else I can debug or is it possible to do masking on SQL server 2012?
I am not so into database and I am finding the following difficulties. I am working on a pretty old version of SQL Server:
Microsoft SQL Server 2008 R2 (SP2) - 10.50.4042.0 (X64) Mar 26 2015 21:18:04 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)
The problem is that I have this query:
SELECT [Sottocategoria]
,[IdSottocategoria]
,[IdCategoria]
,[Note]
FROM [dbo].[PROT_TITOLARIO]
ORDER BY TRY_CONVERT(hierarchyid,'/'+REPLACE(IdSottocategoria,'.','/')+'/')
that is going into error:
Msg 195, Level 15, State 10, Line 6
'TRY_CONVERT' is not a recognized built-in function name.
I think that I can't increase the compatibility level of the DB because it is too old, infact doing:
ALTER DATABASE GHELLA_CRI SET COMPATIBILITY_LEVEL = 110
I obtain this error message:
Msg 15048, Level 16, State 1, Line 1
Valid values of the database compatibility level are 80, 90, or 100.
So the problem seems to be this TRY_CONVERT function that seems not be supported by SQL Server 2008.
There is a way to replace it with something similar supported by this SQL Server version?
Here a query sample: https://dbfiddle.uk/?rdbms=sqlserver_2017&fiddle=c0650397514372818b10958901c98add
Filling somes blanks here with my own guesses, but basing on what the OP has, I suspect we could do something like this instead:
SELECT *
FROM [dbo].[PROT_TITOLARIO] PT
CROSS APPLY (VALUES(CASE WHEN PT.IdSottocategoria LIKE '%[^0-9.]%' THEN NULL ELSE PT.IdSottocategoria END)) TC(IdSottocategoria)
CROSS APPLY (VALUES(CONVERT(hierarchyid,'/'+REPLACE(TC.IdSottocategoria,'.','/')+'/')))V(Hid)
ORDER BY CASE WHEN V.Hid IS NULL THEN 1 ELSE 0 END,
V.Hid,
PT.IdSottocategoria;
I use a CASE expression to check that the value of IdSottocategoria only contains numerical values and .'s and then just CONVERT those values. That works for the sample values the OP supplied: db<>fiddle
To reiterate my comments, SQL Server 2008 R2 SP2 is a really old version of SQL Server. SP3 came out some time ago for 2008R2, and SP2 is not patched against the Spectre and Meltdown vulnerabilities. Even if you aren't updating the version of SQL Server for a bit (which should heavily be reconsidered) I cannot more strongly suggest you get that server updated to SP3 GDR. This is especially true if you are in a country that has GDPR (or similar) legislation, as your local authority will see unpatched (and unsupported) software as a huge concern and will not reflect well on the list of preventative measures in the result of a breach.
I've downloaded SSMA for DB2 V8.2.0. I kept all the default setting and tried to convert couple of Stored procs from DB2 to SQL 2017.
I've selected one SP and clcik on convert Schema and I got special characters just like below.
%####�������#�������
%####�������#����#��
%####������#�
%####������������#���
%####�����������#��������#������#������
Do I have to change any setting? Why is this happening?
I have SQL Server 2008 R2 and linked SQL Server 2012.
When I do the following
SELECT * INTO dbo.Local_table FROM dbo.Linked_table
all decimal columns automatically get converted into numeric.
What is the reason and how can I get rid of it?
This is automatic conversion that occurs with most SQL Servers. You'll find this happening with at least, but not limited to, server year versions 2000-2014. I don't know of a way to get rid of this restriction because it's a built in server feature which restricts arithmetic equations via query statements.
Here is another SO question/answer which might help you:
T-SQL Decimal Division Accuracy
Here is some MSDN for clarification:
https://msdn.microsoft.com/en-us/library/ms187746.aspx
I thought that SQL Azure was built on top of SQL Server 2012, but the compatibility level when you create a new database is 100 (SQL Server 2008's compatibility level), not 110.
SELECT compatibility_level FROM sys.databases WHERE name = 'Test';
I tried changing it to 110 using the two methods that I am aware of:
ALTER DATABASE Test SET COMPATIBILITY_LEVEL = 110;
--> Incorrect syntax near 'SET'.
EXEC sp_dbcmptlevel 'Test', 110;
--> Could not find stored procedure 'sp_dbcmptlevel'.
The reason this is an issue for me is because SQL 2008 doesn't support geography shapes which cross hemispheres, so if you zoom out a map to see the world and try to store the bounds of the map it will fail. Pretty silly right?
I thought that this would not be an issue in SQL Azure, because it has been fixed in SQL Server 2012, but when I try to create a shape that crosses hemispheres I get the following error:
Microsoft.SqlServer.Types.GLArgumentException: 24205: The specified input does not represent a valid geography instance because it exceeds a single hemisphere. Each geography instance must fit inside a single hemisphere. A common reason for this error is that a polygon has the wrong ring orientation. To create a larger than hemisphere geography instance, upgrade the version of SQL Server and change the database compatibility level to at least 110.
So it is telling me to change the compatibility level, like it knows that this has been fixed already, but I can't figure out how to do that in SQL Azure. Anyone have a suggestion of something to try? Or let me know if it just is not possible right now?
It is hard to say if the current SQL Azure is based on SQL Server 2008 or 2012 however November 2011 update adds lots of new feature to it from SQL Server 2008 and 2012. More Info on Database Engine Versions:
Updated Engine Version: This release updates the underlying SQL Azure database engine version from 11.0.1477.26 to 11.0.1750.34 as it is rolled out across data centers.
The following link talks about what is and what not supported with SQL Azure comparative to SQL Server 2008 and SQL Server 2008 R2:
http://msdn.microsoft.com/en-us/library/windowsazure/ff394115
The following links adds more info about what new Programmability Enhancements are added in SQL Azure from SQL Server 2012:
http://msdn.microsoft.com/en-us/library/windowsazure/hh987034.aspx
UPDATE: August 2015
Azure Sql Database V12 has a default compatibility level of 120 with possibility to go up to 130 or down using ALTER DATABASE SET COMPATIBILITY_LEVEL syntax.