From: Peter L. <pl...@ti...> - 2007-03-05 21:30:01
|
I am a newbie to GRAMPS 2.2.6, having migrated a couple of weeks ago from 'another OS' based genealogy programme to Linux under Ubuntu 6.10., although I have been using Linux for all my other tasks for about 2 years. I would be grateful for clarification of data entry for the following elements of Gramps. 1. Date formats How do I change a date entry from YYYY/MM/DD to DD/MM/YYYY? The first is probably a US default setting, but how do I change to the UK style? Although the manual V2.9 mentions the alternative UK format, I cannot find the format change window. 2. Backup identification Is there a shorter alternative to the present cumbersome format of '<file name>.backup.backup.backup.[+ a lot more].gramps. How about a date such as '<file name>.05.03.07.gramps' ident? 3. Source entries Is the Source ID entry automatic?. My first entries went from S0000 onwards but when I next opened the database it had changed to start at S0017. Then next time to S0029 etc, where it seems to have stabilised; No Source entry references from S0000 to S0028 remained, although the people files remained under a new source reference. I have made all my Source entries via the 'Person' window and selecting 'Source' in the tab list on that window. To me, Gramps V2.9 manual seems to indicate that data can be entered via several routes, or am I missing something. It works ok for 'Events' entries which start, and have remained at, E0000 [to E0050]. I hope that somebody can suggest what I need to do to resolve these questions. With thanks, Peter |
From: Brad R. <br...@fi...> - 2007-03-05 22:26:31
Attachments:
signature.asc
|
On Mon, 05 Mar 2007 21:18:36 +0000 Peter Lennard <pl...@ti...> wrote: Hello Peter, > 1. Date formats > How do I change a date entry from YYYY/MM/DD to DD/MM/YYYY? "Edit Menu/Preferences" and then "Display" tab. First item is "Date Format". As for the rest of your problems, I'm afraid I can't help. I'm not expert enough yet. Sorry. --=20 Regards _ / ) "The blindingly obvious is / _)rad never immediately apparent" The public wants what the public gets Going Underground - The Jam |
From: Don A. <don...@co...> - 2007-03-05 22:44:25
|
On Mon, 2007-03-05 at 21:18 +0000, Peter Lennard wrote: >=20 > 1. Date formats > How do I change a date entry from YYYY/MM/DD to DD/MM/YYYY? >=20 > The first is probably a US default setting, but how do I change to the > UK style? You date entry format is determined by your locale. If your locale is en_US, your system tells us the date format is MM/DD/YYYY. If it is en_UK, then the system tells us that it is DD/MM/YYYY.=20 > 2. Backup identification >=20 > Is there a shorter alternative to the present cumbersome format of > '<file name>.backup.backup.backup.[+ a lot more].gramps. How about a > date such as '<file name>.05.03.07.gramps' ident? Right now, only two levels of backup are maintained. .backup.gramps, and .backup.gramps.old. If you want finer grain control, then you should install the RCS package, and use the CheckPoint tool. This will give you full revision control over your database, allowing you to rollback to previous checkpoints using a graphical interface. >=20 > 3. Source entries >=20 > Is the Source ID entry automatic?. My first entries went from S0000 > onwards but when I next opened the database it had changed to start at > S0017. Then next time to S0029 etc, where it seems to have stabilised; > No Source entry references from S0000 to S0028 remained, although the > people files remained under a new source reference. >=20 > I have made all my Source entries via the 'Person' window and selecting > 'Source' in the tab list on that window. To me, Gramps V2.9 manual seems > to indicate that data can be entered via several routes, or am I missing > something. It should be using the ID after the next highest available. It does not try to fill in missing holes, but goes to the end and adds the next. If this is not the case, file a bug report. However, as long as it is doing something reasonable, I'm not sure this is a big deal. What it typically does is takes the length of the source list, (if it was 20, then it starts with S0020) and looks for the next unused ID starting at this point. >=20 > It works ok for 'Events' entries which start, and have remained at, > E0000 [to E0050]. >=20 > I hope that somebody can suggest what I need to do to resolve these > questions. >=20 > With thanks, Peter >=20 >=20 > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users |
From: Joachim B. <ma...@jo...> - 2007-03-05 22:55:43
|
Hi, Am Montag, den 05.03.2007, 15:40 -0700 schrieb Don Allingham: > If you want finer grain control, then you should install the RCS > package, and use the CheckPoint tool. This will give you full revision > control over your database, allowing you to rollback to previous > checkpoints using a graphical interface. Reminds me of a question I wanted to ask since a while: Is there a way to make gramps run the CheckPoint tool instead of creating a simple backup when quitting? I=E2=80=99d very much like that! Greetings and Thanks, Joachim PS: I hope I=E2=80=99ll remember to look for an answer when I=E2=80=99m bac= k online in one week :-) --=20 Joachim Breitner e-Mail: ma...@jo... Homepage: http://www.joachim-breitner.de ICQ#: 74513189 |
From: Alex R. <sh...@gr...> - 2007-03-05 22:44:42
|
Peter, On Mon, 2007-03-05 at 21:18 +0000, Peter Lennard wrote: > 1. Date formats > How do I change a date entry from YYYY/MM/DD to DD/MM/YYYY? Brad already answered that. > 2. Backup identification >=20 > Is there a shorter alternative to the present cumbersome format of > '<file name>.backup.backup.backup.[+ a lot more].gramps. How about a > date such as '<file name>.05.03.07.gramps' ident? You should use grdb format: start a new grdb database and import your *.gramps data into it. The backup will then be called filename.grdb.backup.gramps If you are using .gramps format directly (I recommend that you don't) then you should not need the XML backup as your original data is already in XML. > 3. Source entries >=20 > Is the Source ID entry automatic?. Yes. > My first entries went from S0000 > onwards but when I next opened the database it had changed to start at > S0017. Then next time to S0029 etc, where it seems to have stabilised; > No Source entry references from S0000 to S0028 remained, although the > people files remained under a new source reference. How did that happen? Gramps should not delete any sources on its own. If it did, this is the bug. How do you know that there were entries from S0000 through S0017? Were they in Gedcom file? > I have made all my Source entries via the 'Person' window and selecting > 'Source' in the tab list on that window. To me, Gramps V2.9 manual seems > to indicate that data can be entered via several routes, or am I missing > something. Yes, data can be entered via several routes. Please describe the way to reproduce the problem, if possible, starting with the empty database. Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Alex R. <sh...@gr...> - 2007-03-06 23:03:43
|
Peter, I am replying to the list as well. Please also send replies to the list. On Tue, 2007-03-06 at 21:31 +0000, Peter Lennard wrote: > On Mon, 2007-03-05 at 14:44 -0800, Alex Roitman wrote: > > You should use grdb format: start a new grdb database and import your > > *.gramps data into it. The backup will then be called > > filename.grdb.backup.gramps > >=20 > > If you are using .gramps format directly (I recommend that you don't) > > then you should not need the XML backup as your original data is alread= y > > in XML. >=20 > Please expand on XML - I am using Gramps format, do I have a choice?; Yes. The default format, when you create a new database, is grdb. The very old gramps version (prior to 2.0.0) used .gramps (which is GRAMPS XML format) as a primary format. Nowadays this format can and should be used for backups and for transferring data to another machines. > when I close down it saves in Gramps format by default doesn't it. Yes, this is because you opened your .gramps file directly. Instead, create a new database in grdb format and then import your .gramps file. I do not know how large your database is. For large databases, the opening and closing are remarkably faster for grdb format than for .gramps format. The .gramps format should be used for archiving/backup/portability, not for routine use. Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Peter L. <pl...@ti...> - 2007-03-07 22:37:39
|
On Tue, 2007-03-06 at 15:03 -0800, Alex Roitman wrote: > Peter, > > I am replying to the list as well. Please also send replies > to the list. Sorry for that - I'll get the etiquette correct with practice; first time with this sort of list interchange! > > On Tue, 2007-03-06 at 21:31 +0000, Peter Lennard wrote: > > On Mon, 2007-03-05 at 14:44 -0800, Alex Roitman wrote: > > > You should use grdb format: start a new grdb database and import your > > > *.gramps data into it. The backup will then be called > > > filename.grdb.backup.gramps > > > > > > If you are using .gramps format directly (I recommend that you don't) > > > then you should not need the XML backup as your original data is already > > > in XML. > > > > Please expand on XML - I am using Gramps format, do I have a choice?; > > Yes. The default format, when you create a new database, is grdb. > The very old gramps version (prior to 2.0.0) used .gramps (which > is GRAMPS XML format) as a primary format. Nowadays this format > can and should be used for backups and for transferring data > to another machines. > > > when I close down it saves in Gramps format by default doesn't it. > > Yes, this is because you opened your .gramps file directly. > Instead, create a new database in grdb format and then > import your .gramps file. I will try this; thanks. > > I do not know how large your database is. For large databases, > the opening and closing are remarkably faster for grdb > format than for .gramps format. The .gramps format should > be used for archiving/backup/portability, not for routine use. At this moment my data base is only 20 persons [many more to add yet], but don't want to go further until these teething problems are sorted. May be connected to your comments above - will see what happens with a restart in grdb format. Peter > > Alex > |
From: Eero T. <ee...@us...> - 2007-03-07 18:13:45
|
Hi, On Wednesday 07 March 2007 01:03, Alex Roitman wrote: > I do not know how large your database is. For large databases, > the opening and closing are remarkably faster for grdb > format than for .gramps format. The .gramps format should > be used for archiving/backup/portability, not for routine use. Shouldn't the .gramps format be actually better for a database of only a few hundred persons? I mean: - it's portable - it doesn't otherwise break as easily BSDDB (I think subversion people actually switched from that back to file system backup because of problems). I mean, if I need to select between having database consistent (like the bsddb transactions are supposed to guarantee) or working, I'd rather choose working :-) - it takes less space, if that still matters nowadays And if this is really the case, where goes the limit where the performance difference really starts to show (I guess it depends also a bit on how much memory one has)? - Eero |
From: <ben...@ug...> - 2007-03-07 18:44:32
|
Even with 100 person's having a system crash (and face it, people are running beryl and all sorts of stuff that crashes X server), and not having corrupt data, and moreover only having lost the data you are entering, is a bonus I think. Benny Quoting Eero Tamminen <ee...@us...>: > Hi, > > On Wednesday 07 March 2007 01:03, Alex Roitman wrote: >> I do not know how large your database is. For large databases, >> the opening and closing are remarkably faster for grdb >> format than for .gramps format. The .gramps format should >> be used for archiving/backup/portability, not for routine use. > > Shouldn't the .gramps format be actually better for a database > of only a few hundred persons? I mean: > - it's portable > - it doesn't otherwise break as easily BSDDB (I think subversion people > actually switched from that back to file system backup because of > problems). I mean, if I need to select between having database consistent > (like the bsddb transactions are supposed to guarantee) or working, I'd > rather choose working :-) > - it takes less space, if that still matters nowadays > > And if this is really the case, where goes the limit where the performance > difference really starts to show (I guess it depends also a bit on how much > memory one has)? > > > - Eero > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Alex R. <sh...@gr...> - 2007-03-07 18:31:23
|
On Wed, 2007-03-07 at 20:25 +0200, Eero Tamminen wrote: > Shouldn't the .gramps format be actually better for a database > of only a few hundred persons? I mean: > - it's portable > - it doesn't otherwise break as easily BSDDB (I think subversion people > actually switched from that back to file system backup because of > problems). I mean, if I need to select between having database consist= ent > (like the bsddb transactions are supposed to guarantee) or working, I'd > rather choose working :-) > - it takes less space, if that still matters nowadays For what it's worth, and this is my personal opinion, I don't think .gramps is a conceptually correct working scheme. Everything is first read into memory, then held in memory, then saved on exit. In contrast, bsddb stores changes as they are made. So, to see a middle name of a default person you would have to read in the whole database if you are using .gramps format. To change it, you will have to write the whole file again. > And if this is really the case, where goes the limit where the performanc= e > difference really starts to show (I guess it depends also a bit on how mu= ch > memory one has)? Yes, this depends on memory. As soon as the data does not fit into memory, performance difference really starts to show. Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Eero T. <ee...@us...> - 2007-03-07 20:31:36
|
Hi, On Wednesday 07 March 2007 20:31, Alex Roitman wrote: > For what it's worth, and this is my personal opinion, I don't > think .gramps is a conceptually correct working scheme. Everything > is first read into memory, then held in memory, then saved on exit. > In contrast, bsddb stores changes as they are made. Ok, I hadn't understood that with the XML format the changes are only saved at the exit, this really makes the difference (in case e.g. Desktop crashes like Benny mentioned). > So, to see a middle name of a default person you would have to > read in the whole database if you are using .gramps format. > To change it, you will have to write the whole file again. Ack. > > And if this is really the case, where goes the limit where the > > performance difference really starts to show (I guess it depends also a > > bit on how much memory one has)? > > Yes, this depends on memory. As soon as the data does not fit > into memory, performance difference really starts to show. (For a few hundred persons this shouldn't be a problem on today's machines with at least 1/2 GB of RAM...) - Eero |
From: Don A. <don...@co...> - 2007-03-07 20:38:36
|
On Wed, 2007-03-07 at 22:42 +0200, Eero Tamminen wrote: > > Yes, this depends on memory. As soon as the data does not fit > > into memory, performance difference really starts to show. >=20 > (For a few hundred persons this shouldn't be a problem on today's > machines with at least 1/2 GB of RAM...) >=20 >=20 > - Eero >=20 Actually, it works quite well for under about 5K people. You just don't have the data protection that the db should give you. Don |