I created a PAF file using the free app from many years ago; is it possible for me to upload this fi
Answers
-
@JamesAzevedo JamesAzevedo
.
James
.
IF, you are referring to "Family Tree" of 'FamilySearch'; THEN, "Please" take the time to input/enter your "Ancestral" lines one individual/person at a time.
.
=====
.
There are two (x2) places that you can upload a GEDCOM File into 'FamilySearch'.
.
=====
.
The FIRST is in the "Genealogies" Part of 'FamilySearch', which is fine.
.
This is where you will find the GEDCOM File that you 'uploaded' to the "Genealogies" Part of 'FamilySearch':
.
https://www.familysearch.org/mytrees/trees
.
Now ...
Here are some things that you need to know/understand ...
.
Those GEDCOM Files that you 'uploaded' to the "Genealogies" Part of 'FamilySearch' will NOT contain any individual/person from that GEDCOM File that is REMOTELY considered as "Living" (ie. No "Death" details) - purely and simple for 'Privacy'.
.
Plus, those GEDCOM Files that you 'uploaded' to the "Genealogies" Part of 'FamilySearch' are for RESEARCH purposes ONLY; and, can be viewed by ALL "Registered" Users/Patrons.
.
And, those GEDCOM Files that you 'uploaded' to the "Genealogies" Part of 'FamilySearch' are 'Static'; that is to say that, they cannot be "Edited" (ie. "Changed"), they can ONLY be "Deleted"; and, replaced by an updated version.
.
=====
.
The SECOND and LESS DESIRABLE is in the "Family Tree" Part of 'FamilySearch'.
.
You can; but ...
.
Please DO NOT upload a GEDCOM File in "Family Tree" of 'FamilySearch'.
.
Upload GEDCOM File in the "Genealogies" Part of 'FamilySearch', that is fine; but, please NOT into "Family Tree" of 'FamilySearch'.
.
Some of the reasons that Users/Patrons (like myself) DO NOT want the ability to upload a GEDCOM File into "Family Tree" of 'FamilySearch' are:
.
(1) It is most likely that individuals/persons in a GEDCOM File are ALREADY in "Family Tree" of 'FamilySearch'; and, most Users/Patrons DO NOT even take the time to look to see if any one in their GEDCOM File is already in "Family Tree", in some instances, negating the need to even upload the GEDCOM File.
.
(2) There has been (many) cases where Users/Patrons, using the "Compare" process (of the upload) have "Dismissed" a "Possible" Match with an individual/person already in "Family Tree"; so that, their "Record", from their GEDCOM File, is loaded into "Family Tree", regardless; just so that, their "Record" appears in "Family Tree" (and, in some instances, for Members of the Church, so they can do the "Temple" Work, despite the fact that the "Temple" Work may be ALREADY done with the "Possible" Match with the individual/person already in "Family Tree").
.
(3) Even with the "Compare" process (of the upload), there has been (many) cases where Users/Patrons have uploaded THEIR version of an individual/person in their GEDCOM File, on top of (ie. Over) an individual/person ALREADY in "Family Tree" of 'FamilySearch' that has been there for MANY years and is well documented and "Sources" - in many instances obliterating all of the documentation and "Sources".
.
(4) If an individual/person is ALREADY in "Family Tree" of 'FamilySearch', there is NO need to up uploaded one's version of an individual/person from one's own GEDCOM File - just take note of the the 'FamilySearch Person Identifier' (PID) of the individual/person that is ALREADY in "Family Tree"; and, one can go back later to ensure what information/detail is recorded and attached for that individual/person. Just DO NOT uploaded one's version of an individual/person in their GEDCOM File, on top of (ie. Over) an individual/person ALREADY in "Family Tree" - obliterating all of the documentation and "Sources" ALREADY in place/on record.
.
(5) The "Hours" (sometimes "Days") of work, by other Users/Patrons, that can be needed to CORRECT the DAMAGE done by the upload of a GEDCOM File can be disheartening.
.
I am sorry ... 'off my soap box' ...
.
Enter (ie. 'Create) the individuals/persons in "Family Tree" of 'FamilySearch' one at a time - on a one by one basis.
.
Many of the individuals/persons most probably ALREADY exist in "Family Tree" of 'FamilySearch'.
.
Only one or two of one's generations of "Living" Family members (and, perhaps one or two of one's generations of "Deceased" Family members) may be required to be entered/input in "Family Tree" of 'FamilySearch'; before, some of the "Deceased" individuals/persons from Ancestral lines ALREADY existing in "Family Tree" of 'FamilySearch', are discovered.
.
Use the "Find" facility/function/feature to Search "Family Tree" of 'FamilySearch', you may be surprised to find some (if not, many) of them already there.
.
Many well established and documented (eg. "Sourced") individuals/person in "Family Tree" of 'FamilySearch' have been RUINED by the upload a GEDCOM File into "Family Tree" of 'FamilySearch'.
.
Of course, IF, one has looked in "Family Tree" of 'FamilySearch' and NONE of one's Ancestral lines are in "Family Tree" of 'FamilySearch'; THEN, the upload of a GEDCOM File would be the way to go - BUT, ONLY if one has looked in "Family Tree" of 'FamilySearch' and NONE of one's Ancestral lines are in "Family Tree" of 'FamilySearch'
.
=====
.
Most Users/Patrons do not understand the basic nature and premise of "Family Tree" of 'FamilySearch', when they join in.
.
Please let me explain ...
.
We do not have our OWN "Tree" in "Family Tree" of 'FamilySearch'.
.
We ONLY have "Branches" (ie. Ancestral" lines), that are interconnected, in this SINGLE "One" World "Tree", for all of us, that is "Family Tree" of 'FamilySearch'.
.
"Family Tree" of 'FamilySearch' is NOT like 'On-Line' "Websites" (eg. "Ancestry_com"; or "MyHeritage_com"; or, the like); and/or, 'standalone' personal (computer) programmes (eg, the OLD, now no longer supported, "PAF"; or, "Ancestral Quest"; or, the like).
.
We DO NOT have "Private"/"Personal" 'Trees' in "Family Tree" of 'FamilySearch' like other 'On-Line' "Websites"; and/or, 'standalone' personal (computer) programmes.
.
We do not even, own; or, manage; and, are NOT even responsible for, the "Deceased" individuals/persons in "Family Tree" of 'FamilySearch'.
.
"Family Tree" of 'FamilySearch' is built on a "Open Edit" Platform - hence, why any registered User/Patron can "Edit" (ie. Add, Delete; and/or, Change) ANY "Deceased" individual/person in "Family Tree" of 'FamilySearch'.
.
=====
.
I hope this puts things into perspective.
.
Brett
.
0 -
chances are most of the people in your PAF file - are ALREADY in FamilySearch - Family Tree? Have you checked? loading them again would most likely simply create duplicates and create a mess.
0 -
As has been mentioned, it is inappropriate to dump a large collection of person records into the FamilySearch FamilyTree, either by GEDCOM file or directly (as some applications allow). The FSFT is a single shared database that is not supposed to have any duplicate records in it.
The most current version of PAF is called Ancestral Quest version 16 (made by Incline Software). They have a free version that you can download. If I were you, I would get a copy of that free version of AQ and import your PAF file into it (nothing will be lost) so that you have a current AQ version of your data.
From there you can start start walking through your ancestors in your new AQ database and link each one to to the equivalent record in the FSFT database (most of the records in your AQ file will likely already be in the FSFT). If you cannot find a matching record in the FSFT, you can upload your AQ person record directly to the FSFT. If you have "holes" in your AQ records (e.g., missing siblings, etc.), you can directly download them from the FSFT into your AQ file.
When you do a compare of your vitals data in a person record in your AQ database with the ones it's linked to in the FSFT and you see differences, you can update your AQ database from the record in the FSFT, update the FSFT record from yours in AQ, or both.
This is wonderfully easy to do but will have a bit of a learning curve as the PAF that you are familiar with didn't have the comparing and syncing capabilities with the FSFT that the current AQ tool has. But when you are done, you will have a great way to keep a local copy of the work you do in FSFT. There are SEVERAL other significant benefits of doing this that I won't go into at the moment.
But WHATEVER you do, do NOT sync data from your AQ database up to the FSFT until you have researched each person to understand why the values in the FSFT should be replaced with those from your old PAF file.
When you see differences, you need to read all the supporting information that is already in the FSFT on why those existing FSFT values have been set to where they are. Then IF you have documented reasons (e.g., sources, Notes, memories, etc.) that show why your different values are more reasonable, you can go ahead and sync/upload your values along with the documented evidence to the FSFT overwriting the existing values there.
If you start altering existing values in the FSFT without documented evidence and reasons for why you have made the changes, you will likely get many people quite irritated when they have to go in and correct wrong assumptions you've made or having to merge away duplicates that you've added to the system.
BTW, this is exactly how I started in the FSFT with my original PAF files. One by one, following the FSFT records up my line. for each one, I would create a link between my AQ the the FSFT database records. I would then (from the FS site) go through and validate all the information already in the record while comparing it to my AQ record (frequently there were errors in both). Once I had finished making any changes needed in the FSFT record, I would sync it down to my AQ database updating my record there thus giving me a BACKUP of the last validated information I had on that person. If anyone makes a change in the FSFT, I can do an instant comparison to see what has been changed.
There are other tools (such as RootsMagic) that you can use to accomplish this same thing. However, the "look and feel" of AQ is the same as PAF because it is the same software only with a LOT of improvements added to it. Since you've worked with PAF already, that is why I suggested AQ.
0
