views:

458

answers:

3

I'm using .net framework 3.5 SP1.

After adding a column to one table in Sql Server (as well as changing an existing column from allowing nulls to not nullable), I can no longer run my project without getting this error:

The number of members in the conceptual type 'XBRLDimensionalModel.axis_t' does not match with the number of members on the object side type 'EOL.Xbrl.Persistence.Data.axis_t'. Make sure the number of members are the same.

I gave up trying to find and fix the generated code. I now have deleted all my local entity-related files and re-generated them by starting over from scratch and adding a new item (ADO.NET Entity Data Model). I still get this error.

The only way I can run the project now is to undo all my pending changes and use the last version from source control, and of course change the two modified database columns to nullable.

From all I've read so far it seems like I simply should have been able to "update" my model from the database. That resulted in this exception (above). But now I'm totally confused that even with a complete regeneration of the entity model and supporting classes I'm still getting that error.

I changed the property on my edmx model: "Metadata Artifact Processing" to "Copy to Output Directory". The Designer.cs, csdl, msl, ssdl files all seem to be consistent with the latest DB changes.

The exception is being thrown the first time my entityModel instance is referenced. So it is prior to any loading or saving of the data from the changed table.

any ideas where I'm going wrong? Thanks, TG

A: 

Open your model as XML. Remove all references to that type from the CSDL. Save and close, then reopen in the GUI. Now you should be able to update model as usual. If that doesn't work, do the same thing, but remove from MSL as well.

Craig Stuntz
Craig, sorry, do you mean just the CSDL file or the edmx file or both?and another stupid question: to "update the model" do I just right-click the background of the GUI | Update Model from Database | (Refresh Tab) Finish. ?
TG
And another: When you say "type" do you mean the entity that corresponds to my table (Axis_t)?
TG
The CSDL is generated from the EDMX. You want to edit the CSDL *section* of the EDMX. Yes, you right-click. Yes, I mean the type.
Craig Stuntz
Mystery solved. EF was generating the app.config file in the assembly which containes the model. However, my startup project I was using to test the assembly had it's own version of the EF model to the same database - prior to my DB change. The EntityModel instantiated was my "real" version but the application was using the startup project config file which was pointing to resource artifacts from the old model. I just removed the original test EF model and copied the connection string to the startup proj config file. That's what happens when you have a Sql guy doing .net programming :)
TG
A: 

This seems a little verbose for a comment so I'm adding this as another answer:

In response Craig's suggestion I opened the edmx file in an XML viewer and removed all references to Axis_t (including the associations due to Foreign Keys). From the entire file.

I then "updated" the model by opening the edmx file as the GUI interface, right-click | refresh from database | Add (tab) which now only lists the Axis_t table. I added the table which seemed to work fine and included my new column and the column was mapped correctly.

I then ran the project to the same result. Same error as posted above.

I have now reverted back to what was in source control as well as changing the database columns (new one and modified one) as nullable. The project runs fine. I still have not successfully been able to implement the new DB column in EF. It behaves as if there is some stored/compiled version of the model which is not being updated via the "update" process.

TG
"Update from database" will replace the SSDL section of the EDMX completely. It will also update the CSDL when it believes it can do so without wiping out changes you have made. For example, if you had an entirely new column, it should add this to the CSDL. On the other hand, if you change the type of the column, it might not update the CSDL. If my original suggestion is not working for you, it is likely that there is some portion of the MSL or CSDL related to that entity which you have missed.
Craig Stuntz
It must be something stupid like that. I just performed a little test separately with 2 tables (parent/child), set up a new model, then added a column to the child table. I then performed your suggested steps and it worked fine. Right now the only difference is that the real project is in source control but I can't imagine that would affect this. I'll try (yet) again...
TG
A: 

When changing a foreign key from nullable to non-nullable (or vice-versa), be sure to change the association multiplicity from 0..1 to 1 (or vice-versa). The designer sometimes misses this in an update from the database.

Michael L Perry