I'm now in the process of integrating the dotConnect provider into a larger project of ours, which is basically an application server with WCF endpoints that we ship as part of a package. Depending on the customer, either SQL Server or Oracle have to be wired up, so we have a EDMX generated for SQL Server and pull the Oracle SSDL in, when the customer has an Oracle DBMS; CSDL and MSL are shared.
This worked OK with the Oracle.Data.Access provider, there were some quirks, to be sure but we worked around those.
dotConnect for Oracle poses the following problem: The properties from the entity types do in some cases not match the actual .NET types. Let me elaborate.
Here's what the native Oracle provider generated for the table named DB_INFO:
Code: Select all
<EntityType Name="DB_INFO">
<Key>
<PropertyRef Name="Z_DB" />
</Key>
<Property Name="Z_DB" Type="number" Nullable="false" Precision="10" />
<Property Name="TYP" Type="number" Precision="10" />
<Property Name="MODUL" Type="number" Precision="10" />
<Property Name="NAME" Type="varchar2" MaxLength="250" />
<Property Name="USERNAME" Type="varchar2" MaxLength="250" />
<Property Name="PASSWORT" Type="varchar2" MaxLength="250" />
<Property Name="GUIDDB" Type="varchar2" MaxLength="250" />
<Property Name="BEREICHE" Type="clob" />
<Property Name="BEREICHEPD" Type="clob" />
<Property Name="CONSTR" Type="clob" />
</EntityType>
Compare this to what dotConnect for Oracle returns:
Code: Select all
<EntityType Name="DB_INFO">
<Key>
<PropertyRef Name="Z_DB" />
</Key>
<Property Name="Z_DB" Type="int64" Nullable="false" />
<Property Name="TYP" Type="int64" />
<Property Name="MODUL" Type="int64" />
<Property Name="NAME" Type="VARCHAR2" MaxLength="250" />
<Property Name="USERNAME" Type="VARCHAR2" MaxLength="250" />
<Property Name="PASSWORT" Type="VARCHAR2" MaxLength="250" />
<Property Name="GUIDDB" Type="VARCHAR2" MaxLength="250" />
<Property Name="BEREICHE" Type="CLOB" />
<Property Name="BEREICHEPD" Type="CLOB" />
<Property Name="CONSTR" Type="CLOB" />
</EntityType>
As I already mentioned, CSDL and MSL are shared so both SSDLs map to the same .NET types. Here's the one for DB_INFO:
Code: Select all
<EntityType Name="DB_INFO">
<Key>
<PropertyRef Name="Z_DB" />
</Key>
<Property Type="Int32" Name="Z_DB" Nullable="false" />
<Property Type="Int32" Name="TYP" />
<Property Type="Int32" Name="MODUL" />
<Property Type="String" Name="NAME" MaxLength="250" FixedLength="false" Unicode="false" />
<Property Type="String" Name="USERNAME" MaxLength="250" FixedLength="false" Unicode="false" />
<Property Type="String" Name="PASSWORT" MaxLength="250" FixedLength="false" Unicode="false" />
<Property Type="String" Name="GUIDDB" MaxLength="250" FixedLength="false" Unicode="false" />
<Property Type="String" Name="BEREICHE" MaxLength="Max" FixedLength="false" Unicode="false" />
<Property Type="String" Name="BEREICHEPD" MaxLength="Max" FixedLength="false" Unicode="false" />
<Property Type="String" Name="CONSTR" MaxLength="Max" FixedLength="false" Unicode="false" />
</EntityType>
Now take Z_DB, for example. Type="number" Nullable="false" Precision="10" (Oracle) maps alright to .NET type Int32 (int), but of course, Type="int64" Nullable="false" (dotConnect) does not.
And that is exactly why I'm seeing InvalidOperationExceptions right now:
The type of the key field 'Z_DB' is expected to be 'System.Int32', but the value provided is actually of type 'System.Int64'.
So the question is, is there some way to change this behavior?