Thread: [Phpgedview-talk] Can't add new people
Brought to you by:
canajun2eh,
yalnifj
From: ggpauly <ge...@ri...> - 2007-12-02 13:18:28
|
I get stuck at I2147483647. In other words, every new person gets this GEDCOM ID. Familys are also stuck at F2147483647 Any help appreciated, George -- View this message in context: http://www.nabble.com/Can%27t-add-new-people-tf4931613.html#a14115371 Sent from the phpgedview-talk mailing list archive at Nabble.com. |
From: Nathan Watson-H. <na...@wa...> - 2007-12-02 16:22:12
|
ggpauly wrote: > I get stuck at I2147483647. > > In other words, every new person gets this GEDCOM ID. > > Familys are also stuck at F2147483647 > > Any help appreciated, > > George > Hi George, Could you let us know what version of PGV you are running, what database backend you are using and what version e.g. MySQL v4.1 Is this a real problem or something you have been testing? The reason I ask, it that I don't find it likely that you have 2147483647 individuals or families in your tree - correct me if i'm wrong! For the convenience of other people/developers reading this thread, this sounds like the limit of the "int" numeric datatype in MySQL has been reached. The "int" datatype has a limit of integers from -2147483647 to 2147483647. If this is indeed the case, the database should use an unsigned int which will allow integers from 0 t|o 294967295 (a doubling of possible positive integers) unless there is likely to be some use for negative integers? Or use an unsigned bigint (0 to ||18446744073709551615 possible positive integers) | | I'm not familiar enough with the database setup to comment on exact reasons or even possible solutions - hopefully someone else can also chip in. Nath MySQL datatype storage limits and ranges: http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html | |
From: ggpauly <ge...@ri...> - 2007-12-02 18:58:24
|
Nathan Watson-Haigh wrote: > > Hi George, > > Could you let us know what version of PGV you are running, what database > backend you are using and what version e.g. MySQL v4.1 > > Is this a real problem or something you have been testing? > > The reason I ask, it that I don't find it likely that you have > 2147483647 individuals or families in your tree - correct me if i'm > wrong! For the convenience of other people/developers reading this > thread, this sounds like the limit of the "int" numeric datatype in > MySQL has been reached. The "int" datatype has a limit of integers from > -2147483647 to 2147483647. If this is indeed the case, the database > should use an unsigned int which will allow integers from 0 t|o 294967295 > (a doubling of possible positive integers) unless there is likely to be > some use for negative integers? Or use an unsigned bigint (0 to > ||18446744073709551615 possible positive integers) | > | > I'm not familiar enough with the database setup to comment on exact > reasons or even possible solutions - hopefully someone else can also > chip in. > > Nath > > MySQL datatype storage limits and ranges: > http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html > > Thanks Nath! I changed the type of field ni_id, table pgv_nextid from int to bigint and the problem was solved. (MySQL 5.0.16, PGV 4.0.2) I got myself into this fine mess on account of problems I've had tacking GEDCOMs together. Inevitably there are IDs that clash, causing PGV to see double and hallucinate. I thought I'd solve this by editing the GEDCOMs and pre-pending numeric strings to the ids. This evidently persuaded PGV to exceed the int datatype limit on the table mentioned above as you described. And now I can go beyond that silly 2.15 billion people limit. What's the best way to stitch GEDCOMS together? I've been using a text editor to do search-and-replace to bulk edit IDs, then using GRAMPS to combine the GEDCOMs. Thanks a >2.15 billion, George -- View this message in context: http://www.nabble.com/Can%27t-add-new-people-tf4931613.html#a14118674 Sent from the phpgedview-talk mailing list archive at Nabble.com. |
From: Nathan Watson-H. <na...@wa...> - 2007-12-03 07:26:16
|
ggpauly wrote: > > Nathan Watson-Haigh wrote: > >> Hi George, >> >> Could you let us know what version of PGV you are running, what database >> backend you are using and what version e.g. MySQL v4.1 >> >> Is this a real problem or something you have been testing? >> >> The reason I ask, it that I don't find it likely that you have >> 2147483647 individuals or families in your tree - correct me if i'm >> wrong! For the convenience of other people/developers reading this >> thread, this sounds like the limit of the "int" numeric datatype in >> MySQL has been reached. The "int" datatype has a limit of integers from >> -2147483647 to 2147483647. If this is indeed the case, the database >> should use an unsigned int which will allow integers from 0 t|o 294967295 >> (a doubling of possible positive integers) unless there is likely to be >> some use for negative integers? Or use an unsigned bigint (0 to >> ||18446744073709551615 possible positive integers) | >> | >> I'm not familiar enough with the database setup to comment on exact >> reasons or even possible solutions - hopefully someone else can also >> chip in. >> >> Nath >> >> MySQL datatype storage limits and ranges: >> http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html >> >> >> > > Thanks Nath! > > I changed the type of field ni_id, table pgv_nextid from int to bigint and > the problem was solved. > (MySQL 5.0.16, PGV 4.0.2) > > I got myself into this fine mess on account of problems I've had tacking > GEDCOMs together. Inevitably there are IDs that clash, causing PGV to see > double and hallucinate. I thought I'd solve this by editing the GEDCOMs and > pre-pending numeric strings to the ids. This evidently persuaded PGV to > exceed the int datatype limit on the table mentioned above as you described. > And now I can go beyond that silly 2.15 billion people limit. > > What's the best way to stitch GEDCOMS together? I've been using a text > editor to do search-and-replace to bulk edit IDs, then using GRAMPS to > combine the GEDCOMs. > > Thanks a >2.15 billion, > > George > > You're welcome. May I ask why you haven't updated to PGV 4.1.* yet? Before answering, could you let me know why you are tacking GEDCOMS together and what you are trying to achieve. There may be alternatives, or possibly a way to do it in newer versions of PGV. Nath |
From: ggpauly <ge...@ri...> - 2007-12-03 16:42:57
|
Nathan Watson-Haigh wrote: > > > > You're welcome. > > May I ask why you haven't updated to PGV 4.1.* yet? > > Before answering, could you let me know why you are tacking GEDCOMS > together and what you are trying to achieve. There may be alternatives, > or possibly a way to do it in newer versions of PGV. > > Nath > Nath, If there's an extensive tree related to mine & there's a GEDCOM available it saves data entry to merge the GEDCOMs. I looked at the PGV 4.1 changes & see that there's a merge utility there. Next time I have a GEDCOM to merge I'll try that. Exporting & importing my 5 MB GEDCOM is a bit of a pain. Thanks, George -- View this message in context: http://www.nabble.com/Can%27t-add-new-people-tf4931613.html#a14133293 Sent from the phpgedview-talk mailing list archive at Nabble.com. |
From: Nathan Watson-H. <na...@wa...> - 2007-12-03 16:48:07
|
ggpauly wrote: > > Nathan Watson-Haigh wrote: > >> >> You're welcome. >> >> May I ask why you haven't updated to PGV 4.1.* yet? >> >> Before answering, could you let me know why you are tacking GEDCOMS >> together and what you are trying to achieve. There may be alternatives, >> or possibly a way to do it in newer versions of PGV. >> >> Nath >> >> > Nath, > > If there's an extensive tree related to mine & there's a GEDCOM available it > saves data entry to merge the GEDCOMs. I looked at the PGV 4.1 changes & > see that there's a merge utility there. Next time I have a GEDCOM to merge > I'll try that. Exporting & importing my 5 MB GEDCOM is a bit of a pain. > > Thanks, > > George > Ah yes, I understand. I haven't really had chance to try anything like this yet - still very new to PGV and genealogy! I hope to be able to make some improvements in the PGV code - who knows the efficiency of GEDCOM imports/exports might get some attention - don't hold your breath :) Nath |