editgedcoms.php is trunkated (4.2)

[Ely Schoenfeld]

This is a very strange error I'm Having.

***CURRENT STATE:

I'm upgrading from PGV 4.1.3.

I have two whole installations in different directories, because I manage two (non-related) separate family trees. Both point at the same database (with different prefix for each set of tables).

Something like this:
"www.example.com/tree1/"
"www.example.com/tree2/"

I created a new database and copied the data from the old-one. Also got new directories for the 4.2 installations. This way I have both version running at the same time, so I can go back and forth comparing both.

Also have lots of backups.

***THE PROBLEM IS THAT I CANT UPGRADE THE DATABASE ON ONE OF THEM:

Before any database update, one of the two family trees on the 4.2 editgedcoms.php page only shows until the line that contains something like:

<code>GEDCOM file xxx/xxx/xxx.ged (11.03Kb)  Import   Export Delete   Download   Check </code>

And the other one shows all the page, until the last legend that says <code> Printer-friendly Version</code>

Of course, in the 4.1.3 both look fine.

On the truncated one, If I click on the "Import" link, the next page doesn't show the "Continue" button, so I can't upgrade the database.

Something strange, is that I added some "system('logger ...);" lines in there all along the file, and they all get executed. So the whole page is being processed. But it isn't sending all of it to the browser.

I hope this is not too long and someone out there read it all.

Does anybody has any suggestions on how to fix this, so I can upgrade both trees?

Thank you all in advance.

Ely.

***STEPS TAKEN:

The relevant parts of what I did are:

a) exported the gedcoms and copied them over to the server.

b) Created a different sub-domain, so I'll be able to access the 4.2 trees like this:
"www2.example.com/tree1/"
"www2.example.com/tree2/"

c) Took a copy of the 4.1.3 version directories on a directory called "bak" and fixed:
c.1) the links to point to the new domain,
c.2) database username and password to point to the new database.
c.3) the $INDEX_DIRECTORY variable, so both the old ones and the new ones point to the same directory

d) uncompressed PhpGedView-all-4.2.zip
in a "tree1" called directory.
and again in a "tree2" called directory.

e) Then executed:

DIR=tree1
cd $DIR/
rm -Rf config.php
cp -Rp ../bak/$DIR/config.php .
rm -Rf index/
cp -Rp ../bak/$DIR/index/ .
rm -Rf index/cache/
rm -Rf media/
cp -Rp ../bak/$DIR/media/ .
cd modules/punbb
rm -Rf config.php
cp -Rp ../../../bak/$DIR/modules/punbb/config.php .
cd ../../..

and then again with
DIR=tree2

That's all.

When I go to
"www2.example.com/tree1/editgedcoms.php"
everything works fine, but it doesn't work when I go to:
"www2.example.com/tree2/editgedcoms.php"

The server has:
PHP Version 5.2.5
Apache Version 1.3.39

[Ely Schoenfeld]

I don't know. I can't find out what is happening.

So I decided install from scratch.

What was my surprise? the GEDCOM file that I downloaded from version 4.1.3 Has some errors in it. And it was created with that version of PGV.

When importing the file in the 4.2 version I get:

ERROR:-3 DB Error: constraint violation
SQL:INSERT INTO pgv_q_placelinks VALUES(8, 'I6', 1) [nativecode=1062 ** Duplicate entry '8-I6-1' for key 1]

ERROR:-3 DB Error: constraint violation
SQL:INSERT INTO pgv_q_placelinks VALUES(1, 'F1', 1) [nativecode=1062 ** Duplicate entry '1-F1-1' for key 1]

I searched for multiple I6 persons, but found only one, and a reference as a child and a reference as a husband

So I decided to go check the file in the 4.1.3 version that is still running, and I found out a lot of warnings... only one Error:

0000277[[2 ROMN xxx /yyy/]]  missing INDI:NAME:ROMN:TYPE; see INDI @I16@

So, why are those constraint violations happening?

Any ideas?

[Greg Roach]

1) I think you can safely ignore these errors.  They need to be trapped (and either reported as warnings or ignored).

2) They *might* be caused by having the same place with different upper/lower case letters in I6 and F1.

[Ely Schoenfeld]

Thank you very much for answering.

In fact I haven't found any problem with the tree... so I guess you are right :)

Will keep looking.

Ely.