More fractured records in MySQL
Brought to you by:
canajun2eh,
yalnifj
Menu
▾
▴
Hi John,
At this time I tried another install of phpGedView at the 1go.dk server, only this time at http://phpgedview.1go.dk
At http://phpgedview.1go.dk I already had a copy of phpgedview ver. 2.50 installed and running with one gedcom only.
Before trying to install phpgedview ver. 2.51b I first deleted the gedcom from the gedcom administration.
Next I erased all the old files via FTP, and uploaded the ver. 2.51b files to the server and chmod the new index directory and the new config.php
Then I uploaded eckmann.ged and imported it, then I uploaded royal.ged and imported it.
When trying to manage the existing users I noticed a warning at the checkbox for royal.ged but no warning at the checkbox for eckmann.dk. The reason for the warning at royal.ged probably is, that it was the first time this gedcom was imported to this copy of phpGedView.
At this time I started to use this install of phpGedView, which apparently was working the way it was supposed to.
Several hours later I decided to play with the gdbi interface, in order to try the new getxref command. At this time I realized that I once again was obtaining confused and strange results.
When trying to getxref position first, it returned something like I3039 when I tried to getxref position next it returned a lower number, when I tried to getxref position prev it returned a higher number
At this point I tried to switch from eckmann.ged to royal.ged, and when working with royal.ged the getxref was working correctly.
When inspecting the eckmann.ged, everything was fine in the gedcom file and the order of the records in the gedcom file was unaltered, starting with I1 and ending with I3120 completely unbroken and in perfect order.
When Inspecting the Contents in MySQL it revealed a completely fractured order, and here there hasnt been attempted any editing via gdbi.
In phpMyAdmin the first 30 records couldnt be inspected. The first record appeared to be I3039, the next was I3036, then I3037, I3038, I3034, I3035, I3018
When browsing through the records in MySQL, it appeared that error messages was also written into the MySQL database used for this install.
When I reached the royal.ged records in the MySQL, they appeared to be in perfect order.
From these new findings I now realize that the fractured order of the gedrecords in the MySQL has nothing to do with editing via the gdbi interface, because at this site editing was never attempted.
I can guarantee that the order in my gedcoms has never been fractured, so somehow phpGedView must somehow be responsible for this fracturing dont ask me how, because I dont have the faintest idea.
From the other install at http://hoppalong.1go.dk/phpgedview I learned that the fracturing doesnt happen if the old tables are manually dropped completely before a new install is attempted, but here at http://phpgedview.1go.dk I didnt manually drop the old tables before I made the new install my guess is, that the fracturing wont happen if I now manually drop the tables and removes the gedcoms and associated files completely before making a new upload and install of the gedcom files.
But, in order to give you a chance to inspect the eckmann.ged file and the fractured copy in the MySQL Ill hesitate until you had a chance to examine it. Just drop me a line, if you are interested in getting access, and Ill send you the username and password.
As to the error messages inside the MySQL, I have no idea, if these error messages are leftovers which cant be removed - from earlier versions, or if these error messages are fresh, but I can say, that I experienced no trouble during the install of ver. 2.51b.
Best regard
Arne
The warning in the user administration was probably because the user existed before the gedcom was present and the variable in the user array specifying whether the user had edit privileges for that gedcom didn't exist yet. I'll have to check for that.
I looked at the errors in your database tables and I don't think that they came from phpGedView. They reference the url sql.php which I think is a phpMyAdmin page. So I am thinking that it is phpMyAdmin that corrupted the tables, probably because of the UTF-8 characters in them. phpMyAdmin uses the ISO character set by default.
I'm not sure why they are in the wrong order however. My database has the same problem, but they aren't just in reverse order. The start with ID 6134 and then go to 6135, 6136, etc to 6143 at which point they jump to a different number. I verified that PhpGedView is printing them out in the correct order because it prints out the numbers as it adds them to the database and it adds them in order starting at I1 and going to I6900+. So I can only guess that it is MySQL that is reordering them. I wonder if it has to do with the way MySQL keeps its indexes, but right now I don't know how to prevent the reordering. Other GEDCOM don't seem to have this problem. Your royal.ged gedcom for example. Some of my other GEDCOMS don't have this problem either.
--John
Hi again John,
In regard to the question if certain GEDCOMs create problems or not, I can say:
When I installed royal92.ged at http://hoppalong.1go.dk/phpgedview its representation in MySQL became fractured.
I can add, that prior to installing royal92.ged, I didn't manually drop the existing tables.
After being aware of the fractured representation inside MySQL, I removed the GEDCOMs and all the files and manually dropped the tables in the MySQL. Then I uploaded a fresh copy of phpGedView to the server and made a fresh install, and after that I uploaded the GEDCOMs and installed them, and found that this time the representation in MySQL of royal92.ged didn't become fractured.
Yesterday I installed another phpGedView at the 1go.dk server, only this time at http://phpgedview.1go.dk
Before installing the first GEDCOM, eckmann.ged, I ignored to manually drop the existing tables prior to installing eckmann.ged.
As a result eckmann.ged became fractured inside MySQL.
When installing royal.ged to the MySQL it didn't represent a problem, because prior to this install there only was installed one GEDCOM in this database.
As a result, the royal.ged didn't became fratured inside MySQL.
Today I removed the phpGedView at http://phpgedview.1go.dk and manually dropped all the tables inside the database.
Then I uploaded a fresh copy of phpGedView and made a fresh install, and then I uploaded eckmann.ged and installed it, and then I made a upload of royal.ged and installed it.
This time the representation of eckmann.ged wasn't fractured inside the MYSQL - as well as the representation of royal.ged wasn't fractured inside MySQL.
Before installing the first GEDCOM, eckmann.ged, I ignored to manually drop the existing tables prior to installing eckmann.ged.
As a result eckmann.ged became fractured inside MySQL.
When installing royal.ged to the MySQL it didn't represent a problem, because prior to this install there only was installed one GEDCOM in this database.
As a result, the royal.ged didn't became fratured inside MySQL.
From these situations I learned, that at least the first GEDCOMs representation was fractured inside the MySQL, if I ignored to manually drop all the tables in the database before making the first import.
From these situations I also learned, that none of the GEDCOMs representation became fractured inside MySQL, if only all the tables was manually dropped before attempting the first import.
best regard
Arne
This is very interesting... I have one gedcom in the database. If I manually drop the tables and import the file, they are listed in the correct order, just as you mention above. Then I tried reimporting the file without dropping the tables, and found that every time I reimported, the order of items in the gedcom was different.
But, if I manually drop the tables again and reimport the items are again listed in the correct order. I am going to look at the MySQL documentation and see if I can find a reason for this behavior.
--John
I decided to upgrade to the latest verison of MySQL 4.0.15. Now whenever I import I get the records in the same order, but instead of being I1, I2, I3, which is the order they were imported they are in the order I1, I10, I100, I1000, I1001, I1002...
At least it is consistent though. The same order after every import whether I drop the tables or not.
Maybe the best option will be to sort the list by ID for the getnext and getprev commands. It is not a perfect solution, because they could be listed out of order in the GEDCOM.
Index files should not have this problem.
--John
Hi again John,
Thank you for looking into this problem and for taking the trouble of upgrading to the latest version of MySQL!
Since many users doesn't have the option of changing to another version of MySQL but has to accept whatever version their webhotel provides, I guess it's bad news for those interested in online editing, that the older versions of MySQL are unfit for online editing, and that even the latest version - although different from the older versions - also are unfit for online editing - that is, if the online editing demands that the order of the records must be identical in the GEDCOM and in the MySQL :-(
In regard to the errormessages inside the MySQL, I agree with you, that it doesn't necessary mean that the MySQL structures are broken, but that it - perhaps - more likely indicates that the phpMyAdmin has trouble dealing with certain (so far unknown) conditions in my GEDCOM.
I have located the 3 troublesome records in my GEDCOM where the trouble in all 3 cases are caused by some (so far unknown) conditions in 3 large notes.
When testing the MySQL it said, that it was okay, and that no errors was found.
When looking at the offending records in phpGedView it also appeared to be alright. I tend to agree with you, that the errormessages must be phpMyAdmin related.
I'm not so sure if the errormessages has anything to do with the international characters in UTF-8 versus the phpMyAdmins usage of da-iso-8859-1 to do, because there are plenty of UTF-8 coded international characters in my GEDCOM that doesn't create havoc in phpMyAdmin.
After having located the 3 offending notes I tried to import a renamed version of the GEDCOM from which the offending notes had been removed. And once the 3 offending notes was removed, the errormessages didn't appear.
The phpMyAdmin at 1go.dk is a somewhat older version, so maybe the problem is fixed in the newer version. My regular webhotel at eckmann.dk has the latest version, but at this time I can't check it because the owner of the webhotel, is out of town all week, and immediately after he left on sunday evening, his cable-provider changed the IP address to the webhotel, causing the webhotel to be off-line until he returns home and re-program his routers :-(
best regard
Arne
Hi John
For what it's worth I now had a chance to check my Eckmann domain for the errormessages inside the MySQL tables.
This webhotel uses the SAMBAR server, phpMyAdmin ver. 2.5.3-rc1 and PHP 4.3.1.
I don't know what version of MySQL is used, but I can say that the errormessages are not produced at this server.
best regard
Arne