_NEW would be a unrecognizable custom tag. What the heck would _NEW signify?
You can use a text editor and convert all the
1 _NEW xxxxx
to
1 _EVEN xxxxxxxx
2 TYPE - - - - - - - - -
and then import again.
It sounds to me like an 'additional' CHAN tag, something added to the original data. I believe it would be far more appropriate to log these in a GEDCOM via a SOUR reference. -Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for the typo. This darn forum software does not allow changes.
'2 TYPE'? I Ignored it
You ignored it? or PGV ignored it? I would not think the latter. If you use a text editor or batch update to simply change the
1 _EVEN to 1 EVEN I think you should see all the 2 TYPE appear as PGV doesn't ignore anything upon import, but it would not know how to display the 1 _EVEN tag and would not show the subordinate tag of 2 TYPE.
-Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've made the change from _EVEN to EVEN and import it again. No errors anymore. I don't understand where I could check de 2 TYPE (DATA or what?). For the moment I go to concentrate on the other errors :-).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Without actually seeing the parts of the GEDCOM where the 1 _NEW records appear, we can't give you any meaningful advice on how this output from the Aldfaer program should be handled in PhpGedView.
Stephen gave you some generic advice, but to give you advice that's specific to your situation, we need more information.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The structure is always the same and after '1 EVEN' comes always '2 TYPE 1'. No futher DATA.
0 @I3162@ INDI
1 RIN 3162
1 NAME Jannetgen/Baes/
1 SEX F
1 CHR
2 DATE 4 SEP 1604
2 PLAC Rijsoord
1 FAMC @F1337841572@
1 EVEN
2 TYPE 1
2 DATE 28 MAY 2012
3 TIME 10:24:15
1 CHAN
2 DATE 4 JUL 2012
3 TIME 13:20:48
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We need to know what the structure of the GEDCOM produced by the Aldfaer program looks like, around the _NEW records. Without this information, we are not able to advise you how the output from Aldfaer should be modified to produce something that PhpGedView (and other similar programs) can understand.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What the heck would _NEW signify?
It sounds to me like an 'additional' CHAN tag, something added to the original data. I believe it would be far more appropriate to log these in a GEDCOM via a SOUR reference.
The same may still be true. Using EVEN to record previous log of changes would not be correct, as EVEN usually signifies an event in the life of an individual or family, not a 'bookkeeping' event.
webtrees maintains a change log that is both searchable and filtered in the admin section. It shows both previous data and changes. It you do not have a restriction of disk space (database size), you can keep all your changes. This is a more approriate method of maintaining a change log. If your _NEW does log changes (and then, only the date and time and person, but not the actual values changed, it does you little good and, in my case, we make hundreds of changes each day, so my gedcom would be well over 1gb, maybe 2 and the database would become unmanageable. -Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't really understand what you both asking and saying. I thought I gave the stucture. Perhaps my English is not good enough to understand it all.
For the moment I dropt the question of the meaning of _NEW at the forum of ALDFAER.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have you posted the code from Aldfaer's output for a snippet containing the _NEW tag? I didn't think I had seen it, only your comment "Unrecognized GEDCOM Code: _NEW"
If you post a snippet, it should be pretty obvious what the tag represents and attempts to convey. I suspect that it is similar to the Last Change tag.
-Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you are confused about what we're asking for, the simplest solution is to send either me or Stephen a copy of the entire GEDCOM, as it was originally produced by the Aldfaer program. Either Stephen or I can then look at the file and determine what the Aldfaer program is trying to say.
You can send a ZIP copy of the GEDCOM file produced by Aldfaer to me: gkroll at keldine dot ca . I don't see a need to actually load that GEDCOM file into my copy of PhpGedView.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Several things can be noted here:
- The 1 _EVEN records with sub-record 2 TYPE 1 seem to describe the date and time the individual was added to the Aldfaer database. They should be removed. Apparently, there is an Aldfaer Export option for this.
- The given name is not separated from the family name. The space is missing. If there is an Aldfaer Export option for this, it should be used. Otherwise, PGV can add the missing space by doing a batch Edit from the Admin menu.
- The Fyyyy numbers are very large. These large numbers make it hard to refer to families by their IDs. Unless Aldfaer has a re-number option, there's not much that can be done about this. PGV can't do this right now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yust imported my first GEDCOM generated with Aldfear 4.2.0.0
Unrecognized GEDCOM Code: _NEW
Is this the right place to report it?
_NEW would be a unrecognizable custom tag. What the heck would _NEW signify?
You can use a text editor and convert all the
1 _NEW xxxxx
to
1 _EVEN xxxxxxxx
2 TYPE - - - - - - - - -
and then import again.
It sounds to me like an 'additional' CHAN tag, something added to the original data. I believe it would be far more appropriate to log these in a GEDCOM via a SOUR reference.
-Stephen
First I've update to 4.3.0 SVN. Then I changed the GEDCOM-file as You said. Now is the error message: Unrecognized GEDCOM Code: _EVEN.
I'm afraid you were given slightly incorrect instructions.
The _EVEN should have been EVEN (without the initial underline).
Thats nice :-). And what will I do with te second line: '2 TYPE'? I Ignored it.
Sorry for the typo. This darn forum software does not allow changes.
You ignored it? or PGV ignored it? I would not think the latter. If you use a text editor or batch update to simply change the
1 _EVEN to 1 EVEN I think you should see all the 2 TYPE appear as PGV doesn't ignore anything upon import, but it would not know how to display the 1 _EVEN tag and would not show the subordinate tag of 2 TYPE.
-Stephen
I've made the change from _EVEN to EVEN and import it again. No errors anymore. I don't understand where I could check de 2 TYPE (DATA or what?). For the moment I go to concentrate on the other errors :-).
Without actually seeing the parts of the GEDCOM where the 1 _NEW records appear, we can't give you any meaningful advice on how this output from the Aldfaer program should be handled in PhpGedView.
Stephen gave you some generic advice, but to give you advice that's specific to your situation, we need more information.
The structure is always the same and after '1 EVEN' comes always '2 TYPE 1'. No futher DATA.
0 @I3162@ INDI
1 RIN 3162
1 NAME Jannetgen/Baes/
1 SEX F
1 CHR
2 DATE 4 SEP 1604
2 PLAC Rijsoord
1 FAMC @F1337841572@
1 EVEN
2 TYPE 1
2 DATE 28 MAY 2012
3 TIME 10:24:15
1 CHAN
2 DATE 4 JUL 2012
3 TIME 13:20:48
You misunderstand.
We need to know what the structure of the GEDCOM produced by the Aldfaer program looks like, around the _NEW records. Without this information, we are not able to advise you how the output from Aldfaer should be modified to produce something that PhpGedView (and other similar programs) can understand.
We inquired earlier:
The same may still be true. Using EVEN to record previous log of changes would not be correct, as EVEN usually signifies an event in the life of an individual or family, not a 'bookkeeping' event.
webtrees maintains a change log that is both searchable and filtered in the admin section. It shows both previous data and changes. It you do not have a restriction of disk space (database size), you can keep all your changes. This is a more approriate method of maintaining a change log. If your _NEW does log changes (and then, only the date and time and person, but not the actual values changed, it does you little good and, in my case, we make hundreds of changes each day, so my gedcom would be well over 1gb, maybe 2 and the database would become unmanageable.
-Stephen
I don't really understand what you both asking and saying. I thought I gave the stucture. Perhaps my English is not good enough to understand it all.
For the moment I dropt the question of the meaning of _NEW at the forum of ALDFAER.
Have you posted the code from Aldfaer's output for a snippet containing the _NEW tag? I didn't think I had seen it, only your comment "Unrecognized GEDCOM Code: _NEW"
If you post a snippet, it should be pretty obvious what the tag represents and attempts to convey. I suspect that it is similar to the Last Change tag.
-Stephen
If you are confused about what we're asking for, the simplest solution is to send either me or Stephen a copy of the entire GEDCOM, as it was originally produced by the Aldfaer program. Either Stephen or I can then look at the file and determine what the Aldfaer program is trying to say.
You can send a ZIP copy of the GEDCOM file produced by Aldfaer to me: gkroll at keldine dot ca . I don't see a need to actually load that GEDCOM file into my copy of PhpGedView.
I have received the requested GEDCOM.
A typical GEDCOM record for an individual follows:
Several things can be noted here:
- The 1 _EVEN records with sub-record 2 TYPE 1 seem to describe the date and time the individual was added to the Aldfaer database. They should be removed. Apparently, there is an Aldfaer Export option for this.
- The given name is not separated from the family name. The space is missing. If there is an Aldfaer Export option for this, it should be used. Otherwise, PGV can add the missing space by doing a batch Edit from the Admin menu.
- The Fyyyy numbers are very large. These large numbers make it hard to refer to families by their IDs. Unless Aldfaer has a re-number option, there's not much that can be done about this. PGV can't do this right now.
Sorry:
My text refers to the 1 _EVEN sub-record. It should, in fact, refer to the 1 _NEW sub-record.