Domanda

I have one website that uses EF 4.4 (.NET 4.0 version of EF 5.0) that uses Code First against an existing database. I use the Devart oracle data provider which requires a workaround because of casing issues with the model type.

It makes the Devart provider recognize lowercase datatypes to interpret the schema. (Or something along those lines)

This works properly, until the control within this website, built on EF 4.1 Database First (Also against an existing database) tries to load. The Devart provider seems to be shared across the websites, and it results in errors about the provider not being able to recognize the datatypes (correctly) in all caps, because of the previous workaround to make it work in Code First.

Is there a workaround for this, or do I have to convert the Database First approach to Code First?

Edit: Here is the related workaround code. I seem to have lost the forum post I got it from. I believe it was on the Devart forums:

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        var config = Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfig.Instance;
        config.Workarounds.ColumnTypeCasingConventionCompatibility = true;

        ... initialization code here ...

        base.OnModelCreating(modelBuilder);
    }

And the related error is this:

System.Data.MetadataException: Schema specified is not valid. Errors:
Model.ssdl(205,6) : error 0040: The Type CHAR is not qualified with a namespace or alias. Only primitive types can be used without qualification. 
Model.ssdl(206,6) : error 0040: The Type VARCHAR2 is not qualified with a namespace or alias. Only primitive types can be used without qualification.

There are a bunch more, but they're all the same error with different lines and data types.

È stato utile?

Soluzione

The Devart provider seems to be shared across the websites

After the ColumnTypeCasingConventionCompatibility option is set, it determines the behaviour of the current application domain (web site). The process (web server) may run several application domains with different values of ColumnTypeCasingConventionCompatibility.

The value of ColumnTypeCasingConventionCompatibility for the particular application domain depends on the Fluent Mapping property of the DbContext template used for the model in web site. Fluent Mapping=true must be used with ColumnTypeCasingConventionCompatibility=true, and vice versa: Fluent Mapping=false must be used with ColumnTypeCasingConventionCompatibility=false.

You can set ColumnTypeCasingConventionCompatibility for a web site in the following alternative ways:

a) in your code before the first usage of the context (e.g., in a static constructor of the context or in the Main method of your program, etc)

b) in *.config. For example:

<configuration>
  <configSections>
    <section name="Devart.Data.Oracle.Entity"
    type="Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfigurationSection, 
  Devart.Data.Oracle.Entity, Version=7.5.179.0, Culture=neutral, 
  PublicKeyToken=09af7300eec23701" />
   </configSections>
  <Devart.Data.Oracle.Entity xmlns="http://devart.com/schemas/Devart.Data.Oracle.Entity/1.0">
    <CodeFirstOptions ColumnTypeCasingConventionCompatibility="true"/>
  </Devart.Data.Oracle.Entity> 
</configuration>
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top