Проблемы с набором символов при использовании DB2 SYSPROC.ADMIN_CMD для импорта базы данных

Question

Я запускаю приложение Java, которое передает файлы, которые мне нужно импортировать, на сервер, на котором работает DB2. Затем приложение Java создает JDBC-соединение с базой данных и запускает:

 CALL SYSPROC.ADMIN_CMD('import from <filename> of del modified by decpt, coldel; messages on server inert into <view>')

Проблема, с которой я столкнулся, как-то связана с кодировкой базы данных пользователя, которого база данных использует для импорта файлов (используя хранимую процедуру admin_cmd). Эта проблема: «Umlaute», как и ä, ö, ü, испортил этот импорт. У меня была такая проблема в прошлом, и решение всегда заключалось в том, чтобы установить LC_CTYPE пользователя, импортирующего данные, в de_DE.iso88591

Что я уже исключил в качестве источника проблемы: - Передача файлов на сервер базы данных. (Умлаут все еще в порядке после этого) - Соединение JDBC (я просто вставил строку через команду sql вместо чтения из файла)

Дело в том, что я не знаю, какой пользователь DB2 использует для импорта файлов через ADMIN_CMD. И я также не верю, что это может быть как-то связано с настройками DB2, поскольку при любом другом способе вставки, загрузки ... данных в него все работает нормально.

И да, мне нужно использовать ADMIN_CMD. Инструмент командной строки DB2 - это кошмар производительности ..

Answer 1

Спасибо за ваш ответ.

Я наконец исправил проблему, добавив

MODIFIED BY CODEPAGE=1252 

в мою команду импорта JDBC - ADMIN_CMD.Кажется, это переопределяет любые настройки кодовой страницы, которые БД использовала ранее.Также кажется, что кодовая страница базы данных по умолчанию не имеет значения, так как она установлена ​​на 1252. Единственное, что я могу сейчас вспомнить из-за причины всего этого, может быть параметр linux, который DB2 использует при импорте через ADMIN_CMD.

Answer 2

Лучший подход (для здравомыслия):

1. Создать все базы данных как UTF-8
2. Убедитесь, что все локали операционной системы UTF-8
3. Избавьтесь от всех приложений, которые не обрабатывают свои данные как UTF-8
4. Убой каждого разработчика и поставщика, не соблюдающего UTF-8. Повторите и промойте до 100% завершено.

DB2 действительно пытается быть умным и преобразовывать ваши входные данные для вас (команда импорта в основном переносит ваши данные в предложения вставки - которые всегда обрабатываются таким образом). Ссылка, которую я дал, обрисует в общих чертах основной принцип и даст вам несколько команд, которые нужно попробовать. Также есть официальное объяснение подобному. В соответствии с этим вы можете попытаться установить переменную окружения db2codepage в соответствии с файлами данных с разделителями, и это должно помочь. Кроме того, экспорт формата IXF может работать лучше, поскольку в каждом файле есть информация, связанная с кодированием.