SQL installed but powershell not picking up sqlps commands (like invoke-sqlcmd)

Question

I installed ms sql server with chocolatey:

choco install SQLServer2012DeveloperEditionWithSP1 -y -f -source 'http://choco.developers.tcpl.ca/chocolatey' -c "$env:WINDIR\temp"

SQL seems to be installed and working well outside of powershell where it doesn't work. I can see the sqlps module with:

Get-Module -listavailable

...

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------

Manifest   1.0        SQLASCMDLETS
Manifest   1.0        SQLPS

The commands seem to be missing though. I don't have invoke-sqlcmd etc. In theory I should get access to them if I install the module but when I try to import-module sqlps but I get an error about not having a sqlserver drive:

PS C:\WINDOWS\system32> Import-Module SQLPS
Set-Location : Cannot find drive. A drive with the name 'SQLSERVER' does not exist.
At C:\Program Files (x86)\Microsoft SQL Server\110\Tools\PowerShell\Modules\SQLPS\SqlPsPostScript.ps1:1 char:1
+ Set-Location SQLSERVER:
+ ~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (SQLSERVER:String) [Set-Location], DriveNotFoundException
+ FullyQualifiedErrorId : DriveNotFound,Microsoft.PowerShell.Commands.SetLocationCommand

I know several people in my group who went through these steps and did get the correct sql ps setup working.

Any tips or ideas would be very helpful. Thanks.

Answer 1

Good day,

I am guessing that you are using SQL Server 2017, since this is common issue in 2017, as I will explain below. I am not sure what version is used since this question is a bit old and was asked on May 2 '17 at 22:58

The error that you get includes the basic issue

Set-Location : Cannot find drive. A drive with the name 'SQLSERVER' does not exist.

It does not say that the module 'SQLPS' does not exist, but that the module 'SQLSERVER' does not exist

The explanation is that until 2016 SQLPS module was included with the SQL Server installation, but the PowerShell module which we use is the 'SqlServer' module. 'SqlServer' module was included with SQL Server Management Studio (SSMS) 16.x, but if you are using SSMS 2017 (17.x) then 'SqlServer' module must be installed from the PowerShell Gallery .

The procedure to install it is to execute the command:

Install-Module -Name SqlServer

If you get error like PackageManagement\\Install-Package : The following commands are already available on this system:...

Then you can enforce the installation using the parameters: -Force and –AllowClobber

Since I am not familiar with your system, I will NOT advice you what to do or say if you should enforce the installation, but this is the solution which I would probably do in most cases like this (according to the information I noticed in this thread)

Install-Module -Name SqlServer -Force –AllowClobber

In order to confirm that the module is instead you can execute the following command:

Get-Module -Name SqlServer -listAvailable | select Name, ModuleType, Version

Check the version of your installation using the command above, and use it in the following command in order to import the newest version (at the time I write this answer the version is 21.0.17279):

Import-Module SqlServer -Version 21.0.17279

That is all... If all went well then you should be able to use all the SQL Server PowerShell commands

Answer 2

As pointed, here are the links that you should refer now.

MSDN Link

Running SQL Server Powershell

Cannot find path 'SQLSERVER' Issue

There is an answer given by Jarret. Simply loading the module won't help actually. These set of commands have to run after that.

Push-Location
cd $sqlpsPath
Add-PSSnapin SqlServerCmdletSnapin100
Add-PSSnapin SqlServerProviderSnapin100
Update-TypeData -PrependPath SQLProvider.Types.ps1xml 
update-FormatData -prependpath SQLProvider.Format.ps1xml 
Pop-Location

Hope it helps.

Answer 3

Just a side-note for future readers, I was trying to create a sql backup via powershell. The cmdlets ran as they should under an Administrator account, however running the script under a regular user account, I got the following error:

Cannot find a provider with the name 'SqlServer'

Googling that question brought me here, but the answer to my issue was in a forum post here: https://social.technet.microsoft.com/Forums/windowsserver/en-US/626bb81a-00ba-4239-ad0a-fec32546350a/check-if-drive-exists-if-not-map?forum=winserverpowershell

I encountered a weird issue and hope that somebody may have a fix for this.

Microsoft SQL Server 2014 (SP2-GDR) (KB4505217) - 12.0.5223.6 (X64) (yeah I know...it's a dev server)

Windows 2012 R2

PSVersion 4.0

I load the SQL assemblies in the PS script

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SMO") | Out-Null

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SmoExtended") | Out-Null

The following will fail if I run this immediately after loading the assemblies

Get-ChildItem SQLSERVER:\\SQL$env:COMPUTERNAME

Get-ChildItem : Cannot find drive. A drive with the name 'SQLSERVER' does not exist.

If I run the following first, I'm fine.

Invoke-Sqlcmd -Query "SELECT TOP 1 * FROM sys.sysobjects" | Out-Null

Get-ChildItem SQLSERVER:\\SQL$env:COMPUTERNAME

I just wanted to amend that I just need to run

Invoke-Sqlcmd | Out-Null

This seems to then fully load the assemblies into memory and everything is OK after.

So I added this to my script:

# SQL cmdlets below need some dll imports from system
# These do not get loaded sometime when running under an non-admin account (Cannof find a provider with the name 'SqlServer')
# Running this dummy command seems to load all needed dlls
# Also see: https://www.sqlservercentral.com/forums/topic/unable-access-sql-provider-in-powershell-without-running-an-invoke-sqlcmd-first
Invoke-Sqlcmd | Out-Null

Seems like valuable information that shouldn't get lost, so I thought i'd post it in the highest SO when googling for that particular error.

One could argue that installing the module rather than this dummy method would be cleaner.