[Spliff]

You don't give specifics about the databases. I suppose you will have done the "Tools - Compact and Repair" for both of them, and the problem persists: in both directions, or just in of of them (a>b AND b>a)?

I suggest you create new databases for both, then import everything into those, then see if the problem persists.

By "import", I mean copy ^c in the original databases, switch to the respective new one, then do ^v; I did this for bulks of 5-digit numbers of items at a time, so if you do this for sub-trees containing several thousand items each, there should not occur a problem in the process.

The only REAL problem arising from doing this is possible de-sync afterwards, since while you observe and check, several days, you will have to decide which ones of the databases you will use, the old, or the new ones, and if you then decide to continue to use the other one...

I suggest that after that "export", you just use the new databases (you'll rename the old ones accordingly), after again a "Compact and Repair" which will recreate the text index.

(I have no experience with UR databases though which contain web pages.)

Btw, the perfect SQLite tool for UR is Navicat for SQLite; if you don't use it professionally, you can buy it for private use for $99 plus VAT. (On the other hand, it's a very bad moment to buy since you'd buy v. 15, while v. 16 is way overdue, but you could use, for some days, the fully-functional trial.)

The reason why I say "perfect": It's the only one of those tools which integrates data compare (to be found in the manual by searching for "data syncing"), and that's the functionality you'll be interested in after switching thousands of items between databases, and all the more so if after some days, you'll want to switch your "new" items from one database to the other.


EDIT: I forgot: First thing is to note how many items, then check after the switch; I never encountered item differences so this is to be considered reliable.

And I'd like to explain why I think the a copy into a new file might help; I make assumptions here; correct me if I'm wrong.

SQLite is a quite weird format, the whole database within one file (!), so in that file, there obviously is some "package around" the records, and that may have become slightly faulty, so a "new package" - the data "around" the records data - could help.

I do NOT think that faulty records (especially the "content" fields) may play a role here, because I don't think there is some "check" for all those records and their respective integrity when opening an SQLite database, let alone when just switching to it (i.e. when it's already opened), and faulty records could crash the database indeed, when "touched", i.e. upon the try to access them; before that, they, and their possible database crashing effect, should remain "dormant", so even some really faulty web page "content" record - which obviously would be copied into the new, data-replicating database - should very probably not cause the effect you see.

I may be mistaken though.