Jerry Bryan

Well, crow tastes pretty good sometimes. I was wrong about FS ID not being a column in People View and not being a column in Custom Reports and not being searchable. It is all those things. I thought I checked them pretty thoroughly, but apparently I didn't check carefully enough. My apologies.

Jerry

RM8 will run natively on both a PC and a Mac. The release date for RM8 has been announced as being for "this year", nothing more specific than that.

RM7 runs on a Mac with the assistance of a wrapper that provides PC emulation that allows the native PC version of RM to run on a Mac. I'm not a Mac person, but I believe that absent RM8, the wrapper will soon need to be updated to allow RM7 to continue to run on a Mac as the Mac operating system continues to be updated. I would rather that someone much more knowledgeable than me about Macs speak to new updates for the wrapper. The best solution will be the release of RM8 which will render moot the issue of the wrapper needing to be updated.

Jerry

2. RootsMagic stores FS ID's (into a different part of the database than FACTS) apparently DURING -or- AFTER the AutoMatching process.

RootsMagic stores the FamilySearch ID's into a different part of the database than facts AFTER the matching process. The matching process can be manual or automatic, and the storage of the FamilySearch ID's is the same either way. I think that after the matching you can't tell if the match was achieved manually or automatically.

From a relational database perspective, the linkage between the FamilySearch ID's and the RootsMagic RIN's is achieved by a JOIN between the PersonTable and the LinkTable. The LinkTable stores the FamilySearch ID's, and it includes the RootsMagic RIN for each FamilySearch ID. The RIN numbers are used for the JOIN. It's a similar concept to the way RM stores names. Names (including Alternate Names) are stored in their own separate table, and the linkage between names and people is achieved with a JOIN. The difference is that names are presented in the Edit Person screen as if they were facts, even though they are stored in the NameTable instead of being stored in the EventTable where facts such as birth, marriage, and death are stored.

I suppose it would be possible and fairly easy for RM to show FamilySearch ID's as facts in the Edit Person screen, but you wouldn't want them to be able to be edited from there. They should only be able to be "edited" by going through RM's standard Family Search interface. And I suppose that it would be possible and fairly easy for RM to make Family Search ID's available to RM's searching and marking dialog. Names are certainly available to RM's searching and marking dialog, even though they are not stored in the EventTable. Searches such as FSID>Exists>Is True, FSID>Exists>Is False, FSID>Contains, etc. would be very useful. It's the sort of thing that's extremely easy to do in SQLite if you are able to use SQLite, and which is not really possible in the RM user interface.  Well, you can get a list of FSID>Exists>Is True simply by going to RM's FamilySearch interface. You will see a list of matches. But you can't do things like FSID>Exists>Is True AND Birth>Date>Is Before>1900 or anything like that.

Jerry

I obviously need to make one correction. The Family Search ID can be displayed in lieu of the RIN, anywhere the RIN is displayed. So it can be given considerable visibility in a certain sense. But I believe all the other limitations I mentioned are correct.

Jerry

I don't record Find A Grave ID's, per se. I use Find A Grave as a source. The Find A Grave ID only shows up in my RM database in the sense that my sources that come from Find A Grave are tagged with a screen capture image of the Find A Grave screen for the person. The ID is visible in the screen capture image, but I don't specifically store it in any other place in RM.

Jerry