The Ashdar Partners Blog

Lately, I have been trying to up my game a bit and one of the things I am doing is using some of the latest tools and bits of things. (Partly, this is because I have been working with some old technology lately and I am feeling "dated". Ask me about Fox Pro, if you dare.) PowerShell After many years of not seeing value in updating, I am moving to PowerShell 6. (Version 6.2, specifically.) Frankly, more things work than I expected. I haven't seen any performance regressions and things have gone smoothly. I think I spent more time incorporating the PowerShell version into my Prompt function than anything else that I had to do because of the upgrade. SSMS I am running the absolutely-latest build of SSMS. I skipped some SSMS builds when the removed the diagramming functionality. Now that it has been put back into the product, I am on the update train again. Aside: The diagramming feature isn't awesome but it is easy to use, requires no installation, doesn't ...

(Actually, they are up to version 1.0.2 already.) I've been using DbaTools for a number of years. I have come to rely on it more and more. Now, I find it at least as deeply entwined in my PowerShell code as the SqlServer module is. All right-thinking people use DbaTools. And you should, too. More seriously, DbaTools is one of the few PowerShell modules I absolutely rely on, on a daily basis. I use DbaTools so frequently that I can't easily categorize it all. In short, I can: Check servers, instances, databases, disks, security and many other things for issues on a daily basis Check business rules on a daily basis Restore databases to test environments on an ad-hoc basis. I have this working so smoothly that I forget that I have Ola Hallengren's backup scripts actually running the database backups.  Load data into databases Extract data from databases I've never actually used DbaTools for it's original purpose, which was migrating databases and instan...

My last entry chronicled some of the work I did to get a 'development environment' up and going for the dbatools project. Here are the rest of the details, including the issue with the "BatchParser" DLL error. What I did to get the dbatools Pester tests going on my VM: I checked out a copy of the appveyor project that sqlcollaborative has. This seems to be a requirement for testing with the 'official' dbatools tests, even if you aren't going with a full-blown appveyor workflow. If you want to write your own Pester tests, you can do anything you want to. I created a custom version of configure.ps1 and put it in c:\temp. This informs the Pester tests about my specific environment. I set my SQL Server 2008 R2 and SQL Server 2016 test instances to allow SQL Logins. I do not allow SQL logins on my instances if I can avoid it, but it makes sense to test dbatools features that support SQL logins. Those changes let me run a...

I spent a good amount of time this week getting a system up so that I could actually maybe start contributing code/tests/something to the dbatools project. I've been wanting to do this for a while, but there is a large amount of "stuff" to get working before being able to do "real work" and getting it all done eluded me.  Over the last year or so, I've spent a couple of hours getting up to speed, getting things installed and then run out of time just as I get to the point where I can start working with the code. (You know, the fun part.)  A few months later, I'd give it another go, only to have to spend time fetching my remotes (since I fly solo so often, I'm a perennial newb at some things that I wish I weren't a newb at) and addressing other bit rot issues. By the time I got caught up again, I'd be out of time. Wash, repeat, et cetera and so forth. I still support several SQL 2008 and SQL 2008 R2 instances. I've noticed a...