I have been using PhpGedView for many years. I recently upgraded to 4.2.3, upgraded MySQL, and upgraded PHP to make it all work. Now many of my people have a bogus (unknown) tag just before the last name . . . no idea where that comes from. Example: http://www.corduan.com/PhpGedview/individual.php?pid=I24&ged=Cordua.GED . . . here is the raw Gedcom for that person. Any clues?
0 @I24@ INDI
1 NAME Carl Georg Heinrich /Cordua/
2 SURN Cordua
1 SEX M
2 DATE 27 AUG 1800
1 FAMC @F4@
1 NOTE Family tree says "early" for death
2 DATE 26 FEB 2008
3 TIME 14:44:22
2 _PGVU nys
1 OBJE @M1@
1 OBJE @M2@
1 OBJE @M4@
1 OBJE @M5@
2 DATE DEAD
2 NOTE "Early" is note on family tree when death date should go
1 NOTE Nys says:
2 CONT "geb. 27.VIII, get. 31.VIII.1800 zu Wardow. Paten 1) Pensionär Schroeder zu Kobow, 2)Schreiber Berg zu Diestlow, 3) Bürgermeister Cordua zu Sternberg
2 CONT Ist anscheinend früh gestorben. Denn sein Bruder Theodor schreibt in seiner Lebensbeschreibung, daß er mit zwei älteren und einem jüngeren Bruder erzogen worden ist. Auch lebten bei dem Tode seiner Mutter nach ihrer Todesanzeige nur noch sieben Kinder.
2 CONT Unterlagen von Hayo Pfohl"
Figured it out . . . *sigh* . . . apparently the new version demands a GIVN tag, whereas the old version did not. When I add that, my (unknown) disappears.
Is this a feature or a bug? :-)
This is an "undocumented feature" (i.e., a bug).
You can fix the problem by editing each name and saving it. You don't actually have to change anything. This will automatically add the missing 2 GIVN sub-record.
The other way of fixing the problem is to delete the 2 SURN sub-record by editing the raw GEDCOM.
I don't think there will ever be a fix for this bug.
Did you mis-type the version number? If not, you should really be upgrading to the "SVN" version which can be downloaded by using the link given in a recent Help topic. This version self-identifies as 4.3.0 SVN, but is really 4.2.4 with additional bug fixes. There is no "unstable" code in the SVN version.
I copied the version from the Admin screen . . . 4.2.3 . . . what is "SVN"? I am all for "no unstable code" :-)
I AM still a bit gunshy . . . I have had my database up for years . . . I faithfully backed up my gedcoms, downloading and saving . . . turns out whole legs where not being saved in the downloads. And records were dropping out as time went on, but I didn't realize it.
The symptom that forced my hand in upgrading from 4.0.1 was that I was getting weird "I can't find your XREF record" errors when adding now people . . . yet everything was still showing up on the web. So I have a clobbered database that I am trying to piece back together from Google caches and the like. It has been an awesome piece of software, and I can't argue the price . . . so not intending to whine excessively :-)
It's good that you upgraded from 4.0.1. You could have fixed the problem by exporting the database to a GEDCOM and then re-importing that GEDCOM into the database. During this process, you would let PGV erase existing database records but keep the media information.
"SVN" is the development repository used by the programmers working on PhpGedView to share their updates and to make them available to the public. As such, it's the "latest and greatest".
Currently, there's only one person (me) working on any aspects of PhpGedView. I like to think that I'm very careful about releasing any untested code to the public. This doesn't mean that I don't make mistakes, but these never see the light of day.
Look for the Help topic that starts with Repost:. You can follow the instructions to upgrade. The procedure is the same for upgrading to 4.2.4, but the download location is different.
You shouldn't have any problems going from 4.2.3 to either 4.2.4 or 4.3.0 SVN, but it's important to export the database to a GEDCOM file before upgrading and then re-importing the previously exported GEDCOM as the first thing to do after the upgrade. As usual, it's wise to do site and database backups first.
Hey, thanks for what you are doing. I am sure at times a thankless, time consuming job. I am a geek myself (full time programmer in industry), Visual Basic, C, a bit of Java, PHP, some PERL (I went to college with the author Larry Wall, knew him well . . . reflected glory), Oracle PLSQL . . . with my love of genealogy (and more time?) maybe one of these days I can get positioned to also be of help. I would love it.
I will get the latest and greatest and install . . .
BTW . . . do you know of a PC based package that can interface fairly seamlessly with the PhpGedView gedcoms? After what happened I really feel a need to keep a live, validated backup locally where I have full backup capability . . .
Legacy seems to be the best off-line package.
I'm using Family Tree Maker, 2006 version. This is fairly decent, but it does cost some money and the version I have is very stupid about handling media files. I haven't upgraded to their latest-and-greatest because I don't like the and "improved" user interface.
Why not run a local server, MAMP, XAMMP, LAMMP or others and simply install PGV. For the last seven plus years, I've run no other genealogy software but the main, online program.
Of course frequent backups of all your data are a good idea, in multiple locations, but this is relatively easy to do.
Great idea, Stephen . . . had thought of that.
I DO own FTM (boo, hiss - I have a problem with Ancestry.com and their attempt to control every source of free genealogical information, as well as the liberties they assign themselves to your own data should you choose to publish to the web with their help) . . . Plus the inability - at least in the past - to have media files work the same in both environments. But may try that out again. Legacy sounds like something to check out.
I did make the upgrade last night . . . and after all these years finally committed the unpardonable sin of deleting my config.php (*sigh*) . . . I had a copy from 4.0.1 which I worked into config.dist so, for now, I think I am back on the air.
Back to what could have saved me before . . . am I to understand that when I do a "Backup" that does NOT do the step that an "Export" does, that is align the .ged with the actual data? I did lots of those Backups . . . but never overtly the "Export" because I presumed that "Backup" would cover me . . .
I don't know about "backup". I doubt that that would create a new GEDCOM from the database.
The key here is that your database and the GEDCOM were not in synch. Normally you'd treat the database as being correct, since that's what's used to display most of your data. So: Create a new GEDCOM from the database, and then re-import that newly created GEDCOM.
Log in to post a comment.