Sqlserver

While presenting Backup Basics with PowerShell and dbatools at ONDT, I mentioned a caveat with the -ReplaceExisting switch for Install-DbaMaintenanceSolution. This switch drops all of the objects installed by the Maintenance Solution, including the CommandLog table. If you use that table to produce evidence that the various maintenance tasks are being performed on a regular basis or use it to track performance of those tasks over time, dropping that table presents a problem.

I got a merge a while back that included a change I wasn’t expecting from one of my developers. All they were doing was renaming a column on a table. We had names settled a while ago. What’s up with that?

Turns out, when I created the table, I named one of the fields BrithYear. This merge request corrected it to BirthYear. The misspelling slipped past me, past everyone else, it was only discovered because when this developer was building the a new query into their code, they spelled the field as one would expect, and the query threw an error.

I had the honor of presenting a new session, Backup Basics with PowerShell and dbatools, at the first Ohio North Database Training meeting this evening. Thank you to the group leaders for the opportunity and to everyone who attended.

Because this was both a brand new session and an attempt at a new way of delivering the presentation, I had a couple tech glitches but things went pretty well once they were understood and ironed out. Definitely room for improvement next time!

A former colleague emailed me with a question about retaining/fixing database users and permissions after restoring a database. They were copying a database from one instance to another, with different logins, users, and permissions between the two instances. Backup & restore to copy the database is easy enough, but because users & permissions are kept inside the database itself, the destination environment loses all its permissions settings in the process. What to do?

A little while back, I offered up a one-liner to scan your SQL Server instances and report which ones are out of date. But what if you need to take the next step, determining which updates need to be downloaded? That’s exactly what Josh asked on the SQL Community Slack recently.

Can Test-DbaBuild also bring back the KB number? From reading the docs it looks possible as it does return the compliant version form the .json file, or at least I think it does 😀. The intention is if the KB is returned, then one could pipe it through to Get-DbaKbUpdate and/or Save-DbaKbUpdate to have the KB’s automatically downloaded to the desired path.

Taking it back to SQL 101 today because I recently saw something that floored me. I’m a big fan of temp tables. I use ’em all over the place to stash intermediate results, break a dataset down into more manageable chunks, or even share them between procedures. And as it turns out, there’s more than one way to create them.

The Traditional Way

If you’re planning out your temp table usage, you’re probably creating them just like any other table, then populating them.

It turns out I was doing this all wrong for months.

For the longest time, I’ve been checking my SQL Server instances to see what needs patching with Test-DbaBuild from the dbatools PowerShell module. But the result was always the same - it never returned a Service Pack or Cumulative Update target. I glossed over it because I knew what the right answer was already, but recently I decided that wasn’t good enough. We need a reliable report to give to other people.

This tripped me up a few weeks ago, but once I stopped and thought about for a moment it made total sense. I was trying to copy some data into a temp table and got an error I’d never encountered before.

Column, parameter, or variable #1: Cannot find data type MyStringType.

What’s that all about? Let’s find out.

Why User-Defined Types?

I’ve never been a fan of user-defined types (UDT). They definitely have applications, but there’s also a temptation to use them to “standardize” things like string lengths or decimal field precision across a whole database. On the surface, that seems like a good idea. But these can cause trouble as well. Not right-sizing your fields can lead to data quality and query performance problems.

This is one of several posts on modernizing T-SQL code with new features and functionality available in SQL Server.

Last year, you finally retired the last of your SQL Server 2008R2 instances. Congratulations! But are you taking advantage of everything that your new instances have to offer? Unless you did a review of all of the T-SQL in your applications, I’m guessing not.

This one seems pretty basic, but it’s got a trick up its sleeve - the TRIM() function.

T-SQL Tuesday is a monthly blog party hosted by a different community blogger each month, and this month Tracy Boggiano (blog | twitter) asks us to talk about Query Store, whether we’re using it or not.

---

For this T-SQL Tuesday, write about your experience adopting Query Store, maybe something unique you have seen, or a how your configure you databases, or any customization you done around it, or a story about how it saved the day.  Alternately, if you have not implemented yet blog about why if you are using 2016 and above, we know why if aren’t on 2016.  If you are unfortunate to be on below 2016 write about what in Query Store you are looking forward to the most once you are able to implement it.  Basically, anything related to Query Store is in for T-SQL Tuesday, hopefully everyone has read up on it and knows what it can do.