Unsupported database version

[pisaura]

Hello together,

great tool! I use it for my last backups to extract conversations. Unfortunately, for some older backups (with valuable messages for me) the following message appears: Error: Currently unsupported database version (105). Please upgrade your database

Is it possible to extract threads from these databases? How is it possible to upgrade the backup files to a newer version?

Regards, Michael

[Regular-Baf]

I was hoping to export an old backup of mine to html and ran into the same thing with database ver. 124. It'd be cool if the tool could have a function to upgrade the database automatically or something similar.

[bepaald]

@Regular-Baf: I've tried to add migration for older databases, to try it (update and) add the --migratedb to the command line when exporting. There may be errors, I'd like to know the results.

@pisaura: Of course, I've also tried to migrate from 105, but unfortunately there is a gap in my backup collection: I have 123 (which is hopefully now working) and 99 which is going to be very difficult if not impossible to get working. I don't know if 105 works already (maybe it is very similar to 123), or not (maybe it's more similar to 99). So, I guess you have to try it, but don't get your hopes up. Again, update and add the --migratedb option to the command line. If it doesn't work I will try to get something working in the future, but it might take a little time (and if I can't find a v105 database in my backups, I will need your assistance).

Is it possible to extract threads from these databases?

The program can always decrypt the backup file, whatever version it is. If you don't care about pretty output, you can decrypt to a directory and view the attachments and read the messages from the sqlite database. Or export the various tables to csv. But this is a very different experience from the HTML.

How is it possible to upgrade the backup files to a newer version?

Generally, you would import the backup into Signal Android and let it update it, then export it a new backup. However, I think version 105 is so old even the Android app does not support it anymore. Looking at the source (https://github.com/signalapp/Signal-Android/tree/main/app/src/main/java/org/thoughtcrime/securesms/database/helpers/migration) the earliest version that can still be imported looks to be 149. This will also make it harder for me to support the migration because I'd have to figure out what changed by myself.

[bepaald]

@pisaura: I found an old v111 database, and that is already too old to work correctly, so your 105 will not either. I will start work on supporting it, but it will take time.

[Regular-Baf]

From what I can tell, the latest update handled my database perfectly! Thanks for the quick response and fix on this

[pisaura]

@bepaald: I've now tested with the current version of the tool and all my backups (previously unsupported versions for my databases: 105, 112, 117, 120, 121, 136, 146 and 155). And now? It works for all these versions with the option --migratedb! Also the output in HTML works without errors. Thanks a lot. (For the version 105 I've tested a full export of all thread ids, for the other ones I've just used a single thread id).

[bepaald]

Yeah, I thought I managed to get it working, was just about to drop a message here but you found out already. I'll try to keep the backwards compatibility as much as I can, but if some old database stops working at some point in the future, please let me know.

Thank you both for the feedback!

[Sylnachten]

Hi!

Sorry for commenting in this closed issue, but you said:

if some old database stops working at some point in the future, please let me know.

It seems to have stopped working at least for versions 110 and 148. When I try to use exporthtml with backups of these versions, it fails with this message:

[Error]: During sqlite3_prepare_v2(): no such column: viewed_receipt_count -> Query: "INSERT INTO mms (date, date_received, date_server, thread_id, address, address_device_id, msg_box, body, read, ct_l, exp, m_type, m_size, st, tr_id, subscription_id, receipt_timestamp, delivery_receipt_count, read_receipt_count, viewed_receipt_count, mismatched_identities, network_failures, expires_in, expire_started, notified, quote_id, quote_author, quote_body, quote_missing, quote_mentions, quote_type, shared_contacts, unidentified, link_previews, view_once, reactions_unread, reactions_last_seen, remote_deleted, mentions_self, notified_timestamp, server_guid, message_ranges, story_type, parent_story_id, export_state, exported) SELECT date_sent, date, date_server, thread_id, address, address_device_id, type, body, read, null, 0, 0, 0, status, null, subscription_id, receipt_timestamp, delivery_receipt_count, read_receipt_count, viewed_receipt_count, mismatched_identities, null, expires_in, expire_started, notified, 0, 0, null, 0, null, 0, null, unidentified, null, 0, reactions_unread, reactions_last_seen, remote_deleted, 0, notified_timestamp, server_guid, null, 0, 0, export_state, exported FROM sms WHERE _id IS ? RETURNING _id" [Error]: copying sms._id: 84465

Is that fixable?

In any case: Many thanks for this great tool!

NB: Upgrading the DBs via Signal does not seem to be an option. While the app claims to successfully restore from the v110-file, it subsequently crashes within seconds and does not allow to do anything.

[bepaald]

Hi @Sylnachten! Looking at the migration code, I'm actually not entirely sure how it worked before... But I attempted a fix, please give it a try. Thanks!

EDIT I do know how it worked before, I just broke it a month or two ago...

[Sylnachten]

Wow, thank you very much for the quick reply and fix. It works perfectly now.

Side-note: On the migration from v110 I got a warning:

Failed to determine Note-to-self thread. Consider passing `--setselfid "[phone]"' to set it manually

I don't use note-to-self, so I ignored the warning and did not test the suggested option. Maybe Signal simply didn't have note-to-self back then? I don't recall. In any case, the migration from 148 did not produce any warning.

[bepaald]

I'm not sure when the note-to-self thread was introduced actually. But either way, I don't think I can distinguish between databases with and without note-to-self threads when I can't determine the id of 'self'. So the warning is going to stay, it can safely be ignored.

Thanks for the feedback!