In my previous post, I managed to update a simple model from an existing database. But then I started trying to do things like build my project and ran into so many problem trying to get my simple model to interact with the AdventureWorks database that I finally gave up.

I actually wrote my thoughts on this in a question on the MSDN forum for Entity Framework, with the point of the question being "is there a real example of this? Or is it just a concept that looks good on paper?"

I care a lot about this becuase I have been sharing this concept (which does make sense to me) that the EDMs loose coupling to the database means that you could map the CSDL to different databases.

But the AdventureWorks database just had too many constraints – such as non-nullable fields that I didn’t have in my model and I finally gave up because it was forcing me to modify the CSDL and I would also have to add in some business logic to deal with some of these non-nullable fields. And even if I did that, who knows what other problems would pop up?

Update after I gave myself a little time while eating lunch to think about this some more, I crossed out "finally gave up" becasue it’s basically not in my nature. I decided to go about this in a different direction with just ONE entity and succeeded by removing the unused non-nullable fields from the SSDL and mapped the entity to Insert/Update/Delete sprocs. All I have to say to myself at this point is "well, duh!" The insert stored proc provides the missing non-nullable fields and the update stored proc updates the modifieddate for me. SO problem solved in a not very realistic example, but I plan to build it up thought not today – I’ve already invested too much time. There’s a lot of flexilibity in the model, but we all still have a lot of learning to do for our various use cases.

You can read my more complete thoughts on this in the forum post and if you want to follow the conversation you can sign up to get alerts on this thread from the MSDN forums.

Oh, and if you’ve never signed up for alerts before, you might want to read this blog post I wrote last summer: A few MSDN Forums tips (which I learned the hard way – as usual).

When you use the UpdateModel feature of the Entity Framework design tools, the process relies on matching up existing entity names to table names, more specifically name of objects in the CSDL with names of objects in the database.

IF you have selected objects to add and nothing with that name already exists, it will add a new entity in the model, otherwise, it will use the existing entity.

There are changes coming to how this works detailed in this blog post by Noam Ben-Ami.

But I got bit by something that I overlooked which took hours to pinpoint the cause of the problem, so I wanted to share it.

I had created a model from scratch that was a simple, generic commerce app (see image below). I created entities for Customer, Order, LineItem, Address and Product with some properties, entity keys and associations.

Then I linked it up to  a database using UpdateModel to create the SSDL for me but nothing happened.

It took a lot of experimenting before I realized that the problem was that I was trying to add in a CustomerAddress table but I had an association named CustomerAddress. If that had been an entity, it wouldn’t have posed a problem. But the wizard did not know how to handle the fact that it was an association and just completely gave up the ghost.

The only problem I see here is that some indication of the conflict would have helped me figure out what was wrong a little sooner, though I don’t expect the wizard to overcome the conflict on its own. I did make a note of this in the forums. However, I am putting the info here for posterity in case it’s too late to change the wizard for RTM and somebody else gets stuck on the same problem.