I have noticed today that when I select and open (census) FORMS data from the lower window, after selecting a PERSON, I sometimes get data for a different person from a different census. I don’t know when this might have happened, so restoring a backup is not an easy option. I have run the “Check and Repair Database” routine. I have deleted and recreated several wrong entries, but I keep finding new wrong entries.
When I look at the EVENT data, I see the correct Participant entries, but not when I open the census entry in the FORMS tab. I am not (yet) sure how wide this problem is.
I think the ‘links’ between Event data and People has become confused. I am an experienced GRAMPS user, but know almost nothing about database workings.
I’ve noticed a similar problem with the Combined relationship view add-on. If you use the Previous or Next buttons to change the active person, it does not trigger an update of the Forms gramplet and you get left with the wrong set of forms listed for the currently active person.
It all works correctly if you use Previous or Next with the default Relationship view or on the People view.
AFAIK, forms data is stored in citation attributes. They most probably don’t show up in reports, but you can see them in Gramps XML, so if you have some backups, you might want to unzip them with 7-Zip, which you may need to use twice to get to the actual XML. And once you have those, you may try to compare these XML files with WinMerge, or a file diff add-on running inside Notepad++.
You may also try another approach, which is to create a new empty tree, import a recent (automated) backup into that, and then run import and merge against an older backup. This may show you citation attributes in a friendlier fashion.
There is a chance that the attributes themselves didn’t change, but that a citation object, which was loaded by the open forms Gramplet, lost its connectuon to the person or event it was linked to, and got reconnected to another one. That might explain your experience (mishap) a bit better, assuming that I sort of know how the software works.
Enno, thank you for your reply. I was on the verger of asking you directly, for your help.
I will try your suggestions and report back to the list. I’m no database expert, but I think your final paragraph is correct.
I diligently take regular backups, but I’ve always realised that if a problem goes unnoticed for a long time, backups can’t always help. I’m going to spend some time trying to see how wide-spread this problem is in my tree.
OK, good. You can send two .gramps files to my email, if you want, and Gmail accepts them.
I also hopes that the import and merge feature gives you some insights, but I never tried that with changed citations, and I never really used it for merging either. It is a nice tool to see changes between different versions of the same tree though.
The corruption may be quite easy to detect, if citations were moved between persons or events, because that is a very rare case in normal life. Normally, you create a new citation, enter some data, with forms, or without, and from that moment on, the link from the person or event to the citation is stable. You may attach it to another person, but once attached, the link doesn’t change, so heuristics say that any changed link is suspicious, if you know what I mean. And those changes are easy to see at the XML level, but should also be visible during import and merge. And starting that doesn’t really mean that you need to complete that merge.
Enno, should they be two consecutive .gramps files? The most recent or
a few days back?
I am really panicking. I can’t see any logic to the way things are
corrupted. It’s all very ‘tidy’, no meaningless data, just Census
events appearing against the wrong people.
Thank you for your offer. I am carefully reading your two emails.
Have you tried Import & Merge? It should tell you about changed events, I think.
I suggest that for the oldest file, you send one that you think is OK, and I can understand that thay may be a wild guess. What I need is a pair that shows me what kind of corruption it is, knowing that events too are normally not moved to another person. And that’s something that is probably quite easy to see in the Gramps XMLs.
Absolutely, yes, and my philosophy is that in software, just like in real life, everything is possible, even if you think that it’s crazy, and even more so when I think it is.
I’ve seen many software crashes where colleagues said that they shouldn’t occur, where I saw that they did, and I know that a systematic approach always works to find them.
Thanks, Nick, this helps me find what may have happened, once I get the Gramps XML.
Am I right to understand that event reference attributes are the attributes attached to the link between person and event?
I never use forms, because we don’t have censuses here, and I’m too lazy to create generic forms for births, baptisms, marriages, etc., and store everything that I find in a source in citation notes. That’s why I expected that forms data would be stored in citations too.
Nick, I have tried deleting any wrongly-placed events. If I then try to
re-open the data attached to a person, I see another wrong set of census
data. I deleted that and got yet another wrong set. Should I stop
trying that?
I have seen an occasional double citation, and I have deleted duplicates
if I find them. I don’t know how I added them, or how they were added
if I didn’t actively do it.
I don’t understand ‘Forms data is stored in event and event reference
attributes.’ I can’t find any Events that have any attributes. Is that
odd?
When I combine your findings with Nick’s comments, my thougts are that you may have hit one of the issues that Nick mentioned. And if that is so, it will probably visible in the event references or the attributes themselves, and that’s something that I can see by comparing two Gramps XML backup files.
It also helps when you give a more detailed description of what you did, especially because I don’t use forms myself. This means that I have some sort of idea about what may have happened, but that idea is not influenced by experience, good or bad.
Enno, I have inspected all 350 Census events. I found several that had
two citations, (sometimes the same citation used twice, sometimes two
different citations). I deleted one from each duplicate, but I still
have the same problem.
As far as what I did, I’m not sure. I can’t even say when this problem
first appeared.
While going through the census events, I did see a couple of
duplicates. I tried to correct this by merging them into one, but I
noticed that that left me with a single event, with two citations,
sometimes the same, sometimes different. I then deleted one, so that I
o not have any Census Events with more than a single citation. (Would
NOT having a citation for some Census Events cause a problem? That goes
back to my very early research when I didn’t bother with citations (The
foolishness of youth, at 57 then!)
I can’t remember ever using anything but the form editor.
For a form to be recognised, the event will need a citation.
The form definitions are attached to a source. When you create a new census form a citation and an event are created for you. As you fill in the form, event attributes are created for the headings and event reference attributes (stored in people) are created for the rows. Citations are attached to the attributes created.
When you edit a form, the form editor is passed a citation. It then looks at the source to find an event type from the form definition. For a census, it will look for an event with the type “Census” and the given citation attached.
If the event has no citation then it will not be found by the form editor. If the citation is attached to two events with the type “Census” then the first one found will be edited. This may be the wrong one. Nothing has happened to your data in this case, it is just that the wrong census is being edited.
You can lose data if you do the following:
Open the standard Gramps person editor for a person in a census. This takes a copy of the person object.
Open the form editor and modify the census row for that person.
Save and exit the form editor.
Save changes in the person editor that is still open. This will write a modified copy of the person, before the census changes were made, back to the database.
Only the most recent changes to a single person will be lost.
I saw one interesting thing already, and that is that the import & merge tool claims that the files that you sent are the same, even though a diff of the XMLs shows that you corrected a birth month in one. And that difference IS visible when I compare GEDCOM files.
The new files that you sent show more differences, which are actually visible in import & merge, and some of those look quite suspicious, especially those where an event reference suddenly links to another citation. That is quite rare, IMHO, because I expect that you normally don’t move a citation, which often refers to a particular page/set of lines in a census, to another event.
The only thing is, that the changes that I saw might have been caused by you trying to correct things, so I may need one more file from before your discovery, which is far enough away to have collected some dust (corruption) but not too many deliberate changes.
I have no easy cure, at least not with my means, but the corruption is real, and I found it by comparing your files from April and October, where the 1st page of the XML showed the differences right away, in the citation references stored in a couple of events. I suggested that as a 2nd guess in my 1st reply, so one of my instincts was right.
The event attributes have not changed, so Nick is right too. The census data are all there, and consistent, but when the citation reference in the event (or person) has changed, you see another form, where in my sample, no single row points back to the subject. And that is weird, because when you create a new form, all rows will point to an existing person, or a new one. And that person or the associated event will have a citation reference that points back to the new citation. And in your current database, that circle is broken.
This description may be somewhat simplified, but it suggest that the corruption can be detected by an enhanced check & repair, because software can check for that broken circle.
I found that for your person I0000, 4 out of 5 form links point to forms that don’t list him, and the same is true for 2 out of 4 forms linked to his wife. And these were all OK in your April 13 database.
Nick, I am wondering if this problem started (for me) much longer ago
than I realised. Secondly, I wonder how many others have this problem
but haven’t yet noticed.
And I’m wondering whether it could have been caused by letting Gramps merge citations. This will merge all citations sitting under one source, which is always the case for the citations related to a particular census, unless the dates and vol/page are different.
If the whole census is taken on one day, or a few, and you don’t enter vol/page data, citations will be merged by that tool if you use it, although you can prevent that if they have notes. And since none of the forms citations have notes, that doesn’t help much here.
