Updated from 4.1 to 4.3.1. The original database for 4.1 under the table individuals maintains the main Gedcom file details under the i_gedcom column.
When updating to 4.3.1 the new database structure adds a new column that did not previously exist called i_sex. Oddly enough when viewing a profile some data calls to this new column and some does not. For example, when I view an individual's profile it calls the sex from the i_gedcom field and properly notes it on the individual's profile. However, in doing a search or looking at various charts it calls to the i_sex column and shows all individuals sex as unknown.
When the new database was created for the 4.3.1 version it did not pull the sex from the i_gedcom field to populate that i_sex column, but instead populated all individuals under the i_sex column as U or "Unknown".
Seems to me having sex listed both in the gedcom and as its own column is a bit redundant, but there may be deeper reasons for this structure that I do not understand.
If I try to edit the individual on their profile page via Edit > Quick Update, again it shows the proper sex notated (per the i_gedcom), so I am unable to correct the "U/Unknown" designation in related charts.
Going to PhpAdmin allows me to see both the i_gedcom and i_sex columns in the individuals table where I can also see that the i_gedcom does properly indicate sex (example 1 SEX F) whereas the i_sex column for all individuals lists U.
I have tried fixing the "U" designation in the i_sex column manually in the database via PhpAdmin but it will not let me manually edit the content. This is not really a good solution for me anyway, if it did, as I have thousands of entries.
I have tried renaming the i_sex column in PhpAdmin to see if that would force the correct sex notation in the charts as a possible fallback, but when I do this it breaks the call to see an individual's profile and simply shows the header with no individual details included. So, consideration of dropping or renaming that column seems to be a no-go as a solution.
Anybody have any ideas on a fix?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When you did your upgrade, did you export the database to a GEDCOM file, using the old PhpGedView, then do the uprade, and then immediately import the previously exported GEDCOM file, letting the Import replace the database contents?
This sequence (export - update - import) is crucial. If you don't follow this, the database tables and indexes won't be properly populated.
Check your GEDCOM file (NOT the database), to see whether the sex is properly recorded there. If it is, just re-import the GEDCOM file, letting the Import replace the database contents.
If you forgot to export the database before doing the upgrade, you can try exporting the database using the new (upgraded) PhpGedView, and then importing the just-created GEDCOM file, again replacing the database contents. I have heard that this will work, but I won't guarantee it.
This may work because the database contains not only individual fields/columns for each genealogical fact, but also a text copy of the the original GEDCOM record for each person and family. The Export only looks at that text, and NOT the database fields.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I may be confused on how to export the database. Is this by going to the admin section and using "Backup"? If so, my older version just goes to a white page. The newer version throws this error: Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 20480 bytes) in .../includes/classes/class_pgv_db.php on line 852
It may be because I have thousands of names listed in the genealogy and it is creating to heavy a lift.
If I am confused in the export Gedcom process, I am sorry. Maybe more details or a link showing, if possible would help.
On the original version I am able to got to Amin > Manage GEDCOMs and edit Privacy and do an export without error. But when I go to the new version and select "Export" it goes to a popup that gives me the same error message as above. If I instead go to "Import" to try and add the one exported from the original the "import> GEDCOM File" box is grayed out, so I can not put anything there and it gives me an error that says: A GEDCOM with this file name has already been imported into the database.
Because I do not want risk any issues I modified your upgrade process slightly. What I did was got to my cPanel and
1. Created a duplicate folder and renamed it.
2. Created a duplicate database and renamed it.
3. Uploaded all 4.3.1 files (in Binary mode) overtop (overwriting) all duplicate files (except, config.php, index and media folders)
4. Uploaded modified config file to notate duplicate database info. instead of original
5. Uploaded a new .htaccess file to notate an upgrade to php 7.4
6. Launched new site that took me into new setup that said it updated tables
7. Tested site. All appears pretty good, except the sex notation now.
In the original I have quite a bit of template/theme/format changes that still need to be addressed in the new, but that was all mostly expected and is off topic of this post. At some point I can address theme mods. That is my my skillset and may help others with a more customized site. During this upgrade process I may even venture into adding Bootstrap to develop a theme that is more mobile friendly. Been wanting to do that for some years. This forced change by my server host may be a good time to dive into that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You MUST do an export - and then - import of the database, using a GEDCOM file as the intermediary.
You access the Export and Import functions by launching the Admin page, and then going to the Manage GEDCOMs and edit Privacy option. There, you should find your database mentioned.
On the line that corresponds to your database, notice the "Export" and "Import" options.
"Export" copies the textual GEDCOM information embedded in the database to an actual GEDCOM file in your /index directory. No need to download that file, unless you REALLY want to.
"Import", unless you tell it otherwise, will read that previously exported GEDCOM file and use its information to populate the various fields and indexes of your database. Be sure to let that Import replace the existing database contents. Since you have exported an existing database, your GEDCOM file contains whatever media stuff was present, so don't change the Media option. If your database already contains media stuff and you import the same media stuff from the GEDCOM file without deleting that existing media information in the database, you'll end up with a mess of duplicates.
The business about deleting Media from the database is there in case the incoming GEDCOM file doesn't contain media records (as would be the case with certain older off-line genealogical programs). In this case, you don't want to destroy what's already in in your database from earlier sessions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I get the memory issue error noted earlier on that export. I will contact my server to see if they can increase my memory limits and to see if that will fix the issue. On my original (current non-testing live version) it does not even show me the export option, but does in the new updated version, which throws the error. Once I can get the server to increase the memory limits and if that works hopefully an export > import of it directly on the new version will correct the issue.
I will touch back with the results/progress.
I did notice if I tried to go to php8.1 instead of 7.4 I got some errors as well. Once I can figure out this part I will set up a new thread to discuss those. I would really love to be able to upgrade as far as possible to limit the need of future upgrades.
VERY MUCH appreciate all help and guidance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is a memory usage limitation configured into the /config.php file referenced by PhpGedView.
This file is an ordinary text file that you can edit manually if you wish (not recommended).
Launch the Admin page, then access the "Configuration" option. You should see the "4. Site Configuration" panel. Click on the "Advanced Settings" tab.
The "Memory Limit" set here, when less than what the server's configuration allows, over-rides the server's memory limit. This value should not be less than 64 Mb. Your server is probably configured to allow PHP scripts to request up to 256 Mb.
Be sure to step through the configuration panels until you're told that the configuration has been saved. To get back to known territory after you've used the Installation Wizard, just click on one of the selections of Step 8.
In older versions of PhpGedView, the lowest recommended memory limit was 32 Mb, but that's not nearly enough. For large databases (about 6,000 persons) you should set this to 128 Mb. 256 Mb is excessive, but won't do any harm; PhpGedView will ask the server to allocate memory as it's needed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, I raised it to 256. My database is a lot larger than 6,000 but 256 seemed to work.
I also adjusted the Session Timeout to 7200 and when importing set the time limit to 360.
That all worked and I now have all the sexes. That is super helpful. Thanks.
In my database I have a lot of singular names. For example, if there was a John Tylor but all I knew was John I included just John (in many cases with no other relatives). Under this scenario if I ran into another John with a missing last name I assumed it was a new John. At some points I am lucky enough in my research after finding enough familial matches to then be able to correlate the two (+), sometimes with a last name and then in those cases I use the merge feature to pull all the data together.
Also, to assist in the way I do research I actually record opposite of what most genealogists would consider correct or intuitive. In the Given Name I use the last name and in the Surname I use the natural name for example John.
What this results in when I do searches is then last name, natural/call name. (Tylor, John). Then that makes it easy for me to search through all Tylor names super easy.
In the old (current used version) this methodology has worked well for years. On searches it would just show John ??? (???,John) as John. However, in the new upgrading version where simple names like John are shown it says John (Given name unknown). I need to figure out how to remove the (Given name unknown) part. Looking through the configuration settings, but it may be that I need to remove it from a language file if not part of settings.
Should I move this to a different topic?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You REALLY have a messed-up genealogical database that's NOT following the rules.
You'll have to mend your ways. I do NOT recommend that you try to modify the program to suit your not following the GEDCOM standard.
In order for the program to function properly, the names need to be recorded in the form
1NAMEgivennames/familyname/
That's what the GEDCOM standard specifies, and that's what PhpGedView expects. You must NOT reverse the order of the family name and given name fields.
When names appear in sorted lists, the program automatically reverses the order of the given and family names. Some languages commonly mention the family name first (eg., Hungarian, Chinese) and for these, the program does the reversal for display purposes, but the database still has the name fields in the "proper" order (according to the GEDCOM standard).
If the given names are not specified (they're missing), the program will show "(Given name unknown)". If the family name is not specified (there's nothing between those slashes or the entire slash entry is missing), the program will show "(Family name unknown)". If both the given names and the family name are missing, the program will show "(Name unknown)"
Notice that in a properly recorded NAME entry, there are no commas. However, the program lets you specify which given name is the one commonly used by this person. The usual genealogical practice is to assume that the first of the given names is the one used. If that's not the case, you can add an asterisk as the last character of the name that you wish to underline.
For example, if you wish a name to appear as John George Jones, enter it as John George* /Jones/ . If you're using the on-line editing facility, you enter the given names and the family name into separate fields of that on-line editing form, and the slashes aren't entered. The program handles these slashes automatically as you enter stuff.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I began the project decades ago, it was for private purposes. I was new to the process, had little understanding, and was (fast track) self-teaching to develop a way to reach a specific end goal. In short, I was working from the big picture backward. My whole life, I have been a fixer. Oftentimes, on projects, I simply have the end result, certainly no directions, and I have to take the object apart in (perceived) reverse order of its build to find any potential issues and then build back often from memory. That is how I approached this project at that time, and for decades, it has worked for its intended needs and purpose. It should also be noted that my needs and purpose deviate some from that of traditional genealogy research. This is not to say that the system could not handle them; I am just saying I have a unique need that may require setting up the current configuration in a way that I am not currently aware of and may need to learn.
For a deeper discussion of my project and its unique needs, I will email you. For personal reasons it is not something I want on a public forum.
All that being said I am always an eager learner and always want to do the right thing the right way. If the system will work to meet my unique needs I am not only willing to "mend my ways" but would actually look forward to the process as I imagine it would be a great learning opportunity. Having an expert and guide to assist (for those who are interested in actually learning) is always more efficient than self-teaching.
Because I can not risk my current data set and correcting each entry by hand is impossible given the tens of thousands of entries it has, I will need to make copies of a side project to work through and look for an efficient way to swap the data to the correct structure. I will have to learn about the database and how it relates to the development of GEDCOM. Once I better understand the relationship, I might be able to do a few find-and-replace statements or something similar that can make relatively quick work of the process. I will need to learn the database structure and MySQL better though first.
On the topic of MySQL, do we know if the current 4.3.1 version works well with the newest MySQL 8 version? My server host has said that a move to MySQL 8 will be required and that there are several changes to it vs. 5.5.62. I am able to test my php versions up to 8.1 on my current server, but they have said only one version of MySQL can run at a time on a server and that once it is changed, there is no ability to go back. So, for MySQL 8, I have no way of testing before making a move. This scares me. What if I upgrade the server as required and suddenly have no access or ability to reverse?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Because I can not risk my current data set and correcting each entry by
hand is impossible given the tens of thousands of entries it has, I will
need to make copies of a side project to work through and look for an
efficient way to swap the data to the correct structure. I will have to
learn about the database and how it relates to the development of
GEDCOM. Once I better understand the relationship, I might be able to do
a few find-and-replace statements or something similar that can make
relatively quick work of the process. I will need to learn the database
structure and MySQL better though first.
On the topic of MySQL, do we know if the current 4.3.1 version works
well with the newest MySQL 8 version? My server host has said that a
move to MySQL 8 will be required and that there are several changes to
it vs. 5.5.62. I am able to test my php versions up to 8.1 on my current
server, but they have said only one version of MySQL can run at a time
on a server and that once it is changed, there is no ability to go back.
So, for MySQL 8, I have no way of testing before making a move. This
scares me. What if I upgrade the server as required and suddenly have no
access or ability to reverse
I would not be concerned with fixing the database entries. The database
can be exported to, and indeed is created from, a GEDCOM file. Therefore
there is no data in the database that is not in, or that can be derived
from, the GEDCOM file.
Changing your given/surname swap problem using MySQL would be much
harder than fixing it in the GEDCOM file.
I have a Perl script that takes a GEDCOM file as input and outputs it
with embedded HTML anchors and link as a .html file. This can be opened
with a browser and 'walked' by clicking the links. This can help in
understanding the GEDCOM format and also finding out how to correct
normal errors. Browsing it does take a lot of memory. There are several
GEDCOM description out there, including an annotated one that really
helps. I have a downloaded copy but can't find the original out there.
Assuming you have a computer that can run Perl, doing what you want
wouldn't be that difficult, although Perl code does look like a cat has
danced on you keyboard. Learning Perl would be more profitable than
writing some MySQL data manipulator.
On the topic of your original name switch, I would have thought that the
way Phpgedview pre-populates surname fields when creating new wives and
children would have been more of a problem to you. You must have an
interesting usage case.
I know Gerry doesn't like text-editing GEDCOM files. I have no problem
with it, but I've been editing structured text files since 1975, so I'm
used to it. At least you can easily edit a copy of a file. It's more
difficult to generate a duplicate database to play with.
If you want a copy of my GEDCOM -> html script I can let you have it.
David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Glad to have you in the discussions. My nature is if it isn't broke don't fix it. My server host seems to subscribe to a different mindset though. Since I am beholden to their required upgrades, life is what it is. My nature is also: when faced with adversity - learn. So, I am in the process of changing my mindset from anxiety and fear to openness and excitement.
Gerry has actually suggested text editing. His position may be like most things in life: solutions are often situational.
My case is definitely unique. PhpGedView may not have been intended or even known that it could handle my type of data the way it does, but I may be the only one who has ever used it like I do, so its use was never considered elsewhere, but lucky for me the possible unintended consequence was a good match for my needs. That being said I have done a lot of customization. Mostly on design and renaming of language fields to fit my unique case. Essentially a new paint job though, the under the hood engine is still the exact same.
I am not familiar with PERL but am always eager to learn new things and am always happy to add new tools to my toolbox. Better to have and not need, than need and not have.
I am self taught on all coding. I could not set down with a blank page and code much of anything, but I can take complex systems and chop them up when I need to re-purpose them for a specific task. I quickly see patterns. I am comfortable enough in anything HTML. PHP, Java, so it would be cool to add PERL to my knowledgebase.
Not sure if it can be added as an attachment or we need to determine a different way to share?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello David,
<snip>
I am self taught on all coding. I could not set down with a blank page
and code much of anything, but I can take complex systems and chop them
up when I need to re-purpose them for a specific task. I quickly see
patterns. I am comfortable enough in anything HTML. PHP, Java, so it
would be cool to add PERL to my knowledgebase.</snip>
Having thought more about it, I think you can skip Perl. Every time I do
something new in Perl I have to go back to the manual and old scripts
for some of the constructs. Php will do the job. We tend to think of Php
for generating web pages only, but it's just another programming
language. It can read and write files and its array handling is much
simpler than Perl's. Perl differentiates between Arrays and 'Hashes',
which are just arrays with non-numeric indices, and Perl has different
ways of accessing each.
What sort of machine do you work from? I know nothing about Windows. I
have no idea how you would go about programming in php on Windows other
than by putting the program on a website and accessing it with a
browser. I was an assembler programmer from 1969 till 1983 when I became
a Unix Sysadmin. My first real computer was a Mac which around 2000
became a Unix variant with a command line. Now I use Linux and older Macs.
In php I would open input and output GEDCOM files; pass through, in to
out, all lines that are not Level 0 INDI lines, stopping at each INDI
line. Pass through all non Level 1 NAME lines, stopping at each such
line. Fix the NAME line and output it; read and save the following Level
2 GIVN and SURN line contents, fix them and output them. You may need to
do something with Level 2 TYPE MarriedName lines if what you have done
makes them wrong. There may be other sub-parts of NAME records that need
fixing, but I suspect the rest can be passed straight through.
Not sure if it can be added as an attachment or we need to determine a
different way to share?
My ged2web Perl script is at <davidgledger.plus.com ged2web.tar="">
It's just loose in there but having a .tar extension you should just be
able to save it. Let me know when you've downloaded it or if you don't
want it so I can remove it. Should anyone else want it, that's fine (and
free - no guarantees of course). It does produce some 'variable not
used' errors which can be ignored. It also expects Perl to exist at
/usr/bin/perl in a Unix-like environment. I'm sure it can be modified to
be run on other systems with Perl. Run it with the path of a GEDCOM file
as argument and it spits out the html which needs to be redirected to a
filename with a .html suffix and put somewhere accessible to a browser.
It was written for Unix/Linux where this is the normal way to do things.
The server is a little Mac Mini at home so don't expect too much of it.</davidgledger.plus.com>
The browsed output has anchors on Level 0 lines and obvious links on
those other lines that reference them. Level 1 FAMC and FAMS lines have
the names of the parents of that family added after a '==' delimiter, to
help you know where the link will take you. After the 0 TRLR record are
lines of names with their dates that link back to the INDI records
above. Unfortunately there are not (yet) sorted properly.
David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I might be able to do it in Notepad with a simple Find/Replace. I know I can with the GIVN and SURNAME. It is just the process now to get that to properly reflect with the NAME and not have to do so per individual entry. I have 10's of thousands of entries and my server has given an update by date, so individual entry repair is not a feasible option given my constraints.
I tried going to your website and all that came up was an IP address.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I might be able to do it in Notepad with a simple Find/Replace.
I know I can with the GIVN and SURNAME. It is just the process now to
get that to properly reflect with the NAME and not have to do so per
individual entry. I have 10's of thousands of entries and my server has
given an update by date, so individual entry repair is not a feasible
option given my constraints.
I tried going to your website and all that came up was an IP address.
The email got distorted. It should be
<davidgledger.plus.com ged2web.tar="">
Hoping the same doesn't happen to this. The basic top level does just
show the browser's IP address - handy when travelling and you need to know.</davidgledger.plus.com>
David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. I was able to use Notepad ++ to get the desired results. I appreciate all your input and willing ness to help.
I also enjoyed learning a little more about you personally. I always find it interesting to hear the life experience someone comes from, and how they bring that experience to the table.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can help with getting the NAME entries of your database into the proper GEDCOM standard.
It's really just a question of using a decent text editor (I use Notepad ++ on my Windows laptop) and doing some find-and-replace on the exported GEDCOM file and then importing that edited file back into the database.
Let's take this discussion off-line. Please use my real e-mail address:
gkroll (at) keldine (dot) ca .
I'm located near Ottawa, Canada.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Gerry, I have sent an email yesterday (2/22), but it may have went to spam. I look forward to your response and being able to discuss everything in a more private manner.
It's good to know that MySQL 8 will not be an issue.
I am very comfortable with Find/Replace using Notepad, MSWord, Access. That is how I thought someone might handle such a switch. Especially with larger datasets. I am just a little confused on the separation and correlation between the MySQL database and the GEDCOM. Until recently I thought all was in the database and that is where the whole GEDCOM was also stored. When I look in the individuals table of MySQL I can see a copy of it there.
So, the process of how to get them to match would be of concern in such a fixit case. Not sure if in the process it self-corrects. I can't imagine it would be good to have conflicting data between the GEDCOM and MySQL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Gerry, I have sent an email yesterday (2/22), but it may have
went to spam. I look forward to your response and being able to discuss
everything in a more private manner.
It's good to know that MySQL 8 will not be an issue.
I am very comfortable with Find/Replace using Notepad, MSWord, Access.
That is how I thought someone might handle such a switch. Especially
with larger datasets. I am just a little confused on the separation and
correlation between the MySQL database and the GEDCOM. Until recently I
thought all was in the database and that is where the whole GEDCOM was
also stored. When I look in the individuals table of MySQL I can see a
copy of it there.
So, the process of how to get them to match would be of concern in such
a fixit case. Not sure if in the process it self-corrects. I can't
imagine it would be good to have conflicting data between the GEDCOM and
MySQL.
You can't get MySQL and GEDCOM out of step because the database is
created from the GEDCOM.
David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Updated from 4.1 to 4.3.1. The original database for 4.1 under the table individuals maintains the main Gedcom file details under the i_gedcom column.
When updating to 4.3.1 the new database structure adds a new column that did not previously exist called i_sex. Oddly enough when viewing a profile some data calls to this new column and some does not. For example, when I view an individual's profile it calls the sex from the i_gedcom field and properly notes it on the individual's profile. However, in doing a search or looking at various charts it calls to the i_sex column and shows all individuals sex as unknown.
When the new database was created for the 4.3.1 version it did not pull the sex from the i_gedcom field to populate that i_sex column, but instead populated all individuals under the i_sex column as U or "Unknown".
Seems to me having sex listed both in the gedcom and as its own column is a bit redundant, but there may be deeper reasons for this structure that I do not understand.
If I try to edit the individual on their profile page via Edit > Quick Update, again it shows the proper sex notated (per the i_gedcom), so I am unable to correct the "U/Unknown" designation in related charts.
Going to PhpAdmin allows me to see both the i_gedcom and i_sex columns in the individuals table where I can also see that the i_gedcom does properly indicate sex (example 1 SEX F) whereas the i_sex column for all individuals lists U.
I have tried fixing the "U" designation in the i_sex column manually in the database via PhpAdmin but it will not let me manually edit the content. This is not really a good solution for me anyway, if it did, as I have thousands of entries.
I have tried renaming the i_sex column in PhpAdmin to see if that would force the correct sex notation in the charts as a possible fallback, but when I do this it breaks the call to see an individual's profile and simply shows the header with no individual details included. So, consideration of dropping or renaming that column seems to be a no-go as a solution.
Anybody have any ideas on a fix?
When you did your upgrade, did you export the database to a GEDCOM file, using the old PhpGedView, then do the uprade, and then immediately import the previously exported GEDCOM file, letting the Import replace the database contents?
This sequence (export - update - import) is crucial. If you don't follow this, the database tables and indexes won't be properly populated.
Check your GEDCOM file (NOT the database), to see whether the sex is properly recorded there. If it is, just re-import the GEDCOM file, letting the Import replace the database contents.
If you forgot to export the database before doing the upgrade, you can try exporting the database using the new (upgraded) PhpGedView, and then importing the just-created GEDCOM file, again replacing the database contents. I have heard that this will work, but I won't guarantee it.
This may work because the database contains not only individual fields/columns for each genealogical fact, but also a text copy of the the original GEDCOM record for each person and family. The Export only looks at that text, and NOT the database fields.
I may be confused on how to export the database. Is this by going to the admin section and using "Backup"? If so, my older version just goes to a white page. The newer version throws this error: Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 20480 bytes) in .../includes/classes/class_pgv_db.php on line 852
It may be because I have thousands of names listed in the genealogy and it is creating to heavy a lift.
If I am confused in the export Gedcom process, I am sorry. Maybe more details or a link showing, if possible would help.
On the original version I am able to got to Amin > Manage GEDCOMs and edit Privacy and do an export without error. But when I go to the new version and select "Export" it goes to a popup that gives me the same error message as above. If I instead go to "Import" to try and add the one exported from the original the "import> GEDCOM File" box is grayed out, so I can not put anything there and it gives me an error that says: A GEDCOM with this file name has already been imported into the database.
Because I do not want risk any issues I modified your upgrade process slightly. What I did was got to my cPanel and
1. Created a duplicate folder and renamed it.
2. Created a duplicate database and renamed it.
3. Uploaded all 4.3.1 files (in Binary mode) overtop (overwriting) all duplicate files (except, config.php, index and media folders)
4. Uploaded modified config file to notate duplicate database info. instead of original
5. Uploaded a new .htaccess file to notate an upgrade to php 7.4
6. Launched new site that took me into new setup that said it updated tables
7. Tested site. All appears pretty good, except the sex notation now.
In the original I have quite a bit of template/theme/format changes that still need to be addressed in the new, but that was all mostly expected and is off topic of this post. At some point I can address theme mods. That is my my skillset and may help others with a more customized site. During this upgrade process I may even venture into adding Bootstrap to develop a theme that is more mobile friendly. Been wanting to do that for some years. This forced change by my server host may be a good time to dive into that.
You MUST do an export - and then - import of the database, using a GEDCOM file as the intermediary.
You access the Export and Import functions by launching the Admin page, and then going to the Manage GEDCOMs and edit Privacy option. There, you should find your database mentioned.
On the line that corresponds to your database, notice the "Export" and "Import" options.
"Export" copies the textual GEDCOM information embedded in the database to an actual GEDCOM file in your /index directory. No need to download that file, unless you REALLY want to.
"Import", unless you tell it otherwise, will read that previously exported GEDCOM file and use its information to populate the various fields and indexes of your database. Be sure to let that Import replace the existing database contents. Since you have exported an existing database, your GEDCOM file contains whatever media stuff was present, so don't change the Media option. If your database already contains media stuff and you import the same media stuff from the GEDCOM file without deleting that existing media information in the database, you'll end up with a mess of duplicates.
The business about deleting Media from the database is there in case the incoming GEDCOM file doesn't contain media records (as would be the case with certain older off-line genealogical programs). In this case, you don't want to destroy what's already in in your database from earlier sessions.
I get the memory issue error noted earlier on that export. I will contact my server to see if they can increase my memory limits and to see if that will fix the issue. On my original (current non-testing live version) it does not even show me the export option, but does in the new updated version, which throws the error. Once I can get the server to increase the memory limits and if that works hopefully an export > import of it directly on the new version will correct the issue.
I will touch back with the results/progress.
I did notice if I tried to go to php8.1 instead of 7.4 I got some errors as well. Once I can figure out this part I will set up a new thread to discuss those. I would really love to be able to upgrade as far as possible to limit the need of future upgrades.
VERY MUCH appreciate all help and guidance.
There is a memory usage limitation configured into the /config.php file referenced by PhpGedView.
This file is an ordinary text file that you can edit manually if you wish (not recommended).
Launch the Admin page, then access the "Configuration" option. You should see the "4. Site Configuration" panel. Click on the "Advanced Settings" tab.
The "Memory Limit" set here, when less than what the server's configuration allows, over-rides the server's memory limit. This value should not be less than 64 Mb. Your server is probably configured to allow PHP scripts to request up to 256 Mb.
Be sure to step through the configuration panels until you're told that the configuration has been saved. To get back to known territory after you've used the Installation Wizard, just click on one of the selections of Step 8.
In older versions of PhpGedView, the lowest recommended memory limit was 32 Mb, but that's not nearly enough. For large databases (about 6,000 persons) you should set this to 128 Mb. 256 Mb is excessive, but won't do any harm; PhpGedView will ask the server to allocate memory as it's needed.
Thanks, I raised it to 256. My database is a lot larger than 6,000 but 256 seemed to work.
I also adjusted the Session Timeout to 7200 and when importing set the time limit to 360.
That all worked and I now have all the sexes. That is super helpful. Thanks.
In my database I have a lot of singular names. For example, if there was a John Tylor but all I knew was John I included just John (in many cases with no other relatives). Under this scenario if I ran into another John with a missing last name I assumed it was a new John. At some points I am lucky enough in my research after finding enough familial matches to then be able to correlate the two (+), sometimes with a last name and then in those cases I use the merge feature to pull all the data together.
Also, to assist in the way I do research I actually record opposite of what most genealogists would consider correct or intuitive. In the Given Name I use the last name and in the Surname I use the natural name for example John.
What this results in when I do searches is then last name, natural/call name. (Tylor, John). Then that makes it easy for me to search through all Tylor names super easy.
In the old (current used version) this methodology has worked well for years. On searches it would just show John ??? (???,John) as John. However, in the new upgrading version where simple names like John are shown it says John (Given name unknown). I need to figure out how to remove the (Given name unknown) part. Looking through the configuration settings, but it may be that I need to remove it from a language file if not part of settings.
Should I move this to a different topic?
You REALLY have a messed-up genealogical database that's NOT following the rules.
You'll have to mend your ways. I do NOT recommend that you try to modify the program to suit your not following the GEDCOM standard.
In order for the program to function properly, the names need to be recorded in the form
That's what the GEDCOM standard specifies, and that's what PhpGedView expects. You must NOT reverse the order of the family name and given name fields.
When names appear in sorted lists, the program automatically reverses the order of the given and family names. Some languages commonly mention the family name first (eg., Hungarian, Chinese) and for these, the program does the reversal for display purposes, but the database still has the name fields in the "proper" order (according to the GEDCOM standard).
If the given names are not specified (they're missing), the program will show "(Given name unknown)". If the family name is not specified (there's nothing between those slashes or the entire slash entry is missing), the program will show "(Family name unknown)". If both the given names and the family name are missing, the program will show "(Name unknown)"
Notice that in a properly recorded NAME entry, there are no commas. However, the program lets you specify which given name is the one commonly used by this person. The usual genealogical practice is to assume that the first of the given names is the one used. If that's not the case, you can add an asterisk as the last character of the name that you wish to underline.
For example, if you wish a name to appear as John George Jones, enter it as John George* /Jones/ . If you're using the on-line editing facility, you enter the given names and the family name into separate fields of that on-line editing form, and the slashes aren't entered. The program handles these slashes automatically as you enter stuff.
When I began the project decades ago, it was for private purposes. I was new to the process, had little understanding, and was (fast track) self-teaching to develop a way to reach a specific end goal. In short, I was working from the big picture backward. My whole life, I have been a fixer. Oftentimes, on projects, I simply have the end result, certainly no directions, and I have to take the object apart in (perceived) reverse order of its build to find any potential issues and then build back often from memory. That is how I approached this project at that time, and for decades, it has worked for its intended needs and purpose. It should also be noted that my needs and purpose deviate some from that of traditional genealogy research. This is not to say that the system could not handle them; I am just saying I have a unique need that may require setting up the current configuration in a way that I am not currently aware of and may need to learn.
For a deeper discussion of my project and its unique needs, I will email you. For personal reasons it is not something I want on a public forum.
All that being said I am always an eager learner and always want to do the right thing the right way. If the system will work to meet my unique needs I am not only willing to "mend my ways" but would actually look forward to the process as I imagine it would be a great learning opportunity. Having an expert and guide to assist (for those who are interested in actually learning) is always more efficient than self-teaching.
Because I can not risk my current data set and correcting each entry by hand is impossible given the tens of thousands of entries it has, I will need to make copies of a side project to work through and look for an efficient way to swap the data to the correct structure. I will have to learn about the database and how it relates to the development of GEDCOM. Once I better understand the relationship, I might be able to do a few find-and-replace statements or something similar that can make relatively quick work of the process. I will need to learn the database structure and MySQL better though first.
On the topic of MySQL, do we know if the current 4.3.1 version works well with the newest MySQL 8 version? My server host has said that a move to MySQL 8 will be required and that there are several changes to it vs. 5.5.62. I am able to test my php versions up to 8.1 on my current server, but they have said only one version of MySQL can run at a time on a server and that once it is changed, there is no ability to go back. So, for MySQL 8, I have no way of testing before making a move. This scares me. What if I upgrade the server as required and suddenly have no access or ability to reverse?
On 2/23/25 02:10, DogMan wrote:
<snip></snip>
Changing your given/surname swap problem using MySQL would be much
harder than fixing it in the GEDCOM file.
I have a Perl script that takes a GEDCOM file as input and outputs it
with embedded HTML anchors and link as a .html file. This can be opened
with a browser and 'walked' by clicking the links. This can help in
understanding the GEDCOM format and also finding out how to correct
normal errors. Browsing it does take a lot of memory. There are several
GEDCOM description out there, including an annotated one that really
helps. I have a downloaded copy but can't find the original out there.
Assuming you have a computer that can run Perl, doing what you want
wouldn't be that difficult, although Perl code does look like a cat has
danced on you keyboard. Learning Perl would be more profitable than
writing some MySQL data manipulator.
On the topic of your original name switch, I would have thought that the
way Phpgedview pre-populates surname fields when creating new wives and
children would have been more of a problem to you. You must have an
interesting usage case.
I know Gerry doesn't like text-editing GEDCOM files. I have no problem
with it, but I've been editing structured text files since 1975, so I'm
used to it. At least you can easily edit a copy of a file. It's more
difficult to generate a duplicate database to play with.
If you want a copy of my GEDCOM -> html script I can let you have it.
David
Hello David,
Glad to have you in the discussions. My nature is if it isn't broke don't fix it. My server host seems to subscribe to a different mindset though. Since I am beholden to their required upgrades, life is what it is. My nature is also: when faced with adversity - learn. So, I am in the process of changing my mindset from anxiety and fear to openness and excitement.
Gerry has actually suggested text editing. His position may be like most things in life: solutions are often situational.
My case is definitely unique. PhpGedView may not have been intended or even known that it could handle my type of data the way it does, but I may be the only one who has ever used it like I do, so its use was never considered elsewhere, but lucky for me the possible unintended consequence was a good match for my needs. That being said I have done a lot of customization. Mostly on design and renaming of language fields to fit my unique case. Essentially a new paint job though, the under the hood engine is still the exact same.
I am not familiar with PERL but am always eager to learn new things and am always happy to add new tools to my toolbox. Better to have and not need, than need and not have.
I am self taught on all coding. I could not set down with a blank page and code much of anything, but I can take complex systems and chop them up when I need to re-purpose them for a specific task. I quickly see patterns. I am comfortable enough in anything HTML. PHP, Java, so it would be cool to add PERL to my knowledgebase.
Not sure if it can be added as an attachment or we need to determine a different way to share?
On 2/23/25 22:28, DogMan wrote:
Having thought more about it, I think you can skip Perl. Every time I do
something new in Perl I have to go back to the manual and old scripts
for some of the constructs. Php will do the job. We tend to think of Php
for generating web pages only, but it's just another programming
language. It can read and write files and its array handling is much
simpler than Perl's. Perl differentiates between Arrays and 'Hashes',
which are just arrays with non-numeric indices, and Perl has different
ways of accessing each.
What sort of machine do you work from? I know nothing about Windows. I
have no idea how you would go about programming in php on Windows other
than by putting the program on a website and accessing it with a
browser. I was an assembler programmer from 1969 till 1983 when I became
a Unix Sysadmin. My first real computer was a Mac which around 2000
became a Unix variant with a command line. Now I use Linux and older Macs.
In php I would open input and output GEDCOM files; pass through, in to
out, all lines that are not Level 0 INDI lines, stopping at each INDI
line. Pass through all non Level 1 NAME lines, stopping at each such
line. Fix the NAME line and output it; read and save the following Level
2 GIVN and SURN line contents, fix them and output them. You may need to
do something with Level 2 TYPE MarriedName lines if what you have done
makes them wrong. There may be other sub-parts of NAME records that need
fixing, but I suspect the rest can be passed straight through.
My ged2web Perl script is at <davidgledger.plus.com ged2web.tar="">
It's just loose in there but having a .tar extension you should just be
able to save it. Let me know when you've downloaded it or if you don't
want it so I can remove it. Should anyone else want it, that's fine (and
free - no guarantees of course). It does produce some 'variable not
used' errors which can be ignored. It also expects Perl to exist at
/usr/bin/perl in a Unix-like environment. I'm sure it can be modified to
be run on other systems with Perl. Run it with the path of a GEDCOM file
as argument and it spits out the html which needs to be redirected to a
filename with a .html suffix and put somewhere accessible to a browser.
It was written for Unix/Linux where this is the normal way to do things.
The server is a little Mac Mini at home so don't expect too much of it.</davidgledger.plus.com>
The browsed output has anchors on Level 0 lines and obvious links on
those other lines that reference them. Level 1 FAMC and FAMS lines have
the names of the parents of that family added after a '==' delimiter, to
help you know where the link will take you. After the 0 TRLR record are
lines of names with their dates that link back to the INDI records
above. Unfortunately there are not (yet) sorted properly.
David
I think I might be able to do it in Notepad with a simple Find/Replace. I know I can with the GIVN and SURNAME. It is just the process now to get that to properly reflect with the NAME and not have to do so per individual entry. I have 10's of thousands of entries and my server has given an update by date, so individual entry repair is not a feasible option given my constraints.
I tried going to your website and all that came up was an IP address.
On 2/24/25 15:30, DogMan wrote:
The email got distorted. It should be
<davidgledger.plus.com ged2web.tar="">
Hoping the same doesn't happen to this. The basic top level does just
show the browser's IP address - handy when travelling and you need to know.</davidgledger.plus.com>
David
David,
Thanks. I was able to use Notepad ++ to get the desired results. I appreciate all your input and willing ness to help.
I also enjoyed learning a little more about you personally. I always find it interesting to hear the life experience someone comes from, and how they bring that experience to the table.
Yes, PhpGedView works OK with mysql version 8
I can help with getting the NAME entries of your database into the proper GEDCOM standard.
It's really just a question of using a decent text editor (I use Notepad ++ on my Windows laptop) and doing some find-and-replace on the exported GEDCOM file and then importing that edited file back into the database.
Let's take this discussion off-line. Please use my real e-mail address:
gkroll (at) keldine (dot) ca .
I'm located near Ottawa, Canada.
Thanks Gerry, I have sent an email yesterday (2/22), but it may have went to spam. I look forward to your response and being able to discuss everything in a more private manner.
It's good to know that MySQL 8 will not be an issue.
I am very comfortable with Find/Replace using Notepad, MSWord, Access. That is how I thought someone might handle such a switch. Especially with larger datasets. I am just a little confused on the separation and correlation between the MySQL database and the GEDCOM. Until recently I thought all was in the database and that is where the whole GEDCOM was also stored. When I look in the individuals table of MySQL I can see a copy of it there.
So, the process of how to get them to match would be of concern in such a fixit case. Not sure if in the process it self-corrects. I can't imagine it would be good to have conflicting data between the GEDCOM and MySQL.
On 2/23/25 22:03, DogMan wrote:
You can't get MySQL and GEDCOM out of step because the database is
created from the GEDCOM.
David
Good to know. I love redundancy.
Good to know. I love redundancy.