* Issues when directly Importing RM 8 File with Places

[MFriend]

Hi Folks:
I submitted a ticket with FH support because I didn't think this was an issue that could be helped here... but you all know so much maybe I missed a thread here on the forums.

When I do a direct import of my RM 8 (latest version of RM 8) tree into FH7 (latest edition), dozens of the places show up as "unknown" Unidentified place (see pic ):


I then did a "Where Used on, as an example, record Unidentified 11
It shows as missing in the actual record in FH7.




When I look at the same (original) record in RM 8 though, the place is there.


I generally really like the direct import method of importing a RM 8 directly into FH 7 and avoiding dataloss with Gedcoms. This seems to be the only loss of data that I can find that occurs (I did it several times to see if the problem would repeat).

I'm assuming I will need to wait to hear back from FH support, but you folks are experts with FH so I figured it couldn't hurt to ask.

Thanks,
Matthew Friend

[Jane]

I suspect it's something different in the DB for RM8, if you have not done so it would be worth sending Calico a small sample file which causes the problem, because some of your places have come across suggesting there is some subtle difference in the places which have not come across.

[Mark1834]

I've not been able to replicate this effect with my RM8, but the good news is that CP should be able to identify the source of the problem very quickly. They will know from the internal plumbing of FH when "Unidentified place" is used, and the detailed internal structure of RM databases can be examined readily using freely available tools (unlike FTM) .

My guess is that it is either an internal error in the RM database that the app itself did not identify (have you run the database checking tools?), or an unusual format for the data that CP did not anticipate.

[MFriend]

Thanks for the input. Calico / FH support got back to me already this morning and I've sent them a link to the database so they can check it out. Between the helpers on this forum and the official FH Calico support, FH is an excellent choice

[MFriend]

I thought I would post what Support found was the problem in case anyone else has the same issue. I had spent about a week going through the places and trying to standardize them. I went from 3700+ places to about 2100. In the process I guess I missed a few duplicates. If there is a duplicate in RM 8, then it will show as unidentified after importing into FH 7. Support at FH 7 said they will have a fix for this in the future. Here is their response if others might find it helpful:

"Thank you. We have now downloaded your RM database and investigated the problem. It turns out that the problem arose because you have 21 Place records in your RM database, which have duplicated place names. Family Historian does not allow different Place records in the same project to have exactly the same Place name.

For interest, the duplicates are:

"Ho, Ribe, Denmark [2]"
"Coats, Pratt, Kansas, United States [2]"
"Fairbury, Livingston, Illinois, United States [2]"
"California, United States [2]"
"Cass Township, Fulton, Illinois, United States [2]"
"Croisan, Marion, Oregon, United States [2]"
"Stafford, Virginia, United States [2]"
"West Township, Columbiana, Ohio, United States [2]"
"Wolfersweiler, Birkenfeld, Oldenburg, Germany [2]"
"Weinsberg, Weinsberg, Württemberg, Germany [2]"
"Cass Township, Fulton, Illinois, United States [3]"
"Canton Township, Fulton, Illinois, United States [2]"
"Horne, Ribe, Denmark [2]"
"Harpford, Devon, England [2]"
"Los Angeles, Los Angeles, California, United States [2]"
"Council Bluffs, Iowa, United States [2]"
"Canton, Fulton, Illinois, United States [2]"
"Peoria, Peoria, Illinois, United States [2]"
"Henne, Vester Horne, Ribe, Denmark [2]"
"Long Beach Judicial Township, Los Angeles, California, United States [2]"
"Hastings, Adams, Nebraska, United States [2]"

The number in square brackets at the end indicates the instance. In one case, "Cass Township, Fulton, Illinois, United States", you have 3 Place records with this place name.

In the next update of Family Historian, we will look out for duplicated place names on import and add a numerical suffix to make them unique (i.e. as shown in the list above). You will be able to search for duplicated Place records by creating a query for Place records, which looks for any place name that ends with "]". You will be able to merge duplicate place records if you want to, or take other steps.

If you want to fix the problem now, without waiting for the update, you need to locate the duplicate place records in RM and merge them there, prior to import."

[Mark1834]

I've been experimenting - RM8 doesn't let you create a new place with a duplicate name, but it does permit changing the name of an existing place to the same as that for another record, which is presumably what you did.

In database terms, the place name is not the Primary Key. So both of my options were in fact correct - it was a database fault (IMO, such a change should not be permitted), and CP didn't anticipate that possibility could arise!

[MFriend]

Yes, after standardizing them, I had literally hundreds of dupes which I had to merge. If RM 8, you can have for example Canton, Ohio and Canton, Stark County, Ohio. Then you run the place clean function that can check a location database and add (as an example) United States to all locations in the USA that don't already have the country (or change USA to be United States). In the process of standardizing the city, county, state, country there was a huge amount of overlap. While FH 7 is by far my favorite genealogy program (and much better for most things than RM 8), if your places are in really poor shape (missing a lot of info like the country, etc), RM 8 is great for cleaning that stuff up. Then the nice direct import feature into FH 7 brings all those changes into FH7