So what was the point of OLE DB if you still wrote SQL?

Question

In this OLE DB msdn example, (yes, it is dated 1997, but still works :)) I'm wondering what the historic point of OLE DB was if you still apparently wrote SQL to interact with the underlying datasource.

The one thing I'm thinking is if the ICommandText was not executed directly on the database, but instead somehow interpretted by OLE DB then passed off as a vendor specific SQL command/command to manipulate underlying datasource in format it understands. Is that true?

Answer 1

I can vouch for the fact that there is NO translation done by OLE DB.

If you have different databases, you would have to provide different SQL statements based on the vendor. Always fun with dates and Oracle vs. MS databases...

Answer 2

The intent of OLE DB technology is to have a generalized way to connect, work with transactions, and work with datasets. But you still have to write SQL queries. Remember, the intent of the SQL language was to have a generic language for querying data (but, as you've seen, certain parts of the language are platform-dependent). How you connect and how you query are mutually exclusive.

And, yes, the CommandText is executed directly in the database.

Perhaps you want something a level up such as NHibernate, Subsonic, Entity Framework, etc.?