Simon,

> 
> Not to be rude or anything, but does FirstAID Extractor decrypt all types of 
> BLOBs?

Firebird, like InterBase, has a mechanism for translation among blob formats 
called blob filters.  There is a filter that translates the RDB$DESCRIPTOR 
format to a readable format.  Isql, the utility distributed with Firebird, uses 
that filter when you ask it to display an RDB$DESCRIPTPOR blob.  Similar 
filters translate blobs containing the binary format of BLR into something that 
makes sense to people.

As far as I know, all the non-text blobs used in the metadata have blob filters 
to return their contents as text.

The first place to look for the format of records is the catalog of system 
tables.  RDB$RELATIONS describes tables and views.  RDB$FIELDS describes 
domains - field definitions independent of their use in a particular table or 
view.  RDB$RELATION_FIELDS describes the use of a field in a table or view and 
allows some attributes of the domain to be overridden.  Among other information 
in RDB$RELATION_FIELDS are the field_id - a unique identifier for that field 
int that table, and the field_position which is the default ordering of fields 
in the output.  The field position can be changed.  The field id cannot.  When 
a field is dropped from a table, its field position can be reused, but its 
field id will never be reused.

So, going from the higher level system tables to RDB$FORMATS, when a table is 
created, Firebird creates format 1 for that table.  The descriptor contains a 
list of the fields identified by field id and described in terms of type and 
length.  When a table is altered, Firebird creates a new  RDB$FORMATS record 
that contains the new low-level description.  When a record is stored, the 
current format id  is included in the record header.  When a record is read, 
Firebird checks the format id, and if it is not the current format, updates the 
record to the current format, dropping old data from fields that were dropped, 
and creating new null (or default?) values for fields that had not existed in 
the in the old format.

A data page consists of two parts:  an index consisting of offsets and lengths 
and a data portion.  When looking for record 10 on a particular page, Firebird 
reads the 10th index entry to get the offset and length of the compressed 
record.  It reverses the run length compression to recreate the record data at 
its full declared length.   It then finds the format id in the record header, 
validates that the format is current or updates the record to the current 
format,  and then reads the record as necessary.  Obviously, if the record is 
fragmented across pages, the process is more complicated because the trailing 
portion of the record must be read before decompressing the data.

Good luck,


Ann
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to