Some mistake has been made in the attempt to add a wife to a person, but I (the administrator) can't correct or delete this individual.
Looking at the male individual I16 he has a wife I14. Apparently the record for I14 is not valid (gender is shown as unknown and names are not showning at all. When I try to correct this I get an error:
>Access Denied
>You do not have access to this resource.
>Privacy settings prevent you from editing this record.
>You have no access to pid I14.
>The requested GEDCOM record could not be found. This could be caused by a link to an invalid person or >by a corrupt GEDCOM file.
The last sentence indicates that there's an error in the GEDCOM-file. Editing the GEDCOM-file directly gives the same above message.
Kent
First, it sounds like the INDI was removed, but the residual effects were not (a bug in 4.1.4)
Lets first resolve your issue. A manual deletion from the GEDCOM will only complicate matters, if you use SYNC to GEDCOM. Your problem is probably in the SQL, not the actual GEDCOM.
Navigate to the remaining FAM unit for the original husband and wife.
Open RAW edit and remove the reference to I14.
If you wish to DELETE the FAM unit, then also do so, using the GUI EDIT.
that should fix your issue in the SQL.
A couple of other issues.
1) GET THE HECK OUT oF 4.1.4. Big security holes and there are tons of hackers out there trying to exploit these. We're getting 4-8 registrations per week from people looking to holes. 4.1.5 has some bugs too, but hopefully we are but a few weeks away from 4.1.6 - lots of new, nifty features, faster searches and no known holes.
2) I recommend never using Quick Update. It is not conducive to good GEDCOM construction in that it allows the entry of supposedly factual information without allowing SOUR references. We restrict its use to ADMIN's only.
3) Don't get in the habit of deleting INDIs. PGV has excellent tools for CHANGING the structure of families under the OPTIONs menu in the FAM record. If there is a wrong child or parent, simply remove that person(s) from that family and then either reuse the INDI record by changing the data, or leave it for reattachment to another family. When you think about all the data movement that a deletion creates, its asking for trouble, and 4.1.4 had several bugs where the FAM record was not updated if an INDI was deleted. Always, IOHO, better to change, plus it keeps numbering under control.
Hope this helps, Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually I didn't thought of editing the family...and yes it worked, I deleted I14 without problems.
But something perculiar happened when I deleted I14 in family 5 (F5). The deleted wife automatically got exchanged with a new invisible wife I148 - she even inherited the 3 children from I14. I went for it and deleted I148 just to see that a third wife I149 entered the life of I14 and got the same 3 children. Finally I deleted I149 and now the fun stopped. The wife place in F5 now was empty. I tried to search for I14, I148 and I149 - they didn't exist anymore, strange!
I don't know if this behaviour can be explained, but the most important thing is I've cleaned up the tree for I16.
This leads me to the question : How do I reuse those empty places (as mentioned in your issue #3). In my case I cant change them as they don't exist anymore. I have noticed that I have some more holes in my tree - an extra 3 of them after this (I14, I148, I149)..
Regards
Kent Knudsen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But if you have some form of obsessive-compulsive-disorder that means you need uninterupted sequences of IDs, (and you have a recent version of PGV), then update the table pgv_nextid to "1". New IDs will be generated starting from the beginning (skipping ones that have already been used).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-09-04
Greg, thats an interesting suggestion. I never realised it was so easy. The question of re-using gaps in the ID sequence actually crops up in this forum fairly often. I've always said before that it wasn't possible.
If it can be done this easily - why do we need a next-id at all? Couldn't the next-numbering ALWAYS just start from 1, skipping those already in use?
Does the same apply to FAM, SOUR, MEDIA IDs etc?
ps - yes I do have a degree of OCD, or at least so my wife accuses. Its apparently a trait of capricorns! :-))
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<If it can be done this easily - why do we need a next-id at all? Couldn't the next-numbering ALWAYS just start from 1, skipping those already in use? >>
On a large gedcom, checking for I1, I2, I3, I4... I10000 would take a significant amount of time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<If it can be done this easily - why do we need a next-id at all? Couldn't the next-numbering ALWAYS just start from 1, skipping those already in use? >>
<<On a large gedcom, checking for I1, I2, I3, I4... I10000 would take a significant amount of time.>>
Then a additional table could be introduced. This table keeps track of non-used ID's. A routine is needed to sort ID's (either putting the ID on the free-list or the occupied-list). Maybe its simpler to have one single table where all ID's are tagged free or non-free.
A search throughout all ID's is indeed too timeconsuming/costly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PGV 4.1.4 on FC4
Some mistake has been made in the attempt to add a wife to a person, but I (the administrator) can't correct or delete this individual.
Looking at the male individual I16 he has a wife I14. Apparently the record for I14 is not valid (gender is shown as unknown and names are not showning at all. When I try to correct this I get an error:
>Access Denied
>You do not have access to this resource.
>Privacy settings prevent you from editing this record.
>You have no access to pid I14.
>The requested GEDCOM record could not be found. This could be caused by a link to an invalid person or >by a corrupt GEDCOM file.
The last sentence indicates that there's an error in the GEDCOM-file. Editing the GEDCOM-file directly gives the same above message.
Doing a Quick Update gives:
>Quick Update
>
>Update successful
>ERROR 20: Invalid GEDCOM 5.5 format.
How do I correct this individual I14?
Regards
Kent Knudsen
Kent
First, it sounds like the INDI was removed, but the residual effects were not (a bug in 4.1.4)
Lets first resolve your issue. A manual deletion from the GEDCOM will only complicate matters, if you use SYNC to GEDCOM. Your problem is probably in the SQL, not the actual GEDCOM.
Navigate to the remaining FAM unit for the original husband and wife.
Open RAW edit and remove the reference to I14.
If you wish to DELETE the FAM unit, then also do so, using the GUI EDIT.
that should fix your issue in the SQL.
A couple of other issues.
1) GET THE HECK OUT oF 4.1.4. Big security holes and there are tons of hackers out there trying to exploit these. We're getting 4-8 registrations per week from people looking to holes. 4.1.5 has some bugs too, but hopefully we are but a few weeks away from 4.1.6 - lots of new, nifty features, faster searches and no known holes.
2) I recommend never using Quick Update. It is not conducive to good GEDCOM construction in that it allows the entry of supposedly factual information without allowing SOUR references. We restrict its use to ADMIN's only.
3) Don't get in the habit of deleting INDIs. PGV has excellent tools for CHANGING the structure of families under the OPTIONs menu in the FAM record. If there is a wrong child or parent, simply remove that person(s) from that family and then either reuse the INDI record by changing the data, or leave it for reattachment to another family. When you think about all the data movement that a deletion creates, its asking for trouble, and 4.1.4 had several bugs where the FAM record was not updated if an INDI was deleted. Always, IOHO, better to change, plus it keeps numbering under control.
Hope this helps, Stephen
Thanks for the extensive guidance/ help.
Actually I didn't thought of editing the family...and yes it worked, I deleted I14 without problems.
But something perculiar happened when I deleted I14 in family 5 (F5). The deleted wife automatically got exchanged with a new invisible wife I148 - she even inherited the 3 children from I14. I went for it and deleted I148 just to see that a third wife I149 entered the life of I14 and got the same 3 children. Finally I deleted I149 and now the fun stopped. The wife place in F5 now was empty. I tried to search for I14, I148 and I149 - they didn't exist anymore, strange!
I don't know if this behaviour can be explained, but the most important thing is I've cleaned up the tree for I16.
This leads me to the question : How do I reuse those empty places (as mentioned in your issue #3). In my case I cant change them as they don't exist anymore. I have noticed that I have some more holes in my tree - an extra 3 of them after this (I14, I148, I149)..
Regards
Kent Knudsen
<<How do I reuse those empty places>>
Ignore them.
But if you have some form of obsessive-compulsive-disorder that means you need uninterupted sequences of IDs, (and you have a recent version of PGV), then update the table pgv_nextid to "1". New IDs will be generated starting from the beginning (skipping ones that have already been used).
Greg, thats an interesting suggestion. I never realised it was so easy. The question of re-using gaps in the ID sequence actually crops up in this forum fairly often. I've always said before that it wasn't possible.
If it can be done this easily - why do we need a next-id at all? Couldn't the next-numbering ALWAYS just start from 1, skipping those already in use?
Does the same apply to FAM, SOUR, MEDIA IDs etc?
ps - yes I do have a degree of OCD, or at least so my wife accuses. Its apparently a trait of capricorns! :-))
<<If it can be done this easily - why do we need a next-id at all? Couldn't the next-numbering ALWAYS just start from 1, skipping those already in use? >>
On a large gedcom, checking for I1, I2, I3, I4... I10000 would take a significant amount of time.
<<If it can be done this easily - why do we need a next-id at all? Couldn't the next-numbering ALWAYS just start from 1, skipping those already in use? >>
<<On a large gedcom, checking for I1, I2, I3, I4... I10000 would take a significant amount of time.>>
Then a additional table could be introduced. This table keeps track of non-used ID's. A routine is needed to sort ID's (either putting the ID on the free-list or the occupied-list). Maybe its simpler to have one single table where all ID's are tagged free or non-free.
A search throughout all ID's is indeed too timeconsuming/costly.