Jump to content


Photo

RM7 direct import from Family Tree Maker


  • This topic is locked This topic is locked
59 replies to this topic

#1 mikelevoi

mikelevoi

    Member

  • Members
  • PipPip
  • 26 posts

Posted 04 March 2016 - 04:22 PM

I am not sure where to post this, but the good people at RootsMagic need to know this. I am an FTM user who is going to migrate to RM7 when direct import is available. On the FTM forum, the question was asked/stated by an FTM user that it would be a "bad idea" from the new owner of FTM to allow this sort of import as it would make migration to RM7 easier. The reply was as follows:

 

" ... So we can end the speculation here. The first updated editions of FTM published by Software MacKiev are now officially available (since March 1st) and ... it will NOT be possible for RM to import files directly from them. "

 

The reason is as follows - MacKiev appear to have changed the database structure/layout of the FTM file - and they done this as part of releasing the first patch for the product. The patch was to fix as many bugs as possible since they acquired the software from Ancestry. They obviously took the chance to change the database as well.

 

According to the company, the patch is optional - so people like myself will not apply it - and hope to migrate natively later this year. However, I suspect that the vast majority of FTM users will simply apply the patch via the normal download method - in which case there will be almost nobody who will be able to use your native migration method by the time you have written it as the patch will probably not advise the user of any of this information.

 

Thus, it appears to me that you may as well not waste time writing the code for the 1% of users who could migrate from the old code base. Alternatively, you and MacKiev could enter some meaningful discussions whereby you could both read each other's database. As an example, anyone can read the MS proprietary WORD DOC format. Wouldn't it be nice if all family tree software could do the same with their databases?

 

On a high note, MacKiev have promised to make their GEDCOM output 5.5.1 compliant. So that hopefully will make it easier for you in future anyway.

 

I am interested in RM's thoughts on this problem.

 

 



#2 RootsMagician

RootsMagician

    Administrator

  • Admin
  • PipPipPip
  • 826 posts

Posted 04 March 2016 - 06:21 PM

Yes, MacKiev has changed the file format (or at least the encryption key).  Yes, FTM files are encrypted, which means FTM users better hope FTM continues to work because they won't be able to access their data from external programs like RM users can.  MacKiev wants to make sure no other program than FTM can access their files.

 

Our direct import of FTM 2008-2014 files should be ready within the next few weeks, so it shouldn't be too long of a wait.


RootsMagician

#3 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3421 posts

Posted 08 March 2016 - 05:00 AM

Well, it seems to be here today rather than the next few weeks the Rootsmagician originally thought.

 

http://blog.rootsmagic.com/


We are all limited by our visions and abilities

Whilst we can borrow from the visions of others we cannot always deliver.

 

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


#4 gldaggett

gldaggett

    Member

  • Members
  • PipPip
  • 9 posts

Posted 08 March 2016 - 08:18 AM

A possible work around for FTM users who have applied the update from MacKiev would be to export their file to a FTM 2012 format and import that into RM7. Adds another step and I haven't thought through what might be lost in that export back to FTM 2012.



#5 jeff363

jeff363

    New Member

  • Members
  • Pip
  • 4 posts

Posted 08 March 2016 - 09:36 AM

I just tried to import from ftm12 and it froze...mind you, I have two trees. One is small and that imported no problems. The other tree is over 28gb and that froze up. I can try the export out of ftm and then into roots magic to see if that works, however, I am also concerned about lost data that I may not notice.

Any thoughts??

Jeff

#6 zhangrau

zhangrau

    Advanced Member

  • Members
  • PipPipPip
  • 1518 posts

Posted 08 March 2016 - 11:41 AM

The link on the RM download page identifies it as RM 7.0.11.0 which is the same id used when I did a download on 04 Jan 2016.

I downloaded and renamed the file as "RM7-0-11-0a_Setup.exe" and saw that the new one was slightly larger than the older one.

I installed the just-downloaded version, and checked Help - About and found I now have RM 7.1.0.0 (7 Mar 2016).

 

Time to fix the download link.



#7 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8470 posts

Posted 08 March 2016 - 12:18 PM

We will have another update out in a few hours, just a few items to fix in the FTM import. Beta testing was so hard on this because every version of FTM is different. 

 

The FTM direct import into RootsMagic can use database files and backup files. So if someone did update to FTM 2014.1 they would need to export it with the output format set to FTM 2012. Then they can import that backup created into RootsMagic. 


Renee
RootsMagic

#8 jeff363

jeff363

    New Member

  • Members
  • Pip
  • 4 posts

Posted 08 March 2016 - 04:39 PM

It works now!!  Wow, that was a fast fix.  Great Customer Service....

 

Jeff



#9 zhangrau

zhangrau

    Advanced Member

  • Members
  • PipPipPip
  • 1518 posts

Posted 08 March 2016 - 05:55 PM

RM 7.1.0.1 up and running. Thanks to the Roots Magician and the whole team.



#10 mikelevoi

mikelevoi

    Member

  • Members
  • PipPip
  • 26 posts

Posted 09 March 2016 - 01:08 AM

Almost there - well done. I can import my FTM DB into RM7 without errors. If I try to import my FTM DB into a EMPTY but customised RM7 DB - I get an error:

 

"Some corruption was detected in the file you jst imported. Although RootsMagic was able to complete the import, you may want to carefully check the imported data to make sure it is correct"

 

Guys - it is impossible for me to do that with a DB of 1400 people and 400 odd families. Where do I start? No log is written during the import so I do not know where to look ;-(

 

I am happy to open a support case and upload the "empty" RM7 DB and my FTM DB if that is useful to you.



#11 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8470 posts

Posted 09 March 2016 - 03:20 PM

I'm not sure what you mean by an empty but customized RM database. It would be good to open a support ticket. 

 

http://support.roots...us_requests/new


Renee
RootsMagic

#12 Monsterzz

Monsterzz

    New Member

  • Members
  • Pip
  • 2 posts

Posted 09 March 2016 - 03:39 PM

Unlike other RM users here, I'm having problems importing the FTM 2014 database WITH media files. The import is problem-free without the media files attached. In FTM, I have already run the "Compact File" utility to fix any errors. I have also tried exporting to FTM 2014 and FTM 2012 versions. And yes, I've updated to RM version 7.1.0.1 .  :)

 

Here is the error message: "ERROR: This does not appear to be a valid FTM backup file."



#13 mikelevoi

mikelevoi

    Member

  • Members
  • PipPip
  • 26 posts

Posted 09 March 2016 - 06:12 PM

I'm not sure what you mean by an empty but customized RM database. It would be good to open a support ticket. 

 

http://support.roots...us_requests/new

 

As requested - I have opened a support ticket.



#14 mikelevoi

mikelevoi

    Member

  • Members
  • PipPip
  • 26 posts

Posted 09 March 2016 - 06:30 PM

On a happy note:

 

I am using the latest version which is 7.1.0.1. With this version, RM has neatly sidestepped the problem of long descriptions in FTM. I never realised until today that FTM descriptions were limited to 256 characters. So I created some 256 character descriptions and also some shorter ones and imported my FTM DB.

What RM are now doing is to import the descriptions into a field called ADDR in the GEDCOM standard. In the GUI this appears as "Place Details (address, hospital, cemetery, etc.)". To define a custom sentence, the field being used is [PlaceDetails]. This applies to BIRT, MARR, DEAT etc. In light of this fact, should the GUI field be renamed to:
 

"Place Details (address, hospital, cemetery, etc.) or Additional Information".

 

HOWEVER - for RESI Descriptions - the long descriptions stay in the Description field ;-) I see no logic to this. The GEDCOM specification is quite specific here - RESI does not have a Description - so why not move RESI Descriptions to ADDR as well? Maybe the developer might like to comment on this?

Thus, it is now possible for FTM users who like Descriptions and Notes to be satisfied and to be able to create customised sentences as well. This is good news and should encourage FTM users to migrate to RM7 later this year when sync is working.



#15 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3421 posts

Posted 09 March 2016 - 07:48 PM

On a happy note:

 

I am using the latest version which is 7.1.0.1. With this version, RM has neatly sidestepped the problem of long descriptions in FTM. I never realised until today that FTM descriptions were limited to 256 characters. So I created some 256 character descriptions and also some shorter ones and imported my FTM DB.

What RM are now doing is to import the descriptions into a field called ADDR in the GEDCOM standard. In the GUI this appears as "Place Details (address, hospital, cemetery, etc.)". To define a custom sentence, the field being used is [PlaceDetails]. This applies to BIRT, MARR, DEAT etc. In light of this fact, should the GUI field be renamed to:
 

"Place Details (address, hospital, cemetery, etc.) or Additional Information".

 

HOWEVER - for RESI Descriptions - the long descriptions stay in the Description field ;-) I see no logic to this. The GEDCOM specification is quite specific here - RESI does not have a Description - so why not move RESI Descriptions to ADDR as well? Maybe the developer might like to comment on this?

Thus, it is now possible for FTM users who like Descriptions and Notes to be satisfied and to be able to create customised sentences as well. This is good news and should encourage FTM users to migrate to RM7 later this year when sync is working.

 

I also very much look forward to some official statement from the developer, if Place Details are to become some hotchpotch of information just to pander to the desires of FTM migrants then I have some decision making to do for myself.

 

annoyed.png


We are all limited by our visions and abilities

Whilst we can borrow from the visions of others we cannot always deliver.

 

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


#16 RootsMagician

RootsMagician

    Administrator

  • Admin
  • PipPipPip
  • 826 posts

Posted 10 March 2016 - 09:31 AM

Vyger,

 

Place Details are *not* becoming a "hotchpotch of information".

 

In FTM, there are fields for date, place, and description.  There is not a field for place details.

 

When RM imports an FTM file, it will place whatever the user entered as a description into the RM description field *IF* that fact type defaults to allowing a description.  So, for example, an occupation, residence, etc type fact, RM will import the description into the description field for that fact.

 

However, FTM lets users enter descriptions for facts like birth, marriage, etc. where it doesn't make much sense to have a description.  So FTM users used that field like RM users used Place Details... the name of the hospital, the street address, etc.

 

So when RM imports an FTM fact that doesn't normally allow a description (say birth), it will import that description into the place detail field *IF* the fact actually has a place.  If the fact doesn't have a place then RM will import the description into the description field.

 

Nothing has changed with the way we or the program interpret what the place details field is for.  It is only the import trying to put the FTM users data where it most likely belongs.


RootsMagician

#17 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8470 posts

Posted 10 March 2016 - 09:46 AM

Unlike other RM users here, I'm having problems importing the FTM 2014 database WITH media files. The import is problem-free without the media files attached. In FTM, I have already run the "Compact File" utility to fix any errors. I have also tried exporting to FTM 2014 and FTM 2012 versions. And yes, I've updated to RM version 7.1.0.1 .   :)

 

Here is the error message: "ERROR: This does not appear to be a valid FTM backup file."

 

 

If you open a support ticket we can help you narrow down what the issue is.

http://support.roots...us_requests/new


Renee
RootsMagic

#18 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3421 posts

Posted 10 March 2016 - 02:47 PM


Nothing has changed with the way we or the program interpret what the place details field is for.  It is only the import trying to put the FTM users data where it most likely belongs.

 

Thank you for the reply, I can understand your logic in trying to bring all FTM users data into "where it likely belongs", I am at peace again.

 

thumbs-up-emoticon.jpg

 

To add some clarity for FTM users:

 

 

The Place Details field will allow gedcom import of 255 characters

 

The Description field will allow import of up to 100 characters, in the case where the data is > 100 characters the complete field will be rejected, not truncated to 100 characters.

 

Description fields of < 101 character will be imported regardless of whether Description field is enabled for fact, in such cases enabling the Description field for that field will enable the Description to be visible on Edit Person screen.

 

Quick note that whilst a Description of <101 characters will be imported regardless of whether the Description field is enabled for the fact concerned, if the user does not then enable the Description field for those facts then that Description will be lost on subsequent Gedcom export. 


We are all limited by our visions and abilities

Whilst we can borrow from the visions of others we cannot always deliver.

 

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


#19 tschlarm

tschlarm

    Advanced Member

  • Members
  • PipPipPip
  • 31 posts

Posted 11 March 2016 - 12:34 AM

I think the new FTM 2014 direct import may be creating ghost media entries on the person fact.

 

I did a GEDCOM import from FTM a couple months back and everything looked good. All media and facts came across well.

 

I recently did a direct FTM2014 import and then did a compare of the 2 results hoping to see a few differences and maybe some new things that may have been dropped in the GEDCOM export (media descriptions, privatize settings, etc). I was surprised to see differences on almost all records. What I noticed was, in the compare screen the media column was checked in the FTM direct import file for the Person fact and was unchecked in the GEDCOM import version of the file. There was no media on those records in the original FTM file, only a source and that had no associated media.

 

I have run all the RM7 database cleanup tools and then re-ran the compare, but had the same results.

 

To me it looks like the new RM7-FTM 2014 import is creating ghost media records in the RM7 DB that probably should not be there.

 

Has anybody else seen this? I would upload an image of a screen capture to show more of what I described above, but the editor seems to not support this.



#20 mikelevoi

mikelevoi

    Member

  • Members
  • PipPip
  • 26 posts

Posted 11 March 2016 - 02:09 AM

In FTM, there are fields for date, place, and description.  There is not a field for place details.

 

However, FTM lets users enter descriptions for facts like birth, marriage, etc. where it doesn't make much sense to have a description.  So FTM users used that field like RM users used Place Details... the name of the hospital, the street address, etc.

 

So when RM imports an FTM fact that doesn't normally allow a description (say birth), it will import that description into the place detail field *IF* the fact actually has a place.  If the fact doesn't have a place then RM will import the description into the description field.

 

Nothing has changed with the way we or the program interpret what the place details field is for.  It is only the import trying to put the FTM users data where it most likely belongs.

 

While this is fresh in RootsMagician's mind, I should like to point out that he is probably not correct in his understanding of how FTM users work. If he was to read the FTM forums - on which this import logic is a hot topic - he would realise that FTM users actually use this field for Descriptions - like "He was born on Tuesday morning" or "She was living with her sister at the time she died". These are actually used by almost all FTM users as one-liners to print in reports - think of them as "mini stories". They are almost never used in the way that RootsMagician thinks. I would guarantee that almost every FTM user would like the native import code to do the following:

 

- Import all Descriptions as-is into the Description field

- Turn on the "Description in use flag" as required for BIRT, MARR, DEAT etc if such a description is found in the FTM file.

 

I understand that the GEDCOM logic is the way that it is for a reason. However - we are talking about native FTM import - and that is only for FTM users who wish to migrate as-is off the dreadful FTM software - and yet keep their data where it is. I therefore make this plea to RootsMagician to change the way that FTM import works. He is already doing this NOW - when BIRT does not have a PLACE nominated - see above. RootsMagician - please make our lives easier - always leave the description data in the Description field ;-)