Copying/dragging records across database files

RootsMagic
,
1

I need to be able to identify the records copied from my staging database and my main database files so I can isolate and readily identify them at a later time.

Currently the only way I can see of doing this is by colour coding the records before copying as the colours are retained during the copying process but that colours cannot be assigned a tag and therefore colour usage needs to be remembered or noted external to RM.

My preferred option is to use groups but unfortunately they do not transfer during the copying process.

Also, how can you delete an entire tree. May main database file is more akin to a one name study and contains many trees.

Does anyone have any suggestions?
Dennis

2

Within the RM UI, you can do these things manually but requires a lot of one person at a time operations. For example, you could add a fact such as Reference Number or a custom one to the colour-coded set of people prior to transfer and create a group after transfer using that fact as the criterion. Likewise, for deletion of a tree, it is quick to group everyone in the same tree but then you delete one by one.

Bulk operations of the sort you desire can be performed with SQLite scripts operating on your database. See
sqlitetoolsforrootsmagic.com

3

RM does not do very many bulk operations. For example, it does not support bulk delete. That one is by deliberate design to help save users from themselves when they might do an excessive bulk delete by accident without having a backup.

There are useful and non-dangerous bulk operations RM8 does not support. It does not support bulk adding a fact to a group of people. It does not support bulk adding a source to a group of people. RM7 did support bulk adding a source via the Multi-cite feature, but I haven’t yet found Multi-cite in RM8. It’s not on the list RM7 features that are not included in RM8, but I haven’t found it so far.

The most useful bulk features that RM8 does support are color coding and groups. I love both features, but I think they are both severely limited by being too fragile. Groups do not transfer, even from RM8 to RM8. And groups are not searchable. For example, it’s not possible to do a search for all the people in a group who were not enumerated in the 1910 census. Color coding does transfer from RM8 to RM8. But it is severely limited by the fact that each person can only have one color. Color coding some people blue and some other people red my turn some blue people red, and no, they won’t be turned purple in the process.

What’s really needed is some sort of flag or dummy fact or something like that for each person that can be added in bulk and that is not fragile. The only thing I can think of right now that meets that criterion is dummy sources. Even though RM8 does not support Multi-cite, you can achieve the exact same effect via GEDCOM. Do realize that when you are dragging and dropping between your databases, you are really exporting a GEDCOM from one of the databases and importing the same GEDCOM into the other. So this isn’t such a radical idea.

So instead of dragging and dropping, export a GEDCOM of the exact same people you would have dragged. Then import the same GEDCOM into a second database. As a part of the GEDCOM import, you can add the same source to each person being imported. This will have the effect of providing a permanent record of those people and where they came from. The dummy source needs to have a name that’s meaningful to you. It will be fully searchable. You will be able to color code based on it or make groups based on it etc. If you merge an individual who was imported twice in this fashion, both of the sources will still be there at the same time. It’s not like merging a blue person and a red person and expecting them still to be both blue and red.

The only downside I can see from this scheme is that these dummy sources will appear as citations in reports. There is no way to make a particular source private or to keep it out of reports. It’s clumsy, but you could always make a copy of your database before running reports via File => Tools => Copy. Then before you run your reports, you can delete the dummy source or sources from the copy. This delete will effectively be a bulk delete of the source which is instantaneous. If it were me, I would then delete the copy of the reporting database and recreate it the next time I needed to run a report. That way, my report would be based on the most recent available evidence.

I know that’s a pretty complicated and convoluted sounding procedure. But I think that’s really the only thing that will work for your use case, short of doing bulk operations with SQLite.

4

Wow! I had thought that the drag n drop was a native copy of RM records between two RM files instead of a GEDCOM copy of selected records. That presents the possibility of data loss during a drag n drop operation. I have a excessive number of free-form citations due to past GEDCOM imports.

5

For a comprehensive list of GEDCOM losses:
https://sqlitetoolsforrootsmagic.com/gedcom-dnd-transfer-losses/

6

Thanks to all.
From analysing the feedback received I found that creating a custom fact in my target database with only the description field set and all ‘Include when’ options unchecked and the same construct in my staging database but with ‘Include when … Exporting Gedcom files’ checked works a treat for my purpose and does not impact on reporting. From there, records can be grouped based on the fact value.

It is a pity though that there is no bulk delete for a given criteria option. From experience it is far riskier in stuffing things up running SQL scripts than having built-in functionality with a confirmation dialog.

7

In either case, you would want to be able to fall back to the state prior to the bulk operation. The risks can be managed with appropriate precautions.