Results from Running Tom's RM9 to RM7 Reversion Process
I have now run Tom's process to revert an RM9 database to RM7 and I have run my comparison scripts. There is good news and bad news.
The good news is that my scripts basically report that the reverted RM7 database matches the original RM9 database. There are two issues that need some attention.
The first item is that if you change a place name in the main RM9 Places tab, it updates three columns for that place in addition to the the Name of the place. Namely, it updates the MasterID column, the fsID colum, and the anID column. I don't know what the fsID field and the anID field are for in RM9, and they don't exist in RM7. It's hard to see how their loss during the reversion can create any problems. The MasterID column in RM7 is used only for PlaceType = 2 rows (Place Detail rows). It contains the PlaceID of the owning PlaceType = 0 row (Place rows). After changing a place name in RM9 in a PlaceType = 0 row, the MasterID field is changed to a value of 1366. I have no idea what this means, but that value is reverted back to RM7. It probably needs to be changed back to 0 in RM7.
The second item is that I couldn't quite figure out how to fill in my folder names in Tom's script for the MultiMediaTable.MediaPath column. My own script for MultiMediaTable obviously had to deal with the same issue. But so far I haven't been able to reconcile the way my script handles the issue vs. the way Tom's script handles the issue. It should be easy to figure out, and I'm still working on it. This us surely just a case of Jerry being a dunce.
The bad news is that despite all the tables I care about matching, the newly made RM7 database is essentially unusable. It gets frequent Access Violation errors, far worse than anything I have ever seen in RM9. And the screen simply misbehaves. For example, the left most person in Pedigree View doesn't show birth date. Moving the same person one position right immediately causes the birth date to appear. The red triangles for navigating generations in Pedigree View don't work. Descendant View sometimes only shows up in the left half of the screen with the screen scrunched together hard left.
It's hard to picture anything in the database that would be causing these kinds of problems. It's like the problems must be configuration problems in RM's XML file or something like that. But when I close the reverted database and open my standard RM7 database, all is well again. Running the Database Tools in the reverted database does not fix the problems. And you do have to run the Database Tools. Otherwise, the fake RMNOCASE we use with SQLite leaves RM's indexes completely mangled.
I have studied Tom's reversion script extensively, and I don't see anything wrong with it at all. Everything seems just perfect. So I am pretty mystified. When I have played with the RM7 database created from RM9 via Export=>Dropbox, it has operated pretty smoothly. The only thing I'm aware of so far that I care about that's missing from it is shared facts, so one strategy I might look at is to run Export => Dropbox and then to run the steps of Tom's procedure just for RoleTable and WitnessTable.
The reversion is apparently not a very simple project, and we shall see what happens moving forward.
I developed the heavy conversion from RM8 to RM7 (Convert RM8 Database to RM7) about a year ago and it was used successfully by more than one user. The conversion from RM9 to RM8 (Database Revert RM9 to RM8 to RM7) was recent and superficial, merely changing the database version number in the ConfigTable. However, the ConfigTable itself has changed significantly in both RM8 and RM9, notably with the addition of the Book feature, and it looks very different from what we see in the RM7 ConfigTable. So it does not surprise me that there are new issues. It may be necessary to modify or strip out some content of ConfigTable.
I won't have time to explore this myself for at least a week.
Just a suggestion: don't even begin looking at it in a week's time unless I report that I have not gotten it to work at that time. Two steps I have taken already are to get my SQLiteSpy up to date and to run the RM8 to RM7 reversion without involving RM9 at all. This all worked smooth as silk.
RM7 is operating on the reverted database just as cleanly as it does my normal production database. And my comparison script only reports the MultiMediaTable.MediaPath problem that I described before, and that's my problem to solve. In other words, the RM8 to RM7 reversion worked perfectly. My next step will be to try to understand what went wrong in the RM9 to RM8 step. I probably did something wrong.
I have given up for the time being. My report that the RM8 to RM7 reversion ran smooth as silk was premature.
Using RM8 instead of RM9 did get rid of all the strangeness I reported about screen navigation not working etc. after I reverted from RM9. These were surely problems in the ConfigurationTable. By reverting from RM8 instead of from RM9, it appears that ConfigurationTable problems are solved.
An RM8 database reverted to RM7 does operate smoothly with respect to those most basic of functions that didn't work after reverting from RM9. But when I do things like get into the Edit Person screen in the reverted database and try to look at a media file tagged to a fact or try to open a citation, I get access violation errors. I certainly ran the Database Tools prior to trying anything else. I can close the reverted RM7 database and open my current RM7 database and the access violation errors vanish immediately.
My process was to make a new RM8 database from my current RM7 database and immediately to revert it back to RM7. I ran the RM8 reversion script as is except that I commented out the ATTACH statement and ran it by hand, and I commented out the steps for fixing MultiMediaTable.MediaPath and ran those steps separately. I have those working correctly now for my database.
I've nailed down the problem with access violations that Jerry experienced while others have not. It stems from extreme splitting with no field defined in the Source Template for the Citation (source detail). RM7 trips up on the XML expression from RM9 for the CitationTable.Fields value for such a custom source templated citation. Here's what each generates for that field:
RM7
<?xml version="1.0" encoding="UTF-8"?> --prolog
<Root><Fields/></Root> --no source detail defined in source template
RM8-9
<Root /> --no source detail defined in source template
Both are valid XML. If the value imported from RM8-9 is replaced with the original value from RM7 that indicates no fields, problem solved. The prolog can be omitted as it is optional when default version and encoding is used, according to XML specs.
Other users of the conversion script weren't the extreme splitter that Jerry is so their databases did not trigger this case where RM7 mishandles an error of its own making.
I will post revised scripts for conversions from RM9 and RM8 to RM7 shortly.
Other issues may crop up as the latest version of RM evolves and special use cases such as this one arise. One that I suspect needs looking into is the conversion of a reused Ancestry Source from RM8-9 to RM7; can the resulting citations link back to the Ancestry Source via TreeShare?