Is it possible to split out an ancestor line and create a separated data base. For example: Could I split my daughter*in laws ancestery to a new file just for her?
While you have open the database with your DIL’s ancestor line in it, bring up a view with her showing… Then, use the File menu to create a newly named, fresh, empty data base and drag her with your mouse pointer onto the window for the new database. RootsMagic will prompt you for who to include and then copy those individuals over.
When you do this kind of operation, you do not have to mark each of your DIL’s ancestors one at a time. There are options that allow you to mark your DIL and all her ancestors all in one go.
Thaks that was just what I was looking for.
I also did this and the split worked fine, but none of my defined Groups in the original database came over:( Any ideas on how to fix this?
That’s not the way groups work. They don’t come over in a Drag and Drop operation. You will need to redefine them in the new database.
The only way I can think of is to operate on the database with sqlite directly, not through the RM app.
Well one ~could~ Backup the original database, then Restore it to a different database filename or use Windows filesystem Copy to effect the same, THEN do the unlinking within the resultant copy and just ignore that the other family line(s) are still there (deleting the unwanted people from other line/lines would be tedious in large databases).
I have long wished that RM had a capability to split a line out of a database that would work something like the following.
- You as the user would make a group of people you wish to split out.
- You would issue a SPLIT OUT command of some kind.
- RM would respond by making a copy of your database and in that copy of the database RM would delete all the individuals who were not in the group. Any residual groups, color coding, unused places, unused sources, and the like would still be there in the new database.
- The original database would remain untouched and intact.
Bulk operations can be very dangerous. For example, I would not support a DELETE EVERYBODY NOT IN THIS GROUP command as a standalone command. But it seems to me that doing the SPLIT OUT operation only in a copy of your database which RM itself has just made would be extremely safe. The same process can be done using SQLite and Tom has created such a procedure. But the process should be available to all users, not just to users with SQLite skills.
The procedure I just described could be used twice to split a database between a husband’s family and a wife’s family, for example. The result would be three databases - the original database, the husband’s family database, and the wife’s family database. I wouldn’t recommend doing so because inevitably you would want to put the husband’s family database and the wife’s family database back together which might not be very easy. But the process I described should be safe and it shouldn’t lose data the way a Drag and Drop loses data.
Thanks – so for me it really doesn’t pay to split my database into maternal and paternal. The reason I was doing this was because I was trying to create a familytree in Ancestry that I could sync with. However, it appears that my db is too large and even after 6 hours of uploading (with multiple “time outs”) it failed on the 2nd step . . . Don’t really know how to remedy this.
I’m sure that you’re right, but I guess that I’m going to leave it as is in one large db, rather than two separate - maternal and paternal.
Color coding will survive a drag n drop. You can color-code a group and also create a group from color-coding. It will help in a drag n drop where groups are not preserved. It at least can help with recreating it. If a person is in more than one group they will only show in the one last color-coded in. You would need to manually add them to the other groups.
My wish has now been overtaken by the ability in RM9 to do a bulk delete of a group. The new feature appears not to include the safety features I was suggesting, but appears that you can certainly achieve the same safety as a manual operation. Namely, a copy of your RM database - not a drag and drop but a real copy.Do your bulk delete of the group in the new copy of your database. And start using the new copy as your production database while keeping the old copy of your database around for archival purposes.