We are writing this paper about database access in a web app and have to distinguish between the different categories of the database access layer.
All books and PDF's given us provide only information to JDBC or OLEDB.
Researching on the web brought me to the point that access to a Microsoft SQL Server trough linq-to-entities or linq-to-sql through ADO.Net can't be put under the same category as JDBC or OLEDB (middleware).
What would be the exact definition/category for Microsoft SQL Server-access through the .NET facilities such as LINQ2Entities or LINQ2SQL?
ADO.NET is the next step after OleDB - and it's definitely in the same category as OleDB or ODBC / JDBC.
Linq-to-SQL and Linq-to-Entities are more high-level - they don't solve low-level data access problems, they're more about OR-mapping and providing models to work against. I would put those in a similar category as Hibernate in the Java world.
Marc
LINQ to SQL and the Entity Framework both fit (to varying degrees) in the category of ORMs. Both sit on top of ADO.NET and cannot be used without it. ADO.NET is essentially a .NET replacement for OLE-DB, which, itself, was a replacement for ODBC.
Related
We have a few .Net application that we would like to start using Entity Framework 5.0 but the problem is that our customers can choose to use one of any of the following database engines:
SQL Server (95% of Customers use this engine)
Oracle (3% use this engine)
DB2 (2%)
So as you can see an overwhelming majority of our customers use SQL Server. So my question is that assuming that each database engine will have the same exact schema layout then all we should have to do is to change the entity connection string to target each of these engine types, correct?
Sorry if this seems to be a simplistic question but I just wanted to make sure that I was on the right track here.
I do not know Entity Framework, but the are many differences between the DB engines.
For example the security, in DB2 is always external (OS secutiry), in Oracle most of the time is internal. Procedure language is different, and I hope you don't use it for a multi-platform application.
The best is to try the execution with each database, and tune the procedure in order to work in all of them, but I think you have to do more that change the connection string.
I am looking to use Entity framework as database layer in my application, but I found that it didn't support oracle database and I will need to use third party provider for this purpose.
However I want to build database layer support multiple database (Oracle , MS Sql Server) and in the same time support entity model like LinqToSql and devart.
if any one has any information can help me I will be grateful.
Thanks.
What you want here is probably a repository pattern, something that can sit in the middle so that your application doesn't care how the underlying data is stored.
You could use something like my repository pattern (read about it here : http://blog.staticvoid.co.nz/2011/10/staticvoid-repository-pattern-nuget.html) and implement a custom IRepositoryDataSource for oracle (you could do this by using the LINQ to oracle provider from codeplex, http://linqtooracle.codeplex.com/) or alternatively you could write your own repository with implementations for both sql and oracle.
I found that linqconnect component from (devart) does what I need.
Entity Framework does not include an out-of-the-box provider for any RDBMS other than SQL Server. Any third-party RDBMS vendor that wants to support EF is expected to provide its own implementation based on Microsoft's provider model. Oracle has in fact released an official provider that is part of ODP.NET. I would recommend this one because it is free:
http://www.oracle.com/technetwork/issue-archive/2011/11-sep/o51odt-453447.html
P.S. - The Devart LinqConnect providers are not really Linq to SQL providers. They provide classes that mimick the structure and functionality of the Linq to SQL classes (DataContext, EntitySet<T>, etc.), but they are in a different namespace. It is impossible for anybody other than Microsoft implement a Linq to SQL provider, because they never exposed the provider model through public types.
I am investigating for different ORMs to use in a new Web Application I have to develop.
I hesitate between NHibernate and EntityFramework 4.1.
I know that NHibernate does support different databases (like SQL Server, MySQL, Oracle, and so on.) isn't it?
What about Entity Framework? I cannot find which databases it supports (I suppose it is database agnostic but I am not very sure). For example, I was not able to make it run with MySQL (with MySQL Connector 6.4.3).
The answer I want is only regarding on the support of differents databases. There are some information in stackoverflow about "NHibernate vs Entity Framework".
Entity Framework query is translated into final form (sent to DB) by three "layers":
1. Object Services
2. EntityClient Data Provider
3. ADO .NET Data Provider.
The Object Services layer is a component of the Entity Framework that enables you to
query, insert, update, and delete data, using common language runtime (CLR) objects that
are instances of entity types.
The Entity Framework includes the EntityClient data provider, which manages connections, translates entity queries into data source-specific queries, and returns a data reader the Entity
Framework uses to materialize entity data into objects.
Traditional ADO.NET is still used to communicate to the underlying database.
What does it mean? It means Entity Framework was designed to be database independed. You can use it with every database if database provider has created provider for ADO .NET (which exists for MySQL, Oracle etc.).
For MySQL you should be able to use EF with connector that you've mentioned (more info: http://dev.mysql.com/doc/refman/4.1/en/connector-net-visual-studio-entity-framework.html)
Out of the box NHibernate supports following:
Microsoft SQL Server (including Compact Edition)
Oracle
Microsoft Access
Firebird
PostgreSQL
DB2 UDB
MySQL
SQLite
Corresponding ADO.NET provider needs to be installed. In addition to ADO.NET provider, NHibernate needs its own 'driver' and 'dialect' if you want to extend it to support the database that is not on the list.
We have a SharePoint 2007 site. It is supported by two back-end databases - one hosted on SQL Server, another on an open-source RDBMS. We issue CAML queries to retrieve data from SQL Server, and ADO.NET queries to retrieve data from the other server. Our architect says we would be better off if we used the same approach (namely, CAML) to get data from the both databases.
Is it possible to use CAML queries to retrieve data from any RDBMS other than SQL Server?
If so, please suggest any web resources, docs, anything you find appropriate.
CAML (at least that part used for SPList.GetItems queries) seems to be quite simple, so translating it into valid SQL statements should not be too complex. Which means, you could create a "translator module" and issue your queries against it. For instance, you can follow guidelines published in the article "[Implementing a .Net Framework Data Provider](http://msdn.microsoft.com/en-us/magazine/aa720164(VS.71).aspx)".
I have a project that will be using Access 2003 as the front-end and the data will be stored in SQL Server. Access will connect to SQL Server via linked tables with all the database logic (stored procedures, views) within SQL Server.
Given this setup, would it be better to use ADO or DAO within Access? Is it just a matter of preference or is one more suited to Access as a front-end and SQL Server as the data store? Especially when using linked tables. Thanks.
Write pass-thru queries as opposed to the linked table approach. Performance will be greatly improved. Writing an Access app?
Create some local tables to store some query results. You can dynamically change the pass-thru queries as needed as well as connection info for connecting to multiple databases.
Edit: General consensus is ADO for connecting to sql server/other sources and DAO for mdb only sources.
Use an MDB with ODBC linked tables. Because you are using ODBC, you are connecting via Jet, so it's obvious that DAO is the default choice for data access.
ADO should be used only for those things that can't be done otherwise, or that are performing poorly.
In short, you build your SQL Server app just like you would a pure-Access app (assuming you build an app with a Jet/ACE back end to retrieve data efficiently, which should be a no-brainer), and only resort to server-side functionality or ADO when the default Access approach is inefficient or doesn't get the result you need (e.g., an editable recordset in the case of recordset-returning sprocs).
DAO was used to access MDB databases from any COM application. I don't believe it can even connect to SQL Server.
ADO is a successor of DAO. ADO can connect to many databases, but interacts especially well with SQL Server. So in your situation, using ADO seems like a no brainer.