In a GEDCOM file, records link to other records using special
record identifiers, which appear in the GEDCOM between "at signs"
(@@).
Often these identifiers consist of single letters like
"I" (for "individual"), "F" (for "family"), etc.,
followed by a number that uniquely identifies a particular
GEDCOM record of the corresponding type.
Each application that can create GEDCOM files typically has its
own scheme for creating these record identifiers.
The record identifiers are sometimes preserved across multiple
sessions of editing a GEDCOM and sometimes the records are
relabeled each time the GEDCOM is saved.
Gedcom Viewer provides a Relabel GEDCOM
item under the Tools menu. Selecting this item
causes the records in the currently loaded GEDCOM to be relabeled.
At the moment the relabeling operation simply creates sequentially
numbered record IDs in a standard format -- it is not customizable
in any way. In a later release it might be possible to modify
the scheme by which the record IDs are created.
The main use of this function is in conjunction with
HTML Import Add-on, which creates GEDCOMs with special
record IDs in order to keep track of links and equate records
synthesized from separate documents. The special IDs are not
compatible with some other GEDCOM software. If you find that
this is the case, you can relabel the synthesized GEDCOM before
saving it.
The Check GEDCOM item under the Tools
menu can be used to check the GEDCOM currently loaded into
Gedcom Viewer for various kinds of errors.
The errors currently checked for are:
General formatting problems, such as missing cross reference IDs and misuse of GEDCOM level numbers.
Inconsistencies in sex information, such as a husband in a family having been marked as female.
Problems with the lineage-linked structure. In GEDCOM 5.5 links are bidirectional: an individual links to a family and the family links back to that individual. If any of the required "back links" are missing, it will be reported.
Cycles in the ancestry or descendancy links (e.g. "I'm my own grandpaw"). Surprisingly, many genealogy programs will happily export GEDCOMs with this problem, which makes life difficult for other applications that want to traverse ancestors or descendants for some reason.
Checking for cycles takes a lot of memory, and for large GEDCOMs it might require more memory than the default amount that Java is configured to provide. Should this be the case, you will receive an error message indicating that there was insufficient memory to complete the checking. (It might also be the case that the cycle checking runs very slowly, due to constant scavenging of memory by the Java run-time system.) There is no way for a Java application to increase the amount of available memory "on-the-fly", so the only real solution here is to start Java with a larger "heap size". If you start Gedcom Viewer from a command prompt this is readily accomplished via a command like:
which will start Java with a heap size of 256 megabytes. (The default heap size is typically only 64 megabytes.) However, most people will start Gedcom Viewer by double-clicking an icon on the desktop. I am currently looking for an easy way for users who launch this way to change the Java heap size. When I think of a way of doing it that will likely not create additional problems, I will implement it.