Andr&#233&#59; Dias

Hi All,

I have read some posts talking about the provider model that will enable ISVs and the Community develop specific providers for databases non Sql Server to work with DLinq. Cool !!! I agree that MS isn't responsible for developing others providers and I believe that Oracle and others players will develop its providers and ship with Orcas final release. (I hope so)

But I read a post about MS Data Access Strategy ( and a specific paragraph let me a little bit worried.

If you are writing an application that requires any of the following features, you should use the ADO.NET Entity Framework:

The ability to query relational stores other than the Microsoft SQL Server family of products.

What does it mean Is it better use EF than DLinq to connect in Oracle Why If DLinq is been developed over a Provider Model, why I can't use DLinq with Oracle If I can, why MS recommends that I should use EF

Thanks in advance


Re: ADO.NET (Pre-release) Oracle with DLinq or EF?


(If you are writing an application that requires any of the following features, you should use the ADO.NET Entity Framework:

The ability to define more flexible mapping to existing relational schema, for example:

o Mapping a single class to multiple tables

o Mapping to different types of inheritance

o Directly Modeling Many to Many relationships

o Mapping to an arbitrary query against the store

The ability to query relational stores other than the Microsoft SQL Server family of products.

The ability to share a model across Replication, Reporting Services, BI, Integration Services, etc.

A full textual query language

The ability to query a conceptual model without materializing results as objects)

I am assuming you are talking about the above Microsoft is correct to say you need the framework because some of above involve complex math operations mixing clean ANSI SQL defined operations with RDBMS vendor managed operations like BI that are not standardized.

When the LINQ project was announced the only technical reference was a landmark 26pages long Algebra, it is not easy to please people who expect simple solutions. I connect to both Oracle and SQL Server for development.

Re: ADO.NET (Pre-release) Oracle with DLinq or EF?

Andre Dias

Yes. I'm talking about this post and according to it I should connect to Oracle using EF. My question is simply: Why DLinq is just for SQL Server Where is the provider model

I didn't try DLinq with Oracle because I don't have this db installed on my computer, but if you tell me that it works, including wizards and other features, is enough for me. I'll try as soon as install it.


Andre Dias

Re: ADO.NET (Pre-release) Oracle with DLinq or EF?

Julie Lerman

There's been a lot of speculation about this. The fact that it's called "Linq to SQL" says quite a bit. While there has been information about database vendors writing providers for Entity Framework, it's not so obvious with LINQ to [my favorite database].

Roger Jennings wrote this analysis a few months ago.

Mike Pizzo wrote about alternate vendors and LINQ/EF at TechEd, including IBM's LINQ to DB2 conference session. If IBM is writing a LINQ provider, I would imagine the other biggies are working on something or contemplating something as well. Of course, I think Oracle would generally prefer that you just use their development tools. So if not the actual vendors, don't forget 3rd party provider developers such as DataDirect.

Hope this helps a little...

Re: ADO.NET (Pre-release) Oracle with DLinq or EF?

Michael Pizzo - MSFT

Yes, DLinq (now officially called "LINQ to SQL") is only for SQLServer, at least for this release.

While LINQ to SQL is built on top of the ADO.NET Data Provider for Microsoft SQL Server (SQLClient), the knowledge that the target database is Microsoft SQL Server is pretty pervasive throughout the LINQ to SQL stack. With the current LINQ to SQL internal layering, each provider would have to implement support for interpreting and translating language expressions into queries, applying mappings, and generating their own native SQL queries, instantiating and setting properties on CLR objects through reflection or lightweight codegen to materialize results as domain objects, executing DML expressions to process changes, database definition, and so forth. These tasks, especially the translation of language expressions plus mapping to native SQL, is actually the bulk of the LINQ to SQL code.

Our consistent philosophy, from ODBC to OLE DB to ADO.NET, is to define a common API for database providers to implement that defines the bare minimum necessary to expose the native functionality of their store in the most natural and efficient way possible. We then provide common implementations of extended functionality on top of that provider layer.

ADO.NET Data Providers already define a model for connecting, specifying and executing a command, and retrieving results consistent with their relational domain. In order to plug into the ADO.NET Entity Framework, including LINQ to Entities, ADO.NET Data Providers additionally implement the ability to generate a DbCommand from a common relational query tree representation, which we call CQTs (Canonical Query Trees). Everything else (mapping through client views, query construction, object materialization, LINQ support, etc.) is then provided through a common implementation on top of that low-level provider API. This has several advantages:

Makes it easier for provider vendors to deliver timely, high-quality data provider implementations

Provides a public, low-level interface to native store functionality for efficient result streaming, command execution, etc.

Helps ensure consistency of behavior for extended services (i.e., consistent translation of LINQ expression trees to a relational query)

Gives us the ability to extend higher-level functionality without rev¨ing provider (i.e., adding support for composition, complex types, etc.)

Following this model, we anticipate having broad support for Oracle and other 3rd party databases for LINQ to Entities when the Entity Framework ships in the first half of CY2008.

Of course, we can do the same thing with LINQ to SQL by internally refactoring the code to generate CQTs, provide a common implementation of object materialization on top of provider¨s DataReaders, and so forth, but we simply don¨t have resources to do that work in the Orcas timeframe.