I ran tools and closed.
I opened in DB Browser SQLite
I ran the Integrity Check. The Check found 7 missing rows indexes
In SQLite Studio I find two missing Index
My question is why is the check reporting the missing rows? and will a brand new database? Not sure if this is truly a problem - - but it makes you wonder.
It looks like the integrity check problem is in the SourceTemplate table. That table is already populated with RM’s built-in source templates, even in a new and otherwise empty database. That’s part of the reason that even a new and apparently empty RM database can encounter integrity problems when checked from an SQLite manager. Some of the tables are not empty.
There are several other tables that will be populated with built-in in data, even in a new and otherwise empty RM database. The ones that come to mind off the top of my head include the FactTypeTable and the RoleTable which contains RM’s built-in fact types and roles.
The rest of the reason that RM tables can encounter integrity problems using an SQLite manager can be that you have not installed a fake RMNOCASE collating sequence in your SQLite manager. A number of RM’s tables are indexed with a collating sequence called RMNOCASE rather than the more conventional NOCASE. The RMNOCASE sequence serves to sequence certain non-English letters into the same order that the letters to seem be to a native English speaker. For example, the German letter Ü is sorted by RM using RMNOCASE the same as if it were the English letter U, even though the Ü is a distinctly different letter in German.
RM itself does not encounter integrity check problems with a new and otherwise empty database because it includes RM’s actual RMNOCASE collating sequence. So this “problem” is not truly a problem.
What is interesting with DB Browser with a fake RMNOCASE (extension unifuzz64.dll) gives 7 hits. But I agree it is likely related to that. Rather annoying.
What also is interesting a newly imported GEDCOM in RM7 is clean for integrity check. This lead me to believe there is something more going on with the structure of database between RM7 RM8 an RMNOCASE, but I will have to investigate further — not sure if anyone else has experience with this.
This is entirely due to a mismatch between the proprietary RMNOCASE collation sequence and any fake we have come up with. Unifuzz is the best so far. That’s why I advise a REINDEX in sqlite before an outboard operation and a RM Rebuild Indexes after.
Thanks Tom — I did not realize the need to REINDEX in SQLITE before performing an OUTBOUND operation. Though I always did this before / after in RM. This brings me to my 2nd question. Should one use 32bit or 64 bit SQLITE (obviously then you would have to use the correct UNIFUZZ version to go with it I assume.
One other question. I have noticed that some SQL scripts seem to run completely on a RM7 database without issue. However, the same script will not run completely on an RM8 db. with the RM8 database the script seems to fail after 25-50 rows (for an update query for example
)
I’ve not experienced such failures nor can I fathom that this would be a systemic or widespread problem. More likely, it is due to corruption in the RM8 database not present in the RM7 database. Or it could be a lock on the database unique to RM8; is the db open in RM8 when you run the script?
Caveat: because RM Inc does not support or even condone using outboard SQLite, this discussion may better be carried on outside RM Inc’s forums.