И хотя в доке (из 2009) написано что
InterBase now supports 16-bit UNICODE_BE and UNICODE_LE as server
character
sets.
These character sets cannot be used as client character sets.
Подключение с указанием этих кодовых страниц (к IB2009) проходит.
Вообщем, типа вот.
Подключение проходит. Но текст запроса выполнить не получается. Текст
запроса явно не может быть в кодовой странице UNICODE_BE/UNICODE_LE. Как
видно из ошибки эксперта - он не может найти таблицу. Значит весь запрос (в
ASCII символах) он понимает, а имя таблицы видать хочет в UNICODE_xx
формате. Вообщем, этой болезнью и FB страдает (для русских названий). Но тут
какой то драматический случай - вообще ничего не видит.
-----
Хорошо. Нельзя так нельзя. Подключился в рекомендуемом UTF8.
Размеры текстовых колонок он не учитывают кодовую страницу подключения. То
есть если у нас UCS2 символ превратится в 3-байтный UTF8, то запросто
получаем переполнение буфера. Классика жанра - надо подключаться с
использованием кодовой страницы хранения. А подключиться низя. Смотрим пункт
#1
-----
Далее. Из эксперта в WIN1251 записал в VARCHAR UNICODE_LE, UNICODE_BE
русские буквы.
Потом через IBProvider прочитал из в UTF8 - совпали
Попробовал прочитать из в NONE (тоже через IBProvider) - опять совпали. То
бишь конверторы провайдером выбираются правильные.
Це чудо.
Но толку нет, потому что буферы не перерасчитываются. А потому реально
работать не получится.
-----
Блобы.
Короче я их вставил. Но что, куда и в каком виде я вставил - сам не понял.
Но судя по увиденному - сервер (все так же) не перекодирует данные из
кодовой страницы подключения в кодовую страницу хранения. И наоборот тоже.
Но поскольку в UNICODE_LE/UNICODE_BE подключаться не получается - значит
блобы идут ф топку.
-----
Массивы пробовать не стал. Хотя я думаю это единственный тип который бы
заработал без проблем (через провайдер). Потому что я размеры буфером сам
вычисляю.
-----
Короче мой смелый вывод по поводу этих двух кодовых страниц - ГУАНО.
Коваленко Дмитрий.
www.ibprovider.com
