This content has been marked as final. Show 14 replies
It's an expected error.
In your case, the CSDL section of the edmx file already has Type="Int16" for the column.
That's because number(1, 0) is mapped to Int16 by default.
After the data model is already generated and you change the mapping to Boolean. At runtime
EF calls the provider's GetEdmType() and it returns Boolean accordingly (because your config file
indeed has such new mapping). But your edmx is still using Type="Int16" for the column.
Therefore an error occurs.
If you don't want to regenrate the model, you may manually update the type mapping in the CSDL
accordingly, i.e. change Type="Int16" to Type="Boolean" for the column.
It's highly recommanded that regenerate the data model (and hence to have a new edmx) whenever
the mapping has changed in the config file.
Manual change is prone to mistake and may not be faster than regeneration.
Another approach is double-click on the edmx file, manually delete table(s) from the designer page, save
the edmx file, then use "Update Model from Database..." to select the table(s) again to update the model.
In this case, the edmx file will have the new mapping for the table(s) you have just updated.
Basically, you are doing partial regeneration. Time is saved on Views, SPs, and those unaffected tables in the model.
Edited by: shsu on Oct 5, 2012 4:08 PM
The issue you experienced seems to be opposite.
When the timestamp of the config file has changed, the content of the config file should be re-read and used.
Unless for some reason the path of the config file at that time is incorrect or unknown to ODT, which privdes
ODP with the info, the new mapping should be used by ODP in its GetEdmType().
Can you exit Visual Studio, reopen the solution/project, and then try again?
Have you tried 18.104.22.168 ODAC Rel 5?
I've done it about a dozen times in several projects, using the first release and Rel 5, in VS 2010 SP1 and 2012. Same thing every time. It worked as described for me in beta 2, broke in beta 3, and hasn't worked in any version since. (I've recently formatted and reinstalled everything from scratch, so its not a lingering beta issue.)
What config file is it looking for? I'm putting things in the project's App.config where the .edmx is, but it never picks that up until runtime.
I'm not the only person who has reported the issue here, just the most persistent. :) So I know there's some combination of factors that makes it not work and just haven't figured out what it is yet. When I'm back in the office on Monday I'll try to whip up the simplest test case I can.
Alright. Fired up VS 2012 today and did the following:
- New Project, C# Forms App
- Added an App.config file using Add new item. Put the following into it:
<add name="bool" value="edmmapping number(1,0)" />
- Closed and reopened the solution.
- Opened up Server Explorer and opened the connection I want to use.
- Added a new EDMX model, from the database. Picked one table.
- number(1,0) is mapped to int16 in the model. Running the project and trying to create a context results in an error due to the mapping not being correct (it expects bool).
The configuration is being picked up at runtime and totally ignored at design time. I'm also finding that in VS 2012 it doesn't reliably create a connection string in app.config. The first time around I didn't get one, but when I set the project build to x86 instead of AnyCPU (I only have the 32 bit client) and then told it to update from database, it prompted me again for the connection and saved it that time.
Results in VS 2010 are identical in the model, I still get int16 for number(1,0). It did create the connection string as expected though.
Me again. Sigh. I reinstalled the "fat" 22.214.171.124 client after this test, since we use that one for other things and it's what the production environment has. It's in another home from the developer tools, but as soon as I installed it and then tried updating the model I'd just created to add another table, the mappings broke again and things are coming up as Int16.
Seems like that version and the developer tools version don't play nice with each other when they're both on the same machine, even in different homes.
I am in the same boat! It seems like core functionality and it only works in the beta 2 version. I think I am going to just accept the int16 default mapping and handle conversion in the code. Not very elegant but I have had enough pain. I am very disappointed that Oracle does not seem very interested in addressing the issue. This has been out there for a long time and no fix, bewildering!
Before I go and make the same type of code change over and over and over.... Has anyone made any progress?