Events without first or last name

(GrampsAIO64-5.1.3-2 and Windows 10)

When I list the events I see that there are a number of them that have no first or last name (see picture).
These events are already referenced in the database and assigned to individuals (with another event identifier number).

I guess I have to do some wrong manipulation sometimes to get these events with no first or last name created.

Does anyone have any idea where these entries come from in the database?

Best regards.

I think you have incorrect roles for these events:
For a marriage, you must have a family role.
For a birth or death event, the role must be primary.

Thank you for your reply.

I don’t think it’s that because I don’t use roles (yet) so they’re all primary for births and deaths.

I realized that contrary to what I was saying some of these events are not listed elsewhere in the database.
I will therefore come back here after having analyzed these “ghost” entries in detail.

Best regards.

Please double check these events in the Person’s or Family’s edit windows. The only way the Main Participants would be empty in the Event list is if the person’s Event Role was NOT Primary or a Family event was NOT Family. Any other Role setting will cause what we are seeing in the event list.

If you can tell us that the Role for these events do have the Primary roles, then we will know that something else is at play.

Note: Editing an event from within the Event view will NOT display a person’s (or family’s) role. Roles can only be seen from within the person’s or family’s edits and views.

The roles are set at event creation but in editing an event by copying and editing, it is not uncommon for the role to be set to “Unknown”.

I don’t think Roles are the are the cause of this problem. But you are under a misimpression that needs to be corrected. Correcting it later may let the problem grow too imposing.

Roles often surprise starting users… but only when they start causing problems. They aren’t even aware of Roles before that.


  1. they don’t realize Roles are required , &
  2. Gramps is so automated in creating Roles (based on context) in the normal sequences of adding records, that the Role feature goes unnoticed… until there is a Role that is wrong.

To clarify, if a default Role type can be determined when created by context, then it will be.

As examples: adding a NEW Event (with the '+’ icon) uses the Context of the Editor. Within the context of the Family Editor, defaults the Role to Family (with implied Roles of Bride & Groom). Within the Person Editor, defaults the Role to Primary.

However, without that context (as when in the Event view) adding a NEW Event has an UNKNOWN role.

And sharing an Event (whether by drag’n’drop, the Share button/menu item, or clipboard) does not provide any context or the context is ambiguous. So the Role would be set to UNKNOWN there too.

I got bitten by this in 2 spots before learning about roles:

  1. sharing Birth Events for twins & triplets.
  2. re-cycling Events that were made redundant by a Person Merge

The most blatant Role problem is when no Birth (and/or Death) appears in the on-screen summaries for a person even though there is a corresponding Event in the Person Editor. (Such summaries might be for the age at Event or indicating the lifespan in the Relationship or Chart views.)

I’ve had a similar problem that I need to finish isolating for a bug report. [report has been filed]

It had to do with the stack of parent/child window spawned by Gramps and dismissing them out-of-sequence.

You can get buried under a slew of windows. (In Relationship view, add parents, add mother, add birth Event, add unknown Place, add encoding Places. You may have at least 6 spawned windows on-screen now.

Say that you ‘OK’ the spawned windows, in the correct Inverse sequence, back to & including the Birth Event. This leaves the mother Person Editor & Family Editor window on top of the Main Gramps window. (Plus any detached Gramplet & possibly the Clipboard.) If you accidentally click the Family ‘OK’ first, it pops a warning about unsaved (the mother, although that isn’t identified) and asks if you want to Save. You breathe a sigh of relief and click OK.

Something weird happens. Those New Events might have been created with the previous OK click but they weren’t attached to the new mom yet. Or the Mom get created but wasn’t attached to the Family. Or both. You expected Gramps to layer the Saves from the mostly deeply spawned window… but it loses is place too and just kills the sub-spawned windows.

Since the spawned Family window disappears, you don’t even notice the missing bits.

Or you DO notice and say to yourself: “I could’ve sworn I created that!” Then figure you had just lost your place (because you’ve got Gramps, Ancestry, FamilySearch & WikiTree up along with the scanned Reference book and you’re trying to manually harmonize them all simultaneously) and re-create the missing record. But if you had switched over to the View for that type of record & sorted by ‘last modified’, you would found the orphaned record.

Curious to see the rest of your investigations.

I have never used creating events in Event view or sharing events.
I didn’t even realize that you could create events in Event view.
Thank you for the clarifications you provide on the subject of the roles.

For my part, unfortunately I could not (try) to analyze the anomalies of my database and do tests until this weekend.

I just had time to remove the “ghost events” which I could definitely call “duplicate”.
Maybe a lead (but maybe it’s a coincidence), for these I shared a medium between the birth and death event (for the majority of stillbirths where the death certificate also serves as a birth certificate).

I will therefore come back this weekend with, I hope, more details on the cases that I encounter.

Best regards.

Another thread you may be interested in.

I come back a little early.
What you describe with the multiple open windows speaks to me.
Often in simple consultation but it happens to me sometimes to make modifications in this situation.

I have looked at my “ghost” events and almost all of them are events that I (for one reason or another) deleted.

So if I put one with the other I have the impression that in order to try to reproduce the supposed bug we would have to put ourselves in a situation with several open windows and delete one or more events.

On the other hand we can see on the image that I had posted previously that I had 16 “ghost” events which represents a very low percentage compared to those I have in the database and when I look the modified years are distributed between 2018 and 2020: it is therefore very sporadic.

I still have two, related to the same individual, where I’m not sure I can conclude a deletion if you look at the modified time:

Best regards.

Interesting discussion.
This will be included in the next version of Gramps if I understand correctly (like on Mantis you’re talking about changes you made in 5.1.2 and I didn’t find it on 5.1.3)?

Best regards.

To be clear, when you delete an event from a person or family does NOT delete the event from the database. An event not attached to a person or family will obviously not display a main participant in an event list.

There is a Remove Unused Objects tool to delete these no longer needed events (or anything else, so be careful).

The feature request still needs one of the programmers to take up the issue. I have offered up the basic code that would need changing but there are other areas that may need to be changed to fully implement the request.

You can take my changes and modify your own code as I have done. But until it is set in the code, you would need to modify each new version of Gramps as they become available.

Thank you very much, you light up my lantern.

So we can detach events but not delete events.
The french translation is ambigous : “Enlever l’événement individuel sélectionné”, “Enlever” is nearest “Delete” than “Detach” for me … “Détacher” in French should perhaps be better .

And to resume, there are so two cases to get an event without main participant :

  • role not primary or family
  • event deletion (detaching)

A subsidiary question should be here : how to distinguish those two cases as we can’t view role in events view ?

I have to say that I would have preferred a true deletion but I guess the logic is almost the same than for the media management.

Best Regards.

1 Like

If you edit the event (or any other object) there will be the References tab. This is the list that shows what other object the record is linked with.

There are some oddball cases. There can be notes with the Type “To Do” that are part of the To Do Gramplet. These notes may or may not be attached to another object. The Remove Unused Object is written to ignore these notes. The same with notes with Type “Link”. Notes that are Linked internally to another note but not attached in a way to produce a Reference.

The English text says “Remove the selected personal event” in the Person editor. It does not delete the event. After all, you may want to add that event to another person.

At least once a week I Remove the Unused Objects concentrating on Events, Citations and Notes. I know I have objects in the other areas (mostly Places and Sources) that I have added but not yet attached to other records. I do the remove weekly so that I have a chance to remember why these records are ready for deletion.

And you may need to run the tool three times because there may be a citation attached to the event you are deleting. Or a note attached to either the event or citation. These will not show up for possible deletion until the other objects are deleted first.

You CAN delete an Event from within the Event list View. There, the minus sign [ - ] does say delete and not remove. The same is true for all list Views.

This is what I wanted to say but I was not comprehensive enough.
You are right to say so.

I take this opportunity to say that I find that the icon with the ‘-’ sign is also ambiguous outside the Event view.
I imagine for example, but there are surely better, two pieces of puzzle assembled or separated to represent the current ‘+’ and ‘-’ in this case (and to keep + and - in the event view).

Thank to you, as well as @SNoiraud and @émyoulation, for the help provided and the information shared.

Best regards.

1 Like

This definition of “remove” is not consistently observed. In fact I filed a bug report last week on one example. It’s in the Graph View where there’s a contextual menu option to “Remove” a person. Upon selecting it, you are warned about deleting the person. (I realize this doesn’t contradict what @DaveSch is saying about list views.)

This is not good.™

I like the use of “detach” that’s being implemented in this thread vs “remove”. The former is pretty clear that the Event (or whatever) isn’t going away, whereas “remove” sounds like it might (and in fact at least in the case I mentioned, it does). (I can’t comment on the French. :slight_smile: )

It’s also bad UI to have the same icon mean more than one thing, which is what I take @zebulon to be saying. The minus sign should mean either detach the item or delete it, and not change depending on context. That’s confusing.

I wonder what people think then of two things:

  1. Clean up the language. Remove is ambiguous, so don’t use it. Personally I’d like something else like “detach” as @zebulon has offered. But at least never use it as a synonym for “delete”.
  2. Create a different icon for “delete”. A trash can seems the obvious choice. You can even use this in combination with detach.
  3. OK, a third thing: don’t use a minus sign as an icon at all. It’s ambiguous. In addition to the trash can maybe some kind of separation symbol, like the broken link in the editor when a URL is removed? I have the icon labels turned on, so I can see clearly that it means delete in a list view, but not everyone does.
1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.