Re: Data recovery from Informix 3.30 RDB

On Sep 21, 12:46 pm, bxd...@xxxxxxx wrote:
Trying to do a favour for a small business who had a XENIX machine
(circa 80's) that has crashed beyond repair which was running an
Informix 3.3 RDB ... luckily they have all the nightly backup files
which offload via samba onto DVD's ... in particular all the .dbd
and .dat files are intact ... as the data .dat files are in flat fixed
format and the .dbd (data dictionary) files are readable the
assumption is this data should be easily recoverable.

I have dechiphered some of the details out of the .dbd files but still
struggling with the Field data types and data lengths.

Could someone possibly lead me to a dbd file structure for this
version of Informix to complete this task. If I can pick the Field
Data Type and lengths out of the dbd files then I should have no
problem converting the .dat files into a comma delimited format so we
can recover this 20+ years of customer data.

The dat files were designed as flat fixed data structures with no
delimiters so without the absolute lengths of each field its not easy
to predict the lengths with out the schema details.

What I have so far is

0000: 58FE - appears to be a unique dbd file marker
0002: mmnn- is the absolute offset to the end of the ASCII TABLE/FIELD
stringZ
0004: <Table String> 0
qqrr: <Field String> 0
nnmm: bbcc is the number of tables in this definition file
nnmm + 2: 0000 ???? ???? FFFF 0000 the first 16 bit number is the
offset into the ASCII TABLE/FIELD ... referencing the TABLE name the
first entry in this is offset by 4 so address 0004 is actually
0000 ... there will be one block for each of the tables defined

the remainder of the file is a jumble of numbers that I haven't been
able to associate

The field type and length fields probably follow the same convention
as modern SE and IDS. Types will be in the sqltypes.h header in the
Informix SDK. The length field mod 0xFF00 is the actual length and
the high bit indicates whether the column supports NULLs or not. More
exotic schemes for new types like DATETIMEs and DECIMALs were probably
not supported in RDS 3.30, well perhaps DECIMALs - hopefully they
didn't use them if they were supported. Decoding decimals is tricky,
understanding the type field is described in the SDK headers and ESQL/
C manuals (decoding is described there also but it's incomplete). If
you have to decode DECIMALS contact me, I have a function. Everything
else should be native machine types.

Art S. Kagel

.