Working with the latest release of SQL Server is always exciting, and it’s even more thrilling to discover that some of the new features are already available on Azure SQL DB. As I mentioned in my previous blog post about the “Drop if Exists” clause, many capabilities are introduced on the cloud platform first before being rolled out to on-premise SQL Server. This approach allows for thorough testing and scalability, giving enterprises the confidence to adopt these features.

During one of my presentations at a local user group, someone asked if all features are initially introduced on the cloud. This question piqued my curiosity, and I decided to investigate further. I wanted to see if the “Drop if Exists” code from my previous blog post would work seamlessly on SQLAzureDB. To begin, I connected to the latest database I created. Since I was running the CTP2.0 of SQL Server 2016, I was eager to find out which version was already running on the cloud. To my surprise, the production environment was already using the latest bits. This rapid deployment of updates is a testament to the scalability and agility that the cloud brings to the table.

Returning to the core topic, I had a feeling that my “Drop if Exists” code would work perfectly on Azure. I proceeded to execute the following code:

DROP TABLE IF EXISTS my_test;
GO
DROP PROCEDURE IF EXISTS my_test_procedure;
GO

The code executed without any issues, confirming that the “Drop if Exists” functionality is indeed available on Azure SQL DB.

Next, I wanted to explore something interesting that I could do on the cloud but not on an on-premise SQL Server. I turned to the documentation and discovered a new function called DATEDIFF_BIG(). This function allows for high precision calculations, which is not possible with the DATETIME functions available in SQL Server. For example, let’s calculate the number of nanoseconds in a year:

SELECT DATEDIFF_BIG(nanosecond, '2015-01-01 00:00:00.0000000', '2016-01-01 00:00:00.0000000');
GO

The result is “31536000000000000”, which cannot be obtained using the on-premise version of SQL Server 2016. This discovery highlights the rapid pace of innovation on the cloud platform. If you were to run this code on an on-premise SQL Server, you would encounter an error indicating that the “DATEDIFF_BIG” function is not recognized.

I’m curious to know how many times you’ve needed higher precision when working with DATEDIFF functions. What are some use cases you’ve encountered? I would love to learn from your experiences, so please share them in the comments below.