The main difference that I can see when using
SUBSTRING()in SQL Server versus in PowerShell is that SQL Server is very forgiving.
If you have a string that is 20 characters longs and you ask for everything from the 5th character to the 100th character, SQL Server is going to look at this, see that the string does not go to the 100th character, and just give you everything that it can.
It’s a small difference but an important one.
There are many ways to create a date from a string. First you’ve got the CONVERT() function and the CAST() function. Next you’ve got DATEFROMPARTS(), DATETIMEFROMPARTS(), DATETIME2FROMPARTS(), SMALLDATETIMEFROMPARTS(), TIMEFROMPARTS(), and DATETIMEOFFSETFROMPARTS().
That’s a lot of functions for one simple task isn’t it? To be fair, it’s really more than 1 simple task. Each of these functions is meant to be paired with the matching data type so you get just what you want. To go along with these you also have the ISDATE() function which tests the value to be sure it’s a date.
I never liked the verbosity of the Oracle TO_DATE() function…but I am biased.
Daniel Janik is currently running an Oracle versus SQL Server series, looking at how the two database systems expose common functionality. His latest topic is pagination:
Today’s topic is Pagination. Paging is a really important feature for web pages and applications. Without it you’d be passing large amounts of data to the application and expecting the application code to figure out which rows it needed to display.
Thankfully, someone smart came up with a way to do this on the database so you’re not returning gigs and gigs of data to the webserver to sort through.
Read on to see how the two platforms do this.
select SysDateTimeOffset();and you should see a date and time which mirrors your server’s current time, plus a time zone offset showing its current offset from UTC; this includes any time zone offset, plus any daylight savings time offset.
If I were to run this (from the UK) on August 15th, 2017 while my clock is showing that it’s noon exactly, I would get
2017-08-15 12:00:00.0000000 +01:00; the +01:00 offset is because the UK is offset by one hour from UTC during daylight savings. The
datetime2portion of a
datetimeoffsetis in local time, not UTC.
My normal operation is to store everything in UTC and let the application convert to local times. That allows you to compare dates much more easily and reduces confusion around daylight savings time.
Do you use RIGHT JOINs? I myself rarely use a RIGHT JOIN, I think in the last 17 years or so I have only used a RIGHT JOIN once or twice. I think that RIGHT JOINs confuse people who are new to databases, everything that you can do with a RIGHT JOIN, you can also do with a LEFT JOIN, you just have to flip the query around
So why did I use a RIGHT JOIN then?
Don’t be lazy; switch out those right joins. The trick is that for every RIGHT JOIN statement, there is an equivalent statement which does not use RIGHT JOIN. The percentage of the time that you might benefit from RIGHT JOIN is so low that the fixed costs of mentally processing what’s going on tend to overwhelm the slight benefit of that style of join.
Now I can run the SELECT…INTO statement using the new ON FILEGROUP option. I’m going to run an example SELECT statement to capture Sales in the UK: –
We are one step closer to CTAS on-prem… Being able to select into a specific filegroup is nice when you want to segregate tables by filegroup to make recovery of the most critical tables faster: having a primary filegroup, and then a filegroup for the critical tables for your application, followed by the history tables and other large tables that the app doesn’t need immediately.
One cool little feature in SQL Server 2016 is COMPRESS(). It’s a TSQL function available in all editions that shrinks down data using the GZIP algorithm (documentation).
Things to know about COMPRESS():
Compressed data is in the VARBINARY(max) data type
You get the data “back to normal” by using the DECOMPRESS function – which also outputs VARBINARY(max)
You can’t use columns of the VARBINARY(max) type in an index key column– but it may be useful to use the column as a filter in a filtered index, in some cases
COMPRESS() uses standard GZip compression, so you could use methods other than DECOMPRESS() to inflate the data—for example, bring the compressed data out to your application and use language-specific GZip libraries to decompress the data. Read the whole thing.
The last time we were together, we learned how to use the MERGE statement when we wanted to insert rows that didn’t exist and update rows that didn’t. This time we’re going to add onto that. We’re adding the seldom used, but delightfully potent – delete rows that no longer exist in the original table.
MERGE is an enticing but dangerous piece of syntax. It looks so nice until you realize how many bugs and oddities there are in the command.
Bitwise operators are operators that work on the individual bits of a value. Let’s take a little look at the three bitwise operators that we’ve got in SQL server (there is actually a fourth but I’ll talk about that one another time) and hopefully things will start making a bit of sense.
Now let us never speak of this again…
So, drinking my first (of many) coffee of the day, I asked him what was wrong with it.
I have two tables. 1 with values 1,2,3 & the other with values 1,2,3,4,5. When I use delete exists, it should just delete 1,2,3 but table1 is always empty.
Hmmm, not an unreasonable assumption I suppose so I asked him for his code.
Read on for Shane’s explanation, though he doesn’t like the verbosity. My version is, what happens in EXISTS stays in EXISTS. It just returns a signal to the outer query saying yea or nay and the outer query does its thing accordingly. In this case, if you want to tie results back to the delete operation, use IN (the ANSI standard way) or JOIN (typically my preferred way, given that IN can get dicey with more complex criteria).