I mentioned in the last T-SQL post how you could create a datetimeoffset value by combining a datetime2 with an offset. But sometimes you need to switch to a different offset. And that’s what the SWITCHOFFSET() function does:
In this query, I was taking a local time (that had a timezone offset of 11 hours), and switching it to the current time in Seattle (with a -7 hours offset):
2020-07-06
It’s great to have SQL Server data types now that handle time zone offsets. Sometimes though, you need to combine a datetime value and an offset to produce one of these new values. That’s what the TODATETIMEOFFSET() function does:
In this example, I’ve taken 28th February 2019 and added a timezone offset of 10 hours to it:
the output data type is datetimeoffset.
The data type of the first value is actually datetime2.
2020-06-29
One of the more popular things I’ve ever written is my (free) SQL Server Management Studio Tips and Trips eBook.
I’ve had a few people asking why I haven’t done a video on it lately. I’m planning to do a series on it very soon.
In the meantime, here’s a session that I did with Amit and the people from Data Platform Geeks a while back: Tips and Tricks Session
2020-06-25
I mentioned in previous T-SQL posts that one of the challenges is that there’s no standard way to write dates, so we end up having to write them as strings. Now that was a real problem in earlier versions where people would get that wrong. The DATEFROMPARTS() function added in SQL Server 2012, though, can help with this:
This query takes the year 2019, the month 2, and the day 28 and returns a date:
2020-06-22
When writing T-SQL, it’s surprising how often you need to calculate the end of month for a given date, and so you want the last date in the month for whatever date you supply. That’s the main thing that the EOMONTH() function does.
So in this case, 16th of February 2020, we might wonder if that is a leap year. So would it be the 28th or the 29th? And so if we execute that, we find the 29th is the date, so this is actually a leap year:
2020-06-15
I’ve shown in recent posts how to extract components out of dates and times. You might also want the name of a month or a day, rather than just its number. The DATENAME() function does that.
In this query, I’ve asked for the name of the month that’s part of the date 28th February 2019. So it returns:
An important concept here though is that this is based upon my regional settings. Mine currently are set to US English, to it returned February. But if I had different regional settings, it would display the name in whatever region I was configured to use. So if I had a French configuration that would come back with Février instead.
2020-06-08
I often say that I love writing code that writes code. I use T-SQL to generate T-SQL scripts all the time. (I use Excel to do it too but that’s a story for another day). An issue I ran into a while back though, was how to output decimal numbers. I wanted to make sure I was using the correct decimal separator for the user who was running the script.
2020-06-03
I’ve seen a lot of people lately complaining about meeting burnout. It seems that in our pandemic-isolated world where staff members and others are available pretty much on call all day long, it’s become really common to have a much larger number of meetings than we used to.
I’m interested in why this is. Perhaps it’s the lack of contact leading to a desire for more contact and conversation, but if there were a lot of unproductive meetings before, nowadays that seems to have increased so much that it seems almost silly.
2020-06-02
In previous posts, I mentioned that you can easily extract the year, month, and day from dates and times, but you might want other components. That’s what the DATEPART() function does.
You can see the output from the query above here:
To use this function , we put the interval that we’re after and then the value we want to find it out from. So if you look at this one, I said I wanted the day from 28th of February 2019. The day is 28.
2020-06-01
I’m often working with developers who are migrating to SQL Server from Oracle. (Well, who can blame them?) One of the first questions that I’m often asked though, is where is the dual table?
In Oracle, a SELECT statement must have a FROM clause.
In SQL Server, this code will work fine:
SELECT UPPER('Hello');
It will just return the string converted to upper case. You can alias it as well:
SELECT UPPER('Hello') AS Greeting;
Again, you’ll get the converted string but the column will be called Greeting.
2020-05-29