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.
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 .
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.
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.
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.