July 28, 2013 at 9:00 am
It must have had something to do with the switch in SQL Agent 2008 to 2012 from them dropping us into a mini-shell versus dropping us into a full blown PowerShell.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
July 28, 2013 at 9:05 am
More than likely. I've just gotten into the habit of just calling powershell directly in a cmd line from the job server instead of putting it into a powershell job step just because of niggly little issues like this.
Scott
July 28, 2013 at 9:12 am
That's what I do too, and recommend on 2008 R2 but I was hopeful with the change in the approach to PowerShell steps introduced in 2012 that the user experience would have improved to the point where I would not need to do that anymore. Using powershell.exe some of my command lines have become pretty gnarly with all the parameters I pass to my scripts. However, since I do not run 2012 as a primary platform in production just yet my knowledge is limited to some specialized instances I have rolled out plus some local testing. I have not rolled my generic maintenance routines to a 2012 environment just yet to see how they would react if I converted them to use PowerShell steps.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
July 28, 2013 at 9:19 am
ryan 8226 (7/28/2013)
I chose to use the newer PowerShell command "Set-Location c:" instead, which does the same thing.
By the way, cd is not a different, older command than Set-Location, it's an alias, so they're one in the same:
There are a bunch of built-in aliases in your default PowerShell session, cd being just one of many. Type alias at a PowerShell prompt to see them all:
You can also define new aliases of you own as well using New-Alias in case you are interested. Check the help for complete details:
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
September 30, 2014 at 4:53 pm
This was a huge help. It solved my problem.
June 11, 2015 at 10:47 am
sgnewman (9/5/2012)
You need to change the provider when the job runs. It's running under the sqlserver:/ provider. Just do a cd c: at the top of your script and it will now accept the unc path.Scott
This info helped me solve my problem that was similar to OP (invalid path).
Thank you!
June 11, 2015 at 11:55 am
No problem. This is apparently the most helpful thing I've ever done on the internets. 😉
Scott
June 9, 2016 at 12:27 pm
Just as an addendum; Sql Server 2016 SqlPS FINALLY doesn't switch up the provider anymore (and loads tons faster to boot...), so hopefully this thread won't be useful anymore...
S
May 3, 2019 at 4:07 pm
This is still helpful in 2019.
July 22, 2022 at 9:41 am
Still helpful in 2022, C: solved my problem 🙂
Viewing 10 posts - 16 through 24 (of 24 total)
You must be logged in to reply to this topic. Login to reply