Spliff
04-18-2023, 11:21 PM
We know that for SQLite frontend access to our UR files, we have to replace the header start: from
Ultra Recall DB (=the leading 15 chars) to
SQLite format 3 (=again 15 chars).
We also know that "Tools - Compact and Repair" will then change it back to Ultra Recall DB, so we might have to do this often, more or less manually.
I've now had a corrupted UR db file, and which wasn't even recognized as a (corrupted or not) SQLite file by my SQLite repair tool anymore, and since my last backup was a week or so old - which is impardonable! - I further inspected the header, by comparing it to the headers of "working" UR DBs.
The complete SQLite header here, beyond the above:
53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 (= SQLite format 3)
is then:
00 04 00 01 01 04 40 20 20 00 (and the next byte then is 00 or 02 or 04..., and so on); thus, the complete header being:
53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 04 00 01 01 04 40 20 20 00
Now, in my corrupted db, that 00 right behind the "SQLite format 3" was missing, everything before and after being okay, so I re-inserted that missing byte, and everything was fine again.
THUS, before any other repair tries, the UR user is well-advised to check the header, even when they are "sure" the header could not be affected. In fact, I replace those 15 leading chars in (the hex editor's default) overwrite mode, obviously, not by deleting them, then inserting new bytes, and thus, losing 1 byte in the process was "technically excluded"... and then, as said, and after saving, that 1 byte was missing indeed, so, obviously, checking the header should be your very first action whenever you encounter a corrupt UR file.
Ultra Recall DB (=the leading 15 chars) to
SQLite format 3 (=again 15 chars).
We also know that "Tools - Compact and Repair" will then change it back to Ultra Recall DB, so we might have to do this often, more or less manually.
I've now had a corrupted UR db file, and which wasn't even recognized as a (corrupted or not) SQLite file by my SQLite repair tool anymore, and since my last backup was a week or so old - which is impardonable! - I further inspected the header, by comparing it to the headers of "working" UR DBs.
The complete SQLite header here, beyond the above:
53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 (= SQLite format 3)
is then:
00 04 00 01 01 04 40 20 20 00 (and the next byte then is 00 or 02 or 04..., and so on); thus, the complete header being:
53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 04 00 01 01 04 40 20 20 00
Now, in my corrupted db, that 00 right behind the "SQLite format 3" was missing, everything before and after being okay, so I re-inserted that missing byte, and everything was fine again.
THUS, before any other repair tries, the UR user is well-advised to check the header, even when they are "sure" the header could not be affected. In fact, I replace those 15 leading chars in (the hex editor's default) overwrite mode, obviously, not by deleting them, then inserting new bytes, and thus, losing 1 byte in the process was "technically excluded"... and then, as said, and after saving, that 1 byte was missing indeed, so, obviously, checking the header should be your very first action whenever you encounter a corrupt UR file.