Re. First Impressions
Date: Fri, 5 Jul 2002 10:35:49 +0100
Fred Rump has a file with lots of rejections.
Fred, the reason why John Hanson asked what file produced your GEDCOM is that the problem usually is that there is a mistake in the GEDCOM somewhere, and its often easier to work out what the mistake is if you know which file produced it (also - its helpful to try to keep track of which programs make which mistakes - most of them make at least some mistakes in some versions). In this case, I think the problem is that the rejected GEDCOM is indeed slightly wrong, and Family Historian has correctly rejected it as invalid. That said, I also think that Family Historian is less tolerant than it should be of slightly erroneous GEDCOM, and I will be looking at ways to make it more tolerant in future releases.
The first thing to say is that when you look at your exception report, the lines tell you what has been rejected. But if you want to know WHY the lines have been rejected, you can ignore all lines which contain 'skipped branch line'. What 'skipped branch line' means is that there is nothing (or need be nothing) wrong with this line per se, but it is a 'branch' line of a line that was rejected, and skipped, and it too has had to be skipped as a consequence. GEDCOM lines form a hierarchy - if you chop off the main part of a branch, other branches that come off that branch have to go with it so to speak.
Looking at your error report, the lines that were actually rejected had 'Skipped Invalid Line' in front of them. There were only 3 of these in the example you sent. All 3 had a single '@' character on their own in the data. Believe it or not, that is not valid GEDCOM. The '@' character is used in a special way in GEDCOM, and if you want an '@' character to stand for itself, you have to double them up - i.e. have 2 of them.
So, for example if you changed the line 1 NOTE Juling@zfn.uni-bremen.de wrote the following:
to
1 NOTE Juling@@zfn.uni-bremen.de wrote the following:
you will find that not only will that line load OK, but so will the 11 CONT lines that are associated with it.
When you look at the note in the program you will only see one @ sign of course. The chars have to be doubled when saved to the file, and undoubled when it is loaded (computer programs do this sort of thing all the time). Incidentally, the only case where the above doesn't apply is in the example you sent in your 2nd email. However, I copied and pasted that into a GEDCOM file and it loaded fine. Are you quite sure it didn't load OK in your file?
However, you should also read my Bug Warning email to the list re. @ signs in today's mailing list.
You also wrote:
>> What's with the capitalizing of names with the Umlauts staying in small letters? One way or the other should do.