this is indeed not a "totally unlikely scenario", only an "unlikely scenario" :-)
Could you please paste your mail with explanation in a bug report on http://bugs.gramps-project.org/ ?
It is not urgent so I will not look now to solve it, but somebody should some time in the future, so it should be reported properly which is easy as you already did all the research on how to reproduce this bug.
Thanks for the advice, it so happened that when I restarted Gramps after the crash, the person I was trying to delete, was still there, but could then be deleted without a problem and there seems to have been no damage to the database. I am sure what happened is a bug, though, at least if the aim is to make the (GUI) user interface foolproof, or at least intuitive, which is IMHO always a good design principle.
The problem which I believe in essence caused the crash, can be reproduced as follows:
1. Start a new file
2. Make a person
3. Open the "Relationships" view for that person
4. Add a new set of parents through the "Edit family" window
5. Open the "Edit family" window again and delete both parents, as well as the child, leaving (presumably by mistake) an empty family
6. When trying to save the empty family, Gramps warns it can not save an empty record, and advises to enter data or cancel the changes
7. If one then indeed cancels the changes, the focus returns to the "Edit Family" window, which now contains no data, with only the "Cancel" button enabled.
8. clicking the "Cancel" button bring up the "Save Changes" dialog again where clicking "Close without saving" brings the user back to the "Relations" view, with the parent data intact;
9. clicking on "Edit" for the parent data now causes an unhandled exception (as does deleting the child from the database, which is what I actually tried to do).
This is not a totally unlikely scenario, and there is little in the above sequence that the average user could not reasonably be expected to do under the circumstances. How to avoid it is another matter. Perhaps a family record should be automatically deleted if the user insists on deleting both the parents and the children (in which case one might consider to warn the user before the deletion), whereas canceling the changes should restore the record to its initial state. Unfortunately, I have no time at present to look into the source code to propose a patch, although I would love to help.
Hope, though, that the above is useful for you guys to make Gramps even better that it already is.
New Delhi, India
Benny Malengier wrote:You delete a person, so the person is deleted as child in the family he is child in, but apparently that family did not exist.
It is best to:
1/take a backup as .gramps file and keep it save
2/in the tools menu, run the rebuild reference table tool, rebuild sec index tool and the check and repair tool. In consistencies like people who refer to unexisting families are resolved like that. They can be due to a bug, or due to bugs in older versions that caused this and now are resolved already. Should you think the incorrect person/family link was created in 2.2.10 and you thinkg to know how to reproduce it, let us know.
2008/2/16, Robert V. Schipper <email@example.com>:User Information:
I was removing a person after I had removed the family of which the
father was the only parent as well as the father.
242148073: ERROR: gramps.py: line 148: Unhandled exception
Traceback (most recent call last):
File "C:\Program Files\gramps\DataViews\_PersonView.py", line 597, in
File "C:\Program Files\gramps\QuestionDialog.py", line 104, in __init__
File "C:\Program Files\gramps\DataViews\_PersonView.py", line 614, in
GrampsDb.delete_person_from_database(self.dbstate.db, person, trans)
File "C:\Program Files\gramps\GrampsDb\_DbUtils.py", line 57, in
AttributeError: 'NoneType' object has no attribute 'remove_child_handle'
Python version: 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32
BSDDB version: 126.96.36.199
Gramps version: 2.2.10-1
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Gramps-bugs mailing list