Привет всем.

Суть вопроса в том, что при наличии в поле типа VARCHAR символа с нулевым кодом функция CHAR_LENGTH() возвращает полную длину с у четом символов после #0, а собственно значение поля возвращается обрезанным до первого нулевого символа.

Ниже приведен несложный сценарий для ISQL:

CREATE TABLE ITEMS (
ID INTEGER NOT NULL,
NAME VARCHAR(100) NOT NULL
);

ALTER TABLE ITEMS ADD CONSTRAINT PK_ITEMS PRIMARY KEY (ID);
ALTER TABLE ITEMS ADD CONSTRAINT UNQ_ITEMS UNIQUE (NAME);

INSERT INTO ITEMS( ID, NAME ) VALUES ( 1, 'Name #1' );
COMMIT;


SELECT '<' || NAME || '>', CHAR_LENGTH( NAME )
FROM ITEMS;
/* Здесь все правильно, символа #0 нет */
NAME CHAR_LENGTH
=============================================
<Name #1> 7


/* добавляем нулевой символ */
UPDATE ITEMS
SET NAME = NAME || ASCII_CHAR( 0 ) || '+++';

SELECT '<' || NAME || '>', CHAR_LENGTH( NAME )
FROM ITEMS;
/* Ошибка: CHAR_LENGTH() возвращает большее значение, нежели чем собственно возвращенное значение поля NAME
возвращенное значение поля NAME обрезано до первого нулевого символа */
NAME CHAR_LENGTH
=============================================
<Name #1 11


/* повторно добавляем нулевой символ */
UPDATE ITEMS
SET NAME = NAME || ASCII_CHAR( 0 ) || '+++';
SELECT '<' || NAME || '>', CHAR_LENGTH( NAME )
FROM ITEMS;
/* значение, возвращенное функцией CHAR_LENGTH(), увеличилось на 4
возвращенное значение поля NAME не изменилось (так же обрезано до первого нулевого символа ) */
NAME CHAR_LENGTH
=============================================
<Name #1 15


С уважением, Polesov.

Тестировалось на CHARACTER SET WIN1251

Но ведь функция CHAR_LENGTH() возвращает значение с учетом того, что находится за нулевым символом.

И при передаче параметра в UDF BY DESCRIPTOR значение поля dsc_length структуры, описывающей параметр, тоже содержит значение с учетом того, что находится за нулевым символом.

Все же, если значение поля выводится до первого попавшегося нулевого символа, то и результат функции CHAR_LENGTH() тоже должен учитывать наличие нуля, а не брать значение фактической длины хранящихся в БД данных.

С уважением, Polesov.

Вдогонку:

SELECT CHAR_LENGTH( '123' || ASCII_CHAR( 0 ) || '321' )
FROM RDB$DATABASE;

возвращает 7

Ну, тогда надо, чтобы в FB функция CHAR_LENGTH() тоже возвращала результат согласно лучшим традициям С

Dimitry Sibiryakov,

По крайней мере, при передаче в UDF параметра типа CSTRING BY DESCRIPTOR, значение dsc_length в структуре описания этого параметра содержит такое же значение, как и результат функции CHAR_LENGTH(), т.е. без учета нулевого символа.

Привет всем.

Ниже пояснения по старттопику.

Вводная:

Имеются внешние текстовые данные, которые по связке с неким критерием заносятся в базу через хранимую процедуру.
Соответственно, в связке с этим неким критерием возможны следующие ситуации:
- внешние данные отсутствуют: при этом в БД пишется NULL;
- внешние данные содержат пустую стоку: при этом в БД пишется пустая строка;
- внешние данные введены: при этом в БД пишется строка, обработанная некой UDF.

Объявление UDF:




Естественно, при наличии во входной строке нулевого символа происходила потеря данных.

Решение проблемы – реализация передачи входного параметра типом VARCHAR BY DESCRIPTOR:



Структура описания параметра:




Для типа VARCHAR dsc_address в первых 2-х байтах содержит такое же значение, как и результат функции CHAR_LENGTH(), т.е. реальную длину без учета нулевых символов. При этом надо, что бы входная строка передавалась именно типом VARCHAR (dsc_dtype = 3), что обеспечивается преобразованием


Кстати, при таком решении логику на равенство параметра пустому значению или на IS NULL можно перенести в саму UDF.

Данные для просмотра строк с нулевым символом можно вытаскивать через



С уважением, Polesov.