> I'm I correct assuming only the first 80 byte segment from say
> "COMMENT" BLOB SUB_TYPE TEXT SEGMENT SIZE 80
> since it can be read in one transfer along with the rest
> of the row ?

The only part of a blob read with the normal row is the blob-id (the
10byte identifier which tells IB where to get the blob contents).

> The remaining segments require a looped transfer mechanism ?

AFAIK IBO does an "all or nothing" read of the blob. Segments sizes
defined at the server have almost nothing to do with how IBO reads the
data - I cant remember the full explanation behind segments but I
think it was mostly a server side thing setup to best support the old
line printers.

You can put an event handler in to do things during the blob load
process (via a callback mechanism) - you can see a demo of this in the
sample apps.

> I did some tests. Showing a grid with editable fields and a
> blob present. It populates and manupulates a lot faster if you
> bring up the blob for editing with a generated select into
> a TRichEdit at moment of selection than relying on an automatic
> process with TRichEdit being one of the displayed grid objects.

IBO generally does a "load on demand" for blobs.

If the blob contents are displayed on the grid then it will be fully
loaded. This happens if the gdtShowTextBlob option of the
DrawCellTextOptions property is enabled. If that option is not
enabled then only the [BLOB] indicator is displayed and the blob not
is not loaded. This means that you may be loading a full grid page
worth of blobs when the the grid is displayed - with the resulting
performance penalties.

If you avoid showing blobs on the grid then IBO should only be loading
the blob for the current record - and then only if there is a control
or some processing that forces it to be loaded from the database.


HTH

Geoff Worboys
Telesis Computing