New year and new blog

It has been a looong time since I last wrote a blog post. Not because I have been lazy, but because I have been busy with other things. I have been working on moving my blog to a new engine and I’m happy to announce that it’s finally ready.

What happened?

Well, we all know that things turned out for the worst in 2020 with the pandemic. That year I and Kevin Chant did about 20 sessions for many different events. We also did a lot of work for the community and we were able to help a lot of people.

If you’ve used the data masking command in dbatools you’ve probably noticed that the PowerShell session becomes memory intensive when it has to handle larger tables with one or more unique indexes. The reason that happens is that during the data masking process the command looks for any unique indexes in the table. If it finds a unique index it will create a unique row for all the columns in the unique index. The command creates the values in memory. This means that you’ll have all the values that eventually get inserted into a table in memory. This can lead to a massive amount of memory being used when you have wider unique indexes with large data types. There was also another problem that I had to fix and that was that it would create those unique values for every unique index. This was also the case when there were overlapping columns when multiple unique indexes were being used. This was not efficient and I wanted to make something better for that too. I’ve been thinking about solutions for this problem because I think this command should be usable in almost every situation.

Recently I learned that SQL BITS was going to be an online event. The organizers also decided to do another approach and let the presenters record their sessions. I’m pretty familiar with SLOBS and have been streaming content for the last few months. This gave me some experience in setup scenes and other parts of SLOBS a little more efficiently and make it easy to record my session. Here are some of the things I did to make things easier.

Consider the following scenario, you’re a database developer and your company has just decided that they want to implement DevOps for databases. You have multiple databases that need to be put under source control and each database needs its database project. The first thing you’ll need to do is decide whether or not you want to use migration-based or state-based deployments. This post is not going to discuss the pros and cons of these different methods, instead, we’re going to use state-based migrations using SQL Server Data Tools (SSDT) solutions.

It’s that time of the month for another T-SQL Tuesday.

In case you are new to T-SQL Tuesday this is the monthly blog party started by Adam Machanic (b|t) and now hosted by Steve Jones (b|t). It’s a way of encouraging blog posts from the community and helping to share knowledge. This month’s T-SQL Tuesday is hosted by Jess Pomfret (b|t). Jess invites us all to write about your favorite life hack.