Вывод версии SQLCMD различен для разных версий RHEL для Informix - PullRequest
0 голосов
/ 27 апреля 2018

Мы используем "sqlcmd" для работы с Informix DB. Наши сценарии использовали команду «info columns for» для извлечения столбцов и подготовки / выполнения запросов.

Однако, переходя на RHEL7, последняя версия SQLCMD идет с другим шаблоном вывода.

Eg: RHEL6
$ echo "info columns for <table>" | dbaccess 2>&1 | head
1|<column 1>|258|4|0
2|<column 2>|7|4|0
3|<column 3>|0|2|0
... etc

RHEL7
$ echo "info columns for <table>" | dbaccess 2>&1 | head
colno              1
colname            <column 1>
coltype            258
collength          4
extended_id        0

colno              2
colname            <column 2>
coltype            7
collength          4

Версии следующие:

RHEL 6
$ dbaccess -V
dbaccess: SQLCMD Version 87.00 (2010-10-21)
IBM Informix CSDK Version 3.50, IBM Informix-ESQL Version 3.50.FC7
GNU Readline 6.0
(C) Copyright Jonathan Leffler 1987-2010
Licenced under GNU General Public Licence Version 2

RHEL 7
$ dbaccess -V
dbaccess: SQLCMD Version 90.02 (2016-07-28)
IBM Informix CSDK Version 4.10, IBM Informix-ESQL Version 4.10.FC2DE
GNU Readline 6.2
(C) Copyright Jonathan Leffler 1987-2016
Licenced under GNU General Public Licence Version 2

Есть ли у нас решение для обеспечения обратной совместимости с sqlcmd? Это какой-то флаг, управляемый? Мы должны поддерживать RHEL6 и RHEL7.

1 Ответ

0 голосов
/ 27 апреля 2018

Я только слегка пристрастен - я написал SQLCMD (1) .

Вывод, отображаемый в версии 90.02, отражает добавление формата вывода в режиме «блок» для лучшей эмуляции DB-Access, и этот формат теперь включен по умолчанию при использовании sqlcmd через имя dbaccess.

Так что, да, есть изменение в поведении. SQLCMD 90.02 теперь эмулирует DB-Access более тесно, чем 87.00.

Эта проблема также не имеет прямого отношения к RHEL 6 против RHEL 7; вместо этого он связан с версией SQLCMD.

Я не уверен, что есть простой способ вернуться к старому поведению. Использование dbaccess -F select stores - не отменяет значение по умолчанию в современной версии; запуск format select; в качестве команды. Это легкая неприятность, но не совсем удивительно. Я хотел бы установить режим форматирования, подразумеваемый именем dbaccess, перед остальной обработкой аргументов командной строки, чтобы параметр командной строки переопределял подразумеваемый формат. Запуск SQLCMD через dbaccess -C переводит его обратно в режим sqlcmd, но это означает, что он не интерпретирует аргументы имени базы данных и имени файла, как это делает DB-Access. (Например, в режиме dbaccess добавляется расширение .sql к имени файла, если вы не добавляете его в первую очередь, как это делает DB-Access; sqlcmd этого не делает.)

«Лучшим» решением будет изменение сценариев для непосредственного использования SQLCMD. Однако это подразумевает изменение не только имени команды; вам нужно будет добавить -d перед именем базы данных и добавить .sql суффиксы к именам файлов.

Можно изменить SQLCMD, добавив переменную окружения, такую ​​как SQLCMD_FORMAT, которая вступает в силу, если не переопределена явно в командной строке. Установка этого значения на select восстановит старый формат вывода. Другой возможностью может быть добавление поддержки для файла .sqlcmdrc, содержащего команды, которые будут выполняться при запуске. Я не уверен, что хочу добавить это.

Я предлагаю связаться со мной по электронной почте (см. Документацию SQLCMD или мой профиль SO), чтобы обсудить, что происходит здесь - пожалуйста, включите SQLCMD в строку темы.

Кстати, как краткосрочный обходной путь, ничто не мешает вам использовать SQLCMD 87.00 на RHEL 7. Или, скорее, вы обнаружите, что вам нужно отредактировать jlss.h, чтобы удалить или обновить объявление memmem() - это было в коде 87.00, потому что в то время я не знал, что функция была доступна на некоторых платформах - она ​​не является частью ни C11, ни POSIX 2017 года. Удалите const из возвращаемого типа. Я получаю некоторые другие предупреждения компиляции, когда я компилирую 87.00 на macOS 10.13.4 (High Sierra) с GCC 7.3.0, но они не являются вредными (какими бы нежелательными они ни были). Но код от 2010 года не обязательно компилируется так же чисто на более современных системах.


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

...