I am starting to get a headache.
Please look at http://www.mekinda.com/phpgedview/indilist.php?alpha=A Why do I have all these other names? Also G,S and U only. I have checked all the raw gedcom files in the data base and see no difference between configurations. As the privacy is switched on, some of the names also appear.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Probably a collation issue. I'm sure there is a discussion and solution to this in a bug report, but I can't find it. The tracker search tells me that there are no bugs relating to the word "collation". I know it is lying.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is exactly what I felt, and therefore I checked my other PGVs db that do not have the problem and collations are identical. The only difference I see that this problem started when I upgraded about two weeks ago to 4.2.3. I noticed that the number of tables is only 30 and the the older upgrades have 48 tables. Tables also appear to be disimilar. I can see the problem arising with special characters, but why would C be listed under A?
There are only a dozen or so names that cause a problem - is there a manual workaround?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Collation - Collation - Collation. I've mentioned this previously and now Greg has done so. Its probably too late for the set of gedcom data as you have probably corrupted it. You need to export your original data or return to the original import gedcom and do it again - after you fix your collation to handle the accented characters. utf8_unicode_ci wuld be preferred collation. What is yours' now?
Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do not recall you mentioning previousley collation. Both PGV s (one that works and the other that does not)
MySQL connection collation: utf8_general_ci
Tables collation: latin1_swedish_ci
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
mjm
I am intimately familiar with this issue as, in JUL 2009, I had many of the same issues when I updated some SVN changes and MySQL 5.0+. Suddenly, my A's, C's, and several other letters displayed other initials/names other than the main category. My data had become corrupted and was not being processed properly. I had to change my collation of the tables to utf8_unicode_ci from latin1_swedish_ci using Greg's patch (under patches) and then I had a few names I had to manually fix that had become corrupted. Given that my gedcom is over 70,000 names, it was a bit of a chore, but now all is smooth in operations. I used this opportunity to switch my DB from MyiSam to Inno-DB as well and I haven't looked back. You can see from my site that, despite a large gedcom, operations are quite peppy and I do not have the name errors you experience.
-Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK I exported all the tables. Opened it in my text editor. Clearly the file sql is UTF-8 file. So the next step is to find and replace Find what ? I have entries such as DEFAULT CHARSET=latin1, CHARACTER SET utf8 COLLATE latin1_swedish_ci NOT NULL and others.
In one of the earlier responses I was told to go with utf8_unicode_ci , but the patch mentions only utf-8.
I guess after making modification I must save the file as utf-8
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The patch has three options. Export, convert and import. Run them in that order. Between convert and import, you should also change the USE_DB_COLLATION config option to yes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Before you reimport make sure you change the *database table* collations to utf8_unicode_ci. As I recall you have to go through each table and make sure every field of every table is set to utf8 before you reimport.
I've had to do this as well, and as Stephen says it's worth it once all is well again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I very much appreciate your responses, but I do not see where you convert. I exported the tables and they ar on my machine now. You say I need to convert before import.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just check the inport function and the only thing it has utf-8 and others. Are you saying that once the db is imported go through it manually and change to utf8_unicode_ci?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are you actually running the db_export.php script that we told you to download?
It has three buttons (repeated for each table) - export, convert to utf8 and import. (The import button won't display until after you have exported as there is nothing to import)
There are no options, no manual changes. The instructions are very simple.
1) Click the buttons in order
2) Edit the "Use DB for collation" setting at some point between export and import.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
BTW you say "Between convert and import, you should also change the USE_DB_COLLATION config option to yes."
I have no such animal in my config file, the only thing I have is $DB_UTF8_COLLATION=false I assume you are talkinking about this variable which should be set to true and not yes?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is exactly what I was following. Nothing to download. I exported using phpMyAdmin as the suggested. So where is this script? Are we going around circles or should I start a new tread?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am starting to get a headache.
Please look at http://www.mekinda.com/phpgedview/indilist.php?alpha=A Why do I have all these other names? Also G,S and U only. I have checked all the raw gedcom files in the data base and see no difference between configurations. As the privacy is switched on, some of the names also appear.
Probably a collation issue. I'm sure there is a discussion and solution to this in a bug report, but I can't find it. The tracker search tells me that there are no bugs relating to the word "collation". I know it is lying.
This is exactly what I felt, and therefore I checked my other PGVs db that do not have the problem and collations are identical. The only difference I see that this problem started when I upgraded about two weeks ago to 4.2.3. I noticed that the number of tables is only 30 and the the older upgrades have 48 tables. Tables also appear to be disimilar. I can see the problem arising with special characters, but why would C be listed under A?
There are only a dozen or so names that cause a problem - is there a manual workaround?
Collation - Collation - Collation. I've mentioned this previously and now Greg has done so. Its probably too late for the set of gedcom data as you have probably corrupted it. You need to export your original data or return to the original import gedcom and do it again - after you fix your collation to handle the accented characters. utf8_unicode_ci wuld be preferred collation. What is yours' now?
Stephen
I do not recall you mentioning previousley collation. Both PGV s (one that works and the other that does not)
MySQL connection collation: utf8_general_ci
Tables collation: latin1_swedish_ci
mjm
I am intimately familiar with this issue as, in JUL 2009, I had many of the same issues when I updated some SVN changes and MySQL 5.0+. Suddenly, my A's, C's, and several other letters displayed other initials/names other than the main category. My data had become corrupted and was not being processed properly. I had to change my collation of the tables to utf8_unicode_ci from latin1_swedish_ci using Greg's patch (under patches) and then I had a few names I had to manually fix that had become corrupted. Given that my gedcom is over 70,000 names, it was a bit of a chore, but now all is smooth in operations. I used this opportunity to switch my DB from MyiSam to Inno-DB as well and I haven't looked back. You can see from my site that, despite a large gedcom, operations are quite peppy and I do not have the name errors you experience.
-Stephen
mjm
take a look at this thread for comparison to your issues:
https://sourceforge.net/projects/phpgedview/forums/forum/185166/topic/3330415
Again, this was solved by using Greg's patch:
https://sourceforge.net/tracker/?func=detail&aid=2318005&group_id=55456&atid=477081
Stephen
thanks for the links. Where do I download the patch? wiki is not working?
mjm
NOT in the wiki at all. The 2nd link above is straight to the patch.
-Stephen
OK I exported all the tables. Opened it in my text editor. Clearly the file sql is UTF-8 file. So the next step is to find and replace Find what ? I have entries such as DEFAULT CHARSET=latin1, CHARACTER SET utf8 COLLATE latin1_swedish_ci NOT NULL and others.
In one of the earlier responses I was told to go with utf8_unicode_ci , but the patch mentions only utf-8.
I guess after making modification I must save the file as utf-8
Do not edit the files in a text editor.
The patch has three options. Export, convert and import. Run them in that order. Between convert and import, you should also change the USE_DB_COLLATION config option to yes.
Before you reimport make sure you change the *database table* collations to utf8_unicode_ci. As I recall you have to go through each table and make sure every field of every table is set to utf8 before you reimport.
I've had to do this as well, and as Stephen says it's worth it once all is well again.
I very much appreciate your responses, but I do not see where you convert. I exported the tables and they ar on my machine now. You say I need to convert before import.
<<but I do not see where you convert. I exported the tables and they ar on my machine now>>
The "convert to UTF-8" button is immediately adjacent to the "export" button.
PS - you have taken backups, haven't you??
I just check the inport function and the only thing it has utf-8 and others. Are you saying that once the db is imported go through it manually and change to utf8_unicode_ci?
Are you actually running the db_export.php script that we told you to download?
It has three buttons (repeated for each table) - export, convert to utf8 and import. (The import button won't display until after you have exported as there is nothing to import)
There are no options, no manual changes. The instructions are very simple.
1) Click the buttons in order
2) Edit the "Use DB for collation" setting at some point between export and import.
No, I used phpMyAdmin to export
Instructions were to 1) export all the tables
Where is the db_export.php script that we told you to download? Where do I download this? Nobody told me about this, I don't think.
BTW you say "Between convert and import, you should also change the USE_DB_COLLATION config option to yes."
I have no such animal in my config file, the only thing I have is $DB_UTF8_COLLATION=false I assume you are talkinking about this variable which should be set to true and not yes?
Post #7.
Stephen posted the URL of the patch.
<<the only thing I have is $DB_UTF8_COLLATION=false I assume you are talkinking about this variable which should be set to true and not yes? >>
Correct. I'm working from memory.
And I asked where do you downd this. And his answer was Post 9 and there was nothing to download!!!!
I said post #7.
Let me copy/paste from post #:
Again, this was solved by using Greg's patch:
https://sourceforge.net/tracker/?func=detail&aid=2318005&group_id=55456&atid=477081
That is exactly what I was following. Nothing to download. I exported using phpMyAdmin as the suggested. So where is this script? Are we going around circles or should I start a new tread?