This might be a rare situation but would be very likely with backups separate by a large time gap.
The table I have noticed this is the jid table as the string needs to be unique so the modified entries will not be added if it clashes with another older id.
Sender will be messed up if jid tables are not identical because they wont refer to the right sender. Also sender jids and chat ids are not adjusted for message tables at all. So chats will appear in the wrong chats if those are not identical or have new ones added through this script.
Only way to address this is to probably do a comparison and adjust based on the results. I have no clue how this can be done.
This might be a rare situation but would be very likely with backups separate by a large time gap.
The table I have noticed this is the jid table as the string needs to be unique so the modified entries will not be added if it clashes with another older id.
Sender will be messed up if jid tables are not identical because they wont refer to the right sender. Also sender jids and chat ids are not adjusted for message tables at all. So chats will appear in the wrong chats if those are not identical or have new ones added through this script.
Only way to address this is to probably do a comparison and adjust based on the results. I have no clue how this can be done.