I've found this old script which renumbers gedcom identifiers to remove gaps in the numbering sequence. It assumes you are using the standard prefixes, and have a large enough execution-time-limit on your server.
There really is no need to do this and no advantage to be gained. It can only break your pgv favourites, other peoples's browser favourites, etc.
No instructions, support or warranty.
<?php
$f=file_get_contents('gedcom.ged');
foreach (array('R'=>'REPO', 'M'=>'OBJE', 'F'=>'FAM', 'I'=>'INDI', 'S'=>'SOUR') as $prefix=>$type) {
preg_match_all("/^0 @(.+)@ {$type}\r?$/m", $f, $matches);
$xrefs=array();
foreach ($matches[1] as $match) {
$xrefs[$match]=$match;
}
$new_xref=1;
foreach ($xrefs as $xref) {
preg_match('/^(.*?)(\d*)$/', $xref, $match);
if ($match[1]!=$prefix || !is_numeric($match[2]) || $match[2]>count($xrefs)) {
while (in_array($prefix.$new_xref, $xrefs)) {
++$new_xref;
}
echo "$xref changed to $prefix$new_xref<br/>";
$f=str_replace("@$xref@", "@$prefix$new_xref@", $f);
$xrefs[$xref]=$prefix.$new_xref;
}
}
}
file_put_contents('gedcom2.ged', $f);
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-12-01
Although I am one of those 'an*%^y retentive' people who like order and no gaps in my GEDCOM numbering, I have to support Greg's comments here.
This will NOT improve PGV's speed or efficiency. It will NOT be noticed by 99.999% of your users.
It WILL destroy links to PGV favorites (yours and each individual user's). It WILL destroy user's GEDCOM Id's. I dread to think what it will do to complex OBJE table links.
The only solution I know of that works is :
a) reset the next-id table items all to 1
b) be patient while PGV fills in the blanks from there up as you add new INDI, FAM, SOUR, OBJE items.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"I dread to think what it will do to complex OBJE table links."
If the first occurrence of M1234 assigns a new number, and all other occurrences get the same number (as appears from a superficial look at the code), then all the links will still work fine.
It's what's _outside_ the GEDCOM that will be messed up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-12-02
Wes - yes in the GEDCOM file - but I referred to the OBJE TABLE (i.e. the tables in the database, like pgv_media, pgv_media_mapping.
They 'might' get updated by a GEDCOM re-import, but given the complexities, and nunber if issues media importing raises on these pages, I wouldn't want to be the first to try :-))
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've found this old script which renumbers gedcom identifiers to remove gaps in the numbering sequence. It assumes you are using the standard prefixes, and have a large enough execution-time-limit on your server.
There really is no need to do this and no advantage to be gained. It can only break your pgv favourites, other peoples's browser favourites, etc.
No instructions, support or warranty.
<?php
$f=file_get_contents('gedcom.ged');
foreach (array('R'=>'REPO', 'M'=>'OBJE', 'F'=>'FAM', 'I'=>'INDI', 'S'=>'SOUR') as $prefix=>$type) {
preg_match_all("/^0 @(.+)@ {$type}\r?$/m", $f, $matches);
$xrefs=array();
foreach ($matches[1] as $match) {
$xrefs[$match]=$match;
}
$new_xref=1;
foreach ($xrefs as $xref) {
preg_match('/^(.*?)(\d*)$/', $xref, $match);
if ($match[1]!=$prefix || !is_numeric($match[2]) || $match[2]>count($xrefs)) {
while (in_array($prefix.$new_xref, $xrefs)) {
++$new_xref;
}
echo "$xref changed to $prefix$new_xref<br/>";
$f=str_replace("@$xref@", "@$prefix$new_xref@", $f);
$xrefs[$xref]=$prefix.$new_xref;
}
}
}
file_put_contents('gedcom2.ged', $f);
Although I am one of those 'an*%^y retentive' people who like order and no gaps in my GEDCOM numbering, I have to support Greg's comments here.
This will NOT improve PGV's speed or efficiency. It will NOT be noticed by 99.999% of your users.
It WILL destroy links to PGV favorites (yours and each individual user's). It WILL destroy user's GEDCOM Id's. I dread to think what it will do to complex OBJE table links.
The only solution I know of that works is :
a) reset the next-id table items all to 1
b) be patient while PGV fills in the blanks from there up as you add new INDI, FAM, SOUR, OBJE items.
And, NO SUPPORT from this group for anyone trying this. PLEASE,
BACKUP - BACKUP - BACKUP
Stephen
"I dread to think what it will do to complex OBJE table links."
If the first occurrence of M1234 assigns a new number, and all other occurrences get the same number (as appears from a superficial look at the code), then all the links will still work fine.
It's what's _outside_ the GEDCOM that will be messed up.
Wes - yes in the GEDCOM file - but I referred to the OBJE TABLE (i.e. the tables in the database, like pgv_media, pgv_media_mapping.
They 'might' get updated by a GEDCOM re-import, but given the complexities, and nunber if issues media importing raises on these pages, I wouldn't want to be the first to try :-))