- Host: Steve Stedman / Mitchell Glasscock / George Stedman
- Recording Date: March 12, 2026
- Topic: New updates to Database Health Monitor and a recap of items that have been added
- Listen on Spotify!
- Databasehealth.com
Stedman SQL Podcast Season 3 Episode 6 Database Health Monitor Recap and Updates
In this episode of the Stedman SQL Podcast (Season 3, Episode 6), Steve Stedman is joined by Mitchell Glasscock and George Stedman to dive into the latest 2026 Q1 updates to Database Health Monitor. They break down new quality-of-life improvements like enhanced navigation with the back button history, SQL query formatting for better readability, and improved visibility into historical data updates. The team also explores powerful new Quick Scan checks, TempDB insights, email cleanup options, and major enhancements to blocking query tracking—including query plan capture for faster performance troubleshooting. Plus, they cover schema drift improvements, long-running query reporting, and new filtering capabilities across reports. If you’re looking to simplify SQL Server monitoring and boost performance tuning efficiency, this episode is packed with practical insights and real-world examples you won’t want to miss.
Podcast Transcript:
Steve Stedman 00:16
Hey everyone and welcome to this week’s podcast. This is season three, episode six of the Stedman SQL podcast. I’m your host, Steve Stedman, today I’m joined by Mitchell Glasscock and George Stedman, two of the developers on the Database Health project. Welcome guys. In case you missed it, please be sure to check out our previous podcast on the Deadly Sins of Indexing was episode 3.5 where Mitchell and I cleared up some of the misconceptions around indexing. But as far as this episode goes, this week, we’re going to talk about some of the new Database Health Monitor features that have been released in 2026. So first quarter, we came out with a few improvements around quality of life, improvements, some expanded quick scan things, better troubleshooting workflows and improved historic visibility.
But before we get to that, are you interested in being a guest on the Stedman SQL podcast? If you are just reach out to us and we can talk about what topics, things you want to cover, or talk about anything relating to SQL server, Database Health Monitor or about our company. You can reach out to us at HTTPS, Stedman solutions.com/guests, or go to the podcast page and click on the guest link, fill out the form and find out if you’re going to be a guest on one of our future episodes.
Okay, so Database Health Monitor, what’s new?
Mitchell Glasscock 01:48
Alrighty, well, we’ve, we’re about three months into the year, and we are two releases into Database Health Monitor. We’ve done a January and a late February, March timeframe release. So some of this stuff is pretty new, but some of the users should be on it by the time this podcast comes out. So we’ll go over what we released in January real quick. One of the big things was focusing on some navigation improvement. We’re always working on the quality of life improvements for Database Health Monitor. So we’ve expanded the Back button ability. Now, if you right click the back button, you can get this pop up menu, and you can navigate to any of the pages that you’ve touched in the past. And we there’s about 20 reports depth, so if you’re jumping back and forth, this is a really easy way to climb between reports and servers in Database Health Monitor.
Steve Stedman 02:41
And, you know, that’s one of those that one day I just was working along, and I got so frustrated, and I wished we could do that, so by the end of the day, we could do that.
Mitchell Glasscock 02:50
Yeah, it’s super handy, because we’re constantly jumping through like five different reports to try and pull things all together figure out what’s the problem of something, and being able to look at the times between one hourly report and three others really quickly and say, Oh, hey, this was blocking at the same time that this was happening and this was happening jumping between it.
Steve Stedman 03:11
Yep. And one thing that really pairs well with that is the related links up top where we added those, I think, in the version three, released last year. And if you’re clicking around through those related links, here and there and back again, and you think, oh, gosh, I want to go to that report. That was five clicks back. Well, just right, click on that back button, and yep, and you get the drop down, and you can jump back to where you were, and it shows what the server name, and then the report name and the database name if it’s a database related report. So all right, that’s one of those small improvements.
Mitchell Glasscock 03:46
Another improvement that we made was a formatting option for query readability. So let me see we have it all over the place, but let me find a query that is a little bit longer. Do we have any deadlocks on here? Maybe this won’t be as long as I think it will.
Steve Stedman 04:14
But no, it’s not. It’s not the deadlock go to the long running queries or the blocking on a server that has those. And again, this is our this one is our SQL Server, enterprise 2025 setup, which may not have the kind of load on it we have on our other Okay, there we go. So there’s long running queries.
Mitchell Glasscock 04:38
There we go. So this is just one of the additions in the query advisor. This is a short query, so it’s not going to do much as far as formatting it, but when you’re pulling maybe a 300 line query, and you want to be able to grab this and throw it into management studio, hitting this format button makes it way more readable than what SQL Server gives you. In the raw output.
Steve Stedman 05:02
And you know, what’s worse than the 300 line query is the one line query, where it should be 300 lines, but it’s been formatted on a single line. George and I were working on performance tuning just this morning, and I think probably five or six times I used this dialog to format the query so it was readable where prior to that, it just came through with no carriage returns. And if it’s a stored procedure, it’ll format it correctly. If it’s just a big query with like indentation and sub queries and stuff like that, it gets formatted the way say, the way it should be, the pretty close to the way it is the normal documentation, where it’s indented. Everyone has their own style, but whether you like the style or not, it’s way easier to read this way. So I am really shocked at how often I actually use that format SQL button.
Mitchell Glasscock 05:54
And then one of the last quality of life improvements that we rolled out in January was the historic monitoring, updating visibility. So every time we roll out a release for Database Health Monitor, we’re doing some back end stuff to update the actual DB Health history database that is stored on your SQL Server instance for historic monitoring. So anytime you get an update and you click on one of your instances, and I think I’ve updated all these instances, so we probably won’t, but down here in the bottom left, it’s actually upgrading that DB health, history, database procedures, table expansions and new data collection that we’ve added. So now you can see what it’s actually doing. Think it’s frozen up.
Steve Stedman 06:47
So, yeah, that historic version upgrader, it’s good to know what it’s doing. So it used to be that sometime you would click on an instance, and it would take a second to do that upgrade. And you wonder, Gee, why is it stuck? Well, now you get those updates down in that gray box and, say, updating diversion this, updating the version that, and you can see what it’s doing along the way. All right, so anything else on the version upgrader before we move on?
Mitchell Glasscock 07:11
I think it’s just important to point out, if you are an individual that has a bunch of instances like, I’m connected to roughly 20 on here, maybe not 20. I’m bad at rough counting. But if you’re connected to a bunch of instances, and a new version rolls out, it’s it is important to click on all the instance overviews to get that upgrades on every database that you’re tracking for every instance that you’re tracking. So that’s a good habit of whenever an update does roll out, to do that.
Steve Stedman 07:39
Good point. Okay, so now a word from our sponsor.
Is your SQL Server slowing down your business, slow queries, bottlenecks and unexpected issues, eating up your time, introducing Database Health Monitor, the powerful tool built by our team at Stedman solutions, get real time insights into performance with over 100 built in reports, index analysis, weight stats tracking and proactive alerts, quickly diagnose and find problems before they impact your operations. With an easy to use interface for DBAs and developers, monitor unlimited servers, tune queries and keep your databases running healthy and fast. Download a free trial today at DatabaseHealth.com and take control of your SQL server performance.
Steve Stedman 08:37
Okay, so, George, do you want to take us through the some of the Quick Scan enhancements, and we’ll kind of talk through them together.
George Stedman 08:46
Yeah. So the first one we have is check 39 which is the failed mail messages. We added a right click option to clear failed or retrying messages.
Steve Stedman 09:00
That’s one of those that check 39 has been there for a long time. I mean, that was looking at the numbers. It’s one of the earlier checks I put in years ago, and it was one of those that will we would always, if we see it, we would go and run some T SQL scripts to go and clear out the failed ones. We just made it easy, quick, right click, and you can clear them out if you have them there.
George Stedman 09:26
The other one after that is check number 104, this one is the older failed or retry email messages. It helps you identify older mail features. And then that also includes the right click to purge option, yep.
Steve Stedman 09:39
And with those, the right click option gives you, I think, 30 days, 60 days or a year, or maybe it’s 30 and 90 days back or in a year, something like that. So you can choose, you don’t have to clear them all out. You can choose what you want to clear out on those when they happen. And then 105
George Stedman 09:53
Yeah, check 105 which is large number of email items in MSDB, which this will identify in via. Instruments retaining large volumes of mail history. It’ll also you can use it to clean up and control your MSDB growth, which generally you want to keep on the smaller end.
Steve Stedman 10:11
Yeah, you know what’s interesting too about this one is that Microsoft SQL Server is oftentimes one of your more expensive servers in your in your whole data center, whatever your structure is, whatever you have there, typically it is one of the more expensive ones. Sometimes there’s exceptions. And in the past, we used to have this kind of tagline, we’d say is that a database is a really expensive way to store files. When you can have there’s already a system that stores files. Well, we’ll extrapolate, extrapolate that to say a database is a really expensive system to store sent email if you’re one of those people that tends to be a pack rat and has like, 17 years of sent email items in your inbox, oh, gee, like me or not your inbox, but in your Sent Items folder like me. Well, that’s fine. You can deal with that in Outlook on your own, but don’t waste your SQL Server database as a place to hold years and years and years of sent items out of out of the Yeah, of everything that was sent out of SQL Server. So, yeah, you want to clean this up periodically. Probably should install a job that cleans it up over time. But it’s kind of a waste of a valuable asset like SQL Server to just be pack-ratting the Sent Mail over time. However, if that sent mail is something that is truly, really important to you, maybe you should figure out a way to extract it and store it somewhere else that is a much cheaper storage solution than Microsoft SQL Server.
George Stedman 11:36
Alrighty. The next few checks have to do with Temp DB. We have check 101, which is too many temp TV files. This will identify if you have too, too many files in Temp DB.
Mitchell Glasscock 11:48
And we did a recent podcast on Temp DB configure, or general file configuration recently, Right? Steve, I believe me, and you did one?
Steve Stedman 11:57
Yeah, that was, gosh, that was the one. I think we did it when we were on the road. And I actually record, recorded it for recorded it from the front seat of my car, which I apologize for that. I will never do that one again.
Mitchell Glasscock 12:07
So, well, there was good information on how your Temp DB files should be configured. It’s important to get the number of files and the size of files correctly. So that’s what, 101 and then I’m guessing, George, you’re going to go to 102 next?
George Stedman 12:23
As to what check 102 is Temp DB files are too small, which highlights if your Temp DB configurations will lead to excessive auto growth.
Mitchell Glasscock 12:34
This 102’s is kind of interesting too, because we have another quick scan check that shows if Auto growth is happening a lot, but this one’s kind of that pre if you haven’t had any auto growth and you’re maybe you’re configuring a new server and you miss setting up Temp DB to the correct sizes, this will catch it so that you don’t have to experience the pain of a bunch of auto growth happening every time you restart SQL Server.
Steve Stedman 13:00
Yeah, definitely good things. And you know, on this Mitch, the was it just yesterday or this morning? I forget that you and I were talking, and you made some comment about how I’ve shared that a lot of the things in Database Health Monitor were problems I ran into over time, and I think I shared that with you when you started working on Database Health Monitor a couple years ago, but now that you’ve been on it for a while, you’re now starting to point out that there are things in here that have been added because you found them and you never wanted to run in them again.
Mitchell Glasscock 13:31
Yeah. Or if I run into them, I want to, I want to know about it. Instead of trying to scrounge around for it.
George Stedman 13:36
We have one last quick scan check that we added, which was check 103, which is the target recovery time outside recommended range. This will let you know if there’s an unusual recovery configuration settings, and it helps you highlight configurations that may impact checkpoint behavior and crash recovery.
Steve Stedman 13:54
Ooh. This is a really cool one in that over the last, I don’t know, 12 or 14 years, Microsoft has changed the default setting on type target recovery time many times. Sometimes they had it to zero, sometimes they had it at 60 seconds. Sometimes, I think depending on different versions, there’s been some other settings, but this is one of those that can impact maybe how much data could be lost, or how often things are written to disk. And to simplify, if your server gets turned off or suddenly shuts down, what you’re going to have to go take through crash recovery to restore it on startup. So one of those, typically, it’s setting around 60 is recommended. If it’s outside of kind of that recommended range of, like 30 to 90. Kind of that area, we give you a warning in the Quick Scan, just to tell you about it. This might be something that you want to take a look at and adjust.
Mitchell Glasscock 14:49
This is one of those settings that’s also really helpful when you’re migrating to a new version of SQL Server, which was recent podcast, podcast episode. It. You’re migrating an older database to a newer version. That setting on the database doesn’t get changed to the Microsoft recommended for that version. So if you’re bringing from I believe it’s like 2016 and older, or it’s earlier than 2016 that target recovery time is going to be set to zero, and if you move it up to like 2022, it’s going to stay zero when you restore the databases. But you need to, you should be changing that to the recommended of 60, or whatever the version may be.
Steve Stedman 15:35
Good points. Okay, so the open Transaction Report enhancements.
Mitchell Glasscock 15:43
See, I don’t know, I don’t believe we run any open transactions in our testing environment pretty regularly. But the key..
Steve Stedman 15:49
Sorry, to jump in there. Mitch, do you have multi SQL SQL 2022 is that running? And can you connect to it? That’s the one I had some test workload running on it that was specifically leaving transactions open for a specific test case. I don’t remember if that’s still running. No, it must not be okay.
Mitchell Glasscock 16:08
Well, well, it’s good we don’t have any open transactions.
Steve Stedman 16:11
Yeah, yeah. So if we did have open transactions, what would we what would be seeing there?
Mitchell Glasscock 16:19
The big addition is that we’ve just added a new column, you’re going to be able to see the actual transaction database that’s being affected, so where that transaction has been left open. I believe, correct me, if I’m wrong here, but I believe the main distinction is that it can be started in one database, but that doesn’t mean it’s currently affecting that database. It’s where that query is at, what it’s doing as to where the transaction is being left open and what it is affected.
Steve Stedman 16:50
So let’s say you’re using Database A, and in there you do some queries, and then you do an open transaction, and then you modify something in database B. Well, there’s multiple databases then impacted by that transaction. So it’s going to show you which one is got the where the transaction coming opening came from there. So yeah, good stuff.
Mitchell Glasscock 17:11
And then we’ve also added the blocking query plan tracking. So let’s see, do you want to kind of break down the difference between what we were previously collecting with what we were what we’re collecting now, Steve, between that blocking queries?
Steve Stedman 17:29
Sure. So if you want to click on one of the blocking like blocking over time or blocking queries, one of those, Mitch, I mean, we’ve expanded those a little bit too, but the for a long time, we’ve been able to go in and Database Health Monitor and look at what are the times a day that we’re seeing the most blocking happening. And again, this is a test database here, but wow, we got a lot of blocking going on. We’ve got drill down so you can click and drill down on one of those, like, 100% blocks. And it doesn’t mean that it was blocked for the whole hour. It just means that’s the biggest blocking time. And then from there, you can double click and go in and see what it is, the whole sort of blocking structure which we lay out there with. Here’s the top block, and then here’s what’s being blocked by that. What we modified was that now in the database, and you can’t see this through Database Health Monitor yet, but that will come in the future. But if you go to the blocking over time table in the DB Health history database with Management Studio, the query plan for that top blocker is shown, and you can actually open the plan and look at the actual plan that was used at the time the blocking was occurring. The reason we added that was one. Well, it’s totally awesome to have when you’re trying to track down why something’s blocked, but because the plan that was used at the time the query was run may not always match the plan that you see when you open your own the same query Management Studio depending on settings or parameters or data that’s changed or statistics out of date since then. So it’s a great way to be able to go grab and see that. And what’s really cool about it too is that if that plan shows missing indexes, you can go in and find those. Or if the plan is showing warnings, like we use that feature just this morning, implicit conversion, a query was taken over 15 minutes to run using that plan feature from the from the Database Health history database there, we were able to view the plan. We were able to see from the plan that three implicit conversions were being done, and we were able to change the runtime of a query from over 15 minutes to six seconds by changing how those conversions were being done from a varchar to an end varchar type. So the blocking query tracking. Plan tracking is just, in my opinion, one of my favorite things that I’ve added, or not that we’ve added in the last four or five, six months, maybe even the last two years. It’s pretty darn cool, and it just really helps with when you’re trying to track down what was happening at the time that this query.
Mitchell Glasscock 20:00
Blocking for sure. Another one of the changes that we made with the blocking tracking itself is sometimes in large transactions or multi transaction batches, the query recording wasn’t always perfect in capturing the entire batch, either it was too large or a submission just was, I don’t want to say incorrect, but it just couldn’t capture what was submitted at the time. We’ve altered that to now if the if that query is too large, it will capture the last submitted batch, so it can help you track down where that is coming from. So if you see in here that it says last submitted batch. That means that it’s coming from a very large query transaction that we’re now recording with this.
Steve Stedman 20:50
Yep. And these came from, like we said, experience in using it, and things that we saw where what was there works pretty good, but we found out in a certain environment, it wasn’t quite catching what we needed, so now it does a better job. So yeah.
Mitchell Glasscock 21:09
And then I did just show it off with the blocking by hour. You can drill, drill down into the by hour section, so you can click on any of these. But we’ve also added that to the deadlocks by our report. If you’re on the deadlocks by hour, and you want to look at what was happening at 8am on Friday, you can simply just click on that and it’ll show you all the deadlocks that were occurring in that timeframe.
Steve Stedman 21:36
And I can see that this one happens to have, I think my deadlock test script running right? Yep. So it’s specifically forcing deadlocks to happen continuously on certain days of the week for testing purposes, and the things you do when you’re trying to test a monitoring product.
Mitchell Glasscock 21:55
So that covers everything that we released in the January release, and now that brings us to March’s release our latest one version, 3.1 1281, sorry. So let’s jump into that. One of the big ones was the schema drift update. We’ve added some new stuff to schema drift there, and I believe, Steve, that was pretty much all you’re doing on the comparison changes?
Steve Stedman 22:20
Yes. So we’re always asking people for feedback. What do you like about Database Health Monitor? What do you like about SchemaDrift? What do you don’t want, or what don’t you like about it? And we got some feedback that said, here’s a couple things that schema drift was not doing very well. What SchemaDrift does is it goes out and it points at two different databases and it shows you what’s different in the schema. You can go look at like what procedures are different, or what tables or primary keys, any of that kind of stuff like Mitch is showing there. But what we ran into was that there were indexes that had different case on the name of the index, so we changed it to allow for an ignore case. If you’re on a case insensitive database, it probably doesn’t matter, but if you’re on a case sensitive database, it may matter. But there’s now a checkbox there that you can click for to ignore case when it’s doing the comparisons. So that was a small enhancement that I think had a big impact on things.
Mitchell Glasscock 23:23
Yeah, I know you mentioned it, the bug reports and the suggestions, feature suggestions are huge. A lot of the things that were fixed in these last few Database Health Monitor releases are thanks to the community reaching out to us and saying, Hey, this is something I ran into in my environment, something that’s pretty niche, but it helps us fix everything and make database help monitor a way better product for everyone.
Steve Stedman 23:52
Yep. And in our test environment, we only have like 18 different SQL servers running with like 18 different or not 18 different versions, but every version from 2005 through 2020, 2025, and there are things that we miss. There are things that you might have, some completely different setup. You might have a different I don’t know. Well, we ran into one with differences when people had with a date format because they were using a European date format rather than the US date format. We had to fix some of those. We’re happy to fix some of those for our for our European customers.
George Stedman 24:24
So the other part of that that we’re also slowly working on is very slowly, because it’s a lot and we don’t have necessarily the right test environments, is the AWS and Azure compatibility upgrades. A lot of the stuff doesn’t work with those right now, but a lot of the good features do. But if there’s any reports specifically that you want us to focus on adding compatibility for, let us know we’re slowly working through like everything as we have a couple clients with Azure and AWS. Servers, but it’s one of the bigger chunks of development time that we’re we need to add.
Mitchell Glasscock 25:08
Alrighty, let’s go well, let’s jump into the long running queries reports. Then we can show a couple features that we’ve added there. See we gotta find a good test case that’s showing some long running queries. But this is one of the new tracking reports that we’ve added to the historic database for historic tracking. Sorry. So when you’re seeing those updates, that’s what it’s doing on the back end. Let’s go to long running by hour. See if you have anything here, perfect. So this is going to be everything that’s blocking is going to be running for the same amount of time, but it is recording this. So we can see around nine, 9am on each of these days, we have our longest running queries, and if we click on them, we can actually see what is taking all of that time, and what these queries are actually doing and why they’re running for so long. And then another item that we’ve added is on all of these list views, you can now filter. If you right click on any of the columns, you can filter. So if I want to look at just wait for weights, I can filter on that and you’ll see that it’s now tagged with the filter on that column, and we can easily reset all the filters back to normal. So a couple more. That’s another one of those quality of life improvements. But we’ve also added new reports as well.
Steve Stedman 26:42
So will that work on any column in the grid control, yep, yep, and it’ll work on every grid that we have in Database Health Monitor.
Mitchell Glasscock 26:51
Yep, everywhere on Database Health Monitor. We can even filter queries. It might get a little funky looking. If you have really big queries, you’ll only see that one line view of them. But if I want to see just begin transaction queries, or it’s doing update test tables, those are going to be the deadlocks I can filter on that.
George Stedman 27:10
And that one would probably get a lot more messy if it wasn’t the same test queries being run over and over again.
Mitchell Glasscock 27:17
Yeah. But you can filter down on them where I was looking for it originally was be able to filter on a specific user on a specific server, and just be able to look at a filter down for a problem I was chasing.
Steve Stedman 27:18
So yeah, definitely very cool. I like that slightly more mature version of Database Health Monitor.
Mitchell Glasscock 27:34
Yes. Alrighty. So I believe that wraps up most of the features that we’ve added since January and March releases. We haven’t covered all the little bug fixes here and there. You can definitely check out the release notes that we roll out with every update to Database Health Monitor. But one of the big things that we want to say is thank you to everyone that has sent in any bug reports or any feature suggestions, because that definitely helps shape the future of Database Health Monitor, and it’s invaluable to make Database Health Monitor better for our community.
Steve Stedman 28:11
Yep. And with that, didn’t we have like, a pre release, pre release group. We were going to work on Mitch, where, if you’re one of those people that’s regularly helping us out with bug reports or regularly want to get a preview before we release it. Oftentimes, we will have the update available about a week before we get it out to everybody for testing purposes and things. And if you want to be part of that, just use that feedback form and submit feedback. And we can include you in that if you if you meet the criteria of that exclusive group, for sure.
Mitchell Glasscock 28:42
So if you want to send feedback to our team over here, you can go to Database Health.com and then go to the feedback survey in the About tab. And if you fill this out, we will get back to you on status about whether we’re working on that right now, if it’s something that we’re planning on releasing, or if we’ve we have released it, we should be getting back to you and thanking you for all those bug reports. It’s invaluable. And if you’re interested in joining that list, you can definitely fill it out and ask to be included in more feedback or beta testing.
Steve Stedman 29:17
Hey, listeners, if you’re loving these deep dives and mind blowing insights on the Stedman SQL Podcast. Imagine getting even more exclusive episodes behind the scenes, bonus content and premium interviews you won’t hear anywhere else. Head over to our YouTube channel right now and hit that subscribe button turn on notifications so you never miss out on the content dropping every week. Join 1000s already unlocking the full experience, and don’t get left behind. Subscribe on YouTube today. All right. Well, I think that wraps up this episode. Do we want to do a quick review of everything we just touched on here and from 2026 for q1 so in January.
Mitchell Glasscock 30:00
We did a bunch of navigation improvements that back button, focusing on the quality of life with the format SQL buttons, and then also being able to see when that historic upgrader is actually working in the back end. And of course, those five new Quick Scan checks with options to clean it up right there on the spot. And then it’s the that open transaction report. We did a bunch of quality of life stuff here, and some more blocking query tracking and the deadlocks drill through. And then in March, we did some schema drift improvements that long running query reports that we’ve added, both by hour and for the instance level to be able to see what’s long running. I forgot to mention. On the long running, you can also break it down into the database level. There is the long running query report in the historic section of each database, so you can filter down that way another report I used about five times today as well.
Mitchell Glasscock 31:05
And then if you’re filtering down to the database level, you can filter even further with our new list view filtering on each column of every one of these list reports.
Steve Stedman 31:16
So overall, big improvements in sort of the troubleshooting and monitoring and just usability, overall Database Health Monitor. So yeah, Nice work, guys. We had a lot of improvements this quarter, so I think we already mentioned thank everyone who submitted bug reports. We always appreciate that. We’re always looking for feedback from users to help shape the direction. If there’s something that you see in database, I’ll monitor that it’s or you don’t see that something’s missing, please let us know. So yeah, continue to submit feedbacks, bug reports and features can be done at that feedback survey that Mitch mentioned. And I think that wraps up this episode. Mitchell and George, thank you for joining me this week, and thank you to thank you to all of our listeners. Don’t forget to like and follow and click that bell so you get notified of that next podcast. All right. Thanks for watching. Have a great day.
Steve Stedman 32:32
Thanks for watching our video. I’m Steve, and I hope you’ve enjoyed this. Please click the thumbs up if you liked it. And if you want more information, more videos like this, click the subscribe button and hit the bell icon so that you can get notified of future videos that we create.