Are the ProviderManifests used by EntityFramework backwards compatible, in particular for Oracle and SQL Server?
I'm creating an instance of the DbProviderInfo class to pass to DbModel.Build(). The second argument to the constructor is the ProviderManifestToken.
As the documentation says, the ProviderManifestToken is:
A string that identifies that version of the database server being
used. For example, the SQL Server provider uses the string "2008" for
SQL Server 2008. This cannot be null but may be empty.
There is a related, unanswered question here asking what ProviderManifestInfo does. From reading this page I understand that it allows the database provider to determine which version of the ProviderManifest to return, without using a database connection. (What the ProviderManifest does is also explained at that last link.)
Experimentally, I have found that I can use an Oracle 12 database with a ProviderManifestToken of "11.2" with no problems. But is this supposed to be true in general? For example, if I pass "2008" as the ProviderManifestToken and I am using SQL Server 2012, can I expect 'things' to work OK?
I have been unable to find any documentation on this point and I would not be surprised if things are different from provider to provider.
But is this supposed to be true in general? For example, if I pass "2008" as the ProviderManifestToken and I am using SQL Server 2012, can I expect 'things' to work OK?
Yes, subject to the backwards-compatibility of the database provider. Oracle and SQL Server, at least, are very reluctant to break existing applications in new versions of the database, so applications written for older versions typically work fine.
The main purpose pf the ProviderManifestToken is to allow EF to use new functionality for a database provider, without abandoning support for old versions. For instance SQL Server introduced OFFSET .. FETCH paging in SQL 2012. And without the ProviderManifestToken EF would have to choose between using the older query form for paging (ROW_NUMBER() based), or drop support for SQL 2008.
It is possible that EF would generate a query that doesn't work correctly on a later version, which would be a bug in EF. But I don't know of any such cases.
Related
Good morning all,
recently I came upon problem with DB connection in Python and C#.
For example, let's say we want to connect SQL Server. In .NET (C#) we just need to know the server name, credentials and we can connect to DB with SqlConnection object. That's clear.
Now, in Python, when using pypyodbc we need to specify driver additionally. And here's come the question:
Why in Python we have to specify driver? We don't have to specify it in C#.
On the other hand, if specifying driver is so crucial, then why don't we have to specify it in C#?
I know, that in C# we have dedicated class for SQL Server (does Python? or pypyodbc is the only choice?), does that mean, that it has some method to resolve which driver to use? Is it the same with Oracle?
I know nothing about python, but I think that should answer your main question:
SqlConnection is designed specifically to work with SQL server, so you don't need to specify the driver, because it uses it's own designated driver.
From SqlConnection.ConnectionString Property page on Microsoft docs:
The ConnectionString is similar to an OLE DB connection string, but is not identical. Unlike OLE DB or ADO, the connection string that is returned is the same as the user-set ConnectionString, minus security information if the Persist Security Info value is set to false (default). The .NET Framework Data Provider for SQL Server does not persist or return the password in a connection string unless you set Persist Security Info to true.
(Emphasis mine, other stuff in the quot are just to provide context.)
And later on down the page:
The .NET Framework Data Provider for SQL Server uses its own protocol to communicate with SQL Server. Therefore, it does not support the use of an ODBC data source name (DSN) when connecting to SQL Server because it does not add an ODBC layer.
(again, emphasis mine.)
When working with other connection classes such as OdbcConnection or OleDbConnection, you need to specify the driver in the connection string.
With Odbc Connection Strings use the keyword Driver,
and with OleDb Connection Strings use the keyword Provider.
About Oracle, The .Net framework have a namespace called System.Data.OracleClient, but it's deprecated (from Oracle and ADO.NET):
The types in System.Data.OracleClient are deprecated. The types remain supported in the current version of.NET Framework but will be removed in a future release. Microsoft recommends that you use a third-party Oracle provider.
I'm guessing Oracle's own ADO.Net implementation also works with it's own driver. If you really want to know, you can look it up in their documentation.
I've been trying to connect to a MySQL database which is hosted on a RaspberryPI and I have been having a lot of trouble and wanted to know if it is possible before I continue.
I want to use .Net's Entity Framework 6 on Visual Studio 2013 in the same fashion as you would SQL Server to create Entites from the Database. First of all is this possible?
I have had two problems so far:
Firstly, I have been able to connect to a MySQL database on my local copy but not the Raspberry Pi's even though I have a user which allows any IP and has most privileges (I am connecting through LAN).
My Second problem is that once I have accessed and picked a database I receive this error, which makes me think that Entity Framework doesn't support MySQL:
I am also having a problem logging into my local instance of MySQL when the user has a password, which makes me think this could also be why I can't login to the remote MySQL?
You'll have to use an EF Provider to use MySQL and Entity Framework together. Some older Providers don't work with EF at all, or only previous versions.
Connector.NET is the 'official' solution: http://dev.mysql.com/doc/connector-net/en/connector-net-entityframework60.html
There is also some tooling from Devart (DotConnect) that may work 'better' than the MySQL Connector.NET. The reason I say that is in my experience Oracle's EF Provider (For Oracle) was not nearly as easy to set up / maintain as the Devart Solution.
I know that I can use the following code to enumerate all SQL Server instances on network:
SqlDataSourceEnumerator instance = SqlDataSourceEnumerator.Instance;
DataTable table = instance.GetDataSources();
But I was wondering if there was a way of doing this for Oracle Instances as well. Oracle's ODP.NET (Oracle.DataAccess.Client) supports DataSourceEnuerator, apparently System.Data.OracleClient doesn't though. However the DataSourceEnumerator only enumerates the entries that are found in the local TNSNames.ora file.
What you're seeing is due to the fundamental difference in how SQL Server and Oracle databases announce themselves. SQL Server (at least 2000 and 2005) use the SQL Browser Service to advertise databases available on the network. Oracle, on the other hand, requires you to explicitly enumerate instances available using TNS entries.
This is an instance of When in Rome, where Oracle is attempting to follow the API. Unfortunately, without custom code you won't be able to replicate the SQL Server behavior.
Hey guys I'm new to C# and I'm a little confused on the fields that need to be provided in the connection string while using oledb to connect to my sql server 2008 database, particularly one of them.
The "Provider" field is really giving me problems, partially because I'm not really sure what it does. I have tried two different Provider strings and they both come back with the same error:
The "System.Data.SqlClient provider is not registered on the local machine
Or
The "Microsoft.Jet.OLEDB.4.0" provider is not registered on the local machine
Can someone tell me what this means? Also, my task requires me to not use any addition installations, is there a provider that is default?
Thanks
The Microsoft Jet Engine is the database engine used in Microsoft Access. The error simply means that the required Access version is not installed and thus, your application cannot open the OLEDB driver.
Generally, you should probably just use the System.Data.SqlClient.SqlConnection class instead of the System.Data.OleDb.OleDbConnection class to connect to your SQL Server 2008 database. The connection string should be much simpler.
We want to allow access to our custom back end data store by pretending to be an ODBC server such as Access or SQL Server. In this way, anyone with those ODBC drivers could connect and send us queries (from anything from asp.net to Excel) which we will resolve on the back end and return a result set.
I have the ability to parse SQL and return result set based on a dynamic sql query. What I don't know is how to pretend to be an ODBC or OLEDB server. I don't even care which server we mimic as long as it's a common one that has drivers that ship with windows.
I have searched but could not find a basic implementation that implements authentication and ExecuteQuery() methods. Does such a .net project exist?
You could implement an ADO.NET data provider?
see http://msdn.microsoft.com/en-us/library/a6cd7c08.aspx
The System.Data.Sqlite project is an excellent example of how to build an ADO.NET data provider for an arbitrary data store.