0

I wrote a powershell script that includes a check for the invoke-sqlcmd cmdlet. Script runs fine under Windows Server 2016. On 2012 R2, the script fails with:

Add-Content : Cannot use interface...

errors when trying to create and write to a log file.

What I discovered is that on Windows Server 2012 R2, when the Get-Command invoke-sqlcmd command is run, it changes my drive to PS SQLSERVER:\> instead of PS C:\>. This is apparently causing my create and update log file sections to fail.

Any idea why Get-Command would change the drive when checking for a SQL cmdlet, and suggestions to change it back or prevent it in the first place? I know I could throw a c: in the script, but that seems too simple a solution and might have to do it after every DB call.

0

I found an answer over on StackOverflow.

https://stackoverflow.com/questions/27273440/why-working-directory-is-changing-when-executing-invoke-sqlcmd

Apparently, on Windows Server 2012 R2, doing anything with a sql cmdlet preps the environment to run in PS SQLSERVER:\>. Following the suggestion in the above link, I wrapped my sql cmdlets with Push-Location and Pop-Location. This seems to resolve my issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.