Yes indeed, after I did my post yesterday I was thinking that this is purely an EF Code First problem since it occurs with EF configuration only.

Sorry for the noise and thanks for the tip.

Patrick

It seems that you have multiple questions here so I'm going to try and address them one by one.

This sounds like a pure EF Code First question. Have you tried this scenario without DevForce involved? 

I googled the error and found 2 good links that might help you.

- http://social.msdn.microsoft.com/Forums/is/adodotnetentityframework/thread/1d7dd6ac-5485-4b52-b391-0575b31d72f5

- http://stackoverflow.com/questions/5593426/how-to-implement-concurrency-in-ef-code-first-while-using-a-tpt-hierarchy

Hmm, I don't quite follow this. If your EntityBase.Id column is set to Identity, how are you setting your DerivedEntity.Id to anything other than Identity? Furthermore, what are you setting it to?

I am currently evaluating DevForce and I seem to have reached a dead end trying to put a RowVersion attribute in a base entity using Code First. Here is my setup:

If I put the RowVersion property in the EntityBase class, I get the following error at run-time:

"The store generated pattern 'Computed' is not supported for properties that are not of type 'timestamp'  or 'rowversion'."

It makes no difference whether I tag the property as a RowVersion either using the [Timestamp] data annotation or using the EF fluent interface.

If I put the RowVersion in the derived entities, I get a compile time error stating that I cannot add concurrency checks in derived classes.

Also, the Id column is only set as Identity for the EntityBase table. The Id column in the tables for the derived classes is NOT set as Identity. As a result, the temporary negative Id assigned by the client (e.g. -100) gets stored in the database such that on the second insert I get a key violation exception.

So I am at a loss here...it seems to me that using a base entity is not that useful unless I am missing a key ingredient...