....и выкопаю стюардессу!

Как на интерпретацию CSTRING и особенно его "размера" в скобках влияют:
1) connection charset ?
2) database default charset ?

Я к тому, что вот тут - http://freeadhocudf.org/documentation_english/dok_eng_blob.html - у функций идут параметры CSTRING(32760) - причем и в UTF-8 версиях и в неюникодных, один чёрт.

А вот тут на FB 2.5.5 пытаются объявить CSTRING(32660) - и выпадают на implementation limit exceeded
https://stackoverflow.com/questions/49547235/firebird-errors-when-using-symmetricds

....и ещё раз выкопаю.

Посмотрел лангреф и девгайд IB6, лангрефы FB2.5 (Eng&Rus) - везде говорится, что предел размера CSTRING указан в байтах, а не в буквах. Про кодировку же самих букв не говорится вообще ни в одной доке...

Dimitry SibiryakovТак же как и у любого другого поля/параметра

здесь ты неявно отсылаешь "к любому другому" SQL-типу данных

но CSTRING - он если смотреть синтаксические диаграммы в доках вовсе не стандартный тип данных, а особый исключительный случай, а для него кодировки не прописаны

https://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-ddl-extfunc.html

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

--------

хотя смотрю я в ib_udf2.sql и вижу там DECLARE EXTERNAL FUNCTION strlen STRING(32767) CHARACTER SET NONE

то есть, можно, нло в документации пропустили

а вот для сравнения в ib_udf.sql кодировки нет - DECLARE EXTERNAL FUNCTION strlen СSTRING(32767) RETURNS ....

в fbudf.sql нету вообще CSTRING

kdv,

Чтобы выяснили как реально обстоят дела и чётко отразили в обеих документациях, ENG/RUS

> например по ФБ 2.5 - страница 34.

Открываю официальный сайт, https://www.firebirdsql.org/en/reference-manuals/
Открываю официальное руководство Firebird 2.5 Language Reference (Russian)
"6 сентября 2015 — v.0336-1 для Firebird 2.5.4", страница 34, "Подтипы BLOB" и "Особенности BLOB"

BLOB <> CSTRING

Делаю полнотекстовый поиск, твой кусок нахожу на страницах 29/30

Символьные типы данных
В СУБД Firebird для работы с символьными данными есть тип данных фиксированной
длины CHAR и строковый тип данных VARCHAR переменной длины.

{VAR}CHAR <> CSTRING

> Так что, если метаданные УЖЕ существуют
....и у эти метаданных есть чарсет - то да. А если нет? По документации у CSTRING никакого чарсета нет!

> Чарсет коннекта - определяет перекодирование или его отсутствие

А если у БД нет своего коннекта, например NONE ?
А если коннект используется для создания БД на сервере, а не к уже существующей БД.

Исходная ситуация: есть БД, она пересоздается и переливаются данные, в процессе этого вылезает превышение implementation limit, которого 1) на исходной БД нет; 2) не должно быть по докам; 3) не должно быть по прецеденту fbUDF (тот еще прецедентик, но какой есть, ПОСЛЕ облома с документацией).

Понимаешь, в тот момент когда сервер ведёт себя не по документации - под сомнение ставится всё. Причина ошибки ищется в любом возможном месте. Потому что, если ошибка возникает в "правильном" и очевидном месте - он решается не приходя в сознание и на форумы никто не лезет.

AriochА вот тут на FB 2.5.5 пытаются объявить CSTRING(32660) - и выпадают на implementation limit exceeded
https://stackoverflow.com/questions/49547235/firebird-errors-when-using-symmetricds

Подброшу. Попросил человека посмотреть кодировки старой и новой БД.

I executed this SELECT RDB$CHARACTER_SET_NAME FROM RDB$DATABASE,
the old DB return UNICODE_FSS,
and new DB return NONE

То есть каким-то странным образом (может ли это зависеть от диалекта, от ODS???) у него CSTRING(32660) срабатывало на многобайтовой (хотя и устаревшей) UNICODE_FSS, но не срабатывает на 1-байтовой NONE

Странно это....

Симонов ДенисУ меня тоже нет сведений как это работает.

я догадывался.

Вот именно поэтому я это и поместил не в ветку о документации, а в общем разделе, пускай гуру посмотрят потестируют и сами поймут

Симонов ДенисCSTRING(<size>) прямо отображается на AnsiChar[<size>] поэтому непосредственного чарсета у этого "типа" быть не может

Извините - но ANSIchar и ANSIstring как раз оооочень lf;имеют кодировку.
Это у юникода кодировки нет, есть только Transport Format.

А вот у ANSI есть Win1250, Win1252, oem850, oem866, KOI8-R, KOI8-U, KOI8-RU - на сайта Майкрософта несколько дестяков кодовых страниц, включая разные EBCDIC

HommerСимонов Денис,

спасибо.
the sub_type (represents the blob's subtype and for string types, it is the charset
plus the collation, encoded)

Один байт - чарсет, другой - collation.

Нуц а для блобов subtype имеет свое значение, там видимо надо добираться до

kdvHommerТолько входные данные не преобразуются к чарсету параметра.
гм, интересно. значит я был неправ.

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

Другой вопрос зачем при этом тип указывать? так и писали бы ,что такой-то параметр UDFки имеет тип "дескриптор"

Dimitry SibiryakovAriochне срабатывает на 1-байтовой NONE

NONE - не однобайтовая. Это вообще затычка для "передавай строки как есть, тупым массивом
байт".

Угу, а размер элемента "тупого массива байт" внезапно 1 байт, как я и сказал.

Откуда же implementation limit exceeded ?

Самый безумный вариант, они слишком давно commit не делали и на стопиццотом DDL сервер сломался, а то что при этом создавалас UDF - просто совпадение. Могло такое быть ?

Симонов Денис,

что именно "зачем" ?

функционал есть, унаследованных программ - много.
люди на грабли натыкаются, по факту.

AriochСамый безумный вариант, они слишком давно commit не делали и на стопиццотом DDL сервер сломался, а то что при этом создавалас UDF - просто совпадение. Могло такое быть ?

а вообще - нет, он же там на одной этой команде в IBExpert получает ту же ошибку....