I have been using version 4.0 for about a year and a half without any major problems. Recently when trying to add a spouse I was getting error messages about memory. Unfortunately I didn't save those messages. Even though I was getting an error message, it would create the new individual. But it wasn't connecting them to their spouse. I would have to go through a second step of connecting them together.
Now I am getting a different error message when trying to add (or connect) a spouse.
ERROR 4: Could not find gedcom record with xref:F1893 Line 149 #0 replace_gedrec(F1893, 0 @F1893@ FAM 1 HUSB @I5888@ 1 CHIL @I5861@ 1 CHAN 2 DATE 26 JAN 2008 3 TIME 23:15:29 2 _PGVU bettebrown 1 WIFE @I5891@) called at [/var/www/domains/gedcom.augustacemetery-ohio.com/docs/edit_interface.php:775]
Now what is happening is the newly connected person's individual page will show their Personal Facts and Details (minus the marriage fact) and it also shows the spouse and children, but the family is called "Family with Unknown" and that person (whose page I'm viewing) isn't included in the family (even though the family is shown on their page).
Not sure if that makes sense.
In addition, when trying to delete a newly created spouse (due to duplicates being created in the mess), I am getting this error message:
ERROR 4: Could not find gedcom record with xref:I5889 Line 263
Our GEDCOM file has grown rather large (almost 5MB). Could this be creating the problems and how do I fix it? ANY help out there would be greatly appreciated. Until this problem is fixed we are unable to add new information to the file.
It appears as though PhpGedView has run out of memory.
There are two memory limits that come into play, and the lower of the two values is the one that's actually in force.
Limit #1: The memory limit you have configured on the site configuration page. This the page you get to when you click "Configuration" on the Admin menu. The option is near the bottom of the page.
Limit #2: The memory limit configured for the PHP process on the server. This is under the control of the server administrator.
You can check what limit #2 is actually set to. Do this by clicking "PHP information" on the Admin menu. Search for the text "memory_limit". If you can't find this entry, the server admin hasn't configured any memory limit, and the default 8 Mb is in effect.
Try setting limit #1 higher first. If it's set to 16 Mb, try 32 Mb. You shouldn't need more than 32 Mb unless you have a large number of pictures.
If increasing #1 has no effect, you'll have to contact your ISP and request that they raise the memory limit for PHP scripts.
Thank you so much for responding. My expertise in this area is about 100 rungs below Novice and I was afraid to even post here thinking I wouldn't understand any help I might get. But this makes perfect sense and I am extremely grateful.
Before posting here I had read in FAQ about changing the memory limit in regards to uploading large gedcom files. Since I wasn't uploading a file I wasn't sure it pertained to me, but I followed the suggestion anyway. Limit #1 you write about was set to 32MB. I changed it to 64MB and then 128MB with no luck so set it back to 32MB.
Then I contacted my ISP with the following request:
I have PhpGedView installed and have recently run into problems. I've been told to edit the php.ini file and change the line, memory_limit = 8M, to memory_limit = 20M. I can't seem to find a php.ini file and am wondering if this is something you have to change for me?
They wrote me back stating:
Thank you for the email. I am sorry to say that you do not have access to php.ini file and you do not edit it for customers.
That seemed like a non-response to me. I was about to argue with them about this, but since I really don't know what I'm doing, I decided to post here.
You've given me what I need to go back and do the arguing. So thank you very much! I appreciate it more than you know. Now I just need some luck in dealing with myhosting.com!
Your wording is wrong. You have to request that the ISP make the change for you. Request the memory_limit be raised to 32 Mb. That's NOT something you can (or should) do.
I copied and pasted your last post and sent it off to the ISP. You have no idea how much I appreciate this. We absolutely love PhpGedView and would be so lost without it.
Gerry is a fantastic help as I had the same problem but sadly we sould not resolve the issue. phpGedView is a memory hog.
I was using v4.0.2 and wanted to upgrade to v4.1. I tried everything under the sun to get v4.1 to import my gedcom but it would never finish.
I also tried to get my ISP to raise the PHP memory_limit from 8mb to 32mb but they explained that I was on a shared server and there was no way to raise this limit for just one user. In other words, it's a global php setting and all their customers parked on that web server would then have a php memory limit of 32mb. If a ISP has 200 customer websites on their web server, all executing different types of php scripts throughout the day, the performance slows down for everyone. Most ISP's charge from about $5 to $10 per month per account on a shared server and I would be surprised if your ISP changed it's memory_limit from 8mb to 32mb for you.
There are several options. You could move to a virtual private server but be prepared to pay about $30 a month and then you can set the PHP memory_limit to 64mb! Or you could look at the phpGedView website for specialty hosting that charges you an amount based on how many individuals you have in your gedcom.
Also, you could hope that it has nothing to do with the PHP memory_limit, but rather a corrupt gedcom file, missing phpGedView operating files, or a database issue. I'm no expert, but you might start by backing up all your files using the Admin/Backup feature and then do a completely new installation and try re-importing your gedcom.
Before importing the gedcom into a freshly installed v4.0.2, ask Gerry if you could send him a copy of the raw gedcom and maybe he could spot some obvious syntax error in the individual or family records you were last working on, i.e., a loop. However, I do not know if Gerry is current on gedcom file structure.
Good luck, I'm stuck using v4.0.2 because of the memory limit issue.
I've said this before, and I'll say it all again:
Your ISP should bone up on how time and resource sharing works in the *nix world. The memory limit is just that: it's a limit on how much each PHP process is allowed to grow to. That does NOT mean that each process will automatically get exactly that much memory. The various PHP scripts will only get as much as they actually need, and when the script terminates, its memory usage will drop to zero.
Resource sharing also means that if all the in-memory processes have used up all available physical memory, the server will start swapping inactive processes to external storage. Usually, it selects swap candidates based on how long they have been inactive and how much memory they are tying up.
If the ISP is concerned about swap usage, they have a configuration problem somewhere.
Sigh... First of all, let me say again, I really appreciate everyone's help. Thank you.
I feel like an idiot here. Gerry -- in your first post you told me: You can check what limit #2 is actually set to. Do this by clicking "PHP information" on the Admin menu. Search for the text "memory_limit".
I thought I did this. BUT I went in again last night and found text for memory_limit. I don't think I scrolled all the way down the page before when I looked. Now I see memory_limit, Local Value 32M and Master Value 256M, so perhaps I already have what I've been bugging my ISP for???? The program is still not working. Nothing works now. Anything I try to add to the file puts out the error message.
I did get another response from my ISP and it's the same thing Motoring_along writes about. This is their response:
Unfortunately we cannot make changes to the php.ini file for a specific website. Any change we make to the php.ini file will affect all the websites on the server. Our administrators have already determined the optimal settings in the php.ini file to ensure stability and security of the server and will not make modifications to it for that reason. If your code requires more resources than the server allows, you'll need to modify your code to work within the resources allotted to you.
So that's that.
But again, maybe the memory_limit isn't my problem if it is showing the Local Value is 32M????
Maybe I will have to find a server that already has PhpGedView installed for us since we don't seem to know what we're doing. We're just a bunch of old ladies doing research on people buried in a particular cemetery. We're good at gathering information, but not so good at figuring out how to get the information posted online.
I ran into this memory_limit problem while reading the FAQs on the PGVWiki site. Besides increasing the memory using php.ini, it also states:
Edit PhpGedView source files
If you do not have access to edit the php.ini file, you can also edit the PhpGedView directory "include/functions.php" file and the "importgedcom.php" files and add as the second line in both files: ini_set("memory_limit", "16M")
This is something else I tried before posting here. I found the functions.php file, but couldn't find an importgedcom.php file. I followed the suggestion on the functions.php file, but that wiped out the entire program. Not surprising since I couldn't figure out what the "second line" would be anyway. So I erased what I entered and got the program back.
Then that answer to the FAQ goes on to say:
As an alternate to increasing memory, first try skipping the cleanup options on Step #3. If that doesn't work try to do the GEDCOM importing/indexing on your home computer or split your one large GEDCOM into several smaller GEDCOMs.
It appears this is coming down to having to upload the gedcom file again. And even reinstalling the program. I don't have much faith that I'll be able to upload this large gedcom. It was small (1MB) when I first loaded it into PhpGedView. But I could try skipping step #3 and doing the importing/indexing on my home computer.
I really hate to break the GEDCOM down because I would have no clue as to where I'd want to break it. Everyone is connected together.
If I have to upload the file again, I might as well install the latest version of PhpGedView. I have wanted to do that for quite a while now, but decided with my expertise I would let sleeping dogs lie. I dread having to learn how to do this all over again. I honestly cannot understand this type of computer stuff so it was such a pleasant surprise when I got it installed the first time. It's a shame I can't remember how I did it. I'll just cross my fingers and hope I get lucky again.
Or would it be better for me (easier) to just reinstall the version I'm using? One way or another I'll have to figure something out. Right now I have no idea what my next step should be.
Again, thank you.
I should not be butting in as I know little about the programing stuff but I had to increase my memory and my host would not do it but told me how to do it. I'll insert that message but basically you need to create a directory in the upper most level. In that directory you need a php.ini file with two lines in it. The two lines are:
memory_limit = 24m
mysql.default_socket = /var/lib/mysql/mysql.sock
The second line is to prevent an error and you need that. The first line is what you want your memory to be... in my case I set it to 24m Cindy can set her limit to 32 if that what she needs.
I might add that my host is running php 5.xx
The directory according to my host should be named "etc" and it needs to be even with your public_html directory. In my case my public_html directory is www and on that level is where I put the etc directory with the php.ini file containing the two lines shown above.
Here is what my host emailed me back.
Can I use a custom php.ini file in my account to override default settings of php.ini on the server?
[Updated: January 1, 2008, 11:13 pm by Support]
Yes, you can if you are running php-cgi. To do this-
Create the directory :
in your root directory.
Upload your custom php.ini to this directory and it will be used instead of the default php.ini file.
You only need to specify the php.ini settings which you want to override. Otherwise the default settings will be used.
If you use a custom php.ini, you need to enter this value in order for database access to work correctly:
mysql.default_socket = /var/lib/mysql/mysql.sock
This is because the standard MySQL build from mysql.com and the default php.ini look for the MySQL socket in different locations. Using the setting above will correct this issue. You only need to use this setting if you use a custom php.ini file.
Gary you might be able to explain to Cindy what she needs to do.
But I don't think she has a memory problem. It looks to me like she has something wrong with her gedcom file.
Here is the information I got when I googled her error:
ERROR 4: Could not find gedcom record with xref The xref ID you specified does not match any record in this gedcom.
Again excuse me for butting in
It looks to me there was a memory problem (so hhhoagie's advice is worth following), and that it caused an INDI record to be created that isn't linked to a FAM record.
The latter should be easy to find and fix, using gedcheck.php (GEDCOM config - check).
If the "master value" for the memory_limit is set to 256 Mb, you have more than enough memory allocated, and should not be bugging your ISP. I guess I should have been more specific in explaining what to look for.
Are you trying to import married names? This eats up an inordinate amount of memory, for very little gain. It's not actually an "import" -- it's "calculate every married name". Try doing the import without calculating married names. You'll still get married names when the incoming GEDCOM already has these.
It's possible that there's a problem with the GEDCOM you're trying to import. If you wish, you can e-mail me a ZIP copy of that GEDCOM, and I'll try to reproduce the problem here on my off-line test system.
e-mail: g dot kroll at keldine dot ca
When PGV does the Import, it copies the incoming GEDCOM to the "index" directory. When PGV quits, you can often determine where in the incoming GEDCOM you have a problem. The problem in the incoming GEDCOM is usually somewhere after the last record that you find in the GEDCOM that's been copied to the Index directory.
GEDCOMs are plain text files, and any text editor should be able to handle these.
I appreciate EVERYONE'S suggestions so much.
I was afraid memory wasn't my problem. I'm not trying to import a gedcom file either. We installed PhpGedView in May 2006 and imported our gedcom file at that time. Then it was only about 1MB in size. We work on the file online and never have had a need to upload anything since we first began. Now our gedcom is close to 5MB in size.
PhpGedView has worked great since May 2006. It's just in the past couple of weeks memory errors began to appear when I added a spouse. And then finally a couple of days ago everything just quit and nothing can be done. Anything we try to change or add results in the error message. I have no idea what happened.
I tried the suggestions given by hhhoagie and kiwi. My ISP wouldn't allow me to make a directory called etc because etc already existed. I couldn't see it so they probably won't give me access to it. But that doesn't matter since, sheepishly, I finally checked where Gerry told me to check and now know that lack of memory isn't my problem.
Then I looked for some way to use gedcheck.php to check the gedcom file, but couldn't figure out how to do that either.
I've given up. We just signed up with PGVHosting.com. They will install the program and upload our gedcom for us. I figure if the gedcom file is corrupted, PGVHosting will let us know. Luckily I've saved it every week or two since May 2006 (not over-writing the file each time) so if this one is corrupted I can go back to the previous save, or the save before that.
I appreciate so much all the help I've received here. I've just decided I'm way over my head. Hopefully going with PGVHosting will get us up and running again.
Again, thank you! You've been wonderful!
Export your GEDCOM to a ZIP file and send that to me. Also, send me a ZIP copy of the GEDCOM that currently resides in your "index" directory. I'd like to try sorting out your problem.
The "export" function will create a fresh GEDCOM from the database contents, completely ignoring the existing GEDCOM in your "index" directory. That's why I'd like the two files, which might very well contain conflicting information.
I have received the requested GEDCOM.
The GEDCOM exported from the database was somewhat under 5 Mb in size. The one in the "index" directory was less than 1 Kb, and appears to be a copy of the PGV clipboard, containing only 1 "0 @xx@ SOUR" and 2 "0 @xx@ INDI" records.
I have advised Cyndy to delete the .zip file in the "index" directory and then upload a replacement GEDCOM, using the previously downloaded zip file as the input. Of course, PGV needs to be told to replace all existing information and keep media links.
I have also suggested that Cyndy consider upgrading from 4.0 beta 8 to the most recent release, 4.1.3.
These threads are like an Agatha Christie novel. That's what makes PGV such a great program... the help forum. I'm glad Cyndy got her problem resolved but it leaves me wondering why this happened.
I agree with hhhoagie -- This help forum is AWESOME!
THANK YOU GERRY!!!!! Even though my problem is now fixed (YEA!!!!) I had to come in and thank everyone for their input, and most especially, thank Gerry for finding out what my problem was and telling me how to fix it.
Gerry -- you were VERY patient with me and you will never know how much I appreciate it.
I also wonder why this happened. But I know one thing -- if it happens again, I will know how to fix it!!!!
Again, THANK YOU GERRY! And thanks to all the rest of you for all your input.
Awwww, shucks, 'tweren't nothing.
You're very welcome, and I'm glad things worked out OK. Your e-mail to me indicated that you got two time-out messages when you imported the GEDCOM, and that the Import took about two minutes. You also said that the second time-out didn't give you a "continue" button.
I suggested that you do the Upload and Import again, this time setting the time-limit just a little less (5 seconds less would do). This should give you the same two time-out messages, but you should also see that "continue" button on the second time-out. I fear that there's some clean-up action that didn't complete because of the second time-out. That's why I'd like you to upload again, just to be sure.
Knowing why this happened may be hard to find now that everything is tidy again.
One possiibility would be a fault in the GEDCOM snchronisation. I recall there were some issues with this when it became optional. It was, I think, introduced in one of the 4.0 betas, and not fully fixed until about the 4.1.3 (?) release.
Actually there is still an open problem with it (https://sourceforge.net/tracker/index.php?func=detail&aid=1876059&group_id=55456&atid=477079) so everyone should be very careful if re-importing. To be safe, always re-import from a fresh file created from 'download' as Gerry describes above.
It's possible that the real GEDCOM in the Index directory was damaged or destroyed by something that happened on the server. Once the GEDCOM is damaged, any updates done to the database will encounter errors that will progressively get worse.
I'm back again.
Last week I tried setting the time-limit to 5 seconds less and it didn't work. Afterwards I read somewhere the default is 30 seconds, but for some reason mine was set to 60. I had set it to 55 seconds when I tried uploading again. Perhaps it needed to be set even less.
But I didn't worry about it not working at that time because I planned on trying to upgrade to 4.1.3 and knew I would have to upload the gedcom file again anyway. So I figured I'd worry about it then.
Right now my problem is not being able to bring up the installation instructions on the wiki site. I downloaded 4.1.3 a few days ago and have been reading the installation and upgrading instructions on wiki over the past week (trying to get my nerve up to take the plunge). Now I'm ready to get it installed, but when I went back to wiki yesterday to read the instructions again, I couldn't get on the website.
Again today I can't get to any links that begin with wiki.phpgedview.net. I'm getting the "Internet Explorer cannot display the webpage" notice for any link that begins with wiki.
This problem began at the same time I began having problems with the Record Search on labs.familysearch.org. However, not being able to get to the Record Search seems to be because of a problem with my computer because I can get to the Record Search on my husband's computer.
Because of that problem I wondered if not being able to get to the wiki site might also be related to something with my computer. So I tried reaching the wiki website on my husband's computer and I can't get to it from there either. So maybe this wiki problem isn't just a problem with my computer?
At least I got 4.1.3 downloaded a few days ago. I'm happy about that because I sure as heck can't get to it now.
But I really could use those instructions I was reading over the past week. I guess this is what I get for procrastinating. You snooze, you lose.
Am I the only one having problems getting to http://wiki.phpgedview.net? Any suggestions?
No, I just tried connecting to the Wiki site, and I can't get any response either.
Please e-mail me, and I'll give you instructions on how to do the upgrade to 4.1.3. Are you staying on the same server, or are you planning to do the upgrade at the same time you switch service providers?
g dot kroll at keldine dot ca
I e-mailed Cyndy instructions on how to upgrade.
After a minor glitch caused by telling PGV to calculate married names (don't do this), everything is working OK.
The user is happy.
I am using v4.0.2 stable, and have been doing so for years. Yes, I should upgrade, but while things are working fine….
About 24 hours ago, without any previous problems or warnings, any attempted edits starting generating this error (using an edit on my entry of I2489 as a sample):
ERROR 4: Could not find gedcom record with xref:I2489 Line 150 #0 replace_gedrec(I2489, 0 @I2489@ INDI 1 NAME RODNEY JOHN (ROD) /McInnes/ 2……FAMS @F825@) called at "
Following the discussion above, I checked the GEDCOM file by downloading a zipped backup from the server, and found that it now contains only one entry (x's added for privacy), number 3,332:
0 @I3332@ INDI
1 NAME JOSEPH /xxxxx/
2 GIVN JOSEPH
2 SURN xxxx
1 SEX M
2 DATE 01 JAN xxxx
2 PLAC VICTORIA
2 DATE 11 JAN 2013
3 TIME 18:06:38
2 _PGVU Nxxxxxxd"
The previous backup of the GEDCOM from October last year has entries Number 1 to 3,208, plus a lot of preamble code. So, again, using the example above, it appears that my GEDCOM is corrupted, missing all but one entry from 11th January. The site is working fine (apart from editing). There are entries subsequent to I3208, up until about 15th January when the editing problem occurred. I've Exported the current SQL file which is 2.3MB from myphpadmin.
The discussion above advises to upload your backup GEDCOM to your Index directory.
My issue is that my GEDCOM backup is four months old, and so if it was uploaded it would be missing over a hundred entries. I've got the SQL backup, which must be current. What I'm missing is how I convert the SQL to GEDCOM or download a GEDCOM format from the database site.
Any ideas please?
Several issues here.
1) PLEASE - never resurrect a thread like this that is old. Post a new help request for new help.
2) What about the above GEDCOM snippet shows it is corrupted? It shows him unlinked as a spouse or child.
3) Place = Victoria: Since when is Victoria a country? Do you not use Top Levels? Google Maps will never work properly unless you do.
SQL to GEDCOM is always a simple DOWNLOAD or EXPORT, but if this person (and others) are unattached, as indicated in the ERROR report, you may have to see how prevalent this is. You can run GEDCHECK to see how many errors you have, but with PGV, you do this on a GEDCOM, not on the database.
Also, you have discovered one of the factors involved with the real need for you to upgrade. QuickUpdate is deprecated and causes nothing but problems. Also, your version has significant security holes and your data is at risk.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.