Меня терзают смутные сомнения…
Привет всем.
В Firebird 2.0 был исправлен алгоритм вычисления размера буфера (XSQLVAR::sqllen) текстовых колонок (CHAR/VARCHAR) — он начал учитывать кодовую страницу подключения. Спасибо Adriano dos Santos Fernandes.
Здесь были чертыхания по поводу кодовой страницы блоба и XSQLVAR::sqlscale
До этого (а в InterBase до сих пор), размер буфера под значение вычислялся как количество символов в столбце умноженное на максимальное количество байт в одном символе кодовой страницы столбца.
Проблема, к примеру, проявляется при попытках прочитать столбца с кодовой страницей WIN1251 в подключении с кодовой страницей UTF8. Вылазит ошибка «Arithmetic exception, numeric overflow, or string truncation».
Я как-то пробовал подсовывать серверу правильно вычисленное значение буфера в XSQLVAR::sqllen, но он там внутри у себя все равно использовал буфер с неправильным размером.
Но недавно появилась мысль — а если попробовать работать не с XSQLDA, а непосредственно с MSG-буфером, где появляется возможность использования таких волшебных типов BLR-типов данных как varying2 и text2, для которых можно указать кодовую страницу?
Если сервер сможет вернуть клиенту текстовые данные без приведения к кодовой странице подключения, то это автоматически решит обозначенную проблему с переполнением буфера. Привести текстовые данные к кодовой странице подключения я могу и сам.
Во какая мысль.
Пожалуй, я её попробую покопать поглубже сразу после того как допилю новый код для работы массивами.
UPD1.
Мысль, наверное, не совсем правильная. Нужно сначала попробовать varying2/text2 с указанием кодовой страницы подключения и правильного размера буфера под данные. Может прокатит.