Again, thanks for the cool software. Been here since the near beginning. 2.51.3 looks great. I got screwed up on the table changes (DOH who reads the readme.txt, isn't that a developers way to chew up disk space with un-needed data?).
Anyhow, my fathers thumbnail displays when I'm not logged in. I have tried from random terminals, including one in France at INet cafe.
He is not dead, nor can I figure out what has triggered this. I started seeing this around 2.1x.
The raw record from GedView is:
0 @I97@ INDI
1 NAME Robert Kendall /Trainer/
2 GIVN Robert Kendall
2 SURN Trainer
1 SEX M
1 BIRT
2 DATE 11 Mar 1929
2 PLAC Montclair, New Jersey Essex County
1 CHAN
2 DATE 23 Jul 2003
3 TIME 00:02
1 OBJE
2 FORM jpg
2 FILE C:\Legacy\Pictures\Picture_184.jpg
2 TITL Robert Kendall Trainer
2 _SCBK Y
2 _PRIM Y
2 _TYPE PHOTO
1 OBJE
2 FORM jpg
2 FILE C:\Legacy\Pictures\Robert_Kendall_Trainer.jpg
2 TITL Robert Kendall Trainer
2 _SCBK Y
2 _TYPE PHOTO
1 FAMS @F73@
1 FAMS @F74@
1 FAMC @F663@
What is taging him as dead?
Thanks
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can't say what causes this problem, but earlier this a.m. I discovered that different installs of phpGedView on the same server not are completely independant of each other if they share a common session.save_path.
I can't promise it will help you, but it surely could be interesting to test, if it makes a difference, if you set "Session Save Path" to ./index/
In order to set "Session Save Path" to ./index/ you need to login, then click on the Admin Link, then click on the Configuration link and fill the "Session Save Path" box in with ./index/ and finally click on the "Save Configuration" button.
If this local path solve the problem, you'll have to enter this path everytime you make a new install.
If this local path doesn't solve the problem, I guess that John Finlay has a better solution to you :-)
best regard
Arne
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This ocurs even on a single install. I cleared out my older betas, deleted the databases etc. Current standing is one install, so that is ruled out. It is just odd that my fathers details are displayed, yet the record does not have a death bit in it.
Thanks
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was thinking that you perhaps had your installation at a server where other people also had access to place their installations of phpGedView (a webhotel).
In such a scenario ALL installations of phpGedView on the server would share the same Session Save Path, unless they set the Session Save Path to a folder in their own folder.
So, even if you have a single install, there can be multible installs of phpGedView on the server, if you are using a webhotel or such.
best regard
Arne
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK< I see what you mean. Other instances of GedView, but not just in my home folder. Hmm, interesting. The only issue is that it is still only my father that is wrongly displayed. But I will look around at my installs, and look to localize the path.
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can't remember if you are using MySQL or Indexes, but something that will help me is to know if the program tagged your father as dead when it imported the records.
To check this for MySQL, use phpMyAdmin or the MySQL command line to look at the database table record for your father and let me know what is in the i_isdead column for him.
To check this for file indexes, open the ./index/gedcom_index.php file and search for your father's record in there. Look for the ["isdead"] value of the array.
This will tell me if I need to focus on the function that calculates the death status of a person, or if I need to focus on the display function.
Thanks,
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
John,
after re-importing the Gedcom that flag is now set properly - - individuals still alive are marked private - I will re-download the latest version this weekend and hopefully all will be well
cheers
Jim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After paging through the pgv_individuals table, I found his record, and we have a 1 in the i_isdead colum.
I manually changed this in the database to a 0. Problem went away. So of course I have to play with this now. So I closed all windows, opened the site, browsed, all fine. Logged in saw his thumbnail, all looks good. Logged out, and reviewed the record, still fine.
Re-imported gedcom. Problem is back again.
So it seems to be something in the gedcom record. However, I have not marked him as dead, nor is there a DEAT marker in the record. I'll have to go page by page to see if I notice this again. As of this momment, this is the only record I have noticed this with. Boy am I glad you figured out the thumbnail request. This is actually how I noticed it.
I can set up an additional database, and let you have admin rights to review if needed. please advise.
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After much playing and tweaking, I found that if I edit the Gedcom directly either; before first import, or before a reimport, I then make my fathers record behave correctly as does all others. (Still only record that I have noted this issue with.)
The edit is simply to remove the CHAN records from his individual ID. Importing this record corrects it's display from phpGedView.
Yes with the CHAN in the record, the value I_ISDEAD = 1.
I'll try the Index install to see if the problem goes away.
Thanks
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, the CHAN entries are part off the Gedcom 5.5 standard:
CHANGE_DATE: =
n CHAN {1:1}
+1 DATE <CHANGE_DATE> {1:1}
+2 TIME <TIME_VALUE> {0:1}
+1 <<NOTE_STRUCTURE>> {0:M}
The change date is intended to only record the last change to a record. Some systems may want to manage the change process with more detail, but it is sufficient for GEDCOM purposes to indicate the last time that a record was modified.
best regard
Arne
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried using the gedcom record you posted above in one of my test gedcom files and it correctly marked him as private. I don't think that the CHAN record itself is the problem, but the records location in the file relative to other records. If you want to email your gedcom to me I will try to figure it out.
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
John,
Again, thanks for the cool software. Been here since the near beginning. 2.51.3 looks great. I got screwed up on the table changes (DOH who reads the readme.txt, isn't that a developers way to chew up disk space with un-needed data?).
Anyhow, my fathers thumbnail displays when I'm not logged in. I have tried from random terminals, including one in France at INet cafe.
He is not dead, nor can I figure out what has triggered this. I started seeing this around 2.1x.
The raw record from GedView is:
0 @I97@ INDI
1 NAME Robert Kendall /Trainer/
2 GIVN Robert Kendall
2 SURN Trainer
1 SEX M
1 BIRT
2 DATE 11 Mar 1929
2 PLAC Montclair, New Jersey Essex County
1 CHAN
2 DATE 23 Jul 2003
3 TIME 00:02
1 OBJE
2 FORM jpg
2 FILE C:\Legacy\Pictures\Picture_184.jpg
2 TITL Robert Kendall Trainer
2 _SCBK Y
2 _PRIM Y
2 _TYPE PHOTO
1 OBJE
2 FORM jpg
2 FILE C:\Legacy\Pictures\Robert_Kendall_Trainer.jpg
2 TITL Robert Kendall Trainer
2 _SCBK Y
2 _TYPE PHOTO
1 FAMS @F73@
1 FAMS @F74@
1 FAMC @F663@
What is taging him as dead?
Thanks
John
Hi John Trainer
I can't say what causes this problem, but earlier this a.m. I discovered that different installs of phpGedView on the same server not are completely independant of each other if they share a common session.save_path.
I can't promise it will help you, but it surely could be interesting to test, if it makes a difference, if you set "Session Save Path" to ./index/
In order to set "Session Save Path" to ./index/ you need to login, then click on the Admin Link, then click on the Configuration link and fill the "Session Save Path" box in with ./index/ and finally click on the "Save Configuration" button.
If this local path solve the problem, you'll have to enter this path everytime you make a new install.
If this local path doesn't solve the problem, I guess that John Finlay has a better solution to you :-)
best regard
Arne
Arne, Thanks for the reply.
This ocurs even on a single install. I cleared out my older betas, deleted the databases etc. Current standing is one install, so that is ruled out. It is just odd that my fathers details are displayed, yet the record does not have a death bit in it.
Thanks
John
Hi again John Trainer
I was thinking that you perhaps had your installation at a server where other people also had access to place their installations of phpGedView (a webhotel).
In such a scenario ALL installations of phpGedView on the server would share the same Session Save Path, unless they set the Session Save Path to a folder in their own folder.
So, even if you have a single install, there can be multible installs of phpGedView on the server, if you are using a webhotel or such.
best regard
Arne
Arne,
OK< I see what you mean. Other instances of GedView, but not just in my home folder. Hmm, interesting. The only issue is that it is still only my father that is wrongly displayed. But I will look around at my installs, and look to localize the path.
John
Yes, I agree: It is strange that this only happens to your father, and as you say there are nothing in the record indicating death.
I wonder if the CHAN entry:
1 CHAN
2 DATE 23 Jul 2003
perhaps could be misinterpretated?
Just trying to guess ;-)
best regard
Arne
Hi John,
I can't remember if you are using MySQL or Indexes, but something that will help me is to know if the program tagged your father as dead when it imported the records.
To check this for MySQL, use phpMyAdmin or the MySQL command line to look at the database table record for your father and let me know what is in the i_isdead column for him.
To check this for file indexes, open the ./index/gedcom_index.php file and search for your father's record in there. Look for the ["isdead"] value of the array.
This will tell me if I need to focus on the function that calculates the death status of a person, or if I need to focus on the display function.
Thanks,
--John
John,
after re-importing the Gedcom that flag is now set properly - - individuals still alive are marked private - I will re-download the latest version this weekend and hopefully all will be well
cheers
Jim
John,
I use the mySQL version.
After paging through the pgv_individuals table, I found his record, and we have a 1 in the i_isdead colum.
I manually changed this in the database to a 0. Problem went away. So of course I have to play with this now. So I closed all windows, opened the site, browsed, all fine. Logged in saw his thumbnail, all looks good. Logged out, and reviewed the record, still fine.
Re-imported gedcom. Problem is back again.
So it seems to be something in the gedcom record. However, I have not marked him as dead, nor is there a DEAT marker in the record. I'll have to go page by page to see if I notice this again. As of this momment, this is the only record I have noticed this with. Boy am I glad you figured out the thumbnail request. This is actually how I noticed it.
I can set up an additional database, and let you have admin rights to review if needed. please advise.
John
I upgraded to 2.51.3 then re-imported the gedcom (after telling it to clear the tables) and the problem went away - all works fine now
Jim
John,
After much playing and tweaking, I found that if I edit the Gedcom directly either; before first import, or before a reimport, I then make my fathers record behave correctly as does all others. (Still only record that I have noted this issue with.)
The edit is simply to remove the CHAN records from his individual ID. Importing this record corrects it's display from phpGedView.
Yes with the CHAN in the record, the value I_ISDEAD = 1.
I'll try the Index install to see if the problem goes away.
Thanks
John
Hi again John Trainer
I'm interferring again to say I'm glad you tried to remove the CHAN entry, and that it proved successful :-)
best regard
Arne
John,
2.52b did not correct the problem with my fathers record inport. I will mess around tonight, and clear the database, and drop the CHAN entries.
Are the CHAN entries part of the Gedcom 5.5 standard?
John
Hi John Trainer,
Yes, the CHAN entries are part off the Gedcom 5.5 standard:
CHANGE_DATE: =
n CHAN {1:1}
+1 DATE <CHANGE_DATE> {1:1}
+2 TIME <TIME_VALUE> {0:1}
+1 <<NOTE_STRUCTURE>> {0:M}
The change date is intended to only record the last change to a record. Some systems may want to manage the change process with more detail, but it is sufficient for GEDCOM purposes to indicate the last time that a record was modified.
best regard
Arne
Hi John,
I tried using the gedcom record you posted above in one of my test gedcom files and it correctly marked him as private. I don't think that the CHAN record itself is the problem, but the records location in the file relative to other records. If you want to email your gedcom to me I will try to figure it out.
--John
John,
What address can I send my gedcom to you at?
I'd be interested in your findings.
John
yalnifj at users.sourceforge.net
--John
Sent