Увидел, ща проверю с юзингом

3 прежде чем тестить джобы проверь команду без джоба

не помню справку по gci позволяет ли он в include подавать массив

А у него разве не должно при просмотре этого джоба полотно с ошибками вываливаться?

как повезет
может erroraction все давить

Да работает, спасибо.

А ошибкам там особо браться неоткуда.
Только если нет доступа на чтение, но это еррорекшеном давится

супер 👍

Все-таки нашел время посмотреть. Соглашусь, что, скорее всего, баг в dll, но к ее обновлению есть вопросы, потому что

The types in System.Data.OracleClient are deprecated. The types remain supported in the current version of.NET Framework but will be removed in a future release. Microsoft recommends that you use a third-party Oracle provider.
https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/oracle-and-adonet

Я бы использовал ODP.NET
https://docs.oracle.com/en/database/oracle/oracle-database/19/odpnt/index.html

И код почти такой же получается, только рабочий:

test.ps1:

$asm = [System.Reflection.Assembly]::LoadFile('C:\Services\Oracle\Client_19\ODP.NET\bin\4\Oracle.DataAccess.dll')

$connectionString = 'Data Source=db01:1521/pdb1;User Id=PDBADMIN;Password=pdb1PASS;'
$inputString = 'foo'

$oracleConnection = New-Object Oracle.DataAccess.Client.OracleConnection($connectionString)

$cmd = New-Object Oracle.DataAccess.Client.OracleCommand
$cmd.Connection = $oracleConnection
$cmd.CommandText = 'isFoo'
$cmd.CommandType = [System.Data.CommandType]::StoredProcedure

$cmd.Parameters.Add('inputString', [Oracle.DataAccess.Client.OracleDbType]::Varchar2)
$cmd.Parameters['inputString'].Direction = [System.Data.ParameterDirection]::Input
$cmd.Parameters['inputString'].Value = $inputString

$cmd.Parameters.Add("outString", [Oracle.DataAccess.Client.OracleDbType]::Varchar2)
$cmd.Parameters["outString"].Direction = [System.Data.ParameterDirection]::Output
$cmd.Parameters["outString"].Size = $inputString.Length

$oracleConnection.Open()
$cmd.ExecuteNonQuery()
$oracleConnection.Close()

$result = $cmd.Parameters["outString"].Value
Write-Host "result of isFoo($inputString) is $result" -ForegroundColor Yellow

cmd:
powershell -File test.ps1
result of isFoo(foo) is foo

Всем привет, подскажите, есть ли лучшая практика по работе с функциями внутри функций?
Пример - есть функция, которая зарегистрирована в модуле как командлет, внутри неё есть функция, которая выполняет основную работу и должна бы называться так же, но в итоге название получается корявым. Аналогичная история с параметрами в этой коряво названной функцией, они совпадают по смыслу с параметрами и переменными из внешней, но для отличия им добавлены суффиксы типа _fncIndx1. Суффиксы были сделаны, чтобы при поиске можно было отличать переменную из функции от внешней. У меня складывается ощущение, что здесь изначально что-то неправильно, хотелось бы понять, как избегать подобного

дотсоурс?

А в рамках одного файла?

тогда скриптблок внутри использовать вместо функции

Функция внутри функции уже намекает, что подход так себе.

Функция и есть именной скриптблок

согласен, но я хез чё ещё придумать)

пример бы

Просто сделать экспорт из модуля, только нужной функции, а вложенную вынести. Тогда вспомогательная функция будет доступна только в контексте модуля.

ок, допустим есть просто скрипт и в нем функции, соответственно, в них передаются +- те же параметры, которые были переданы в скрипт, соответственно, делая поиск по переменной, мы будем находить все вхождения, в основном теле скрипта и в функциях

в модуле, видимо, так и буду делать, спасибо