A friend of mine has entered about 36,000 people into the database in PRO-GEN.
He would like to transfer to Gramps. Because he himself is not sufficiently knowledgeable in the field of PCs, he asked me to look at it.
Direct import via the Gramps plugin where the message No (Correct) DEF file: PG35-1.DEF is displayed.
Am I missing something here, do I need a different version of PRO-GEN?
GEDCOM is not an option because too much data is ignored, especially address data.
A folder pg30 has been created on my PC containing the following files:
/home/marteng/pg30/THEIKE1.CHK
/home/marteng/pg30/THEIKE1.DEF
/home/marteng/pg30/THEIKE1.IXI
/home/marteng/pg30/THEIKE1.IXP
/home/marteng/pg30/THEIKE1.IXR
/home/marteng/pg30/THEIKE1.MEM
/home/marteng/pg30/THEIKE1.PER
/home/marteng/pg30/THEIKE1.REL
/home/marteng/pg30/THEIKE1.X11
/home/marteng/pg30/THEIKE1.X21
Which version of PRO-GEN is your friend using?
From the āmissingā error, is it 3.51? (The Pro-Gen list the current version as ā09/02/2022 PRO-GEN version 3.51ā.)
From the wiki, Iām guessing the Pro-Gen Importer plugin module was written in 2017 for Pro-Gen 3.0
The Pro-Gen change log shows changes to the .def files since the Gramps importer was created.
Do you have that file somewhere, or is what you listed all that you have? And how do you mean that that pg30 was created? Was it created by a Pro-Gen installer? Did you extract a ZIP file that you got from this friend? Can you run the latest Pro-Gen (demo) in Windows somewhere?
Gramps probably needs this DEF file to know where all the data fields are, and their types.
I got a ZIP file from my friend and extracted it on my PC. I only have a linux machine with gramps installed.
The files he zipped came straight from te ProGen directory.
That line in the DEF file is probably just a reference, so that you can work with different database definitions, when needed. And that file is installed by the Pro-Gen installer, which may work in Wine.
In all honesty, I must say that if heās not sufficienty knowledgable with PCs, migrating to Gramps is most likely not a very good idea, because Gramps is more complex than Pro-Gen, and stores all data in hidden folders, which are much harder to explore than the files stored by Pro-Gen.
This suggests that a ZIP with the full PG30 folder might help, because in that case. the DEF file is included. There mught be a problem though, because like @emyoulation already mentioned, the importer was probably written and tested with version 3.0, and not newer.
We want to move the data from him to gramps, because the date is hidden but in sqlite format, a regular worl standard for databases. If that succeeds I will give it a try to move it to postgresql in gramps web. The database W work with in AEZEL. I want to give it a try to include the webgramps in our site a a genealogical alternative where interpretation can be done. AEZEl itself just works with the documents itself. There is no room for interpretation. Gramps or WebTrees could be a welcome addition.
Itās OK, but I fear that it wonāt help, because Gramps 5.1.6 gives the same error for his file as it does for the files that are included with the Pro-Gen demo version. They all use the 3.51 definition, so I have that DEF file already, and with that file included, Gramps runs into another error with some buffer size, which I may try to debug, when Iām in Linux again, but I canāt promis anything.
This suggests that the import was indeed written for 3.0.
I did a short test with a debugger, but I have no real clue about the changes between 3.0 and 3.51, so I have no idea how to change the import code to make it work, and the original author of the importer hasnāt been active after 2016, according to his history on GitHub.
I was able to test this, because the missing DEF file is included with the 3.51 demo, so that part was easy to solve. The real problem is that there was a change in the file format, for which I have no idea what it is.
This suggests that GEDCOM will be the only option left, and maybe the extra data can be recognized in there.
I just had another look at the code, and I think that the GEDCOM import can be improved, so that it can import addresses like these:
1 RESI
2 ADDR Overhoven 59
3 CITY Sittard
In 5.1.6 and 5.2.2, this address is imported as a place named āSittardā of type āAdresā, which is quite weird by itself, because itās exported as a city. And in addition to this, Gramps adds a note saying that the ADDR line was ignored, and it does that, because it doesnāt understand that this line shows a street address.
And this part is inconsistent, because in the same piece of code, it does recognize a line with an ADR1 tag as a street, and in the standard, that ADR1 is the equivalent of the first ADDR line, so that the standard implies that the ADDR line itself, when filled, is a street.
Tamura Jones explained this 12 years ago on this site, in an article thatās also mentioned in our import code:
Many thanks Enno.
We did give it a try today but as you already mentioned, the import fails.
I have a few urgent matters to attent to so it will take a while. But I will report to you if I find an answer.
Before printing this email, think about the environment.