I want to combine a small database with a very large database. The small database has lots of unused places. Is there an easy way to not include or delete all the unused places?
I have already tried Gedcom but all the unused places were included.
Using RM7
That is surprising because all my memory says is that unused things like places, sources, citations, medialinksā¦ are not included in a GEDCOM export or dragānādrop.
Unused places are not included in drag n drop and GEDCOM exports in any version. In RM10 you can view the unused places on the Enhanced Properties List on the Tools page and delete them in mass there.
The unused places were definitely in my gedcom and also in the drag & drop of everyone in the tests that I did with RM7. I also imported the same gedcom into RM10 (a new file) and still saw all the unused places.
In RM10, I viewed the unused places under Places. I wouldnāt have known otherwise to look under Tools > Enhanced Properties List for Unused places to delete them all at once. I have since wasted at least an hour deleting them all - one by one - in RM7.
Direct import of RM7 into RM10 should have included the unused places. Are you sure you didnāt use that?
One cannot drag ānā drop between versions, but importing a .GED file into more recent versions of RM definitely brings along Unused places and Sources w/ no citations.
@mapleleaf and @kbens0n Sorry guys BUT @rzamor1 and @TomH are correct-- a gedcom import does NOT include unused places.
This is my RM 7 place list
the unused place list from RM 7
and this is the same database transferred to RM 10 by a gedcom
I did drag and drop from the smaller RM7 database to a blank RM7 database.
I created a gedcom of the smaller database and did File > Import (RM7).
With the same gedcom, I did File > Import from Another Program > Gedcom (RM10).
If that is not correct, what should have I done?
@nkess What do you see upon going to Tools>Enhanced Properties list? If Iām remembering correctly, even exporting a Gedcom from RM7 and back into a new RM7 database shows Unused places being preserved.
Edit: You show RM10ās Place List ~ click the 3-dot menu and go to Unused Places.
this bunch here was an RM 7 file that I made a gedcom of and opened with RM 10
Same fileāUnused places under the 3 dots
same database-- enhanced properties
this bunch here is from an RM 10 file that I made a gedcom of and opened in RM 10
original
3 dots
and enhanced properties
@nkess Canāt understand whatās happening for You.
Yesterday, I did all these things.
-Exported full RM7 Gedcom to file.
-Imported that Gedcom to a new RM 10 database. Found matching Unused places in both source and destination databases.
-Imported that Gedcom to a new RM7 database. Found matching Unused places in both source and destination RM7 databases.
-Opened the RM7 Gedcom file in a text editor and searched for names from Unused Places and they are in the Gedcom.
Think that should be @kbens0n Canāt understand whatās happening for You
because I did EXACTLY what you did except I did NOT send it back to RM 7 since I had no unused places
@nkess upon re-checkā¦ Geocoded Places with Lat/Long get exported to Gedcom.
Sorry, to not have known there was a difference between Geocoded Places vs NOT. So, as youāve now surmised, removing Lat/Long entries from those Unused Places ~should~ exclude them from winding up in the Gedcom file. Appreciate your patience. Good Luck!
Whaaat?! Youāve discovered that unused but geocoded places are included in a GEDCOM export and pre-RM10 dragānādrop? That is the first time this has been reported in the 16 years since RM4 was released. In all that time, the mantra has been that places unused by the events of the people within the scope of the export are not included.
Why should geocoding make any difference to whether an unused place is exported? Iām at a lossā¦
Letās say youāve designed source templates, custom fact types and roles, etc. ā¦but never used them. Should they be discarded, too? Places having been geocoded give the hint of prior āintentionāā¦ whether created contemporaneously and geocoded singularly or en masse. They take on additional supporting data (confirmed existing places) that logic dictates should be preserved. Same can be said for Places imported from other programs or software interfacing. Makes pretty good sense, but they just happen to be lumped in with Places like Cheerie Valley, Misspelled County, Wrong Country, Missing Most Parts of placename that is duplicated already, ETC.
Iāve always taken for granted (but appreciated) that they survived because some match searches in facts/sources/notes and may still have applicability, despite having been the inadvertent result of a merge or binary choice or whatever, somewhere along the line. I have a manageable number and suspect thatās the case with virtually everybody.
Iām not even sure that RM Support and maybe even the developers have even been recently conscious of there having been a design decision based on the justification you present.
Remember that Import Lists was added so that unused things could be transferred from one database to another!
Cāmonā¦ the program very explicitly does this. Sure, we didnāt know the discerning detail, but Iāve always seen them transfer. I just didnāt know that some were actually NOT transferred.
And having sidestepped the question of should other unused data structures created but unused, be preservedā¦ they are in the export, too (even if all people are deleted from the database).
EDIT:
@mapleleaf ~ Extra details (RM specific), when unchecked during GEDCOM export, results in non-preservation of those geocoded Places (and the other data structures)
Where have you been? Clearly, you have been on a different trail from most of the rest of us, including RM Support. I just did a dragānādrop of 1 person out of populous databases of RM5, RM7 and RM10. Not a single unused Place, geocoded or not, Source, Media linkā¦ was transferred.
I just exported the one person from the populous RM5 and RM10 databases with that option checkmarked: not a single unused thing was exported.
I did note one exception to the unused things: the GEDCOM exports do include Fact Type definitions. Iād have to explore further whether these are all the Fact Types or only custom ones and standard ones having user-defined sentences or roles.
So whatās different between your export procedure and mine, or between your databases and mine that result in these opposite behaviours?
For years, I have posted here, on Facebook and in the old Forums the link below to warn people about risk of loss in a GEDCOM transfer. Others have contributed to the list. Nobody has questioned that unused Places are lost and I have yet to witness otherwise.
I did no research for dragānādropā¦ strictly GEDCOM import/export. I stand by what I said. I did not know that non-geocoded Places were dropped during GEDCOM exchange. I casually āknewā that Unused Places in earlier versions were present in subsequent versions, but had no reason to investigate the particulars. That is obvious in my troubleshooting within this thread.
If, by āthingā, you mean Unused Places that are geocodedā¦ I suggest you:
-create an RM7 database with one person, one fact w/place name Chicago, Cook, Illinois. Geocode that place. Save.
-change that place name (within the fact Place field) to Shikago, Cooke, Indiana and Save.
-change that place name a third time and empty the Place field. Save.
-delete the person and export a GEDCOM.
-report back what you find in that export
Iāve seen your ārisk of lossā mentions numerous times, though Iāve only visited your website once or twice back in the day, but Iām mostly self-centered in my approach to using RM and work in the realm of the program as it exists and evolves.
