PowerShell invoke-sqlcmd Get-ChildItem : Cannot call method. The provider does not support the use of filters

Question

I have a strange error occurring when using the invoke-sqlcmd to insert rows into a table. The entire script works perfectly if executed one time, but if I run it a second time,

Answer 1

This may or may not help you. I had the same error when trying to run my script in a SQL Agent job. It would work fine for my account and the service account the agent was running under but refused to work as a job until I prefixed the UNC file path it was reading with

Microsoft.PowerShell.Core\FileSystem::

I don't recommend file shares in automation solutions... but had no choice. Hope it helps.

Answer 2

The answers posted helped me to understand the problem but were not specific enough to provide a solution that worked in my environment. This is what solved the problem for me:

$latestFile = Get-ChildItem Microsoft.PowerShell.Core\FileSystem::$dir | where-Object {$_.Name.ToString() -like $databasePattern} | Sort-Object LastAccessTime -Descending | Select-Object -First 1

The ToString() was required for success. The complete problem statement, debugging, and solution were posted at https://social.msdn.microsoft.com/Forums/sqlserver/en-US/f28d9276-7aad-464c-823e-b9b4637856e1/powershell-script-using-getchilditem-works-with-invokesqlcmd-when-called-from-visual-studio-code?forum=sqlkjmanageability&prof=required I provided the link only for research and attribution purposes. In accordance with StackOverflow's convention of wanting complete solutions instead of links, what I posted was the complete solution to the problem as manifested in my environment.

Answer 3

I know this is a rather old thread, but I ran into a similar issue which led me to this page. Here are the links that explained and resolved the issue for me.

PowerShell Invoke-Sqlcmd switches into sqlps session
Stuck in Powershell sqlserver

Short answer

The SQLPS provider does not recognize UNC paths by default. You can either prefix the UNC path with a specific file system provider:

Get-ChildItem Microsoft.PowerShell.Core\FileSystem::\\pcslog1011\dtcs\ContractEmailNotes\
-Filter '*.txt'

or switch your working directory back to the default after the SQLPS module is loaded by adding this to the top of your script:

Push-Location
Import-Module SQLPS -DisableNameChecking
Pop-Location

Long Answer

It seems the issue is due to a combination of PowerShell switching the working directory from the default to that of the SQLPS provider in addition to the fact that the SQLPS provider doesn't recognize UNC paths (without some encouragement).

So where the normal PowerShell prompt looks something like this:

PS C:\Users\foobar>

It will instead look like the prompt below when you are working in the directory structure of the SQLPS provider (more on what this means here):

PS SQLSERVER:\>

In any event, the first time the script calls Get-ChildItem it is likely done so from the context of the default PowerShell working directory (where UNC paths are understood). However, calling Invoke-Sqlcmd loads the SQLPS module which changes the working directory to that of the provider which does not recognize UNC paths. So the next time Get-ChildItem is called, it is done so from within the directory structure of the provider, raising an error. The issue doesn't actually have anything to do with filter support.

Two ways others have found around this are to either prefix the UNC path with a file system provider so that SQLPS can parse it (source):

Get-ChildItem Microsoft.PowerShell.Core\FileSystem::\\pcslog1011\dtcs\ContractEmailNotes\ -Filter '*.txt'

Or switch back to the default working directory after the the SQLPS module loads. This is perhaps best done by explicitly loading the SQLPS provider at the beginning of your script and adding the Push/Pop-Location cmdlets before and after (no other changes required to the original script).

Push-Location
Import-Module SQLPS -DisableNameChecking
Pop-Location

Two final things to note. First, I've run my code against about 100 servers on different OS versions, patch levels and PowerShell versions. I've only seen this issue on some servers running PowerShell 5.1. Other 5.1 servers were fine.

Second, this whole affair can apparently be avoided by simply by using the newer SQLServer provider that is supposed to replace SQLPS.