Splitting databases and then combining them after changes

My tree is need of a great deal of “fixing” after a lot of years of neglect. I have been plugging away trying to remedy the situation but of course it is a time consuming task.

It occurred to be that it might make sense to split the tree along the lines of my family in one tree and my wife’s family in another then we could concentrate on working on our own ancestors of which hopefully we have more knowledge. Then after a suitable time of “fixing” we could combine them back upload them and repeat the process.

So I copied my .rmtree file into a new location and renamed in Windows so that there was no danger of a mix up with the original trees, (I have multiple copies of the original tree(s) and I back up regularly). I then created two empty .rmtree files one using my last name and one using my wife’s maiden name. I then dragged and dropped using firstly myself and then my wife as the starting point and used Ancestors and their descendants selection. I set the generations to 25 for both.

This created 2 new trees where the only common people, at least at first glance is myself, my wife and our descendants.

I have not as yet tried any editing and combining as I wanted to seek advice as to whether my initial steps as described above are the correct methodology? By doing as described above am I losing any of the data (sources, citations, media, links etc etc) that existed in the original tree.

Also I am unsure as to what the best way of combining the trees are. Do I create a further blank tree and drag and drop say my tree first and then from my wife’s tree, use her as the base and drag and drop her into to the new tree and confirm that they are the same person and chose Ancestors and their descendants?

Or indeed are there too many risks and pitfalls in the above method and is there a better way of achieving this, even if it is just plugging away with just myself doing the fixing?

Grateful for any thoughts and advice.

Regards

Michael

There can be valid reasons to split trees as you describe. But for most users most of the time, you are far better off leaving everything together in one database.

I totally understand the need and desire to break your cleanup project into smaller and more manageable pieces. But this can be managed instead by color coding or making groups. For example, you could color code your people one color and your wife’s people another color. Or you could make a group of your people and a group or your wife’s people. Then you could work only in one color for a while or only in one group for a while.

I’m sure that others with chime in for reasons to keep your tree all together. One reason is that the drag and drop operation can lose data. Another reason is that you might discover at some point that you and your wife have people in common in your trees - probably not ancestors but possibly individuals who have married into both families or possibly distant cousins. Another reason is keeping consistent place lists and source lists and that sort of thing. Another reason is putting the databases back together can be a fairly onerous operation, and doing so can do things like create duplicate source templates, duplicate sources, duplicate places, etc.

Here is a link to an article about that that can be lost by drag and drop operations. Drag and Drop Transfer Losses

A few years ago I separated my family lines into 6 separate RM7 files. At the time, I created separate db copies, then created groups for each line, and then deleted the unwanted lines ending with a single family line remaining in each file. Over the years I’ve used GEDCOM to transfer data between files. As described in the “Drag and Drop Transfer Loss” on the SQLite page, an unacceptable amount of data has been lost. Most notable has been data related to non-principal roles, source template formats, family fact sharing data, detailed notes and much more. Many of my formatted source records are now in “free form” format due to GEDCOM transfers. SO Michael, my advice for you is to stay with separate family line data files at this point. Keeping all of one’s family lines in one database has lots of advantages but my original family file just got to large to effectively manage. So, I’ve continued with separate family line databases.

Thank you both for the replies. I think on reflection I will leave all of the data in just one tree. This is mainly because of the potential for data loss. I did experiment with having the same test database open on 2 PCs at the same time across our network. Although it would open and be visible on both PCs any changes that were made were not reflected on the other PC and after closing RM8 on one PC when the 2nd one was closed it overwrote the newly saved file from the 1st PC (if that makes sense). No real surprise but I thought it worth a try.