At 12:38 PM 7/01/2007, Enrico Cima wrote:

>Then i checked on Interbase DataDef manual and i saw that Text was
>to be sub_type 1 and i changed just these three BLOB, leaving the
>one of the BMP to sub_type 2, since was suggested from the manual
>for BINARY LANGUAGE REPRESENTATION (BLR). I misunderstood the meaning of this.

BLR is a specialised text format, used by the engine internally. Do
not confuse "BLR" with "Binary". BLR is a special text format that
is used internally by Firebird (or InterBase) to store a lower-level
representation of your DDL definitions. Accessing the BLR is
certainly not everyday stuff. IBO supports it (for the
knowledgeable) but it is certainly not basic stuff!!

>Many thanks for Your clear help, now i will go deeply in Your
>suggestion for Blob Filter and adding code to interpretate different
>binary information.

It is only a suggestion. It is a quite challenging programming task
to write a Blob Filter (and the small amount of available
documentation is very poor!)

>The one for storing HTML is also interesting, is there already some
>samples i can study to see how is working the link between the
>retrieving data and the filter to be use ecc?

I don't know what you mean by "ecc". I do not know of any Blob
Filter that does anything with HTML.

I think you misunderstood my point about using NEGATIVE blob
sub_types as a convention for self-documentation. I'll try to
explain it again, with an example of how one might establish such a convention.

Suppose I have a system where several tables in my database store
Blobs. As the designer, I know that I want to use Blobs to store
several different "kinds" of data. For example:

- for my web application, I want to store chunks of HTML that are
read at run-time and displayed on my web-site as "chunks" of my web pages

- for my documentation application, I want to store chunks of XML,
that my application will read and pass to a publication tool such as
HelpAndManual4

- I also want to store images in various formats (.wmf, .bmp, .jpg, .gif)

So - I decide on a CONVENTION for storing all of my various different
types of Blob. Here is what I might decide on:

RTF - sub_type -10
HTML - sub_type -20
XML - sub_type -30
WMF - sub_type -40
BMP - sub_type -50
JPG - sub_type -60
GIF - sub_type -70

When I define the metadata for my database, I would then make it a
rule to use these sub_types whenever I define a blob. If I have a
Blob field in which I want to store HTML, I will declare it as
sub_type -20. If I have a Blob field in which I want to store GIF
images, I will declare it as sub_type -70...and so on.

The sub_types have no significance to the Fb/IB database engine, the
client library or to IBO - these are all just a "soup" of binary
codes. Sub_type -30 is not recognised as text data, for example, so
it is pointless my defining this field as CHARACTER SET UNICODE_FSS -
my application will have to take care to store Unicode data in this
field if I want it to be recognised as Unicode...and so on.

It is a *convention* that I invented for my own purpose, which is to
allow me and others working with my database to know that I intended
to store that type of data under those sub_types. From the engine's
point of view, it is a "do-nothing". It is purely a convention I
have invented for self-documentation of my database.

======
Then (optionally!!) I can write some external Blob Filters. A Blob
Filter is a program that processes the contents of a blob and returns
data to the caller as a a Blob that is changed, i.e. the Blob
contents that are returned to the caller are different to the
contents that are stored.

Suppose I have some Delphi code that can convert RTF to HTML. I
decide to use this code to write a Blob Filter that converts Rich
Text Blob data to HTML. I can write this program in any language
that is capable of exporting an entry point and responding to the
CDECL calling convention - such as Delphi.

A Blob Filter is a special kind of UDF that must be designed to take
a Blob as input and produce a Blob as output. I have to compile it
as a DLL. I make it available to the database server by declaring it
in my database and locating it in the place where the engine looks
for UDF libraries. (In Firebird 1.5 and above you can configure a
special place for Blob Filters if you want to.)

If I have several Blob Filters, I will probably want to bundle all of
them into one DLL ("module") with a useful name, e.g. BlobFilters.dll.

I need to give an export name to the entry point to my Rich Text to
HTML conversion routine, so I might name it RICHTEXT_TO_HTML, for clarity.

Assuming I have thoroughly tested my conversion routine and have
taken care of all the memory aspects, I can now make it available for
the server to use in my database, just as I do when I declare a UDF.

The declaration is a little different, because I have to tell the
engine the sub_types of the INPUT and OUTPUT data. So, supposing I
use the same sub_types as I used above for my sub_type storage
convention, I would declare my Blob Filter like this:

DECLARE FILTER GET_HTML
INPUT_TYPE -10 /* Rich Text */
OUTPUT_TYPE -20 /* HTML */
ENTRY_POINT 'RICHTEXT_TO_HTML'
MODULE_NAME 'BLOBFILTERS'

The Blob Filter now gives me the ability to process my RTF Blob data
and return it as HTML.

In my application, I would retrieve this HTML from my stored RTF data
using the FILTER clauselet, e.g.

Metadata:

create table WebChunks (
ID BigInt,
Chunk Blob sub_type -10 /* Rich text */);

DML:

select ID,
Chunk Filter from -10 to -20
from WebChunks

It is a rather simplified description of what is quite a complicated
thing to implement, but I hope it clears up the misunderstanding....

Helen