Jump to content


Photo

RM7 direct import from Family Tree Maker


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

#21 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6254 posts

Posted 11 March 2016 - 08:32 AM

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.

There may be a difference between the direct and GEDCOM imports in the way they handle sources for the preferred name in the presence of multiple names. While these were imported from the GEDCOM, they were invisible to RM users until the procedure was revised to reassign them to the Person (or General) with a flag that would allow them to be restored to the preferred name once RM develops support for that feature. Your example that is ostensibly without media belies this explanation but perhaps you have not looked in the right place. My explanation implies that the direct import is behaving the way the former GEDCOM import from FTM worked, resulting in phantom citations and associated media.

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.


#22 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3420 posts

Posted 11 March 2016 - 10:01 AM

I understand that the GEDCOM logic is the way that it is for a reason.

 

I am not sure how the Rootsmagician arrived at that conclusion but I can tell you that personally that I have always entered those little "mini stories" like "he was born on Tuesday morning" into the Notes field.

 

I can also assume that Rootsmagic does not wish to enter data in a non standard form which will later be a problem if that user decides to migrate from Rootsmagic and subsequently loses data in that transfer. This is the problem we are seeing now with FTM users where FTM appear to have paid little or no respect to the gedcom standard.

 

Perhaps, bearing in mind what you have said, there should be an import option to decide what to do with such FTM Descriptions, move to Place Details or Notes, that should please most users.

 

With a database where really anything can be entered anywhere it is impossible for a programmer to satisfy everyone, only help. I have and continue to clean up files from other genealogy collaborators and I know the challenges only too well.


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


#23 mikelevoi

mikelevoi

    Member

  • Members
  • PipPip
  • 26 posts

Posted 11 March 2016 - 04:53 PM

Vyger,

 

That is a good point - and would hopefully please everyone ;-) For RM developers - here is the FTM forum entry:

 

http://boards.ancest...1.1.2.2/mb.ashx

 

If you read this, you will see that many experienced FTM users use NOTE for any and all long notes - that go on for pages - that they certainly do not want in their short "reports". Hence the request to leave Description where it is for use in reports and for getting a quick overview of a person.

 

So - yes - an option for FTM users to always keep Description data where it is would be very well received. I admit that the solution that RootsMagician has come up with is elegant. However, I do feel it is inconsistent. Either you move the data to Place Details - or you do not. The logic that says move a Birth Description to Description if Place is blank is a recipe for disaster. This means that I need 2 different sentences to display this info in a report. And I need to develop a sentence construct with 2 IF tests in it. This is almost certainly impossible for the average FTM user to manage. In short, move the data all the time - or do not move it ever. Having an IF test which relates to a Place - where the data almost never refers to the Place anyway - makes no sense to me.

 

I repeat - I do not care. I can see all the data on the screen and that is what I care about. It is the many, many FTM users who use Description and Note for the same fact that do care.



#24 tschlarm

tschlarm

    Advanced Member

  • Members
  • PipPipPip
  • 31 posts

Posted 12 March 2016 - 03:55 PM

There may be a difference between the direct and GEDCOM imports in the way they handle sources for the preferred name in the presence of multiple names. While these were imported from the GEDCOM, they were invisible to RM users until the procedure was revised to reassign them to the Person (or General) with a flag that would allow them to be restored to the preferred name once RM develops support for that feature. Your example that is ostensibly without media belies this explanation but perhaps you have not looked in the right place. My explanation implies that the direct import is behaving the way the former GEDCOM import from FTM worked, resulting in phantom citations and associated media.

 

My question is:

 

Why would the checkmark in the media column exist if there is no media associated with the record?

 

The person I was looking at had only a single name and 1 spouse. The person fact had only a single free-form source. That source has Research Notes with a transcription of an obituary, and no media.

 

When I double click on that person to show details, it shows a checkmark under the media column for the person fact. Looking in the Media Album the dropdown selections look correct ('All media, citation, etc) and none of them show any media. Going into the source to look at the citation, it also has no media associated with it.

 

The original FTM 2014 file also had no media associated with this person and the GEDCOM import I did a while ago of this FTM 2014 file does not show the checkmark.

 

It looks like the import moved everything across correctly, but the person fact seems to imply there's media when there is not and I don't understand the reason for it.

 

This does not appear to be limited to just 1 person. I found several others with the same issue.

 

Creating a test person with a test citation with matching info does not set the media flag on the Person fact so this must be related to the new FTM 2014 import process.



#25 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6254 posts

Posted 12 March 2016 - 08:00 PM

There is a parallel discussion about which import from FTM is more trustworthy: direct vs GEDCOM. And it is about the different count of multimedia links as seen in File > Database Properties. Because this is simply a count of the number of records in the MediaLinkTable, it is possible that some may point to non-existent media items. Try a drag'n'drop of the person with the unexpected media flag to a new database and see if the check mark disappears. Or examine the database with SQLite and see if the MediaIDs in that table have corresponding rows in the MultiMediaTable. If not, or if the check mark is gone, those were phantoms that should not have been created by the direct import.

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 tschlarm

tschlarm

    Advanced Member

  • Members
  • PipPipPip
  • 31 posts

Posted 12 March 2016 - 08:35 PM

There is a parallel discussion about which import from FTM is more trustworthy: direct vs GEDCOM. And it is about the different count of multimedia links as seen in File > Database Properties. Because this is simply a count of the number of records in the MediaLinkTable, it is possible that some may point to non-existent media items. Try a drag'n'drop of the person with the unexpected media flag to a new database and see if the check mark disappears. Or examine the database with SQLite and see if the MediaIDs in that table have corresponding rows in the MultiMediaTable. If not, or if the check mark is gone, those were phantoms that should not have been created by the direct import.

The check mark disappeared when drag 'n dropping to another database. So these appear to be phantom values that are not cleared up by the options in Database Tools. Thanks for the trick to prove this!

 

I dragged everybody from the direct import file into a new database and this cleaned up all the phantom records. I also noticed that the in the Media Album the 'General Media' had a '*' in front of it for the direct import file. The '*' was gone after I dragged everybody over. 



#27 mikelevoi

mikelevoi

    Member

  • Members
  • PipPip
  • 26 posts

Posted 12 March 2016 - 09:17 PM

Now using RM7 version 7.1.0.6. The following may be working as designed. If so, then RM should state that the FTM file should not be copied to another location BUT should be imported from its original location, or words to that effect. Obviously, the direct import is expecting the media files to be in a sub-directory underneath the original FTM file. If the import is done from a copy of the FTM file, the following occurs:

 

--- Location of original FTM file and media---

 

D:\MyData\Family Tree Maker\Le Voi.ftm
D:\MyData\Family Tree Maker\Le Voi Media\

 

--- FTM GEDCOM ---

 

Location of GEDCOM file:
D:\MyData\MyHeritage Backup and Data\RootsMagic\GEDCOM\Le Voi_2016-03-13.ged

 

1871 Census Image for Alfred Le Voi

3 OBJE @M601@
...
0 @M601@ OBJE
1 FILE D:\MyData\Family Tree Maker\Le Voi Media\1871 England Census(25).jpg
2 TITL 1871 England Census(25)

 

--- RM7 new database after GEDCOM import ---

 

Location of RM7 DB:
D:\MyData\MyHeritage Backup and Data\RootsMagic\Le Voi_2016-03-13.rmgc

 

Image file in RM7 DB:
D:\MyData\Family Tree Maker\Le Voi Media\1871 England Census(25).jpg

 

Note that RM7 DB shows the location of the media as in the GEDCOM file

 

--- RM7 new database after FTM import ---

 

Copy FTM file to new location to be "safe". Location of FTM file used for import:
D:\MyData\MyHeritage Backup and Data\RootsMagic\FTM\Le Voi.ftm

 

Location of RM7 DB:
D:\MyData\MyHeritage Backup and Data\RootsMagic\Le Voi from FTM.rmgc

 

Non-existent image file in RM7 DB:
D:\MyData\MyHeritage Backup and Data\RootsMagic\FTM\Le Voi Media\1871 England Census(25).jpg

 

--- End result ---

 

No media can be seen after the direct import as the direct import has "chosen" the wrong sub-directory for the media files.

 

--- Workaround ---

 

Copy BOTH the FTM file AND the media sub-directory to a new location prior to direct FTM import. This workaround is not required for GEDCOM import.



#28 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6254 posts

Posted 13 March 2016 - 08:17 AM

Are these two issues really one? The "phantom multimedia links" and the "misconstrued media path", both from direct imports from FTM. The latter should show the media item in the Media Gallery with a "X" broken media link. The former seemingly has no associated media item in the Gallery, just an unexpected count in Database Properties.

Note that over time, RootsMagic terminology has resulted in these links between a media item and a person, event, source, citation, place becoming called "media tags" almost everywhere else in the user interface. The Gallery of media items is made up from records in the MultimediaTable which store the file name and file path to each media file. Each Media Tag is a record in the MediaLinkTable linking a record in the MultimediaTable to a record in another table, such as PersonTable, EventTable, ...

From what has been reported so far, they do seem to be different: one creates a record in the MultimediaTable with an incorrect path and a tag while the other creates lots of tags but no Gallery item to which they point. Both seem to be bugs in the FTM direct import.

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.


#29 mikelevoi

mikelevoi

    Member

  • Members
  • PipPip
  • 26 posts

Posted 14 March 2016 - 01:58 AM

New "bug":

 

- Import FTM file

- Unnoticed by the user, the MARR Description has been LEFT in the Description field as this particular marriage, unlike almost all the others, has no PLACE specified for this marriage

- Drag and Drop the person to another database

- The MARR Description is NOT COPIED to the new database as, by default, MARR does not have Description enabled - and drag and drop is via GEDCOM ;-(

 

Hence, my earlier requests for a consistent FTM import:

 

- Stick all the Descriptions in Place Details - regardless of whether place is specified or not

 

or preferably - and what all FTM users probably want

 

- Leave all Descriptions where they are AND turn on the "Description In Use" flag for each record type as appropriate

 

I suspect that you will have lots of support calls about drag and drop in the future if you do not fix this aspect of FTM import ;-(

 

Mike



#30 mjashby

mjashby

    Advanced Member

  • Members
  • PipPipPip
  • 182 posts

Posted 14 March 2016 - 02:47 PM

I believe you may be confusing two 'issues'.  If you drag and drop an individual between RootsMagic databases then his/her marriage events don't transfer with the individual.  You have to drag and drop both parties to the shared marriage event at the same time for that event to transfer with them. See "Dragging and dropping people in the RM Help File to confirm. 

 

Mervyn


MJA

"A Mac User with Windows Tendencies"


#31 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3420 posts

Posted 14 March 2016 - 02:51 PM


- Stick all the Descriptions in Place Details - regardless of whether place is specified or not

 

 

Why would you not want all these "short stories" and other information placed in the Notes field rather than in a field designed as a subset of the Place field and not designed for this at all?


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


#32 mikelevoi

mikelevoi

    Member

  • Members
  • PipPip
  • 26 posts

Posted 15 March 2016 - 12:10 AM

 

Why would you not want all these "short stories" and other information placed in the Notes field rather than in a field designed as a subset of the Place field and not designed for this at all?

 

Because many FTM users - see the FTM forums - see my earlier link - use Description and Note to contain two different kinds of data.

 

Description - a one liner for use in REPORTS. Note - any and all sorts of stuff - could be emails - could be ramblings - could be anything. In FTM there is no such thing as a "Place Detail" field. There is a "Description" field for ALL FACTS. And FTM users use that field. It is only RootsMagician who thinks that FTM users are using "Place Details" as a convenient place to stick these "Descriptions" ;-)

 

In RM7 you have 4 fields - Date, Place, Place Details, Description (if enabled - and you can enable it if it is not enabled).

 

In FTM you only have 3 - Date, Place, Description. And yes I repeat my earlier statement - it is RootsMagician who is transferring the Description data to Place Details - not the FTM user ;-)



#33 mikelevoi

mikelevoi

    Member

  • Members
  • PipPip
  • 26 posts

Posted 15 March 2016 - 12:18 AM

I believe you may be confusing two 'issues'.  If you drag and drop an individual between RootsMagic databases then his/her marriage events don't transfer with the individual.  You have to drag and drop both parties to the shared marriage event at the same time for that event to transfer with them. See "Dragging and dropping people in the RM Help File to confirm. 

 

Mervyn

 

Actually, I dragged and dropped the ENTIRE RM7 database. The error noted was one of those that showed up immediately. I apologise for simplifying the issue.

 

Dragging and dropping the entire database should not - by default - lose or corrupt data.

 

I repeat the earlier request - if the data is going to left in the Description field as part of the import process - then - the "Description In Use" flag for that Fact Type should be enabled during the import process. The developer has made the decision during the import process to leave a MARR Description where it is - therefore the Developer should enable the MARR  "Description In Use" flag - as it is certainly in use for that Fact Type ;-)



#34 mleroux

mleroux

    Advanced Member

  • Members
  • PipPipPip
  • 68 posts

Posted 15 March 2016 - 05:48 AM

 

Why would you not want all these "short stories" and other information placed in the Notes field rather than in a field designed as a subset of the Place field and not designed for this at all?

Amen. RM has a nice capability for entering place notes, and a good facility for place details. The usage of these, from what I have seen in this forum, seems to be fairly standard, so it would not make sense to suddenly use place details for notes


Marc
Always learning and loving the discovery process. Focusing on the Huntingdon and Soulanges areas of Quebec - O'Connor/Leroux/Walsh/McCann/Savage/Lalonde/Lauzon


#35 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3420 posts

Posted 15 March 2016 - 06:54 PM

 

Because many FTM users - see the FTM forums - see my earlier link - use Description and Note to contain two different kinds of data.

 

Description - a one liner for use in REPORTS. Note - any and all sorts of stuff - could be emails - could be ramblings - could be anything. In FTM there is no such thing as a "Place Detail" field. There is a "Description" field for ALL FACTS. And FTM users use that field. It is only RootsMagician who thinks that FTM users are using "Place Details" as a convenient place to stick these "Descriptions" ;-)

 

In RM7 you have 4 fields - Date, Place, Place Details, Description (if enabled - and you can enable it if it is not enabled).

 

In FTM you only have 3 - Date, Place, Description. And yes I repeat my earlier statement - it is RootsMagician who is transferring the Description data to Place Details - not the FTM user ;-)

 

 

Amen. RM has a nice capability for entering place notes, and a good facility for place details. The usage of these, from what I have seen in this forum, seems to be fairly standard, so it would not make sense to suddenly use place details for notes

 

I was never in any doubt about the MISUSE of the Description field in FTM outside of the gedcom standard and allowed by FTM without any warning to it's users. Whilst this is now a problem for FTM users wishing to transfer their data to another platform it is certainly not a Rootsmagic problem but still it is one Rootsmagic are trying to help with.

 

The problem stems from FTM allowing users to enter long (>100 characters) into a field where compatibility with other programs could not be maintained, such long verbage belongs in the Notes field where FTM also allowed storage. It seems that FTM users, albeit unaware of compatibility issues, started using the Description field on events for their own purposes and worksrounds. If I were in that position I would wish to preserve that information rather than lose it, however I think I am safe in saying such a field for that specific purpose will not become available in Rootsmagic. At present it seems Rootsmagic are trying to facilitate the transfer of those long Description fields where a Place exists into the Rootsmagic Place Details field and from what I understand many FTM users are not going to want it there.

 

If this is a gedcom transfer I would suggest the only suitable solution is to modify the FTM gedcom file to suit the users end needs within the new software platform, in other words translate it to something within the gedcom standard. This might seem like a task beyond most users but I can assure you it is not and if I am ever in the position of transferring to another platform it is something I would be investing time in.

 

Rootsmagic will import Description fields of <101 characters and all Description fields can be enabled (I have all mine enabled) I would suggest it is folly to believe Rootsmagic are going to change the use of their Place Details field to suit new FTM refugees so FTM users really do need to be looking for another solution. I would suggest examining either truncating those Description fields to less that 101 characters in FTM before the transfer to Rootsmagic or examining the FTM gedcom export and making the changes their, whichever is easier. 

 

Again Rootsmagic cannot guess or program for incorrect data entry which FTM users have been allowed to freely enter to suit their own needs and no standard exists!

 

I got this from the link below and it sums up the problem pretty well:

 

Content:

Birth and Death facts (and other events like burials, cremations) have space in FTM for entering descriptive text.  When these facts are exported as a GEDCOM, the description text is appended to the end of the tag, like this:

 

Suspect that exported GEDCOMs do not conform to standards


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


#36 mikelevoi

mikelevoi

    Member

  • Members
  • PipPip
  • 26 posts

Posted 16 March 2016 - 02:38 AM

 

I was never in any doubt about the MISUSE of the Description field in FTM outside of the gedcom standard and allowed by FTM without any warning to it's users. Whilst this is now a problem for FTM users wishing to transfer their data to another platform it is certainly not a Rootsmagic problem but still it is one Rootsmagic are trying to help with.

 

Rootsmagic will import Description fields of <101 characters and all Description fields can be enabled (I have all mine enabled) I would suggest it is folly to believe Rootsmagic are going to change the use of their Place Details field to suit new FTM refugees so FTM users really do need to be looking for another solution. I would suggest examining either truncating those Description fields to less that 101 characters in FTM before the transfer to Rootsmagic or examining the FTM gedcom export and making the changes their, whichever is easier. 

 

Again Rootsmagic cannot guess or program for incorrect data entry which FTM users have been allowed to freely enter to suit their own needs and no standard exists!

 

 

Vyger, all the stuff you quote about GEDCOM is true. However, here is why I believe RootsMagician's logic is flawed:

 

- Firstly, we are NOT talking about GEDCOM import - we are talking about DIRECT import via the original FTM file ;-) Happy to leave the GEDCOM import logic unchanged.

- Secondly, I can enable Descriptions for BIRT, MARR etc and quite happily type 256 characters into the Description field of the RM7 GUI!!!

- RootsMagic does not have to guess what to do - it allows me to type 256 characters into a Description field - so why can't it import 256 characters into the SAME field???

 

Unless I am as thick as a whale omelette (vide BlackAdder) - I really cannot understand the current logic of using a Place Details field when that is patently not what a FTM user wants ;-)

 

I repeat:

 

- During direct FTM import, leave all Descriptions where they are AND turn on the "Description In Use" flag for each record type as appropriate

 

Seriously, how hard can this be? If it is so bad to do this - and one should not do this - why on earth does RM7 let me type an invalid number of characters into a Description field?

 

Happy to be corrected ;-)

 

Mike



#37 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3589 posts

Posted 16 March 2016 - 06:23 AM

RM has created a real mess through the years by allowing an illegally large number of characters to by typed into the Description field and then truncating the Description field without warning on GEDCOM export. The illegally large number of characters prints just fine on reports, but fails to be exported.

 

This is an especially sinister problem because RM's drag and drop process uses a GEDCOM export followed by a GEDCOM import. The GEDCOM export/import is behind the scenes and you don't see it, but it's there. Therefore, a drag and drop operation can lose Description data without warning, and a drag and drop operation is the only way supported by RM to produce a copy of an RM database which is a subset of the original. A drag and drop operation is also promoted by RM as a way to correct problems with database corruption. Complaints from RM users about the loss of data from the Description field have been met with a response from RM that they do not want to create illegal GEDCOM.

 

I can only speculate, but I wonder if RM is beginning to address this design problem. For FTM users at least, Description fields that could result in the loss of data on GEDCOM export are not being created. Obviously, a more holistic solution is needed that solves the problem for all RM users, not just for FTM refugees. I'm really curious what RM has in mind to do about this problem in the RM rewrite.

 

I don't have a dog in the fight about where the Description fields from FTM should be placed in RM by the RM's direct import process. And I don't really know how "most FTM users" make use of the Description field. It does seems to me that moving FTM's Description field into RM's Place Details field may seem like a very clever short term solution to a very tricky problem, but that doing so is likely to create long term problems for FTM refugees. I would suggest that a more holistic and a more long term solution is needed for FTM refugees, and that RM should rethink the solution that they have put in place for the problem of where to put FTM's Description field.

 

Jerry



#38 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3420 posts

Posted 16 March 2016 - 07:28 AM

 

Happy to be corrected ;-)

 

Mike

 

It's not a correction, if RM wand to help here there needs to be at least a decision facilitated as to where the ex FTM user wants their Description data to go.

 

I only use Description fields in RM for small research tags to help me sort on the People View, nothing close to 100 characters. Jerry has explained this problem very well, as he usually does, and RM are as guilty as FTM in allowing >100 characters to be entered into the Description field and then be lost in gedcom transfer.


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


#39 mikelevoi

mikelevoi

    Member

  • Members
  • PipPip
  • 26 posts

Posted 17 March 2016 - 05:14 PM

RM has created a real mess through the years by allowing an illegally large number of characters to by typed into the Description field and then truncating the Description field without warning on GEDCOM export. The illegally large number of characters prints just fine on reports, but fails to be exported.

 

This is an especially sinister problem because RM's drag and drop process uses a GEDCOM export followed by a GEDCOM import. The GEDCOM export/import is behind the scenes and you don't see it, but it's there. Therefore, a drag and drop operation can lose Description data without warning, and a drag and drop operation is the only way supported by RM to produce a copy of an RM database which is a subset of the original. A drag and drop operation is also promoted by RM as a way to correct problems with database corruption. Complaints from RM users about the loss of data from the Description field have been met with a response from RM that they do not want to create illegal GEDCOM.

 

Jerry

 

Jerry and Vyger,

 

I agree - sort of - with all your comments re problems with GEDCOM export and Descriptions > 100 characters. Apparently, I have been told, a lot of this is due to incompatibilities between RM6 and RM7. However, what we are talking about here is FTM import - and drag and drop within RM7. The point I am making is that drag and drop is not simple GEDCOM export and import - it is export and import which is entirely under the control of the developer!

 

Here is some pseudo-code to solve the problem:

 

- User initiates drag and drop
- GUI prompts user to select people or choose all people
- RM7 sets "Drag and Drop FLAG" to be TRUE - this flag will be used later
- RM7 executes GEDCOM export logic using selected people

 

GEDCOM export logic code
- IF "Drag and Drop FLAG" is FALSE THEN execute normal GEDCOM export LOGIC
ELSE
- IF Description contains non-blank characters THEN export them as-is - irrespective of length AND irrespective of "Description In Use" FLAG being TRUE

 

You have to say to yourself - if there is a Description - and Description In Use is FALSE - how did it get there? It got there as part of an import from Legacy, PAF, FTM or GEDCOM. If data exists - export it ;-)

 

- RM7 now executes GEDCOM import logic

 

GEDCOM import logic
- IF "Drag and Drop FLAG" IS FALSE THEN execute normal GEDCOM import LOGIC
ELSE
- IF Description contains non-blank characters THEN import them as-is - irrespective of length AND irrespective of "Description In Use" FLAG being TRUE
- IF "Description in Use" FLAG for this Fact Type is FALSE THEN set it to be TRUE
- When import is complete, set "Drag and Drop FLAG" to be FALSE

 

I cannot think of a reason not to copy all data fields during drag and drop ;-)

 

Guys and Gals - we are talking about 10-20 lines of code here and a new FLAG. I would have thought that this is quite simple to implement. It also means that RM7 can leave FTM import descriptions in Description for all Fact Types - irrespective of length. A FTM refugee to RM7 is not going back to RM6 ;-)

 

Mike



#40 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3589 posts

Posted 17 March 2016 - 06:01 PM

 

Here is some pseudo-code to solve the problem:

 

..........

 

I cannot think of a reason not to copy all data fields during drag and drop ;-)

 

I couldn't agree more that there is a problem and that it needs to be solved. And I couldn't agree more that it's solvable. It is simply the case that whether it should be or not, a drag and drop is a GEDCOM export/import that can lose data.  The issue from my perspective is that RM has never even acknowledged that there is a problem that needs to be solved. 

 

The problem is deeper than the Description field. Firstly, there are other data elements than the Description field that are at risk on a drag and drop. Secondly, individual RM fact types can be enabled or disabled for GEDCOM export, and drag and drop honors the fact type enabled/disabled flags for GEDCOM export. So if you want to use drag and drop (or a GEDCOM export/import) to create a subset of your RM database, you have to remember to enable all the RM fact types for GEDCOM export. There have been wish list items for an "export all fact types" option, but this wish has not come true.

 

In a sense, I don't care if RM fixes the drag and drop problems or not. I think the best way to frame the requirement is that there needs to be a way to create a subset of an RM database that doesn't lose any data except for the people and families that have been omitted from the subset.

 

Jerry