Modern Software Experience


Access limits

Legacy Family Tree

Legacy 7.5 does not run on my Vista 64-bit system, and Millennia's website documents various issues you may run into when installing it on a 32-bit Windows. Still, I managed to install it on my older 32-bit Windows Vista system with 4 GB of RAM.

Legacy import is not exactly fast, but I just let it run, periodically checking up on it. Legacy imported FAN19.GED just fine, but failed to import FAN20.GED. Legacy did not run out of memory importing FAN20.GED, it just confused itself somehow, and showed a messagebox saying that it could not save the surname, that it could not open its own database, that the file might be corrupt. The messagebox offers to try again, but if you do so, you just get that same messagebox again. I initially wondered whether this was somehow connected to the computer's power-saving mode. To make sure I did not have to mouse the mouse or hit any key to check up on the progress, I decided to run the test with power-saving disabled, just to be sure. Legacy failed again, at exactly the same point in the import process.
I understood why Legacy failed when I looked at the data directory. It seems that Legacy's database format is inefficient. Legacy turned the FAN20.GED file into a multi-gigabyte database. When the file had grown to about 2 GB, the maximum size for a Microsoft Access database, the application crashed. The messagebox I saw wasn't a Legacy messagebox, but a Microsoft Access messagebox.

Legacy 7 Limits


Interestingly, Millennia's own website claims that Legacy supports Individuals and Families File size to 1 billion characters (1 gigabyte), that is only half of what Access supports, yet Legacy does not stop the import when it reaches 1 GB. Their statement does make me wonder whether I should consider the import of FAN19.GED successful; the FAN19.fdb database file that Legacy created is 1.503.694.848 bytes, and that is well over the 1 GB size that Millennia officially supports. If Millennia themselves does not recognise the resulting database as a valid Legacy database, then the import of FAN19.GED has to be considered a failure. The size of the FAN18.fdb database file created upon importing FAN18.GED is 732.569.600 bytes, well within the size limit Millennia supports.

Legacy still uses GEDCOM 5.5 instead of 5.5.1 and uses an _EMAIL tag instead of the GEDCOM 5.5.1 EMAIL tag. It would be better if Millennia took advantage of GEDCOM 5.5.1 and the EMAIL tag, but Legacy's output is valid GEDCOM.
Well, not entirely. Legacy defaults to using the illegal ANSI encoding, and that is wrong. Legacy offers two other choices: ANSEL and UTF-8. That Legacy supports UTF-8 is nice, but UTF-8 requires GEDCOM 5.5.1; GEDCOM 5.5 does not allow UTF-8 encoding. That leaves ANSEL as the only valid GEDCOM 5.5 encoding that Legacy 7.5 supports. It is surprising that Legacy defaults to the illegal ANSI encoding while it supports the legal ANSEL encoding; ANSEL is not only a legal GEDCOM encoding and a better, more powerful encoding, it is also the encoding that GEDCOM specification prescribes for systems such as Legacy.

VGed Legacy FAN4 Invalid

The resulting GEDCOM file contains several GEDCOM extensions such as the _UID tag. All GEDCOM extensions start with an underscore, as they should.
Visually, the GEDCOM file looks fine, but VGed does not like the space after CONT and MARR tags without value; Trailing space(s) not allowed. VGed is right; a tag without a value may not be followed by any white space, but must be followed by the line terminator. The file that Legacy created isn't a valid GEDCOM files.


Legacy manages to import FAN19.GED, but according to Millenia's own information, only by exceeding its documented limits. Therefore, Legacy's fan value is 18 or less.
You need to override Legacy's default and pick ANSEL.
On superficial inspection the generated GEDCOM files seem fine, but that is only because you do not see spaces. The files that Legacy generates includes illegal spaces, and therefore aren't legal GEDCOM files. Legacy's fan value is not 18, but 0.