Is there any way to share sources between GEDCOMS? Several of my sources cross over between all of my GEDCOMS. Is there a way to link a source from one GEDCOM to individuals in another GEDCOM?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Trevor
You wouldn't want to do this - really! The concept of PGV and other GEDCOM v5.5+ compliant programs is to maintain that GEDCOM for portability across multiple platforms - hence the acronym for the name itself. If you link to other gedcoms for their source (or other information), you would not have those sources within the gedcom you are managing at that time. Bad data, bad record keeping.
That said, there is nothing to prevent you from copying these sources and using the same SOUR number and SOUR descriptions in multiple GEDCOMs, as long as the numbers don't conflict. I have each CENSUS year as a SOUR, S1800, S1810, S1820….S1930 in all four GEDCOMs, and S31 is always the SSDI/SSN database, etc. It certainly makes it easy when I cross GEDCOMs and are quickly entering SOUR references from memory, rather than auto-complete.
Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Stephen,
Like your concept for SOUR numbers for Census. Did you manually set the numbers? Or when you got to that number, reserve them for that purpose? Would love to do that for my US Census sources. I have a lot, all part of the same 'groups' (1880, 1900, 19xx)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-05-20
Stephen,
Got it. I did consider the fact that in order to be able to link to an "outside" source that the source would in fact be stored outside of the GEDCOM. However, I thought that maybe, just maybe there was a way to import these sources into the current GEDCOM automatically when "linking" to a source outside of it.
Anyway,I too, very much like your method of numbering sources - that is a good idea!
I considered the fact that if you could link to
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-05-20
That last line of my previous post is a typo.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I set them up using PGV's new SOURce, then accesses the SQL and changed each of the SOUR ID numbers to the ones that I wanted.
Then I returned to the SQL and reset the SOUR Next ID to a low number so that it would fill-in the 'holes' sequentially, and skip the Census SOUR numbers when it reached them.
To set these up in the other GEDCOMS, I simply copied them from a text GEDCOM into the other GEDCOMs and reimported those. I suppose you could do this all in text and reimport, but I wasn't sure of conflicts on my big GEDCOM.
Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I like the idea for setting the source id's for census sources to a unique number that is easy to remember. It have a lot of value when you use the same source over and over.
Question: Internally, do these "foreign keys" obtain their values for searches from the record that uses the source. For example the Individual "I23" has a source of "S1880". Is the "S1880" used directly from the "I23" SOUR record? Would the PGV still function (including the queries, source lookup and reports) if the "S1880" was changed to a "C1880" for census (or CS for Census Source) thus eliminating the need to jump over the "S1880" when you reach the number. I could envision using source "Foreign keys" of any descriptive type or value like "CS_G1880" for "census source germany" so it is not confused with CS_U1880 for USA.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, maybe it's bit complicated after all. I have 3 Gedcoms on the site. Not sure how the tables differentiate the SOURs for each of them as each has a S1, etc. Is there 3 different pgv_nextid?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll try to answer each of the pending questions.
The AlphaNumeric IDs for all GEDCOMs can contain several alpha characters, after the first one you specify in the GEDCOM configuration, the default being: I=Individual, F=Family, M=Media, S=Source, R=Repository, etc.
So the answer to the question of multiple alpha characters would be yes, SC1800, SC1810, SC1820, SC1830, SC1840….. would be just fine, but a better question would be WHY? I can't imagine why you'd wish to muck up the standardized and simple system. It would be just as simple to have it be s1800, s1810, etc as the lower and upper case are entirely different. But again, Why?
The easiest method for creating these is simply use PGV to create each source, in order (and I did some future ones as well). After creating them, each will be present in the database. Simply access the table: pgv_sources, search for the first one to change and modify the SQL (both the s_id field and the s_gedcom field) changing Sxxx to S1800 in both places to create the SOUR @S1800@, etc.
After modifying each SOUR reference for your newly assigned designations, navigate to:
pgv_nextid table and reset the SOUR table ni_id field to a very low number, even 1. It will auto-increment to the next available SOUR record number when it creates the next ID-number, skipping over existing records, filling in the holes. (This same technique works for INDI-ID numbers, Media-ID numbers, Family-ID numebrs, etc in case you have deleted a lot of ID-numbers or created a gedcom by merging and you didn't renumber the INDI's, etc.
s there 3 different pgv_nextid?
Yes, the field ni_gedfile in the pgv_nextid table specifies to which GEDCOM the change applies. If you have only one GEDCOM, then the number is most likely 1, unless you previously had a #1 and deleted it.
Hopefully, I answered all the pending questions. if not, simply repost in a single line format and I'll try to respond.
Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The only reason for the CS would be so that you could keep the standard "S" for the natural source numbering and the "CS" or "s" or any other letter would be so you would not someday advance past to the "S1880" and need to remember to jump over the previously defined "S1880". i.e. Add a new source in PGV of "S1879" then the next ID for source would be set to 1880 which you then would have to manually change in pgv_nextid to 1881. Correct?? Having the lowercase "s" in "s1880" works fine. and does not require you to manually change the nextid.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wrong - as previously described, the ni_id field in the pgv_nextid table auto-increments to the NEXT AVAILABLE ID-number. That's why I said you can set it for '1' (that's a one) and let it fill in all the holes, should you wish to do that. If you set SOUR ni_id field for 1 and S1, S2, S3, S4, S5, S6 existed, but S7 did not, it would assign S7 to the newly created ID.
Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Then I'm wrong, but if you had several thousand sources would not setting it to "1" cause a lot of overhead finding the first available open source number?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SQL indexing is likety-split. If you think you could sense any delay, you're a better person than I. Remember, setting to 1 is not necessary, but it would allow you to 'fill-in' every missing number. I would assume there are few missing IDs, but it is really irrelevant. Compared to adding an INDI via edit-gedcom or other intensive insert-SQL commands, the find-next-id-number load is miniscule.
Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I view <Database> > Table: pgv_nextid I see:
SQL query:
SELECT COUNT( * ) AS `Rows` , `ni_gedfile`
FROM `pgv_nextid`
GROUP BY `ni_gedfile`
ORDER BY `ni_gedfile`
LIMIT 0 , 30
When I view field s_id:
SELECT COUNT( * ) AS `Rows` , `s_id`
FROM `pgv_sources`
GROUP BY `s_id`
ORDER BY `s_id`
LIMIT 0 , 30
So guess I am not understanding how you're seeing "direct" reference to your PGV gedcom file. I'm viewing in phpMyAdmin. <Server> <Database> <Table> <Field>. Is this the correct place to see what you are referring to?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I click around I get to:
<server><database><Table: pgv_nextid>
Field: ni_id
Type: INT
Length/Values: 11
Collation: -
Attributes: -
Null: null
Default: NULL
Extra -
Comments -
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
HOw would you specify a number, except to use the technique I discussed early-on - do it manually in the gedcom text and then reimport. You wouldn't need all the details, just the 0 @Sxxx@ SOUR line and add the 1 TITL line if you wish, then reimport.
Mac - you must not be accustomed to browsing your SQL with phpMyAdmin
1) Open phpmyadmin to your database list
2) click on the PGV database (left side)
3) click on the table pgv_nextid (left side)
4) opens a columnar report with check box | Edit | Delete| ni_id | ni_type | ni_gedfile
5) scroll down to the SOUR ni_type that pertains to your gedcom (1 ?)
6) click EDIT (pencil icon)
7) opens columnar report with last column titled VALUE
8) change the value to whatever number you wish to reset the numbering system
9) click GO to save your change. Your next-id has been reset for this parameter
-Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I uploaded images of what steps I took based upon your steps. They're in FLICKR in reverse order. (I never use this and didn't take time to play around). The below should get you to the images, Step 1-3, Step 4, Step 5. Didn't go beyond as you'll see I didn't see what you were seeing.
Mac
That's a private account and I can't see any images. Why not email me directly? But what are you trying to do here?
To create the SOUR references, if you have nothing in that series, you can use the create an unattached source and title it to the desired content/reference. Then open it with RAW edit and change the SOUR reference line to whatever you wish, Like:
0 @S1234@ SOUR
1 ABBR 1870 USA Federal Census
1 TITL 1870 USA Federal Census
to
0 @S1870@ SOUR
1 ABBR 1870 USA Federal Census
1 TITL 1870 USA Federal Census
Then the next one, and the next and the next. But you still have to reset the next_id for SOUR if you don't want the system to start with S1931, assuming you stopped at the 1930 Census.
Stephen
mailto:gedcoms-at-myarnolds-dot-com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there any way to share sources between GEDCOMS? Several of my sources cross over between all of my GEDCOMS. Is there a way to link a source from one GEDCOM to individuals in another GEDCOM?
Trevor
You wouldn't want to do this - really! The concept of PGV and other GEDCOM v5.5+ compliant programs is to maintain that GEDCOM for portability across multiple platforms - hence the acronym for the name itself. If you link to other gedcoms for their source (or other information), you would not have those sources within the gedcom you are managing at that time. Bad data, bad record keeping.
That said, there is nothing to prevent you from copying these sources and using the same SOUR number and SOUR descriptions in multiple GEDCOMs, as long as the numbers don't conflict. I have each CENSUS year as a SOUR, S1800, S1810, S1820….S1930 in all four GEDCOMs, and S31 is always the SSDI/SSN database, etc. It certainly makes it easy when I cross GEDCOMs and are quickly entering SOUR references from memory, rather than auto-complete.
Stephen
Stephen,
Like your concept for SOUR numbers for Census. Did you manually set the numbers? Or when you got to that number, reserve them for that purpose? Would love to do that for my US Census sources. I have a lot, all part of the same 'groups' (1880, 1900, 19xx)
Stephen,
Got it. I did consider the fact that in order to be able to link to an "outside" source that the source would in fact be stored outside of the GEDCOM. However, I thought that maybe, just maybe there was a way to import these sources into the current GEDCOM automatically when "linking" to a source outside of it.
Anyway,I too, very much like your method of numbering sources - that is a good idea!
I considered the fact that if you could link to
That last line of my previous post is a typo.
I set them up using PGV's new SOURce, then accesses the SQL and changed each of the SOUR ID numbers to the ones that I wanted.
Then I returned to the SQL and reset the SOUR Next ID to a low number so that it would fill-in the 'holes' sequentially, and skip the Census SOUR numbers when it reached them.
To set these up in the other GEDCOMS, I simply copied them from a text GEDCOM into the other GEDCOMs and reimported those. I suppose you could do this all in text and reimport, but I wasn't sure of conflicts on my big GEDCOM.
Stephen
Couldn't find where to edit the SQL. In PhpMyAdmin I can get to the tables but not how to edit :(
I think where he is saying is the table called pgv_nextid. This file contains the next index/ID number for each of the GEDCOM record types.
I like the idea for setting the source id's for census sources to a unique number that is easy to remember. It have a lot of value when you use the same source over and over.
Question: Internally, do these "foreign keys" obtain their values for searches from the record that uses the source. For example the Individual "I23" has a source of "S1880". Is the "S1880" used directly from the "I23" SOUR record? Would the PGV still function (including the queries, source lookup and reports) if the "S1880" was changed to a "C1880" for census (or CS for Census Source) thus eliminating the need to jump over the "S1880" when you reach the number. I could envision using source "Foreign keys" of any descriptive type or value like "CS_G1880" for "census source germany" so it is not confused with CS_U1880 for USA.
Okay, maybe it's bit complicated after all. I have 3 Gedcoms on the site. Not sure how the tables differentiate the SOURs for each of them as each has a S1, etc. Is there 3 different pgv_nextid?
If I remember correct you will have 3 ??_nextid tables. I don't have multiple GEDCOMs now.
I'll try to answer each of the pending questions.
The AlphaNumeric IDs for all GEDCOMs can contain several alpha characters, after the first one you specify in the GEDCOM configuration, the default being: I=Individual, F=Family, M=Media, S=Source, R=Repository, etc.
So the answer to the question of multiple alpha characters would be yes, SC1800, SC1810, SC1820, SC1830, SC1840….. would be just fine, but a better question would be WHY? I can't imagine why you'd wish to muck up the standardized and simple system. It would be just as simple to have it be s1800, s1810, etc as the lower and upper case are entirely different. But again, Why?
The easiest method for creating these is simply use PGV to create each source, in order (and I did some future ones as well). After creating them, each will be present in the database. Simply access the table: pgv_sources, search for the first one to change and modify the SQL (both the s_id field and the s_gedcom field) changing Sxxx to S1800 in both places to create the SOUR @S1800@, etc.
After modifying each SOUR reference for your newly assigned designations, navigate to:
pgv_nextid table and reset the SOUR table ni_id field to a very low number, even 1. It will auto-increment to the next available SOUR record number when it creates the next ID-number, skipping over existing records, filling in the holes. (This same technique works for INDI-ID numbers, Media-ID numbers, Family-ID numebrs, etc in case you have deleted a lot of ID-numbers or created a gedcom by merging and you didn't renumber the INDI's, etc.
Yes, the field ni_gedfile in the pgv_nextid table specifies to which GEDCOM the change applies. If you have only one GEDCOM, then the number is most likely 1, unless you previously had a #1 and deleted it.
Hopefully, I answered all the pending questions. if not, simply repost in a single line format and I'll try to respond.
Stephen
But you would need to only deal with one for renumbering. and copy the newly created "source" records from one GEDCOM to the other 2 GEDCOMs
The only reason for the CS would be so that you could keep the standard "S" for the natural source numbering and the "CS" or "s" or any other letter would be so you would not someday advance past to the "S1880" and need to remember to jump over the previously defined "S1880". i.e. Add a new source in PGV of "S1879" then the next ID for source would be set to 1880 which you then would have to manually change in pgv_nextid to 1881. Correct?? Having the lowercase "s" in "s1880" works fine. and does not require you to manually change the nextid.
Wrong - as previously described, the ni_id field in the pgv_nextid table auto-increments to the NEXT AVAILABLE ID-number. That's why I said you can set it for '1' (that's a one) and let it fill in all the holes, should you wish to do that. If you set SOUR ni_id field for 1 and S1, S2, S3, S4, S5, S6 existed, but S7 did not, it would assign S7 to the newly created ID.
Stephen
Then I'm wrong, but if you had several thousand sources would not setting it to "1" cause a lot of overhead finding the first available open source number?
SQL indexing is likety-split. If you think you could sense any delay, you're a better person than I. Remember, setting to 1 is not necessary, but it would allow you to 'fill-in' every missing number. I would assume there are few missing IDs, but it is really irrelevant. Compared to adding an INDI via edit-gedcom or other intensive insert-SQL commands, the find-next-id-number load is miniscule.
Stephen
When I view <Database> > Table: pgv_nextid I see:
SQL query:
SELECT COUNT( * ) AS `Rows` , `ni_gedfile`
FROM `pgv_nextid`
GROUP BY `ni_gedfile`
ORDER BY `ni_gedfile`
LIMIT 0 , 30
When I view field s_id:
SELECT COUNT( * ) AS `Rows` , `s_id`
FROM `pgv_sources`
GROUP BY `s_id`
ORDER BY `s_id`
LIMIT 0 , 30
So guess I am not understanding how you're seeing "direct" reference to your PGV gedcom file. I'm viewing in phpMyAdmin. <Server> <Database> <Table> <Field>. Is this the correct place to see what you are referring to?
Query? Why query?
Browse the table to look at the data.
Stephen
When I click around I get to:
<server><database><Table: pgv_nextid>
Field: ni_id
Type: INT
Length/Values: 11
Collation: -
Attributes: -
Null: null
Default: NULL
Extra -
Comments -
Why not just create the new unconnected source, S1900, then merge the current 1900 census source (in my case S44) into it on the Admin page?
I'd do that if I knew but have no idea how to override the auto next number that PGV would use.
HOw would you specify a number, except to use the technique I discussed early-on - do it manually in the gedcom text and then reimport. You wouldn't need all the details, just the 0 @Sxxx@ SOUR line and add the 1 TITL line if you wish, then reimport.
Mac - you must not be accustomed to browsing your SQL with phpMyAdmin
1) Open phpmyadmin to your database list
2) click on the PGV database (left side)
3) click on the table pgv_nextid (left side)
4) opens a columnar report with check box | Edit | Delete| ni_id | ni_type | ni_gedfile
5) scroll down to the SOUR ni_type that pertains to your gedcom (1 ?)
6) click EDIT (pencil icon)
7) opens columnar report with last column titled VALUE
8) change the value to whatever number you wish to reset the numbering system
9) click GO to save your change. Your next-id has been reset for this parameter
-Stephen
I uploaded images of what steps I took based upon your steps. They're in FLICKR in reverse order. (I never use this and didn't take time to play around). The below should get you to the images, Step 1-3, Step 4, Step 5. Didn't go beyond as you'll see I didn't see what you were seeing.
http://www.flickr.com/photos/macalter
Mac
That's a private account and I can't see any images. Why not email me directly? But what are you trying to do here?
To create the SOUR references, if you have nothing in that series, you can use the create an unattached source and title it to the desired content/reference. Then open it with RAW edit and change the SOUR reference line to whatever you wish, Like:
0 @S1234@ SOUR
1 ABBR 1870 USA Federal Census
1 TITL 1870 USA Federal Census
to
0 @S1870@ SOUR
1 ABBR 1870 USA Federal Census
1 TITL 1870 USA Federal Census
Then the next one, and the next and the next. But you still have to reset the next_id for SOUR if you don't want the system to start with S1931, assuming you stopped at the 1930 Census.
Stephen
mailto:gedcoms-at-myarnolds-dot-com