Продолжаю серию головоломок.
Сегодня порешал.

Дано : Informix 11.50, база в Unicode UTF8, старая процедура, в которой есть код




Процедуре 100 лет в обед, и вдруг она начала возвращать Error 202 для одной резервации res_id = 10000

SELECT для этого res_id возвращает:
l_company COMPANYABC
ldr_lname Atzmüller
modseccode A

Традиционный российский вопрос - кто виноват и что делать ? :)





В таком вот аксепте

АнатоЛойВыбегалло, так не прикольно :).
Понятно, что информации в задаче выдано скорее всего достаточно для решения, но это сужает область поиска. Можно было бы привести ещё типы полей.

Уточнения:
1) ошибка возникает в строке присваивания?


Да

АнатоЛой2) какая точно версия 11.50?

11.50.FC7W3

АнатоЛой3) какой тип данных у l_confname?

CHAR(25)


АнатоЛойВарианты:

1) ошибка в файле локали с немецкой у-умляут (секция CTYPE).


Нет

АнатоЛойЕсли процедуре сто лет в обед, для оценки вероятности нужно понимать, когда поменяли версию сервера, версию клиента или насколько оригинальные данные имеем в сбойном случае.

Данные оригинальные. Года 2 назад базу перекодировали в Unicode UTF8, но это в данном случае неважно

АнатоЛой2) невидимые символы в возвращаемых данных.

Close but no cigar :) Возвращаемые данные не имеют невидимых символов, но....

АнатоЛой3) ограничение по длине строки в l_confname.

Это в любом случае не даст Error 202

АнатоЛой4) баг сервера...

Nope. Совершенно штатное поведение, если подумать :)

АнатоЛойВыбегалло, и вдогонку: какой смысл на UTF использовать выражения с подстроками?
Логичнее было бы использовать SUBSTR/SUBSTRING :).
Заодно и ошибка может уйти :).

Та-дам ! Вторая часть российского вопроса, "что делать" - успешно решена!

Да, после замены скобок на SUBSTR проблема уходит.

Так "кто виноват" и конкретно чем ?

Relic Hunter


или "l_company" оказалось короче 4-х букав, или "l_ldr_lname" меньше 5-и. :O)

Я же ж указал, что SELECT возвращает :

l_company = "COMPANYABC"
ldr_lname = "Atzmüller"
modseccode = "A"

И чиста напомнить :
finderr 202
-202 An illegal character has been found in the statement.

A character that cannot be interpreted as part of an SQL statement is
embedded in this statement. If a program constructed the statement, the
character might be a nonprinting control character. Make sure the
statement contains only printable ASCII characters, and reexecute it.

Relic HunterВыбегалло,

Сори, проглядел вывод sql-ля.
Новая версия. Проблема в UTF8, а именно в том, что она "variable-width encoding". Вот на этом "ü" оно и споткнулось. Видимо брикеты не правильно байты обрезают. Хотя доказать не могу.

Игзектли ! :)

Эта самая "ü" в UTF8 состоит из 2х байтов :

c3 bc , "LATIN SMALL LETTER U WITH DIAERESIS"

И при обрезании первого байта, с добавлением следущего символа, получается недопустимая для UTF8 комбинация. На которой исполнитель SP - кода затыкается.

Фишка именно в том, что умляут попала в 5ю позицию имени и была квадратными скобками порезана попалам :)

АнатоЛойВыбегалло, я не зря интересовался типами данных. Если это не TEXT, сервак на операциях обрезания, исходя из документации , по идее должен был заменить "байтовые остатки" символов в каждой операции вырезания в однобайтовые пробелы. Т.е. склейка должна была представлять собой "COMP Atzm A"...

IBM Informix GLS Guide, Avoidance in a multibyte code setIf your database locale supports a multibyte code set and you specify a particular column substring in a query , the database server replaces any truncated multibyte characters with single-byte white space characters.

...

IBM Informix database servers replace partial characters (to single-byte white space characters - примечание редактора :) in each individual substring operation, even when they are concatenated.

...

Правда в доке ссылки всё больше на операциях в SQL-запросах, по почему исполнитель SP-кода должен вести себя по другому - непонятно.
Выбегалло, ради интереса проверь, как будет вести себя запрос на этих данных. Ну типа:



Просто SELECT таки выдает пробел вместо умляута. Ошибка возникает если строка клеится внутри процедуры.

АнатоЛойВыбегаллопропущено...


Nope. Совершенно штатное поведение, если подумать :)
Штатное - соответствующее документации.
Как должны выполняться данные операции с partial characters в SPL - не сказано. Твоё LET-выражение в ХП содержит printable символы.
То что он в процессе выполнения в преобразованном им коде получает non printable - особенности реализации - а не штатное поведение.

Если допущение, что SQL-исполнитель и SP-исполнитель должны вести себя одинаково по отношению к одинаковым операциям логично, по вышеприведённым ссылкам на документацию это:
либо бага сервака - работает не соответственно доке;
либо бага доки - описывает не так, как собирались реализовывать/реализовали.

Это глубокий философский вопрос - является ли данное поведение сервера багом или фичей :)

Блин,

сегодня опять на том же месте навернулся :) И, главное, забыл, что год назад сам ее порешал - только гугл и вывел на этот топик :)

В третий раз закинул он невод...

Короче, оказывается такая полезная функция перевода кода символа в сам символ chr отказывается работать с UTF8 базами.

Банальное select chr(250) from systables where tabid = 100 выдает код ошибки 202.
А
select "ü" from systables where tabid = 100 отрабатывает нормально.

Пришлось написать самому функцию


create function chr_utf (p_in smallint) returning varchar(3);
define l_str varchar(255);

LET l_str = " ¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ";
if p_in < 128 then
return chr(p_in);
elif p_in < 162 then
return " ";
else
return substr(l_str, p_in - 160, 1);
end if
end function;