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