Devart Forums

Hi,

this information was really helpful and it works in my software. But when I want to use the model in LINQpad (from the compiled assembly) I receive the same error as mentioned above. Is it possible to pass that configuration setting e.g. in the connection string?

Best regards
Jochen

Hi,

I would like to confirm this walk through worked, however there should be a lot more of these done properly as tutorials to help newbies get going. I have had dotConnect for a fair while now and have hardly got any use out of it, bumbling between one issue and another.

I would like to add a little clarification to the walk through to assist with others having the same issues. Also it would be nice to see examples of using the UnitOfWork and Repositories in full. Also how to go about creating your own methods etc.

Firstly it is really important if anyone like myself is mapping to a third party database, make sure your permissions are set, the bare minimum is the best approach. In my instance I only want to write to 2 tables, the rest are read only so I have created a database user with those permissions.

Secondly if like our HR system the database you are mapping to isn't native to oracle and is basically just dumped in oracle tables, rely on NOTHING being mapped correctly as standard. This caught me up massively with duplicate values being returned for the correct number of rows, that you query should return or even just returning nothing.

For example, I have moved house 3 times so on the address table I have 3 address. Lets say these have 3 primary key fields (employee id, address type and date keyed).

Automatically the primary key for no good reason is mapped to address line 2 and phone number.

What you will find is that if you are lucky and it finds you based on a query of say employee id = 12345, you will get 3 lines come out with the same data or some variation if there is some unique values in the fields that were automatically assigned as primary keys.

Simply go back to your model diagram, right click, select mapping and turn auto synchronization on. (This will half the work you need to do).

Next select an entity (table) and click edit. Here you can see all the fields or properties relating to your entity (table). In this example we are going to make sure that the primary key box is ticked ONLY for employee id, address type and date. You can also change details should you wish to set fields as nullable etc.

Make sure you have added a class under the namespace of your model and referencing your model entity as described previously. Also make sure you have EF5 installed from nuget and here's the weird bit, despite EF5 being installed and EF5 being the framework I selected in the entity developer wizard, you need to reference Devart.Data.Oracle.Entity.dll from EF4 in your Devart program files.

Finally save, rebuild and run and you should get the data displaying as expected.

Hope this helps,

Andy

jauinger wrote:But when I want to use the model in LINQpad (from the compiled assembly) I receive the same error as mentioned above.

Entity Framework support features can be configured either in code using Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfig class or in the project .config file (http://www.devart.com/dotconnect/oracle ... ation.html).
How do you configure them? Try configuring them with the following code: Additionally we can recommend you our new tool LINQ Insight, which allows you to execute LINQ queries in your code right from the Visual Studio code editor.
http://visualstudiogallery.msdn.microso ... 0b359dcfe0

mcinnes01 wrote:Also make sure you have EF5 installed from nuget and here's the weird bit, despite EF5 being installed and EF5 being the framework I selected in the entity developer wizard, you need to reference Devart.Data.Oracle.Entity.dll from EF4 in your Devart program files.

Please describe the situation in more details:
* Do you use Visual Studio 2012?
* Does your application have .NET Framework 4.5 as the target framework?
* Which errors occur if you add our assemblies for EF 5 and when do they occur?

We will consider the possibility to add the references to the required versions of Entity Framework-specific provider assemblies automatically when adding an Entity Framework model to the project with Entity Developer. We will also consider the possibility to automatically download and add the corresponding NuGet package.

I have this issue with a clean install of...
Visual Studio 2012 Ultimate
DotConnect for Oracle 7.7.242
We are running our App with EF 4 and .NET 4.0.

Adding Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfig.Instance.CodeFirstOptions.ColumnTypeCasingConventionCompatibility = false;
to the static constructor of our DB context classes fixed this error for us.

However, I consider this a work around. We generated our model from the database with the Entity Developer that came with dotconnect 6.80.??

When opening the EDML with the Enitity Developer that came with 7.7.242, it sees no issues. Seems there should be some sort of update tool to make it compatible with the latest dotconnect version. Any sort of tool like that exist?

Thanks.

The ColumnTypeCasingConventionCompatibility option allows you to avoid explicitly turning off the ColumnTypeCasingConvention for each DbContext when working with Devart dotConnect for Oracle. By default it is set to false. When using XML mapping (Entity Framework v1 and v4) - a edmx/edml file and ObjectContext or DbContext in the XML mapping mode - this option must be FALSE. When using Entity Framework Code First (Entity Framework v1 and v4), this option can be true or false, but if it is set to false, you must turn off ColumnTypeCasingConvention explicitly for each DbContext. This option must be True for EF Code-First Migrations (EF v4.3.x and v5.x) to work correctly.

hyiothesia wrote:However, I consider this a work around.

This is not a workaround. There is a particular algorithm in dotConnect for Oracle for setting the needed value of the ColumnTypeCasingConventionCompatibility option automatically in runtime. But we recommend setting this option explicitly to avoid ambiguity.

Agreed. Upon further inspection we found the EF compatibility reason behind the setting.