Хочу на реальных данных проверить насколько просядет производительность и где.
Есть чем конвертнуть?

Вано СусанидзеNickDeeЕсть чем конвертнуть? гугл был жесток в своём бане ? ;-)
Цитата из http://www.ibase.ru/unicode_faq.html :
ibase.ruКак мне сконвертировать базу WIN1251 в UTF8?

Это можно сделать только копированием данных из одной базы в другую:
создать новую базу в UTF8
извлечь скрипт метаданных, убрать оттуда все упоминания WIN1251 (помните - у вас могут быть проблемы с отсуствием используемых сортировок в UTF8), и применить этот скрипт на базе в UTF8
перенести все данные каким-нибудь инструментом, вроде IBPump. Такому инструменту не надо уметь поддерживать юникод, т.к. при записи данных в чарсете коннекта win1251 сервер сам преобразует их в UTF8.
dbcDataPump не справился.
IBPump справился

Чтобы кому-то просто проверить как его система будет работать с UTF8-базой, ему (если пользоваться советом c ibase.ru), придётся научиться пользоваться например IBPump, научиться извлекать метаданные (например через IBExpert)
Очень "user-friendly" :)
Но зато я узнал, что UDF с параметром VARCHAR(32762) не допустим в UTF8, а то была у меня UDF с таким параметром...
Это тоже было "user-friendly" :) Грабли грамотно так разложены :)

hvladNickDeeНо зато я узнал, что UDF с параметром VARCHAR(32762) не допустим в UTF8, а то была у меня UDF с таким параметром...Такие параметры вообще не должны использоваться без крайней необходимости
Этого же нет в документации :) Типа я сам должен был догадаться почему и от чего? :)
Ладно я раньше наступил на эти грабли, увидел что медленно, и исправился (сделал отдельную функцию для строк < VARCHAR(256)), и потом получил от тебя объяснение 10592614 .


В release notes к тройке упомянуто "Stored procedures, triggers and functions written in Java, C++, ObjectPascal, etc".
При передаче в такую функцию параметра VARCHAR(8000), там тоже будeт происходить аллокация от ОС на 8000 символ-байт (пусть будет символ-байт :)), как и в UDF? Или там другой механизм?

Блин... я только сейчас осознал всю глубину... это ведь перед каждым вызовом для каждого параметра идёт аллокация, затем копирование... Нет чтоб просто передать указатель на строку и увеличить её reference-count :) Но это в текущей реализации (с ограниченной длиной строк) не реально.
Если бы был просто VARCHAR - там понятно: есть данные строки, есть её длина, есть счётчик ссылок и чарсет. И тогда не нужно постояно делать алокейт-деалокейт. В Delphi это работает как часы.
С новым API имхо можно сделать так же (по крайней мере удобным для api-юзера способом, и без лишних алокаций памяти). Всё хранить во внутренней структуре IFbString (FieldLengthInBytes, RefCount, CharSet: Integer; Data: Pointer), и дать наружу функции:


Это можно сделать доступным в "Stored procedures, triggers and functions written in Java, C++, ObjectPascal, etc", так и при отдаче строковых значений клиенту (т.е. fbclient получил сетевой пакет, при доставании записи аллоцировал блок памяти равный суммарному размеру стрингов в этой записи, создал IFbString по количеству полей, и отдал их в вызывающую сторону. А вызывающая сторона уже может с ними делать что хочет (но должна не забыть позвать ReleaseFBString для каждой такой строки, когда закончит)).
Как-то так видится :)