Introduction

If an ORM or application says multiple added entities may have the same primary key, the issue is usually not that the database suddenly forgot what a primary key means. The real problem is that the application is creating or tracking multiple objects with the same key value before persistence, or it is misconfigured so the ORM does not know the database should generate unique keys for new rows.

Separate database rules from ORM tracking rules

At the database level, a primary key must be unique. The database will reject duplicates when the constraint is enforced. But many errors appear earlier, inside the ORM's change tracker, because it does not allow two tracked instances that claim to be the same row.

That means the bug may happen before INSERT even reaches the database.

A common example in Entity Framework-style code is creating several new entities that all have Id = 0 or manually assigning the same key to different objects.

Let the database generate keys when appropriate

If the primary key is supposed to be identity-generated, do not assign the final value in application code.

1public class Order
2{
3    public int Id { get; set; }
4    public string Number { get; set; } = "";
5}

With database-generated keys, new entities should usually be created without forcing a real primary-key value.

1using var db = new AppDbContext();
2
3db.Orders.Add(new Order { Number = "A-100" });
4db.Orders.Add(new Order { Number = "A-101" });
5
6await db.SaveChangesAsync();

If the model is configured correctly, the database generates unique IDs and the conflict disappears.

Problems happen when key generation is misconfigured

If the ORM thinks the application must supply the key, then several new objects with the same default key become ambiguous.

For example, if IDs are not configured as generated-on-add, every new entity with Id = 0 may be treated as having the same key identity in tracking logic.

That is why model configuration matters just as much as table constraints.

Do not track two objects for the same row in one context

Another common cause is loading or attaching one entity and later creating a second object with the same primary key in the same unit of work.

1var existing = await db.Orders.FindAsync(5);
2var duplicate = new Order { Id = 5, Number = "Changed" };
3
4db.Update(duplicate); // tracking conflict likely

The context already has an entity with key 5. Attaching another object with the same key confuses the identity map.

The usual fix is to update the tracked entity instead of attaching a second instance, or to clear or isolate tracking boundaries intentionally.

Bulk inserts need unique client-side keys when the DB is not generating them

Sometimes the database is not responsible for key generation. In that case, the application must ensure uniqueness before adding entities.

Examples include:

• GUID keys generated in application code
• composite keys derived from business data
• imported legacy identifiers

If the app owns key generation, duplicate prevention is part of application logic, not something to defer blindly to the database.

Watch detached graphs and DTO mapping

Duplicate-key tracking errors often come from mapping DTOs into fresh entities without respecting what is already tracked. This happens a lot in web APIs where a request body becomes a new entity instance even though the context already loaded the same row earlier in the request.

A safer pattern is:

1. load the tracked entity by key
2. copy changed fields onto that entity
3. save changes

That keeps one in-memory object per database identity.

Common Pitfalls

• Manually assigning primary keys when the database should generate them.
• Misconfiguring ORM metadata so generated keys are treated as application-supplied keys.
• Attaching a second entity instance with the same key into a context that already tracks the first one.
• Assuming duplicate-key problems are always database problems rather than change-tracker problems.
• Mapping request DTOs into brand-new entities when an existing tracked entity should be updated instead.

Summary

• A real primary key must be unique in the database, but many errors appear earlier in the ORM tracker.
• If the database should generate keys, do not manually assign final primary-key values.
• If the application owns key generation, ensure uniqueness before adding entities.
• Keep only one tracked object per database row inside a unit of work.
• Many duplicate-key issues are configuration and tracking problems, not mysterious database behavior.