2015-05-28 3 views
1

Я использую Perl DBD :: ODBC для подключения к базе данных Informix, к которой я ранее был слеп к схеме. Я успешно открыл схему с помощью запросов таблиц tabname и colname. Теперь я повторяю каждую из этих таблиц, извлекая все в них для загрузки в другую модель. То, что я нахожу, это то, что нулевые столбцы выходят из запроса select. Например. если таблица выглядит следующим образом, с необязательно нулевым lastseen колонке (любого типа данных):Выбор всех строк из таблицы Informix, содержащей несколько нулевых столбцов

ID username lastseen 
-- -------- -------- 
1  joe   1234567890 
2  bob   1098765432 
3  mary   
4  jane  1246803579 

затем select * from mytable (или с указанием всех имен столбцов indiidually) останавливается на мэри подряд.

у меня эту работу с помощью NVL следующим образом:

select nvl(id, ''), nvl(username, ''), nvl(lastseen, '') from mytable 

И это хорошо, но мой вопрос: есть ли более простой синтаксис Informix, чтобы обнуляет прийти в мой результирующий набор , что-то простое, как NULLS OK или что-то, что мне не хватает? В качестве альтернативы, может использоваться некоторая опция дескриптора базы данных?

Вот пример моего Perl с NVL() взломать, в случае, если оно соответствует:

my %tables = (
    users => [ 
     qw(id username lastseen) 
    ] 
); 

foreach my $tbl (sort keys %tables) { 
    my $sql = 'select ' . join(',', map { "nvl($_, '')" } @{$tables{$tbl}}) . " from $tbl"; 
    # sql like: select nvl(a, ''), nvl(b, ''), ... 
    my $sth = $dbh->prepare($sql); 
    $sth->execute; 
    while(defined(my $row = $sth->fetchrow_arrayref)) { 
     # do ETL stuff with $row 
    } 
} 
+1

Это действительно не обязательно. Конечно, DBD :: Informix правильно обрабатывает значения NULL - есть ли веская причина, по которой вы не можете использовать этот драйвер, а не ODBC? – RET

+0

Полу-хорошее, просто я в очень большой и параноидальной корпоративной среде, и на самом деле это огромная боль, чтобы установить новые модули, возможно, не стоит усилий для этого ограниченного приложения, так как у меня есть обходной путь. У нас есть другие решения, аналогично использующие ODBC для абстрагирования слоя базы данных, поэтому я, конечно же, буду заинтересован в изучении его ограничений и причуд, если это действительно виновник (и я очень хочу поверить, что это так). – swornabsent

ответ

0

После неудачной попытки установить DBD :: Informix я вернулся к этому и обнаружил, что по какой-то причине включение LongTruncOk в дескрипторе базы данных позволило выбрать все строки, включая те, которые имеют нулевые столбцы. Я не думаю, что это корень проблемы, но она сработала.

Однако это решение, похоже, столкнулось с несвязанной настройкой локалей для поддержки символов, отличных от ascii. Я добавил DB_LOCALE=en_us.utf8 и CLIENT_LOCALE=en_us.utf8 в мою строку подключения, чтобы предотвратить выбор из аналогичного разбиения при встрече с символами без ascii (т. Е. В наборе результатов 500, где 300-я строка имела символ не-ascii, возвращающие 200 строк не возвращались) , С локалями, установленными таким образом, а также LongTruncOk, включенными на dbh, возвращаются все строки (без перехвата NVL), но у нулевых столбцов есть байты, добавленные к ним из предыдущих строк, а не в какой-либо схеме, которая очевидна для меня. Когда я покидаю настройки локали от строки подключения и устанавливаю LongTruncOk, строки с нулевыми столбцами выбираются правильно, но строки с символами utf ломаются.

Так что, если у вас нет проблемы с кодировкой, возможно, только LongTruncOk будет работать на вас. Для моих целей мне пришлось продолжить использование обходного пути NVL для нулей и указать локали для символов.

-1

Check this - раздел NULL в Perl. Похоже, что с этим драйвером нет простого способа справиться с этой проблемой.

Смежные вопросы