Scripts to Import RM9 or RM8 to RM7
Here's a new script for importing a RM9 database directly to RM7 and a revised script based thereon that supersedes the one described at Convert RM8 Database to RM7. The two are essentially the same with the references to RM9 or RM8 set accordingly. The RM9 script eliminates the intermediate step described at Database Revert RM9 to RM8 to RM7.
Both new scripts solve the problem that @thejerrybryan encountered because of his unusual use of custom source templates having no field defined for source details. They also now work correctly with citations that have been reused, correcting an error in the earlier RM8 versions.
Of course, there may be other issues not yet discovered, especially related to the data in the ConfigTable such as report settings and also probably around the conversion of folders and research items. Both areas underwent significant structural change from RM7 to RM8 which makes it extremely difficult or impossible to transform constructs to be compatible with RM7. Another area that I've not exercised intensively is FamilySearch so there may be wrinkles yet to iron out there.
Uploaded files:I'm presently reworking my scripts which compare an RM7 database to an RM8 or RM9 database not to be so literal.
The scripts I posted previously require that the primary keys be identical between the two databases for all the tables being compared. That was a reasonable design for my scripts assuming I would import from RM7 into RM8 or RM9, and then use Tom's script to revert from RM8 or RM9 back to RM7. All the steps retain all the primary keys for all the tables of interest.
But as I have reported, there is apparently something in my RM7 database that is causing the reverted RM7 database to be unusable. No other users of Tom's reversion scripts have encountered this problem. Neither Tom nor I have been able to identify the problem in my RM7 database that is causing this symptom.
As a result, my new plan is to GEDCOM export/import from RM7 to RM7, import the new RM7 database into RM8 or RM9, and to use Tom's script to revert to RM7. I have already established that adding the GEDCOM step cleans up whatever is causing the problem and the reverted RM7 database seems fully usable.
However, the GEDCOM step does not maintain the exact same primary keys for any table except one. Namely, it's possible to maintain the exact same primary keys for PersonTable during a GEDCOM export/import. With some reworking of my scripts, maintaining the same PersonID is sufficient is sufficient for my scripts to identify any data loss problems. When I'm done reworking my scripts, I'll start testing again, this time including the GEDCOM export/import step, and this time using Tom's newly updated reversion script.
That begs the following obvious question: if I can get the GEDCOM export/import step to be clean enough, why do I even need Tom's reversion script? Could I not use a GEDCOM export/import step to get from RM8 or RM9 back to RM7? For now, I'm only going to confuse one issue at a time. I really like the idea of Tom's script, and it's still an essential part of my disaster recovery plan in the event that I have to revert to RM7 after converting to RM9.
Quote from thejerrybryan on 2023-06-13, 1:43 pmBut as I have reported, there is apparently something in my RM7 database that is causing the reverted RM7 database to be unusable.
Have you tried the latest scripts? I believe I've solved your exceptional problem and a second one arising from reused citations. Is there something else making your reverted db unusable?
I don't know what you fixed, but I just ran the the new version of the script for RM9 and there is nary a sign of the Access Violation errors we were seeing before. I have a number of additional things I want to check out, but it's looking good so far.
I think I may continue with the development of a Version 2 of my database comparison scripts that depend only on RIN numbers matching between two databases. What that will allow me to do for testing is to make parallel changes to both RM7 and RM9 and then to compare the databases. I could do the same thing with Version 1 of my database compare scripts, but it was really touchy. I had to do everything in both databases in exactly the same order. Doing almost anything in a different order between the two databases would get the primary keys out of sync for quite a few tables, even if I kept PersonTable.PersonID perfectly in sync.
I have spent several hours testing the new version of the script to revert RM9 to RM7, and it all looks good. There no longer seems to be a need for me to test with RM8.
Here is one minor suggestion. When resetting the MultiMediaTable.MediaPath, concatenate a \ character at the end. The reverted RM7 database doesn't actually require it, but the original RM7 database has it. So if I go from original RM7 to RM9 to reverted RM7, there is a meaningless mismatch between original RM7 and reverted RM7. My comparison scripts pick up the difference.
For example, here is what I do. I don't have the * case in my database so I didn't bother with it. I only handle the ~ and the ? cases.
UPDATE MultiMediaTable
SET MediaPath=REPLACE(MediaPath,'~','C:\Users\jbryan') || '\'
WHERE SUBSTR(MediaPath,1,1) LIKE '%~%'
;
UPDATE MultiMediaTable
SET MediaPath=REPLACE(MediaPath,'?','C:\Users\jbryan\Dropbox\mybackup\aalevel2\mywebpages\rm_media') || '\'
WHERE SUBSTR(MediaPath,1,1) LIKE '%?%'
;
Note that the concatenation of the \ has to be outside the REPLACE. It can't be a part of the replacement string.