I recently teamed up with PowerShell MVP Chrissy LeMaire to make a bigger difference in the SQL Server + PowerShell community. Last week we were talking about SQL + PoSh like always, and we started talking about what really annoys us about the SQLPS PowerShell module (besides the dearth of cmdlets) and we up with 3 main points that are pretty close to show-stoppers as far as us recommending to others that they should use the SQLPS PowerShell module.
(from Chrissy’s blog…)
“Reasons I don’t use SQLPS
- It takes 3-5 seconds to load
- It changes my directory
- It produces warnings upon load”
So as we were coming up with this list of things that we feel really need to change we started digging into how hard it would be to change them. Right away (we’re talking line #7 of the code) Chrissy spotted something that shouldn’t be done. With a quick edit to what should be done Chrissy was able to drop the load time of the SQLPS module from 3-5 seconds down to sub-second.
I was amazed. Dumfounded actually that for years such a simple fix has existed and none of us supposed ‘SQL+PoSh Experts’ ever caught it. I chimed in next with how much I hate the fact that when you load the SQLPS module it relocates you to the SQLSERVER Provider. If you just wanted to backup a database with the cmdlet don’t actually need to be within the provider. Plus when you’re within the SQLSERVER:\ Provider you can just forget about tab completion. Chrissy helped me put together a Connect Item to recommend that that functionality be removed. To make sure I wasn’t off-base in my dislike for this ‘feature’ I surfaced this Connect item with some people active in the PowerShell community. Some of these people are familiar with PowerShell capabilities of SQL Server and some are not; here are a couple of their reactions:
So I basically found two allies on this issue instantly, on to the third thing. The SQLPS module uses unapproved PowerShell verbs and you get a message about this on load. Whether the verbs the SQL team used need to be added to the approved verbs list or not is not the point. Turns out, SQL Server and PowerShell are made by the same company so if the SQL team needs them that badly it would seem to me that they need to go make their case to the PowerShell team. This is going to be the 3rd major release with this warning message popping up every time you load the SQLPS module; this should have been resolved by now.Here are the 3 Connect items we ended up filing that night.
I realize with RC0 already being out that there is very little chance of these items getting fixed before RTM of SQL Server 2016, but there’s a chance. That’s why I’m asking you to Up-Vote these 3 items if PowerShell support in SQL Server is important to you. It’s slim, I know; but if you think about it, they probably have everyone they could possibly need assembled already. If the necessary people aren’t bogged down with bug fixes for RC0 then maybe they could start working on this. Or even if they don’t have the time to fix it right now, they might be able to at least start scoping out the fixes and see if they think it’s really as easy as we think they are.
Again, there are lots more things we dislike about the PowerShell experience for SQL Server and I’m sure you have plenty of things to add too! So maybe, just maybe, if we can get some visibility and <fingers crossed> some traction </fingers> on these 3 Connect Items, then we can get to work asking for more stuff.
Please join me in up-voting or just leave what you dislike most about the PowerShell experience for SQL Server in the comments below. J
