Блог

Главная - Вопросы по программированию - Определяемая пользователем Java-функция SQL (недопустимое преобразование символов между CCSID 65535 и CCSID 1200)

Определяемая пользователем Java-функция SQL (недопустимое преобразование символов между CCSID 65535 и CCSID 1200)

#sql #ibm-midrange

#sql #ibm-midrange

Вопрос:

У меня возникла проблема с функцией iSeries, из-за которой она неправильно преобразует данные, потому что мой профиль пользователя по умолчанию использует CCSID 65535. Я могу изменить задание на CCSID 37, и все работает нормально.

Мне нужно решение, при котором пользователю не нужно изменять свои рабочие свойства.

Функция запускает java-приложение и выглядит следующим образом

 CREATE FUNCTION mylib/re_Test2(input VARCHAR(500) CCSID 37,
                              regex VARCHAR(500) CCSID 37)
RETURNS INTEGER
EXTERNAL NAME 'UDFs.re_Test'
LANGUAGE Java
PARAMETER STYLE Java
FENCED
NO SQL
RETURNS NULL ON NULL INPUT
SCRATCHPAD
DETERMINISTIC

Я попробовал это без использования CCSID 37 изначально, но нашел несколько сообщений, предполагающих, что добавление этого приведет к преобразованию любых параметров в US English. Похоже, у меня это не работает.

Есть предложения?

Я попытался запустить из STRSQL и скрипта RPGLE, но оба не работают, однако из SQLSquirrel (SQL-программа с открытым исходным кодом, использующая ODBC) она работает.

Ответ №1:

CCSID 65535 означает «нет перевода символов» … поэтому, если ваша таблица создана с определенным CCSID, я бы предложил запустить приложение с этим CCSID.

Комментарии:

1. В настоящее время я использую строковые литералы для тестирования, например, select re_test('a','a') from sysibm/sysdummy1 это не работает. CCSID sysdummy1 равен 37

2. Если ваш CCSID задания равен 65535, то это ожидается … вы говорите системе НЕ выполнять перевод символов.

3. CCSID 65535 предназначен для неперевода; по сути, он определяется как «двоичный» (и я не могу понять, почему он так часто используется). Все, что используется в качестве CCSID получателя (например, 37), будет работать нормально , если это точно такой же CCSID, который использовался для ввода данных в первую очередь. В противном случае в преобразованных данных будут ошибки, которые не будут обнаружены, кроме как при визуальном осмотре. Программное обеспечение не выдает ошибок (за исключением случаев, когда CCSID недопустим для преобразования).

Ответ №2:

У меня была та же проблема. Я обнаружил, что это не касается параметров функции (у меня были целые числа).

Вопрос в том, как вы вызываете функцию. Например, в моем случае ее вызов с помощью System i Navigator работал, но не с программой RPG (которая, вероятно, использует пользовательский CCSID, то есть 65535).

Для последнего я решил CHGJOB CCSID(37) (37 для «COM EUROPE EBCDIC», любой может выбрать правильную кодовую страницу), а затем снова CHGJOB CCSID(65535) ввести.

Другой аналогичный способ CHGUSRPRF USRPRF(MYUSER) CCSID(37) . Не нашел ничего лучшего…

Ответ №3:

Приведенный выше выбор тоже работает нормально, за исключением того, что если вы попытаетесь ввести переменную :INTO host в RPG, это приведет к ошибке. Решение состоит в том, чтобы выполнить chgjob с CCSID до 37, затем запустить встроенный SQL, а затем изменить CCSID задания обратно на 65535. Тогда все работает нормально. Если вам нужна дополнительная информация или образцы, отправьте мне электронное письмо по адресу William.Ramos@mohawkind.com для получения дополнительной информации. Я столкнулся с этой проблемой, используя функции КОДИРОВАНИЯ / декодирования в мире RPG. Спасибо.

Ответ №4:

используйте простое приведение, где CSSID 37 = CSSID 65535 ,

Пример: 

 select cast( campo1 as varchar(500) CCSID 37 ) from biblioteca.tabla

db2 необычно

Ответ №5:

Решение состоит в том, чтобы сделать CHGUSRPRF CCSID равным 37, затем запустить встроенный SQL, а затем изменить CCSID задания обратно на 65535. Тогда все работает нормально.