RM9 Enhanced Properties List

My first reaction on seeing this new feature was delight mixed with a rueful “it only took 13 years”! One of the earliest scripts published on SQLiteToolsforRootsMagic in 2009 was a query that replicated the original RM Database Properties. The query was rapidly enhanced in 2010 to assist in identifying potential problem areas in a database. RM was requested to incorporate something similar back then. Below is the first few rows of the 2013 version that was looking at a RM5 database.

The new RM tool has taken a great step in that direction and neatly incorporates links to address some issues. I’d love to see it go further and as the list grows, make sections collapsible and flag sections and items in which there is a reported problem.

Sample Output

Value Variable Remark
5008 Version vs Control version 5008
1157 People all records in PersonTable
0 – Nameless People no record in NameTable for that RIN
97 – Unresolved Duplicate Name Pairs pairs of Given and Surnames, not flagged as “Not a Problem”
16 – Resolved* Duplicate Name Pairs flagged as “Not a Problem” – flags lost on transfer
2 – Unresolved Duplicates with Media Links secondary persons’ links lost on merge
39 Alternate names all records in NameTable where IsPrimary=0
0 – Orphaned Alternate names* no Primary name record found
389 Families all records in FamilyTable
66 Fact Types no. of records from FactTypeTable
2 – Custom Fact Types no. of custom Fact Types
9 – Customised Built-in Fact Types no. of built-in Fact Types modified
35 – Unused Fact Types no. of Fact Types not used
0 – Blank Fact Type Names FactTypes must be named
0 – Blank FactType Sentences FactType needing definition
2831 Events all records of EventTable
0 – Orphaned Events events for which no person or family match in respective tables

I had the same reaction until I realized that I couldn’t do much with it. For example, under Unused Media is a “view” hotlink. Great, I thought, now I can rid my media folder of some bloat. But the “view” just results in a worthless child window listing the unused media in which you can take no action. You can’t even copy the filename out of the window!

Even the court is not updated for unused media. I went to a person record, attached one of the “unused media” to a person. After returning to the Enhance Property view, I found the unused media item was still listed and the count unchanged. After using the tools to reindex, the unused media item still remained in the list and the count remained the same. Also, It would be nice to have a “copy” feature to copy/paste the results of the listing for unused media. This feature was not thought out well.

I can’t recreate that. I just viewed my list of “unused media” and added a media tag to one person. Ran the Enhanced Property List again and it was no longer on the list of unused media. Make sure you added media to the correct media item. Take a screen shot of the page if you need to reference it.

Here is what I am experiencing where the unused media item is not removed from Enhanced Properties Unused list and the count remains the same.

Does the false “unused” persist after closing and reopening the database?

Does the database pass the Integrity Check?

The captions, descriptions and date of the “unused media” are not the same. Look on the Media Gallery for a second incident of the same media. That is the one not being used.

Good eye! I was only looking at the file path and name. For some reason, I’ve always thought that a media item could only be linked once to a given database. A duplicate in another path could also be linked. But the same file???

In RM4, you could have a unique caption and description for each tag of an item. I objected strenuously to the change in RM5 that restricted caption et al to one set per media item. Case in point is this class picture for which a different caption might be desired for each tag to a different person in the photo.

So I guess a workaround is to link the photo to the database as many times as you want a different caption but that sucks because it clutters up the Media Gallery and misleadingly inflates the Properties list and other reports.

So I go back to my RM5 enhancement requests that the proper way is:

  • Only allow a file to be linked once
  • Support a ‘master’ metadata set (caption, description, location…) per file that is the default for each tag
  • Return to custom metadata at the tag level (RM4) which overrides the ‘default’
  • New: revise the structure to parallel that of Citations in which ‘uses’ have been split from the data: that would interpose between the MultimediaTable and MediaLinkTable a MediaMetadataTable for the custom metadata.
  • Support the reading and writing of master metadata from/to the linked files

Thanks. I now see the different media descriptions for the same file name. I found the problem. I had two different links to the same file. I have several of these that I’ll need to clean up. I would also be in favor of having one media link per media file since the focus should be on the content of the media object rather than the object to which it is linked. Sorry for the confusion. Thanks again.

I should add that custom cropping which the database structure also supports and did from RM4 (and maybe earlier) should also be at the tag level to respect the one file-one link to database rule while allowing multiple crops from the same image file.

There are ways to get more than one copy of the same media. Ancestry will send duplicate media if download more than once, but the file names will show (1), (2) etc. If you rename and link to the same media afterwards it will not get rid of multiple thumbnails. If you add media and the link are broken it’s possible to repair it and what was once in different folders could now link to the same media image. Not sure how we could prevent any of these from happening.

It’s called Merge. Merging of media links is also an old request. Similar to merging of Sources and Citations, we need merging of Media and Tags.

And has been discussed recently, the control over media duplication from TreeShare surely lies with the receiving system, not the API.