Имеем FB2.0.3, IBExpert от 08.10.2010
(аналогичное поведение на FB2.5 и последнем IBExpert)

Не спрашивайте зачем мне это надо, но создаем БД в UTF8
размер страницы 16к.

В ней создаем таблицу

CREATE TABLE TEST_ASCI (
ID INTEGER NOT NULL,
ASCI_1 VARCHAR(32760) CHARACTER SET ASCII,
ASCI_2 VARCHAR(8185) CHARACTER SET ASCII
);

И вот парадокс, длина поля ASCI_2 не может быть больше 8185,
иначе при заходе на закладку Data в IBExperte вылезает ошибка
block size exceeds implementation restriction.
Почему? Поля в ASCI, соответственно длина всей записи
(не учитывая служебные) 4+32760+8185=40949, это сильно
меньше ограничения в 64к.
Причем никакое поле больше впихнуть в эту таблицу нельзя.

Причем, если увеличить ASCI_2 до 8186 (на единицу),
то ошибка вылезает, а если увеличить ASCI_1 до
32761 (на единицу) то ошибки нет.

UTF8

А как быть, если мне нужно два поля в таблице по 30кб? BLOB не могу использовать ввиду низкой производительности. На базе в 1251 все работало и летало. Проба использовать BLOB показала жуткие тормоза.

>> Не использовать utf8 на клиенте.

Надо.

>>Значит ты неправильно его использовал.

Несколько сот записей за раз загружаются, 1,2,3 записи могут содержать один документ (картинка) - результат сразу пакуется и по tcp/ip отправляется на сервер. Т.е. экспорт.
BLOB всяко тестировался, т.к. очевидно, что он удобнее, но хранение построчно документа в base64 дает сильное преимущество по производительности при выгрузке да и вообще даже при отображении одной картинки.

Когда наконец не будет ограничений 32к и 64к??

> Я чую дот-нет провайдер...

:-)

Нет, FIBPlus 7.0.15, Delphi XE Prof.
Тормоза из-за массовости. Понятно, что загрузка 2-3 картинок из блоба не покажется юзеру утомительной, но если их 100...

Попробую не упоминать оба поля в одном запросе. Т.е. по два запроса на запись будет. Если результат покажет сравнимое с BLOB время, то видимо придется юзать BLOB.

А вот если б небыло ограничения в 32 и 64к, то таких проблем небыло бы. 21 век, 64-разрядные процы о ОС... а у нас 64к.. Ппц, так и сидим в 1980х. :-(

2 kdv

Сам болен ;-)

Нужна максимальная производительность и практика показывает, что хранение в варчарах самое быстрое с точки зрения извлечения! Потестируй сам.

> чтобы хранить мегабайтные картинки в варчаре? да ты болен :-)

Картинки как раз по 10-100кб примерно. На самою большую, которая пока была, уходило 2 записи с двума варчарами.

> Ох, что-то ты делаешь не так... При таком размере блоба не должно быть разницы.

Есть. Большинство картинок умещается в одну запись с двумя варчарами. Поэтому на извлечение одной картинки уходит одно обращение к серверу. При этом открыв pFIBQuery и слизав оттуда одну за другой картинки сильно быстрее. В один запрос все сразу. А как извлекается блоб? Фактически в два обращения к серверу! Т.е. на каждую заголовочную запись картинки еще идет обращение за содержимым блоба. Вот и разница.

Я не прав?

2 kdv

> какие то два несчастных tcp пакета в ЛОКАЛЬНОЙ системе замедляют работу прямо жуть?

Логика: Юзер жмет кнопку "Экспорт". Программа выводит modal-окно с индикатором, быстренько готовит пакет, ложит его на диск, закрывает окно с индикатором и запускает отдельный TThread, который и уже гонит в фоне данные через интернет. Если юзер будет ждать пока данные онлайн из базы через инет перекачаются на сервер, то он курить замучается.
Т.е. речь идет о том, чтобы быстро приготовить данные и запустить их отправку уже в фоне.

Короче, спасиба всем. Ваши мысли я понял. Сеня действительно попробую сделать просто одну таблицу с одним полем варчар 32к вместо блоба и попробую так, т.е. на картинку будет уходить по 2-4 записи в таблице. И тоже самое с использованием блоба. Время засеку, тут выложу. Посмотрим.

2 Dimitry Sibiryakov

Не прав в чем именно?

Если кто-то спросит почему нельзя готовить пакет в фоне, отвечаю, потому что логика такая, не должен юзер во время подготовки пакета ничего изменять, поэтому modal окно с индикатором. Программа не сетевая.

2 Dimitry Sibiryakov

Тогда чем объяснить, что блоб медленнее варчара? Реально медленнее - факт!