Family Historian User Group

I want to give a copy of my FH7 Project to a relative who is a new FH7 user. Is it best to create a Full FH7 Backup file and send that to them or is it better to zip up everything in my FH Project folder/subfolders and send that? Or does it matter either way? (I have always opted to copy my media files into the Project folder.) How much difficulty might they expect to encounter with my project because of differing program settings, e.g. because I use 6 part Place names and they don't?

A full backup is a zip of a single project folder.

Other items you might want to include are any custom Fact Definitions you have created, or any Source Template Definitions.

Mardon wrote: ↑

09 Nov 2022 14:43

How much difficulty might they expect to encounter with my project because of differing program settings, e.g. because I use 6 part Place names and they don't?

There is no such setting for Places. You can freely mix 6 part with 3 part etc, in the same project, with no problem.
The reason most of us stick to ’x’ parts, is to make it easier to work with the places data, allowing an easy way to sort/filter our places.
for example, using your US places as an example, each place would have the state in the same column, so sorting on this column would arrange places in alphabetical state order, making it easier to list all those places within the same state.

The advice in FHUG KB Family Historian Copy and Migration Guide is largely relevant.
You are right to consider your customisation settings.
The number of Place Columns is set in Tools > Work with Data > Places... via the Columns... button and the display looks odd with only 3 Columns defined. Other features will work OK with any Columns setting.

Since your relative is a new FH7 user, they may like to adopt your settings, so you can work together with a common setup.

You will also need to consider how you "send" it to your relative. A full zip backup of your project folder and custom settings backup could be an extremely large file that is too big to send as an e-mail attachment. If that is the case, and you want your relative to have a full copy, you may have to explore sharing via cloud storage.

Jane wrote: ↑

09 Nov 2022 16:34

Other items you might want to include are any custom Fact Definitions you have created, or any Source Template Definitions.

Thanks for the comments. I use a lot of custom Fact Definitions and Source Template Definitions in my Projects. I thought that all of these that have been added to a Project will get included in a Full Backup of that Project. Is that not the case? If it is not, how do I include them? If they are not in the Full Backup, then a crash of my own system followed by a restore would not include these custom Definitions. That feels like a major problem. Can you elaborate a little more? Thanks.

Gowermick wrote: ↑

09 Nov 2022 16:50

There is no such setting for Places. You can freely mix 6 part with 3 part etc, in the same project, with no problem.
The reason most of us stick to ’x’ parts, is to make it easier to work with the places data, allowing an easy way to sort/filter our places.

Your feedback is appreciated. I use 6 part Places with nothing in the Address field. The address information is entered in the first 2 parts of the Place. I do this so that I can specify GPS locations of individual buildings and grave sites within a cemetery. AFAIK the Address Field can not be assigned GPS coordinates, so that level of detail has to be part of the Place. Does this sound correct to you?

Mark1834 wrote: ↑

09 Nov 2022 17:21

You will also need to consider how you "send" it to your relative. A full zip backup of your project folder and custom settings backup could be an extremely large file that is too big to send as an e-mail attachment. If that is the case, and you want your relative to have a full copy, you may have to explore sharing via cloud storage.

Thanks, and your point is well-taken. I plan to use OneDrive for transferring the data. My Project's Full Backup is 2.2GB. My OneDrive account offers 1TB of storage. It also allows for private file sharing. Both my relative and I have fiberoptic connections with fast up and down speeds.

This recent thread is highly recommended reading for settings backups.

It is a common misunderstanding that Project Full Backups save everything you need but they do not save settings.
That is why I advised the FHUG KB Family Historian Copy and Migration Guide which explains Copying Program Settings.
See also Backup and Recovery that explains what is backed up.
You are correct that a PC/Disk crash would jeopardise your custom settings of Fact Definitions, etc, unless you use one of the Backup and Restore Family Historian Settings plugins. It is a flaw in the FH design that is not made clear to users.

tatewise and Mark1834,

After reading your comments, I realized that back when I originally installed FH7 I also installed the plugin, "Backup and Restore Family Historian Settings via Windows". Somewhere along the way I forgot that running this plugin had to be part of the backup process. I had incorrectly reverted to backing up only the Project data. I just corrected that error and ran the Plugin.

I like FH7 a lot but this backup process seems cumbersome and prone to user error. It's confusing to have separate procedures for backing up settings and backing up Project data. Anyway, I know that forgetting this was my fault but it would be nice to have a fix for this problem on a wish list of needed features (if such a list exists.) Thanks for the feedback that put me back on the right path again for doing my backups.

There is a Wish List entry Ref 118 Backup and or archive custom reports, queries and text schemes.
However, it was closed when the Plugin was written.

Also, see the New Wish List Requests Forum that feeds the Wish List.

A complication is that those FH settings apply to all Projects. When a Project Backup is performed the FH settings would have to go into a separate backup file, such that it always holds the latest settings and can be restored independently.
A snag would be the user must perform a Project Backup to backup the settings, so a separate Backup command for settings would be better, which is not so different from having a Plugin to do the job.

Nevertheless, the FH Help pages on Project Backups should make it clearer what is backed up and what is not, so users are aware of the custom settings being omitted.

You would have gathered by now that there are two overlapping plugins for backing up and restoring settings. They both do essentially the same job, but have different interfaces and detailed features. One advantage of the newer Windows-based plugin is that it can be set up to run automatically in the background on a predetermined schedule, or from a simple desktop shortcut. It needs a little basic knowledge of Windows batch files, but the plugin help points you in the right direction.

Mark1834 and tatewise,

Can I get a final clarification about my original question of how to send a copy of my Project file to a relative who is a new FH7 user. I now understand that I have to send two things: 1) The Full Backup Data File for the Project, and 2) the folder/subfolders that I've created by running the "Backup and Restore Family Historian Settings via Windows" plugin. I guess I'll have to zip the settings folder structure in order to send it. My new-to-FH7 relative will have to install the plugin, unzip the settings folder/subfolders to the correct location and then restore the FH7 Settings and Project files. This seems like it might be overwhelming for a computer novice who is also brand new to FH7. I'm concerned that my relative may find this so confusing that they lose interest in helping with our family history. BTW, is my use of 6 part Places included in the settings files produced by the plugin or does my relative have to make this setting manually.?

You may be able to get away initially with just the 1) Project Backup file.
You will have to explain how to use the File > Backup/Restore > Restore Backup... command.
Your relative should be able to navigate through all your Project data without any major problems.

Tip: If custom Facts Sets are important then consider making them local Project Fact Sets.
Then they are included in the Project Backup and won't affect your relative's other Projects.
You may need to re-organise your Fact Sets to achieve this.

It is difficult to say how important your customisations are to your relative without knowing all the details.
Just warn them that some features may need customising for you both to achieve the same experience.
When that happens your relative will have become more comfortable with FH.
You then have two methods of synchronising your customisations:

1. Use the File > Import/Export options, where you Export, and your relative Imports, a specific customisation file.
   That will work for the most likely customisations such as Report Types, Queries, Fact Sets, etc.
   The Tools > Work with Data > Places... Columns... and similar simple settings you can explain over the phone.
2. Use the 2) Backup and Restore Family Historian Settings for Windows plugin and files.
   That will include the Places... Columns... setting providing that the Windows Registry Data is restored.

Just remind your relative that most such customisations affect all Projects

There's another option that might be worth thinking about. If your FH project folder is in OneDrive, and you grant another person read-only access to that folder, they will always see your up-to-date project, without having to faff about with backups, zips and copies.

It would also be possible to set it up so that the main settings (queries, plugins, fact sets, custom reports and charts etc) are shared and updated automatically as well. However, that takes a fair level of PC expertise to set up directory junction shares, and is more complex than just defining a project folder.

I don't recall ever seeing that setup discussed on the forum, but I can't see any reason why it shouldn't work. I've partly simulated it by creating a copy of my main project, remapping all the media to the local project folder, and copying just the project and GEDCOM files and media folder to a mastered DVD. This ensures all the project data are pure read-only, and FH runs just fine. FH is not designed to operate with two copies of the program writing to the same project at the same time (say on a local network share), but if one of those copies is read-only (the OneDrive share), it should be fine, so one person can read the data even while somebody else is updating it.

Any gotchas that I've missed? It could be an interesting option for sharing FH data on a read-only basis. In principle, it could work read/write as well, but you would have to ensure that only one user has the file open at a time, which would be difficult in different locations.

Mark, have you never seen Synchronizing Family Historian Settings Using Directory Junctions that has been discussed before.

I can see that a Project on a DVD might work, but not so sure about read-only OneDrive.
What happens with the FH Autosave if the user happens to change something even by accident?
I've also noticed that running a Query causes FH to think the Project needs to be saved.

Think I do recall seeing it before - I wrote it .

My caveat over directory junctions was not that I don't think it will work, but is more complex to set up than just selecting a project folder.

FH does seem robust to a read-only project folder, as it just gives a polite message to say that the GEDCOM is read-only if you try to save it, and similarly, auto save produces an error message, but this is easily dismissed.

Just to be clear - I'm not suggesting using a DVD as the transfer medium - it is just a surrogate to test how FH works with a relatively slow read-only project folder. I'm now testing it with the project copied to a read-only NAS share accessed over Wi-Fi from my old laptop (while also being opened on my desktop), and it seems stable.

I'm getting more confident that this could work well if somebody wants to try it for real...

Added in edit - one minor issue noted - plugins that write to the project folder may fail with an un-trapped error, as it is not normally necessary to check that the folder is writable.