Changing Oracle connection strings between EF4.0 and EF4.1

Discussion of open issues, suggestions and bugs regarding ADO.NET provider for Oracle
Post Reply
object
Posts: 91
Joined: Tue 26 Oct 2010 08:29

Changing Oracle connection strings between EF4.0 and EF4.1

Post by object » Mon 09 May 2011 08:22

Hi,

I am working on examples of using dotConnect for Oracle (11gR2) with Entity Framework 4.0 and 4.1 ("code first"). Here is my connection strings section:

Code: Select all

  
    
    
  
The "model first" connection works fine, however when I try to connect to a database using "code first" connection, I am getting a provider exception. Is this the right syntax? I would like to use direct connection and avoid Oranames.

Thanks in advance

object
Posts: 91
Joined: Tue 26 Oct 2010 08:29

Post by object » Mon 09 May 2011 14:41

More about this error: looks like the connection is treated as an SQL server connection. Here's exception stack:

System.Data.ProviderIncompatibleException : The provider did not return a ProviderManifestToken string.
----> System.Data.SqlClient.SqlException : A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
at System.Data.Common.DbProviderServices.GetProviderManifestToken(DbConnection connection)
at System.Data.Entity.ModelConfiguration.Utilities.DbConnectionExtensions.GetProviderInfo(DbConnection connection, DbProviderManifest& providerManifest)
at System.Data.Entity.DbModelBuilder.Build(DbConnection providerConnection)
...
at System.Data.SqlClient.SqlProviderServices.GetDbProviderManifestToken(DbConnection connection)
at System.Data.Common.DbProviderServices.GetProviderManifestToken(DbConnection connection)


Why on earth it should try MS SQL Server if prodiver name is "Devart.Data.Oracle"?

object
Posts: 91
Joined: Tue 26 Oct 2010 08:29

Post by object » Tue 10 May 2011 09:21

Did some more testing just to validate that connection string is valid.



If I send it to an OracleConnection instance and later use in OracleCommand, it works fine. But if I try instantiating DbContext from it, I get "Unhandled Exception: System.Data.ProviderIncompatibleException: The provider did not return a ProviderManifestToken string" exception.

Any help is appreciated.

AndreyR
Devart Team
Posts: 2919
Joined: Mon 07 Jul 2008 13:16

Post by AndreyR » Tue 10 May 2011 12:25

There are two possible solutions:
1. Change the name of the connection string in your configuration file to the name of your DbContext class.
2. Create an OracleConnection instance using the connection string from your configuration file and pass this instance to the DbContext constructor.
I recommend you to refer to our Code First article for more details.

object
Posts: 91
Joined: Tue 26 Oct 2010 08:29

Post by object » Tue 10 May 2011 12:39

Hi Andrey,

1. This is a workaround, although it's kind of ugly. Why should I name my connection strings after the context? What if I want to reuse the same context with different connections?

2. The second one is not nice either because it requires referencing Devart assemblies in the project.

I tried (1), it seemed to work, although I received another exception ("Schema specified is not valid"). But at least I can move on after reading "Code First" article you mentioned.

BTW, is this EF 4.1 or dotConnect limitation that you can not create a context using an arbitraty name for a connection string? If this is a limitation of dotConnect, I'd consider fixing it.

AndreyR
Devart Team
Posts: 2919
Joined: Mon 07 Jul 2008 13:16

Post by AndreyR » Tue 10 May 2011 13:49

1. You can achieve this by creating a constructor that takes a string or a DbConnection instance, as I have already described.
2. You are using Devart assemblies anyway for DB access, so you can easily reference them.
If you are using one context for several DBMS, just move the DB-specific code to an inherited class, like it is described in our sample.
3. This is a DBContext feature.

object
Posts: 91
Joined: Tue 26 Oct 2010 08:29

Post by object » Tue 10 May 2011 13:57

1. Sure, I misunderstood. I thought the connection should have names after the context.

2. Isn't it a good practice not to reference assemblies directly in case their classes are instantiated via reflection? But since option (1) is available I'll stick to that.

But I seem to be getting some data now. Thanks for you help, as always!

Post Reply