Jump to content


Photo

FTM & RM 7.0.10.0


  • Please log in to reply
65 replies to this topic

#21 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3482 posts

Posted 31 December 2015 - 11:55 PM

 

FTM had a nice interface for setting a fact to private (think global search/replace) or making it Private automatically (think as a default setting) when you add a new fact/event of that type (i.e. SSN) to that person.

 

 

RM has no user interface to set all facts of a particular type to private.

 

This would be trivial to do with SQLite - maybe just a couple of statements. I just checked RMTrix to see if anything there would do the trick, and I didn't see anything. I haven't checked Tom's SQLite Wiki to see if he already has something there or not.

 

Be aware that if you decide to go with the SQLite route, you will have to rerun the SQLite query periodically to be sure any newly added SSN facts are set properly. There are lots of things in RM that RM users describe as "static" rather than as "dynamic". For example, if you color code all descendants of John Doe as red and then add a new descendant of John Doe, the new descendant will not be color coded as red until you color code all descendants of John Doe as red again. Running an SQLite query to set all SSN facts as private would be no different. Such settings would be "static". I emphasize this point because you describe FTM has having the ability to set all SSN facts as private for all present SSN facts and for all future SSN facts.

 

Jerry



#22 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 01 January 2016 - 08:08 AM

Media can't be marked as Private in RootsMagic so even if FTM exported that designation, RM would have no place to put it.

I never link private media or private facts or notes about people or sources that is important to not share with anyone else in a database I am going to share for two reasons.

I may accidently forget to exclude a fact or private facts or private notes from a report or gedcom. I can't mark media or sources as private in RM.

The program the gedcom will be imported into may not recognize the private designations on import.even if theu were exported in a gedcom.

If I must keep highly private data, I enter it into a separate database that I never share.

FTM users might consider removing highly private data from their main database and entering it into a new database which they will not ever share as part of their cleannup in FTM before they import the main database into RM or any other program especially since FTM isn't exporting the privacy designations.

#23 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 01 January 2016 - 08:30 AM

I'm still finding some problems like those explained by riegelstamm, is this RM's final effort to help?


Thst is up to Bruce Buzbee.

Renee has stated on another thread that no changes will be made in RM at this time if it requires a change in RM's database structure.

Bruce is doing a complete rewrite of RM so it will work on either Windows or Mac so I doubt he will be making any database structures changes for any reason to RM 7.

If he can make further corrections to the import of FTM gedcoms without changing RM's database structure, he might do that.

#24 pjm68

pjm68

    New Member

  • Members
  • Pip
  • 4 posts

Posted 01 January 2016 - 08:38 AM

Hi Laura, is Bruce the only person developing RM?



#25 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6174 posts

Posted 01 January 2016 - 08:59 AM

We don't really know. Sometimes it seems that way but there does appear to be involvement by Michael Booth and Bruce's son. There may be others we have not heard about.

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.


#26 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3482 posts

Posted 01 January 2016 - 09:04 AM

RM is a small privately held company. They never say exactly how many developers they have. For the main RM product, the only two developers they ever talk about are Bruce Buzbee and Michael Booth. Some of the work on the mobile app (maybe all the work?) was done by Bruce's son Jason.  When RM4 first came out, I think it was mentioned that one of their power users had been the one who developed the source templates (not the computer code for the source templates, but rather the actual source templates themselves that implement the Evidence Explained standards). I have never seen discussed whether they have other developers as regular employees or as part-timers or as contract workers or whatever. They might or they might not.

 

I think most genealogical software is developed and marketed by very small companies very much like RM. FTM and ancestry.com might have been an exception, but FTM was first developed by a small company and later purchased by ancestry.com.

 

Jerry

 



#27 tschlarm

tschlarm

    Advanced Member

  • Members
  • PipPipPip
  • 31 posts

Posted 01 January 2016 - 11:23 AM

 

Concerning private info, there's no way to indicate this in the GEDCOM standard. The main purpose of the boxes in FTM is so that FTM can privatize info before you export it to GEDCOM. I believe some apps use curly brackets in the GEDCOM to mark private data, but that's not standard. About all you could do is include the word "private" in the fact note for each fact that is private, or something like that, but there's no easy way to find or filter private info that I can think of.

No, nothing in the standard, but we all know about the standard's limitations. It's good the authors had the foresight to allow vendor defined tags. Unfortunately, it's also the most widely adopted transfer mechanism we have at this point, since the other attempts at newer standards didn't really find any adoption by anything other than a few open source programs. That's the most likely reason for FTM's liberal use of the vendor specific _* tags like _PRIV that FTM already uses for media marked private in some variations of their gedcom export. 

 

I'm not sure I'd go out on a limb and say:

"The main purpose of the boxes in FTM is so that FTM can privatize info before you export it to GEDCOM"

It looks like FTM and RM7 utilize this setting much the same way. It provides users a way of hiding certain information in general program output. So not only is it optionally hidden in gedcom, but also optionally hidden in reports, books, website output, etc...

 

RM already has a corresponding private field for facts (though not for media as you've pointed out). Unfortunately, we'd need cooperation from FTM to export the _PRIV tag with their gedcom for facts and some help from RM to import it and apply it. I doubt we'll get the former, so the latter probably won't be needed, but it's great to see RM being very responsive and helpful to its (possibly) new user base.

 

My message was just to let people know who may have used the Private checkbox on facts in FTM (like me occasionally and now I'm glad I didn't make extensive use of it), that those facts will get published in their output should they publish/print/export any of their data from RM7. No fault of RM's, FTM is not providing any knowledge of the setting in the gedcom.

 

Unfortunately, after playing with FTM's reports there doesn't seem to be an easy way to determine who has private facts or what they are on each person. You pretty much have to know what facts you possibly made private (either as a default setting on a specific fact or by setting it individually on a fact) and then make the same changes in RM. The Custom report is as close as I can find at the moment, but I find I am still doing some visual comparisons. If I come up with a decent way, I'll post it. Happy New Year everyone!



#28 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 01 January 2016 - 12:56 PM

In RootsMagic 7 you can create a Fact list report to get a list of people that have facts marked as Private.

Choose Private fact from the Create a list dropdown menu.

On the People to Include menu, choose Everyone, Select from list to use search criteria or choose a Group.

Or, you can choose People with this fact type and choose a specific fact.

Check Print private facts.

This gives you a list of the people who have that fact marked private.[/quote]In RootsMagic 7 you can create a Fact list report to get a list of people that have facts marked as Private.

Choose Private fact from the Create a list dropdown menu.

On the People to Include menu, choose Everyone, Select from list to use search criteria or choose a Group.

Or, you can choose People with this fact type and choose a specific fact.

Check Print private facts.

This gives you a list of the people who have that fact marked private.

Uncheck that box for a list of people that don't have that fact marked Private.

It doesn't help FTM users right now, but, later it can help when tracking private facts.

#29 mel1beck

mel1beck

    New Member

  • Members
  • Pip
  • 1 posts

Posted 01 January 2016 - 06:59 PM

ya'll all sound so far above me in knowledge but I'm trying to learn.  I have already imported my FTM gedcom last month into my new RootsWeb and was waiting for my book to arrive before I tried any more "clean up"   Now I wonder if I should just go back to FTM and make a new gedcom and import (because of the 12/30 update to RM)   What do you suggest?

thanks



#30 gldaggett

gldaggett

    Member

  • Members
  • PipPip
  • 9 posts

Posted 01 January 2016 - 07:48 PM

Preferred facts

 

I am a long time user of Family Tree Maker and am investigating Roots Magic. I like what I see and have installed the free version, imported a ged from FTM to look at things. I have the latest version of RM and the import went surprisingly well. 

 

The first thing I notice is an issue with multiple facts coming over from FTM. In FTM I collected multiple data for a fact and would research and resolve those in the future. For instance Birth, Death, etc contain several dates with one of them marked as preferred. The preferred data would then print in reports and printouts. 

 

After import into RM, all the data is present in each fact but all print not just the preferred data. How is this handled in RM?

 

Thanks

Gary



#31 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3482 posts

Posted 01 January 2016 - 09:02 PM

After import into RM, all the data is present in each fact but all print not just the preferred data. How is this handled in RM?

 

RM doesn't have the concept of preferred data or preferred facts. The closest I think you could come in RM would be to mark all the facts that are not preferred as private keeping only the preferred fact as not private, and when you print a report do not enable the option to print private facts.

 

I tend to avoid duplicate facts of the same type in RM like the plague, and instead to include information about conflicting data in fact notes. Indeed, I've even gone so far as to avoid using the built-in census fact and to use a custom fact for each census year - "1850 Census" without the quotes for the 1850 census year, "1860 Census" without the quotes for the 1860 census year, etc. The reason is that certain parts of RM don't deal very gracefully with duplicate facts of the same type. I already said that I avoid duplicate birth facts and duplicate death facts etc. by using the fact note for conflicting data. But the census fact is inherently a duplicate fact if the same individual appears in multiple censuses. Examples of the parts of RM that don't deal very gracefully with duplicate facts of the same type include the following: People View (which is wonderful!!) will only show one instance of any duplicate fact; searches such as "census date equals 1850 AND census place includes Texas" frequently yield results that are technically correct but nevertheless are not very useful - for example,if someone was enumerated in 1850 in Tennessee and in 1860 in Texas.

 

Jerry



#32 tschlarm

tschlarm

    Advanced Member

  • Members
  • PipPipPip
  • 31 posts

Posted 01 January 2016 - 10:45 PM

ya'll all sound so far above me in knowledge but I'm trying to learn.  I have already imported my FTM gedcom last month into my new RootsWeb and was waiting for my book to arrive before I tried any more "clean up"   Now I wonder if I should just go back to FTM and make a new gedcom and import (because of the 12/30 update to RM)   What do you suggest?

thanks

 

If it were me, I'd re-import into RM with the latest update. 



#33 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3444 posts

Posted 01 January 2016 - 11:47 PM

 

If it were me, I'd re-import into RM with the latest update. 

 

YES, to what tschlarm says. THEN if you want to also get the new data you added this past month, just do:

   File -> Compare Files

and look for anything in the old database that you want to add to the newly-imported database.


---
--- "GENEALOGY, n. An account of one's descent from an ancestor who did not particularly care to trace his own." - Ambrose Bierce
--- "The trouble ain't what people don't know, it's what they know that ain't so." - Josh Billings
---Ô¿Ô---
K e V i N


#34 rob p

rob p

    Member

  • Members
  • PipPip
  • 25 posts

Posted 02 January 2016 - 10:42 AM

 

RM doesn't have the concept of preferred data or preferred facts.

 

I tried marking the "non-preferred" facts as Disproven on the Edit Person page, but that had no effect on the inclusion in reports.

What does this marking do?

 

This is another potential deal-breaker. I'm not going to give up all that research and documentation of 'conflicting' data.



#35 tschlarm

tschlarm

    Advanced Member

  • Members
  • PipPipPip
  • 31 posts

Posted 02 January 2016 - 11:37 AM

 

I tried marking the "non-preferred" facts as Disproven on the Edit Person page, but that had no effect on the inclusion in reports.

What does this marking do?

 

This is another potential deal-breaker. I'm not going to give up all that research and documentation of 'conflicting' data.

 

My guess is perhaps the Primary checkbox on each fact is the closest thing to the Preferred setting in FTM. It is used in the pedigree chart for BMD dates so I assume it's used where ever only 1 date is shown. The Individual Report shows all data unlike the FTM version where it's filtered to a single birth/death fact. It seems to control which date is shown in the Pedigree, Family and Descendants views, but not the People or Timeline views in the main program.

 

If you search for 'Primary' in the RM7 Help then choose the 'Adding Facts' topic you'll find a write-up on Primary. It seems to be exactly what Preferred is in FTM.

 

Another downside is that the FTM 'Preferred' setting (as far as I can tell) is not put in the gedcom file generated from FTM so the Preferred setting will all have to be re-assigned no matter what program you go to. 

 

Thanks for the reminder on the Preferred setting. I forgot about that one.



#36 TruthSeeker

TruthSeeker

    Member

  • Members
  • PipPip
  • 20 posts

Posted 02 January 2016 - 12:49 PM

Thst is up to Bruce Buzbee.

Renee has stated on another thread that no changes will be made in RM at this time if it requires a change in RM's database structure.

Bruce is doing a complete rewrite of RM so it will work on either Windows or Mac so I doubt he will be making any database structures changes for any reason to RM 7.

If he can make further corrections to the import of FTM gedcoms without changing RM's database structure, he might do that.

Thank you for the informed reply Laura, it's always best to approach these things being fully aware. The latest version of FTM is as modern as Rootsmagic so I think I will continue with FTM whilst studying other options for the future. I have watched some videos on Rootsmagic and dealing with places is not so straightforward as in FTM, this item and quality reports are very important to me. I have downloaded the free version of Rootsmagic and Legacy so I will work with them both on the side and wait to see what there next versions bring before committing my research to a new platform.



#37 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6174 posts

Posted 02 January 2016 - 02:00 PM

 

I tried marking the "non-preferred" facts as Disproven on the Edit Person page, but that had no effect on the inclusion in reports.

What does this marking do?

 

It does nothing AFAIK other than changing the font style in the Edit Person screen to Disputed and Disproven. "Proven" is the same as blank. 

 

What might one do with these Proof and Primary flags with SQLite until such time as RootsMagic exploits them?

  1. Set the Private flag for the event for any marked Disputed or Disproven or not marked Primary. That would allow them to be optionally suppressed in reports.
  2. Prepend or Append the "Disputed" or "Disproven" word or phrase containing it to the fact Description. This would work well in tabular reports but probably poorly in narratives. Also, increasing the length of the Description string may result in truncation on drag'n'drop or export.
  3. Prepend or Append the "Disputed" or "Disproven" word or phrase containing it to the fact Note. This can only work well if the Note option is enabled in the report. There is no issue of potential truncation nor awkwardness in templated sentences. Optionally, this phrase could be enclosed in privacy braces.
  4. Perhaps a combination of #1 and #3 would be optimum among the available options. Where report settings give control over both private facts and private notes, it would be possible to output a Disputed or Disproven fact three ways: fully, private note suppressed, not at all. There might not be much merit in the second of these as the fact would appear equal to a proven one.

Is a SQLite script that would globally make these changes of 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.


#38 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 02 January 2016 - 02:09 PM

Thank you for the informed reply Laura, it's always best to approach these things being fully aware. The latest version of FTM is as modern as Rootsmagic so I think I will continue with FTM whilst studying other options for the future. I have watched some videos on Rootsmagic and dealing with places is not so straightforward as in FTM, this item and quality reports are very important to me. I have downloaded the free version of Rootsmagic and Legacy so I will work with them both on the side and wait to see what there next versions bring before committing my research to a new platform.


As you experiment hands on with RootsMagic and Legacy, you may decide you like working with Places in RootsMagic. Or, you might decide you like Legacy's process better.

Just watching a video or looking at screen shots will not really tell me if I will actually like the way a program hamdles a feature until I try it hands on.

If I was in the position of needing to choose another program, I would tryout other programs and make a detailed list of what I liked and disliked about all features in each program while trying to be objective and not comparing with RootsMagic.

The program that had the most likes would be the winner. That will be the program that I would be most comforable using even if it does have feature handling I don't like.

#39 rob p

rob p

    Member

  • Members
  • PipPip
  • 25 posts

Posted 02 January 2016 - 03:29 PM

 

What might one do with these Proof and Primary flags with SQLite until such time as RootsMagic exploits them?

 

I really don't like #1 - these alternate facts are not "private"; in fact, far from it as far as what I want reported.

#2 would be sweet - Would you mean, "Disproven Birth Date" (?) But I understand the issues.

#3 sort of doesn't work for a lot of us FTM refugees. Because we didn't have to use Fact Notes to get the information where we wanted (reports, publications), it's not a seriously populated field.

 

I guess there' s not a clean answer.

 

FTM reports these as "Alternate" facts in most reports, and they can be suppressed.

Surprisingly, Legacy does, too (from an FTM Gedcom import!). I can't find anywhere in the GEDCOM where FTM exports this "Preferred" setting, but the preferred is always the first of a fact type to appear in the GEDCOM. Did Legacy exploit this?



#40 TruthSeeker

TruthSeeker

    Member

  • Members
  • PipPip
  • 20 posts

Posted 02 January 2016 - 04:38 PM

As you experiment hands on with RootsMagic and Legacy, you may decide you like working with Places in RootsMagic. Or, you might decide you like Legacy's process better.

Just watching a video or looking at screen shots will not really tell me if I will actually like the way a program hamdles a feature until I try it hands on.

If I was in the position of needing to choose another program, I would tryout other programs and make a detailed list of what I liked and disliked about all features in each program while trying to be objective and not comparing with RootsMagic.

The program that had the most likes would be the winner. That will be the program that I would be most comforable using even if it does have feature handling I don't like.

That's exactly what I would intend to do