You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Attempt to Read in data from a GEDCOM file fails because of numerous errors.
import.log file has hundreds of lines like this.
error: Person I3 is referred to but not defined.
error: Person I4 is referred to but not defined.
error: Person I5 is referred to but not defined.
error: Person I7 is referred to but not defined.
error: Person I9 is referred to but not defined.
error: Person I10 is referred to but not defined.
error: Person I11 is referred to but not defined.
error: Person I12 is referred to but not defined.
error: Person I16 is referred to but not defined.
error: Person I28 is referred to but not defined.
error: Person I30 is referred to but not defined.
Comparing the exported GED file and the source database reveals that the erroneous individuals are siblings of ancestors - I1 and I2 are ancestors married to one another, I6 is also an ancestor, and I3, I4 and I5 are siblings of that ancestor, who should have been stripped from the FAM record.
Tom Wetmore suggests that the call to gengedcom in the .LL file is where the non-ancestors should have been stripped out.
The text was updated successfully, but these errors were encountered:
Tom Wetmore suggests that the call to gengedcom in the .LL file is where the non-ancestors should have been stripped out.
This implies that the GEDCOM you're trying to import was generated via gengedcom() in a report?
I assume a normal export from the main menu works fine?
Have just double-checked u=>s to export and u=>r to import the same database as I was using.
Tom pointed me to this function in his original code, which does the job of stripping out the references to non-ancestors as each family is exported. You'll find the whole of his comment on the LINES-L list.
/*============================================
write_family -- Write family record to file ==========================================/
static void write_family (String key, Table itab)
// key; /* family key /
// itab; / table of persons in file */
{
GNode *fam = keyToFamily(key);
char scratch[30];
String t;
sprintf(scratch, "0 %s FAM\n", fam->gKey);
//poutput(scratch);
fwrite(scratch, strlen(scratch), 1, Poutfp);
fam = fam->gChild;
while (fam) {
t = fam->gTag;
if (eqstr("HUSB", t)) {
if (isInTable(itab, rmvat(fam->gValue)))
new_write_node(1, fam, false);
} else if (eqstr("WIFE", t)) {
if (isInTable(itab, rmvat(fam->gValue)))
new_write_node(1, fam, false);
} else if (eqstr("CHIL", t)) {
if (isInTable(itab, rmvat(fam->gValue)))
new_write_node(1, fam, false);
} else
new_write_node(1, fam, false);
fam = fam->gSibling;
}
}
PS As indicated in the heading to my issue report, I wanted to export all ancestors of a given INDI using the standard-issue anc2_ged.ll report. Although the non-ancestors' INDI records are excluded from the faulty output, the FAM records are output with references to those excluded INDIs. I don't have a 32-bit machine on which to check that 3.0.62 delivers the expected output.
Attempt to Read in data from a GEDCOM file fails because of numerous errors.
import.log file has hundreds of lines like this.
error: Person I3 is referred to but not defined.
error: Person I4 is referred to but not defined.
error: Person I5 is referred to but not defined.
error: Person I7 is referred to but not defined.
error: Person I9 is referred to but not defined.
error: Person I10 is referred to but not defined.
error: Person I11 is referred to but not defined.
error: Person I12 is referred to but not defined.
error: Person I16 is referred to but not defined.
error: Person I28 is referred to but not defined.
error: Person I30 is referred to but not defined.
Comparing the exported GED file and the source database reveals that the erroneous individuals are siblings of ancestors - I1 and I2 are ancestors married to one another, I6 is also an ancestor, and I3, I4 and I5 are siblings of that ancestor, who should have been stripped from the FAM record.
Tom Wetmore suggests that the call to gengedcom in the .LL file is where the non-ancestors should have been stripped out.
The text was updated successfully, but these errors were encountered: