Maybe I'm missing something here, but is there any way to update the primary key of an entity?

I know that PKs should be immutable, but I'm working with an existing database where some of the tables are set up with PKs that routinely change. If EF doesn't support this, then EF is pretty much a non-starter.

Here's my test code. The database table is a made up one for testing EF.

@JohnAskew: Like I said, it's an existing database with other applications reading it, so updating the key structure isn't a real option.

I was just surprised at this limitation of EF, since every database I've ever used lets you update the PK column. I wonder what the reasoning is behind this decision. Does EF not track original values like ADO.NET DataColumns do?

@JohnAskew: Like I said, it's an existing database with other applications reading it, so updating the key structure isn't a real option.

I was just surprised at this limitation of EF, since every database I've ever used lets you update the PK column. I wonder what the reasoning is behind this decision. Does EF not track original values like ADO.NET DataColumns do?

I would imagine PK values are immutable for EF tracking and navigation (as FK relations).

I'd not want to deal with concurrency issues, meddling with PK values... perhaps that's one reason...

The analysis numbers are just generated IDs, but the effective date is chosen by the user setting up the analysis. Let's say they enter a date of November 15th, but it was supposed to be October 15th. With EF, they would have to remove the analysis and re-add it with the correct date.

Concurrency is not an issue because the row is locked in the database (another questionable choice, but it works for the limited cases where concurrency is an issue).

Could we have designed the table with an "id" column as the primary key and the set the three columns as a unique key? Sure, but most times the effective date is not changing.

The analysis numbers are just generated IDs, but the effective date is chosen by the user setting up the analysis. Let's say they enter a date of November 15th, but it was supposed to be October 15th. With EF, they would have to remove the analysis and re-add it with the correct date.

Concurrency is not an issue because the row is locked in the database (another questionable choice, but it works for the limited cases where concurrency is an issue).

Could we have designed the table with an "id" column as the primary key and the set the three columns as a unique key? Sure, but most times the effective date is not changing.

while it may be a PIA to fix it I would think really hard about doing so....

seems like it should not really be that hard to fix and might allow you to make the whole system better.

changing a date should not make the whole thing break.... and a PK should just be an internal pointer not a data value the users ever need to alter.

while it may be a PIA to fix it I would think really hard about doing so....

seems like it should not really be that hard to fix and might allow you to make the whole system better.

changing a date should not make the whole thing break.... and a PK should just be an internal pointer not a data value the users ever need to alter.

I agree that a PK should never be changed as a best practice.

I will also suggest making the change for an "id" column as PK, and those three columns as an unique index. Those other apps that read from these three columns wouldn't have to change at all, correct? If true, then the change is not so hard.

Thread Closed

This thread is kinda stale and has been closed but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.