Jump to content


Photo

Improved method for Copying Events

Copy Events

  • Please log in to reply
11 replies to this topic

#1 Rick Landrum

Rick Landrum

    Advanced Member

  • Members
  • PipPipPip
  • 409 posts

Posted 05 December 2019 - 09:31 AM

Looking for a short cut -
 
For reasons previously discussed at length in this forum, I do not use shared events. However, since you can not copy and paste an event in RM from one tree member to another, I have been using this technique:
 
Share the event with the person to be copied to, go to that person and create a new event of the same type. Copy and paste data from the shared event to new event field by field. Also memorize and paste sources, and tag media to the new person. Next unshare the "copy to" person for the event from the "copy from" person.
 
This works, but takes for-e-v-e-r, especially if copying say a census record from the father to the wife and to each of the children. Many families have many children.
 
I am searching for a "short cut" process to accomplish this.
Any suggestions??
Thanks
Rick

RickL


#2 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6283 posts

Posted 05 December 2019 - 01:36 PM

I developed a SQLite script to copy an event to a group, if that's of any interest.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#3 Rick Landrum

Rick Landrum

    Advanced Member

  • Members
  • PipPipPip
  • 409 posts

Posted 05 December 2019 - 04:12 PM

Tom,

I was aware of that, but mostly my need revolves around a family unit and not a group per se. I could add them all to a group and then use the script to update them but that sort of seems like "six of one or a half dozen of the other".  :rolleyes:

 

I had also thought of placing a note with the Head's census record referring to the other family members. However, that gets messy when others review the info unless they have the complete tree. However, something like that may be the best option, short of using the process I previously described, at least until an "event copy" functionality is available.

Thanks

Rick


RickL


#4 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6283 posts

Posted 05 December 2019 - 04:47 PM

Yes, it's not a real simple procedure and the advantage grows with the size of the family covered by the census. You'd have to do a click count on each method to compare.

 

One bit of streamlining I would do would be to create a group to be edited and used over and over again with different families so that the GroupID remains constant in the script. Or have the script look up a group name that is consistent from family to family, even though it has a different GroupID. That would save repeatedly looking at tables in the database to get the GroupID.

 

Another would be to have the script copy the last Event in the EventTable to the group, on the premise that it is run immediately after you have created the Census event for the Head of Household and before any other events.That saves having to look at the database tables to identify the EventID that is the master.

 

That said, have we not already discussed my other technique? Use RM's shared events functions and then run my script to convert the shares into standard events? That should be the most efficient approach.


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#5 Rick Landrum

Rick Landrum

    Advanced Member

  • Members
  • PipPipPip
  • 409 posts

Posted 06 December 2019 - 07:42 AM

 

That said, have we not already discussed my other technique? Use RM's shared events functions and then run my script to convert the shares into standard events? That should be the most efficient approach.

Tom,

Actually, I did not think of that approach. I have sucessfully used this script before, so that would work.

Thanks for the help.

Rick


RickL


#6 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6283 posts

Posted 06 December 2019 - 08:01 AM

However, watch out for RM8 to break the script. The preview video shows that there is an enhancement to 'share' citations. That will necessitate a change in the database structure and I would expect there to be potential consequences to all of my scripts that work with the CitationTable.


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#7 Rick Landrum

Rick Landrum

    Advanced Member

  • Members
  • PipPipPip
  • 409 posts

Posted 07 December 2019 - 08:05 AM

However, watch out for RM8 to break the script. The preview video shows that there is an enhancement to 'share' citations. That will necessitate a change in the database structure and I would expect there to be potential consequences to all of my scripts that work with the CitationTable.

Got it.

Wonder if R8 will have anything new on the "copy events" front......similar to share but just straight memorize and paste??

Rick


RickL


#8 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3663 posts

Posted 07 December 2019 - 08:46 AM

Wonder if R8 will have anything new on the "copy events" front......similar to share but just straight memorize and paste??

 

There is no way to know until RM8 is released or until more information is previewed prior to the release.

 

I think a "copy events" is very much needed, but equally I would like to see improvements in the way shared facts are supported. In particular, there might be times when shared facts would be better than "copy events" if only shared facts would act more like real facts after they are shared. Both improvements are needed, and neither improvement should be viewed as obviating the need for the other.

 

While really needed, "copy events" would have sort of the same issue RM has with groups being static instead of dynamic and the same issue RM has with citations being static instead of dynamic after they are memorized and pasted. It appears from the preview that RM8 includes a "shared citation" facility (although I don't know if that is what it will be called). That will make citations dynamic so that a correction to a "shared citation" will need to be made only once and all the places it is "shared" will inherit the correction. I would picture "copy events" as being static. Once copied, the copy of the fact and the original would be independent of each other and making a correction to one would not affect the other.

 

On the other hand, the existing shared fact facility can be either static or dynamic. Shared facts are mostly dynamic. For example, you can change the date or place or citations and the changes will instantly apply as well to all instances where the fact is shared. But you can customize the note. If you do so, the note effectively becomes static. The static/dynamic terminology is not used in RM's help files or tutorials about shared facts, but I think that's effectively what individual customization of notes or not allows you to do. Another weakness of shared facts in my view is that you really don't share a fact. You only share a role that is subordinate to the fact. I think it would be very helpful sometimes really to be able to share the original fact without referring to a role that is being shared.

 

And I think there is an odd problem in the user interface for shared facts that needs to be fixed and which should be trivial to fix. Suppose you have person's X and Y and suppose person X has a fact A which has a role B and role B is shared with person Y. In the Edit Person screen for person B, the shared fact shows up as fact A rather than as role B. For example, if you share a birth fact for a person with the midwife who attended the birth with the role of Midwife, the fact shows up in the Edit Person screen for the midwife as Birth rather than as Midwife. I find that behavior of the user interface to be very counter intuitive and very confusing. I wish it would be fixed in RM8.

 

Jerry



#9 Rick Landrum

Rick Landrum

    Advanced Member

  • Members
  • PipPipPip
  • 409 posts

Posted 13 December 2019 - 09:10 AM

Jerry and Tom,

After some days reflection on your responses to my question, I have decided how I am going to proceed as follows.
 
First, a couple of points.
1) I use RootsMagic as my primary genealogy platform. I use Ancestry primarily, but extensively, as a research source. My reluctance to use event/fact sharing was because I could not transfer shared events/facts through TreeShare to sync with my Ancestry tree.  Actually my goal should have been to make my RM tree as complete and accurate as possible, instead of trying to make my two trees the exact same.
2) We do not know what or how RM8 is going to contain as far as event/fact memorizarion and pasting, or how TreeShare will be changed.
 
As a result, I have decided to use the following process, (at least for shared census records):
 
1) Complete the census citation (with notes, sources, and media, for the "head of the family", usually the father.
2) Use the RM Share tool to share this event/fact with members of the census family (very fast and efficient). (Use sharing roles: head, wife, census family member, etc).
The shared census record (with notes, source, and media) will appear in each RM shared person's edit person (profile) screen, and works fine for reports, etc.
3) Post a general "person" note in RM for all census family members, except the "head". This will transfer to Ancestry.
example - [Note: There are shared census records for this person in RootsMagic which can not be synchronized with Ancestry.com through TreeShare - Ancestry readers refer to the head of the family for original census event details].
4) Use TreeShare to maintain the fact/event on my Ancestry tree (recognizing that the census record will only be updated for the "head"). Other census family members will only have the shared census note posted to Ancestry, but RM will reflect the event. Ancestry readers can reference the complete census details by reviewing the census head person's record.
 
Running Tom's SQLite script later, to convert shared events to regular events, remails a future option if  RM8 does not break that script. However, it seems unnecessary if one accepts the above approach regarding Ancestry with the census details being available in the head persons record.
 
This seems to be the only viable process for me, at least until we know what RM8 will offer.
 
Thanks for the the feedback.
Rick 

RickL


#10 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3663 posts

Posted 13 December 2019 - 09:43 AM

 

3) Post a general "person" note in RM for all census family members, except the "head". This will transfer to Ancestry.

 

As you point out, shared facts cannot be transferred to ancestry at all. RM's fact notes can actually be transferred to ancestry, but it's in a way that I find not to be very helpful. The problem is not in RM or TreeShare at all. Rather, the problem is that ancestry does not support fact notes in its data model. TreeShare makes a brave effort to work around this problem by storing RM's fact notes as funny kind of sources in ancestry. So the data is not lost, but it is not stored in a very helpful place. This is surely the reason you chose to store your census notes in RM's general person note. It's not an ideal solution, but it's probably the least bad solution available to you.

In deciding how to use RM, one of my most important considerations is how the data will transfer to other genealogy software. I really like fact notes and I use them extensively. My experience is that they usually transfer quite well to other desktop genealogy software. But sometimes they don't transfer very well to online genealogy software such as ancestry. Notwithstanding this problem, I will continue to use fact notes.

 

My most, most important consideration in using RM is how data will appear in narrative reports. I don't think research is of much value until and unless it can be presented in a reasonable fashion. That's why I will continue to use fact notes even though ancestry doesn't support them (and because most desktop genealogy software does).

 

Jerry



#11 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3438 posts

Posted 13 December 2019 - 01:01 PM

In deciding how to use RM, one of my most important considerations is how the data will transfer to other genealogy software.

 

I can confirm Shared Events do transfer well to the software I am currently using, in fact most RM items do and quite good reporting options. I am always wary of adapting the way I record data based on restrictions of other conduits like Ancestry and that concern also exists within RM. It's disappointing we are just not free to enter data as it should be entered including witness events, having said that the software I am using has avoided direct Ancestry interaction, no bad thing really.


Customers should never be frustrated by things they cannot do.

 

User of Family Historian 6.2.7, Rootsmagic 7.6.2, Family Tree Maker 2014 & Legacy 7.5

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#12 Rick Landrum

Rick Landrum

    Advanced Member

  • Members
  • PipPipPip
  • 409 posts

Posted 13 December 2019 - 04:23 PM

 TreeShare makes a brave effort to work around this problem by storing RM's fact notes as funny kind of sources in ancestry. So the data is not lost, but it is not stored in a very helpful place. This is surely the reason you chose to store your census notes in RM's general person note. It's not an ideal solution, but it's probably the least bad solution available to you.

Jerry,

Yes, that is why I choose the "general person note" as a place for the comment about referring to the head of the family census record for details. I had considered placing that note in the Ancestry "Comments", which would work, but then I would have added another set of steps to have to go to Ancestry and paste in the note. The only reason I'm even concerned about that is because I have several members of my family who use Ancestry.

Thanks

Rick


RickL