26.07.2011 16:30, Alessandro Fiorino wrote: > I've been at least a bit lucky: the record structure of the data I > want to recover is simple and I already found how to detect a record > and decode all the other fields (a varchar which always store a 17 > chars string and two integers). > The database is in ODS 11 format and the field is DECIMAL(18,4).
You haven't provided the SQL dialect of the database. If it's Dialect 3, then the value is stored as 64-bit scaled integer (multiplied by 10000, as scale = 4). If it's Dialect 1, then the value is stored in the IEEE double precision (64-bit) floating-point format. So it's always eight bytes, but with different internal structure. > Comparing with some data I have from an old backup, I've noticed that > when the value is zero it is stored as two bytes (0xE7 0x00), > otherwise the value always seems to be encoded with eight bytes with > the first equal to 0xEF. 0xE7 = -25, 0xEF = -17. They're RLE compression prefixes for repeating values, but it's hard to decode the data without knowing all the bytes of the whole record. Follow /src/jrd/sqz.cpp for more details. Dmitry ------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
