* Copying Source Records to a New Project

[E Wilcock]

Maybe someone has already mentioned this. I apologise if so. But this work round was something I failed to find when considering a move to FH.

I keep multiple Projects. In UK genealogy one is repeatedly using the same sources for censuses, births, marriages, deaths etc.

One of my regrets was the FH did not apparently allow one to copy sources from one project to another.

I seemed to remember that in TMG one was able to save labour by retaining the sources one had already entered and moving them to a new Project. This was done by copying or merging an existing project, empty of individuals, but retaining the sources. This may not be exact, as it is a long time since I did it and this is an FH Forum.

Experimenting in FH today, I have discovered that it is possible to copy existing source records to a new FH Project. Copy a FH project, rename it and then delete everyone in it. I left in a couple of token individuals for fear it might wreck the enterprise if I removed everyone. But it looks as if you can keep as many of the sources and also places as you choose.

[tatewise]

I have moved this to the FH General Usage Forum, because the Importing and Exporting Forum is, as it says, for "Importing from or exporting to another genealogy program."

The thread Sources and Citations (14222) does touch on the subject and refers to how_to:exporting_gedcom_with_multimedia|> Exporting a Family Tree with Multimedia that discusses a similar process for retaining Media records. It focusses on the File > Import/Export > Export > GEDCOM File command.

However, it begs the question why, because if there is so much commonality of Sources and Places then you should seriously consider having one merged Project. Otherwise, every time a Source or Place is updated it may need to be copied to several Projects. It is usually far easier to manage one merged tree, and extract sub-trees as and when required, than try to manage a great many duplicated records in different Projects.

As is often the case, if you could explain your objectives, rather than your perceived solution, then there may be better options.

[LornaCraig]

I note that elsewhere you have said that "my personal family trees are still in TMG" and that you use genealogy software for historical research. If each project relates to a different area of research, and you want to share separate projects with different researchers, your approach is probably a sensible one. Keep a separate project with nothing in it except Source records and (perhaps) Place records, and make a copy of it to start each new project. But you will need to remember each time you create a new Source that you will need to add it to the 'dummy' project as well.

If at some point in the future you decide to move your personal trees to FH, do consider merging them into a single project. In that situation, as Mike says, managing one merged tree and extracting sub-trees when required is generally easier because the records relevant to different groups/branches of family members will often overlap.

[tatewise]

If each Project relates to a different area of research, and want to share separate Projects with different researchers, then it seems unlikely that many Source and Place records will be common to multiple Projects.

If there is much in common, then I still maintain that one Project is probably easier than many, and just export the sub-tree for each researcher.

[davidf]

The assumption behind the recommendation to merge all records into a single project is that everyone is potentially related or that you are willing to show people as related.

Sometimes you do a project that you expect to be completely separate. For instance, a while ago a number of WW1 soldiers' bodies were found (about 30 a year are found on the Western Front). In this case the bodies of these five soldiers (if I remember correctly) could have been those of any of 60 possible missing soldiers. A number of us undertook to research individual members of this group of 60 in the hope of helping the MOD in tracing living relations who might offer DNA samples to possibly allow identification of these bodies. I know that the man I researched was exceedingly unlikely to be related so keeping this as a separate project seemed logical and made later submission easier. This same consideration would apply to anyone who uses FH for third party research.

When facing a brick-wall it is sometimes worth doing a small one-name study (constrained by a date range and a geographical area) mainly to exclude a whole group from your own research. If I do find a line of relatives I will extract them and put them in my main personal family tree project. Otherwise I want a separate project of people who whilst they share a surname are as yet unrelated. You can always open two projects side by side if you suspect that you have a match. (Drag and drop between projects would then be very useful! I think there is some family history software that does this.)

In my family I also have a few "wrong side of the blanket" births and adoptions. In some cases, I may be the only person living who has disentangled both the birth and adopted family lines and accidental disclosure is probably not a good way for someone to realise that their relative was a philander! Separate projects are a good way to avoid accidental disclosure.

That said I would find it so useful if sources could be kept in a single linked database. (I use the system where I treat "1881 E&W Census" as a source - so "E&W Census 1881" should be treated as a duplicate)

[tatewise]

David, since your Method 2 style Source records such as E&W Census 1881 rarely change, you can get very close to a single linked database.

See the thread Plugin: Add Source From Template (14258) and try my adapted Add Source From Global Template Plugin. Once set up, the same Source records can easily be created and inserted into any Project.

The same strategy could be used for Repository and Place records, etc.
With a little development each 'Template' could be created from any existing Source record, so they can be propagated around, to provide a method of copying 'shared' records from Project to Project.

[davidf]

Mike,

Sorry, that last post makes so little sense to me (even after a week-end of pondering, experimenting and "cleaning up") that I do not know how to even ask for clarification - I must be in a different mind warp! The "guidance" on Add Source From Template for the original plug-in leaves me baffled (which again indicates that my understanding is way off-beam!)

I was sort of expecting this plug-in to offer me a pull down list of source records when I click Add Citation to a fact (or possibly only when I click "New Source" - but then what would be in the pull-down list?). Clearly I have to populate that pull-down list (which is what the second tab would seem to be for). If this is a manual operation it is clearly going to be a long operation.

Going forward that would then seem to offer a means of ensuring that sources had a consistent name (hence the idea of a template?!), assuming that:
- in each project you "cleaned up" the existing list of sources - presumably by merging templated sources with their non-templated equivalents (to be done with care - one careless slip and you have merged 1891 data with an 1881 source!). Deleting the sources from the project file and relying on the templated list appears to be catastrophic as I cannot see a way to maintain external links!
- you could get the plugin to offer the templated versions when adding sources and to avoid use of non-templated ones. However your comment "Once set up, the same Source records can easily be created and inserted into any Project." indicates that my mind has gone off in completely the wrong direction - I must have developed a very non-standard personal workflow!

Is your suggestion for a non-standard use of the plug-in and therefore more of a sort of work-around for what I was trying to do - get a "master-file" of source that would link into all projects? I can see from my experimentation that I have created some files (one per source) in C:\ProgramData\Calico Pie\Family Historian\Plugin Data\Add Source From Global Template.dat and that this is the beginning of a sort of master directory.

As is often the case, if you could explain your objectives, rather than your perceived solution, then there may be better options.

Ok, my objectives! By example:

When I am adding a census fact and I click on Add Citation - and the list of Source Records comes up, I want:

• that list to be a list that is common to all projects so that I have consistency of naming source records (1881 E&W Census, 1891 E&W Census etc.) - and also realise when a "new" source record may already be being used by another project (to prevent duplication - and possibly highlight the relevance of previous work)
• If I add a genuinely new source say "1921 E&W Census", I want that source record to be available to all projects

On many of my source records I hold research notes (such as "Copied this file when at TNA may 2006, stored in C:\...", "Searched for [name] October 2016 - 16 records found, stored in C:\...\parish records\LittleBunthorpe.xls") To have these records available across all projects would be rather useful.

(My perceived solution is a linked master-file!)

Ideally similar functionality would apply to other data - such as places and addresses (with the nifty auto-fill functionality). Ditto Occupations - although in FH occupations are not yet subject to the same standardisation process as places.

I somehow expect that this is an item for the version 10 wish-list!

[tatewise]

David,
This needs a short master-class on FH features and Plugins dealing with your points in reverse order.

Yes, to get completely automatic shared resources such as Source Records across all Projects will need a Wish List item and a great deal of luck.

Occupations are subject to the same standardisation as Places, Addresses, Source Types, etc.
They will auto-complete, and can be standardised via Tools > Work with Data > Occupations.

To add Census Events many users employ Ancestral Sources because that simplifies the process and ensures a consistent naming strategy across all Projects, not just for Source records but also for Media records and files. So Ancestral Sources is the shared resource that ensures identical Method 2 Source Records get added to every Project, but only when required.

Plugins cannot fundamentally alter any of the FH dialogues, so cannot change the Add Citation dialogue.
Plugins can change files that FH uses, so for example they can add or modify a Fact Set file so that Tools > Fact Types will list different Facts and the Edit button will show different values, but the boxes built in to the dialogues cannot change.

An example of that is the C:\ProgramData\Calico Pie\Family Historian\Plugin Data\Add Source From Global Template.dat folder you discovered, which holds the shared set of Sources across all Projects, in the same way that all other customisations in the C:\ProgramData\Calico Pie\Family Historian\ folder are shared by all Projects.
That shared set is what the Add Source From Global Template Plugin refers to as Templates as explained later.
The Plugin allows a Source Record to be added to a Project derived from a Template.
So, if that is repeated for every Template in every Project, they will all have the same Source Records.
Then the Add Citation button will always have the same choice of Source Records.

When a new Source Record is required, start with the Plugin and create a new Template.
Then add a Source Record derived from that Template to every Project, and your 'shared' Source Record objective is almost fulfilled. The unfulfilled aspect, is if you want to change an existing Template and Source Records, then currently all the copies will have to be changed. BUT the Plugin could be improved to have an Update as well as an Add button to make such changes semi-automatic, and possible apply them across any chosen set of Projects.

Why are they called Templates?
In your Method 2 style Source Records you have only one instance of each type of record with no variances.
But in Method 1 style Source Records per document some of the fields have identical values, but some have quite different values. The same Template can be used to add such records and prompt the user for the variant values required by using the {Note} style feature. Thus a whole series of similar Source Records can be derived from one Template.