Discussion of open issues, suggestions and bugs regarding ADO.NET provider for Oracle
-
object
- Posts: 91
- Joined: Tue 26 Oct 2010 08:29
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:
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!