Hello Enrico,

At 12:02 AM 6/01/2007, you wrote:

>I do have a generic simple database containing like:
>
> TABLE _TITOLO (
> TITOLO TITOLO NOT NULL COLLATE NONE,
> CONFERMA INTEGER NOT NULL,
> TIT_TXT BLOB sub_type 1 segment size 1,
> TIT_COMM_1 BLOB sub_type 1 segment size 1,
> TIT_COMM_2 BLOB sub_type 1 segment size 1,
> TIT_BMP BLOB sub_type 2 segment size 1);
>
>While i use this i a normal Form i can insert everything and all is
>shown correctly (just tuse TIT_BMP for putting and image, the other
>BLOB for text only).
>In the form i'm using IB_RichEdit for text and IB_Image for the BMP.
>
>When i post the data, all is correctly saved.
>When i retrive the data, the BMP is not shown, seems empty. But, if i
>use EMS i can see is correctly saved and i can show the image.

Two comments here:

First, you should *not* use sub_type 2 for your own blobs. This
sub_type (and all positive sub_types higher than 1) is used
internally by the database engine for some specialised text types.

If you want to assign custom numbers to sub_types, you must use
negative numbers. However, it does not make great sense to use
custom numbers for your example case. You should sub_type 1 for your
text blobs (because the engine has special capabilities for this
type) and sub_type 0 for your bitmaps.

There is only one way that the DB engine can have knowledge about the
kind of data that you might store in a blob. That is by way of Blob
Filters. A Blob Filter is a specialised kind of UDF that takes
"binary soup" from one sub_type and outputs it in some structured
way. Blob sub_type 1, for example, uses a Blob Filter that tells the
engine to handle the contents as strings of characters. For
sub_types 2 and higher, the engine has internal procedures to convert
the binary data to specially formatted text that the engine accesses
for BLR and ACL routines (and others).

The engine has otherwise has no knowledge of what is expected to be
stored in a blob. If you are not using Blob Filters that you have
written, there is no special reason to use custom sub_types.

Some people do employ the negative sub_type numbers to implement
their own self-documentation conventions for the Blob data they are
storing. For example, you might decide to declare HTML code as
sub_type -2, XML as sub_type -3, jpegs as -4, bmps as -5, Word
documents as -6, etc. It is harmless, as long as these numbers don't
conflict with any custom Blob Filters you have installed.
===========
Next, your "problem":

The reason that you can "see" your images using a third-party client
application like EMS is that the application itself is providing
"containers" to manage and display your bitmaps. When you write your
own applications, you need to supply those objects yourself.

Inside a database, Blobs are stored separately from the table records
that they belong to. In the table record itself, the Blob is
referenced by the Blob_ID, an internal identifier that may change
many times during the life of the Blob. In some cases, a Blob
containing a small amount of data will be stored on the same
*database page* as the record data but, in a lot of cases, the Blob
data is actually physically separated from the record data, in
specialised Blob pages. Client applications don't need to know
whether the Blob data is stored; nor can they *tell* the engine to
store it one way or the other. The engine looks after all of this itself.

Any retrieval and storage operations involving Blob data have to use
special structures in the API. IBO surfaces all of this Blob stuff
for you in classes and methods, just as it does with other kinds of data.

If EMS were written with IBO (which it is not!) it would use a
specialised descendant of TIB_Column to provide these things to the
interface that you see when you use EMS. (Actually, I think EMS uses
FIBPlus, which has parallel implementations to those provided by IBO,
although it is less developed than native IBO in this regard, because
it has the same limitations as the Delphi VCL Blob data members...)

TIB_Column has a descendant TIB_ColumnBlob that is the base class for
the more specialised TIB_ColumnMemo (for sub_type 1 Blobs),
TIB_ColumnBinary (for sub_type 0 Blobs) and TIB_ColumnBLR (for some
special handling that IBO can provide for processing BLR
directly). You should study the help for the first two sub_classes
because they provide a lot of properties and methods to help you
display and manage your text and image blobs. You can, for example,
use and Assign() method to pass data between the column and Delphi or
IBO controls such as TMemo and TIB_RichEdit (for text and styled
text, respectively) and TIB_Image descendants.

Some TIB_ controls - TIB_Grid and TIB_RichEdit, for example - provide
automated handling of the appropriate Blob sub_types. I suspect that
your problems with TIB_RichEdit (and TIB_Grid too, if you have bumped
into the problem there) will be found to derive from using sub_type
2. IBO can apply the appropriate "smarts" if it knows that the Blob
data is expected to be character strings. If you replace them with
sub_type 1, these problems should go away.

>I'm using the same way for other situation, but not having this
>problem. (I'm wondering if is because three blobs in the same Archive
>and something is happening through IB_Query while opening. Infact
>also when opening in the IDE with IB_Query TIT_BMP is empty.
>The query is just SELECT * FROM TITOLO
>
>I'm using CBUILDER6 and IBO 4.2Ie, the last version that i thank a
>lot Jason to have given me for my hobby.

I realise that using Builder makes it a little more difficult to make
sense of the IBO examples, especially if you are not particularly
literate in Pascal. But please do take the time to study the help
for the TIB_ColumnBlob descendants and to fix up your Blob metadata
so that IBO is able to get the correct information about your Blobs
from the API.

Helen