zholnerovich,

логически он и дне должен "сразу". как вы это себе представляете? чем char/varchar от blob отличается, знаете?

zholnerovich,

почти так. Ну а вы предлагаете блобы прямо в запись запихивать? 1-10-100 мб, или гиг? Блобы относятся ко "вторичной" информации. И не потому что так хранятся. А потому, что по сути они представляют собой хранилище для вторичных данных - картинок, документов, видео, музыки, сканов, и проч. Вся эта лабуда в записи при выборке не нужна.
Клиентские компоненты - да, могут вам прямо в грид вытаскивать тонны этих блобов, специально чтобы у вас сетевой трафик был повыше, и чтобы ваше приложение потребляло побольше памяти :-) Ну, чтобы тормозило, по серьезному.

zholnerovich,

если блоб влезает на страницу данных - он хранится на этой странице. не влезает - хранится на отдельной (или отдельных) страницах.

я никак не пойму, вы чего хотите? Осчастливить пользователей Firebird запихиванием блобов в запись?

zholnerovich просто интересуюсь, так ли это на самом деле и не будет ли каких изменений с этим в ФБ3
да, чтобы вытащить блоб из записи надо сделать вызов api. компоненты это делают для вас относительно прозрачно.
Возникает вопрос, чем это вас не устраивает, что вы захотели изменений. В ФБ 3 с блобами все так же.
Или вы считаете, что у разработчиков Фб возникла идея хранить мегабайты блобов прямо в записях, чтобы не надо было делать "вызов API"? я вот как-то логики в вашем вопросе не улавливаю.

Это типа как спросить - "Firebird выдает данные из БД только в ответ на SQL-запрос. Будет-ли это изменено в ФБ3"?

zholnerovichрассматривается вариант вытягивать данные из блоба по мере надобности в процессе работы программы, но это дополнительные запросы к БД, что тоже не есть хорошо.
блоб всегда вытягивается отдельными запросами к api. Если блоб вытягивать отдельным sql-запросом, получится в 3 приема, а не в 2. Но по сравнению с размером блоба, скорее всего эта разница ни о чем.
Ваши компоненты либо вытягивают блоб сразу, либо потом, когда вы сами к нему обращаетесь.
Так что "не есть хорошо" у вас что сразу, что потом. Потом - лучше, чем сразу. Потому что сразу нельзя понять, что нужно. А вот потом - очень даже можно выбрать только то, что нужно.

zholnerovichИ что в этом плане предвидится в FB 3 так как планируется переход
уже ведь сказали: в этом плане - ничего. Вы-то что хотите предвидеть, я не пойму? Какие-то полунамеки, мутные вопросы.
Можно было ведь сразу написать
- какие компоненты используются?
- сколько записей в этой "таблице с данными" считывается при старте программы?
- какого размера блобы хранятся в этой таблице
- когда этой программе нужны эти блобы, и в каком количестве - все сразу, конкретный блоб, или?

тут даже если вы сами на эти вопросы ответите, то вам станет ясно, что делать.