Работа с System.DBNull в PowerShell

Question

Работа с System.DBNull в PowerShell

Тратить больше времени на извлечение данных SQL в PowerShell. Проблемы с [System.DBNull]::Value и как PowerShell ведет себя с этим во время сравнений.

Вот пример поведения, которое я вижу, наряду с обходными путями

#DBNull values don't evaluate like Null...
    if([System.DBNull]::Value){"I would not expect this to display"}
    # The text displays.
    if([string][System.DBNull]::Value){"This won't display, but is not intuitive"}
    # The text does not display.

#DBNull does not let you use certain comparison operators
    10 -gt [System.DBNull]::Value 
    # Could not compare "10" to "". Error: "Cannot convert value "" to type "System.Int32". Error: "Object cannot be cast from DBNull to other types.""

    [System.DBNull]::Value -gt 10
    # Cannot compare "" because it is not IComparable.

    #No real workaround.  Must use test for null workaround in conjunction to avoid comparison altogether:
    [string][System.DBNull]::Value -and [System.DBNull]::Value -gt 10

#Example scenario with a function that uses Invoke-Sqlcmd2 to pull data
    Get-XXXXServer | Where-Object{$_.VCNumCPUs -gt 8}
    #Error for every line where VCNumCPU has DBNull value

    #workaround
    Get-XXXXServer | Where-Object{[string]$_.VCNumCPUs -and $_.VCNumCPUs -gt 8}

Я что-то упускаю, или нет "простого" обходного пути, который позволил бы людям с небольшим опытом использовать сравнения PowerShell, как и ожидалось?

Я представил предложение по Connect и получил временный обходной путь от Dave Wyatt, который преобразует datarow в psobjects с dbnulls, преобразованными в нули, но это добавляет немного накладных расходов. Похоже, что-то, что должно быть обработано под прикрытием, учитывая существующее "свободное" поведение PowerShell?

Любые советы, или я исчерпал свои варианты на данный момент?

Спасибо!

25

sql powershell dbnull

Источник

user3067642 09 мар '14 в 17:01

6 ответов

Другие вопросы по тегам sql powershell dbnull

user2610398 03 апр '18 в 21:29 2018-04-03 21:29 · Answer 1 · 2018-04-03 21:29

Самый простой способ $var -isnot [DBNull],

Я проверил это в моих собственных сценариях, и это работает как ожидалось.

32

Источник

user2610398 03 апр '18 в 21:29

user1630171 09 мар '14 в 19:49 2014-03-09 19:49 · Answer 2 · 2014-03-09 19:49

Я думаю, что вы ошибаетесь подходом здесь. Как документально подтверждено, DBNull класс представляет несуществующее значение, поэтому сравнения, такие как -gt или же -lt не имеет никакого смысла. Значение, которое не существует, не является ни большим, ни меньшим, чем любое заданное значение. Value поле имеет Equals() метод, который позволяет вам проверить, является ли значение DBNull:

PS C:> ([DBNull]::Value).Equals(23)
False
PS C:> ([DBNull]::Value).Equals([DBNull]::Value)
True

user696808 30 мар '16 в 14:17 2016-03-30 14:17 · Answer 3 · 2016-03-30 14:17

Что я обычно делаю, так это:

[String]::IsNullOrWhiteSpace($Val.ToString())

Или это:

[String]::IsNullOrEmpty($Val.ToString())

Или это:

$Val.ToString() -eq [String]::Empty

Это часто работает просто отлично, так как [System.DBNull]::Value.ToString() возвращает пустую строку, так что оба [String]::IsNullOrWhiteSpace([System.DBNull]::Value) а также [System.DBNull]::Value.ToString() -eq [String]::Empty оценивать как истинное

Очевидно, что они не являются логически эквивалентными, поскольку ваши данные могут на законных основаниях иметь пустые строки или могут представлять собой тип данных, который не имеет смысла как пустая строка (например, целое число). Однако, поскольку вы часто хотите обрабатывать DBNull точно так же, как пустые строки и строки только для пробелов, это может быть полезно, если вы достаточно хорошо знаете свои данные.

Если вы действительно хотите узнать, является ли значение DBNull, конечно, тогда используйте [DBNull]::Value.Equals($Value),

user7723862 16 мар '17 в 21:20 2017-03-16 21:20 · Answer 4 · 2017-03-16 21:20

if( %youfunctetc%.GetType().Name -eq 'DBNull')
{}
else {}

1

Источник

user7723862 16 мар '17 в 21:20

user5553142 20 мар '18 в 10:12 2018-03-20 10:12 · Answer 5 · 2018-03-20 10:12

При работе с данными SQL в PS я включаю эту функцию и при необходимости вызываю:

function Check-IsNullWithSQLDBNullSupport ($var) {
    if ($var -eq [System.DBNull]::Value -or $var -eq $null) {
        return $true
    } else {
        return $false
    }
}

Можно использовать так:

if (Check-IsNullWithSQLDBNullSupport -var $VarToBeTested) {
    write-output "Is Null"
}

0

Источник

user5553142 20 мар '18 в 10:12

user4749264 23 ноя '19 в 18:09 2019-11-23 18:09 · Answer 6 · 2019-11-23 18:09

Кажется, я комментирую только старые сообщения, но я думаю, что ссылка на обсуждение с Дэйвом Вяттом выше не работает, я нашел ее здесь, перепроверив Google.

Код, над которым я сейчас работаю, не зависит от производительности, но мне нужно сравнить возвращаемые данные, чтобы сбросить свойства другого целевого объекта с другим типом.

Обычно удобный PowerShell вроде:

If( $SrcObject.Property ) { $TargObject.Property = $SrcObject.Property }

Это не работает с [DBNull]

Обычно я бы потратил время на то, чтобы посмотреть /dev, а затем использовать самый быстрый код, независимо от необходимости или сложности, но я должен получить rev1 как можно скорее. Прежде чем я даже осознал проблему [DBNull], я переворачивал объекты в [PSCustomObject], используя простой| Select $Props

$Props - это типизированный массив имен столбцов. Но это не меняет тип подсвойства, поэтому сравнение все равно не удается!

Учитывая, что я уже шел по пути, который предлагал Дэйв, я пошел еще немного.

$Props = ( $SQLData.Tables[0].Rows[0] | Get-Member -MemberType Properties ).Name
$Rows  = $SQLData.Tables[0].Rows | Select $Props

ForEach( $RowObject in $Rows )
{
    ForEach($Prop in $Props )
    {
        # Maybe: [String]::Empty below?
        If( $RowObject.$Prop -is [DBNull] ) { $RowObject.$Prop = "" }
    } #End Inner Loop.
} #End Outer Loop.

Примечание: это немного псевдо, потому что код продукта содержит строки в словаре, но этого должно быть достаточно, чтобы передать подход. Кроме того, приведенное выше не полностью протестировано, поскольку оно было переведено из рабочего кода.

Я не знаю, почему Get-Member не возвращает другие свойства, такие как RowError, RowState и т.д., но это работает, если вы не возражаете против преобразования [DBNull] в пустые строки. Кроме того, Get-Member стал более универсальным, без ввода реквизита...

Очевидно, что это не сильно отличается от некоторых приведенных выше приведений, но я, вероятно, не единственный, кто хочет припарковать некоторую сложность во вспомогательных функциях, поэтому "main" выглядит немного чище. Более того, пустая строка должна удовлетворять большинству сравнений позже, особенно с учетом того, что преобразование типов происходит в фоновом режиме.

Я знаю, что это комментарий, а не вопрос, но если у меня что-то не так, дайте мне знать. Я наткнулся на это, работая над активным проектом. Благодарность!

user10423776 27 сен '18 в 11:00 2018-09-27 11:00 · Answer 7 · 2018-09-27 11:00

Некоторая команда | где FieldOfInterest - это DBNull Кажется, у меня работает. DBNull является типом, и оператор -is проверяет, имеет ли значение слева заданный тип.

Вы также можете использовать противоположную команду some | где FieldOfInterest - не DBNull

0

Источник

user10423776 27 сен '18 в 11:00