I found this question here: OLEDB v/s ODBC
Which gave me more information, but did not really answer the question I'm asking, so I shall proceed from there.
I am working in C#. I'll spare you the long story about how I arrived at this conundrum, but basically I'm trying to decide between ODBC and oleDB.
We work with a lot of different clients who have vastly varied Databases (some SQL, some oracle, some something else that I've never heard of and didn't bother to remember the name of)
Now, from what I understand, ODBC is old, and was/is the standard. And now OleDB has come along and... is... different? but accomplishes the same thing (it talks to databases)
Why would I want to use one over the other? ODBC is (according to the above post) cross-platform, which is good, but he offers very little information as to what OleDB offers that ODBC does not.
In my other research, I've found (on the MSDN forums) People saying "use OleDB if you can, if you have to, resort to ODBC" Naturally, three's no reasoning given for this, so I'd like to hear some.
ODBC is a C API for accessing databases. There is a standard for it, it is supported by every major database vendor, it is very well documented, it is cross-platform. OLEDB is a similar interface that uses Microsoft's COM technology instead of the C API. This means that it is only easily useable on platforms that support COM.
At the end of the day, both libraries provide roughly equivalent basic functionality. Indeed, Some OLEDB drivers actually make use of ODBC rather than native database libraries.
So, if you are C# developer, working on Windows, OLEDB is the obvious choice between the two. If you are using C (or C++ not using COM), or need cross-platform support, then ODBC is the better bet.
As a C# developer and because you are accessing many different datasources you should go with OLEDB. I copied the following from this white paper because it gives some hints what to use when:
OLE DB is Not a Replacement for ODBC
The ODBC technology and third-party market have matured to a point at which ODBC is an ideal technology for accessing SQL databases. As a result, an integral part of OLE DB is a new OLE DB driver manager that enables OLE DB consumers to talk to ODBC providers. The following information can guide your choice of which technology to use:
If you are accessing standard relational databases from a non-OLE environment, ODBC is the best choice.
If you want to expose a data interface to non-SQL data, OLE DB is the best choice.
If you are programming in an OLE environment, OLE DB is the best choice.
If want to build interoperable database components, OLE DB is the only choice.
If you're programming in C#, you will not directly use either one. You'll use ADO.NET in some form.
True, the provider that you specify in your connection string may turn out to be an ODBC provider or an OleDB provider, but this will not matter to your code. ADO.NET will both APIs from your view.
Related
From Database Management Systems, by Raghu Ramakrishnan, Johannes Gehrk
In contrast to Embedded SQL, ODBC and JDBC allow a single
executable to access different DBMSs without recompilation.
Thus, while Embedded SQL is DBMS-independent only at the source
code level, applications using ODBC or JDBC are DBMS-independent
at the source code level and at the level of the executable.
An application which uses JDBC can access only DBMSs specified in source code. So I was wondering what it means by
"ODBC and JDBC allow a single executable to access different DBMSs without recompilation"?
DBMS-independent "at the source code level" and "at the level of the executable"?
Both ODBC and JDBC are DBMS-agnostic APIs. You do not need to know anything about the eventual target DBMS, when writing ODBC or JDBC applications — in fact, those target DBMS may not even exist yet!
With ODBC- or JDBC-compliant applications, changing the target DBMS is as simple as changing the ODBC DSN or JDBC URL for the connection.
Many application developers do create DBMS-specific applications using ODBC or JDBC as their data access mechanism, by ignoring the DBMS-agnostic aspects of the ODBC and JDBC APIs, and instead choosing to use DBMS-specific SQL dialects.
Because of this specificity, these applications are not actually ODBC-/JDBC-compliant, though they are often presented as such.
You said —
An application which uses JDBC can access only DBMSs specified in source code.
This is absolutely not the case. I suggest you read further, starting with the links I included above.
While using JDBC, you typically define the database using configuration of database url, username and password. So you really need not recompile and only switching the configuration you can connect e.g. to development and production DB.
While compiling the JDBC program the database is not accessed, it could be the database even doesn't exists at the time of the compilation.
Contrary in embedded SQL such as SQLJ (I'm not sure how much embedded SQL is relevant now; SQLJ has anyway 37 tagged questions on SO) while compiling the database is accessed to check the relevant tables etc - see here.
So switching to other DB (or even after structure changes in the same DB) the program must be recompiled.
This is my interpretation what the quote try to say. Let me conclude that under DBMS-independence is typically meant a possible switch between different DBMS (such as Oracle and MySQL), which is definitively not relevant in this context.
we have an applcation of some size (about 1MLOC) that were started back in the days when BDE was just about to be deprecated. Nowadays we only use it to connect to SQL Server using ODBC. It has worked surprisingly well in spite of its deprecated status, and chances are it will keep on working for another 15 years. However, no one knows if or when it stops working. And if it stops, Embarcadero wouldn't be able to do much about it. So, it's a timebomb, and we need to replace it. But with what?
The ADO-components in Delphi looks promising. There are table and query components that resembles the BDE-components, and they are not third-party components made by a one-man shop that might loose interest. We also look forward to use connection-strings instead of the clunky ODBC-Administrator.
However, about a year ago Microsoft announced that OLE DB is deprecated, and for native development we should use SQL Server Native Client ODBC driver.
So, my qestion is, is the ADO-components in Delphi hardwired to OLD DB? Or would we not be using OLE DB if we select "SQL Server Native Client" in the list of drivers?
I expect/fear that to make use of the SQL Server Native Client ODBC driver, we have to set up a datasource in ODBC-Adminstrator, like we do now. Or is it possible to connect with ODBC using connection-strings?
And what Delphi-components exists that can connect to ODBC without using OLE DB?
Yes, I know about dbExpress, but it looks like it would take us years to convert to it from BDE.
Thanks,
LandShark
We had a similar migration need 5 years ago and did quite a bit of research and testing on it. The easiest migration path from the BDE is to SDAC from devart (http://www.devart.com/sdac/). Devart has a BDE replacement utility that goes through your code and replaces the BDE components with equivalent SDAC components. It will get you about 90% of the way there then you have to manually make some changes to get everything to work (e.g., if you use fetchall, have to comment out all the fetchall code - but you will see a pattern and can fix the remaining code mostly through search and replace). Performance of the SDAC components is excellent, they support all the sql server calls and you can use encrypted connections over the internet. The components support Native SQL or OLEDB connections to SQL Server. They also work in detached mode using cached updates. Another option, if you plan on supporting other database platforms in addition to SQL server is to use UniDac - it's just like SDAC but will work with SQL Server, Oracle and others - very similar to the old BDE without the overhead.
1) "native connection" does not mean use of ODBC or OLE DB, nor BDE and DBX. Native connection mean using special library that only can connect to MS SQL and that does not uses any standard server-agnostic pipileines. Contrary BDE and DBX and ADO and ODBC are generic libraries providing connection to any server you'd install plugin for.
Generally native libraries provide you closer integration with server and use of some features that generic libraries may miss (like events in firebird/interbase servers). They can also work faster for they do not need to transcode data streams and commands to/from the pipeline public API standards.
Public interfaces OTOH aid you with easier switch of servers and easier development of server-agnostic application.
2) Why do you think that BDE -> DBX conversion would be any harder than BDE -> ODBC or BDE -> ADO or BDE-> whatever ? The conversion is the conversion. ADO also has its share of limitations and gotcha's like DBX and like any other library.
3) DBX have MS SQL plugin. DevArt offers their suit of DBX plugins and may provide better one than stock Delphi DBX MS SQL support. Or maybe not.
4) Aside of those there are few well-known server-agnostic libraries
ZeosLib - FLOSS but have poor support for recent Delphi versions. Eternal alpha.
AnyDAC - http://www.da-soft.com/anydac , commercial, well-known
UniDAC - http://www.devart.com/unidac , commercial, well-known
5) you can have a lot of direct ODBC connection on any component collector site like http://www.torry.net/pages.php?id=570
6) same for native MS SQL connectivity http://www.torry.net/pages.php?id=1513
However, evaluating those choices and making your decision requires inside context knowledge that only you can have.
We had the same problem a few years ago. I suppose if there would be a perfect solution then there wouldn't be that many alternatives.
Anyway, we switched from BDE + ODBC to ADO + SQLOLEDB. The main reasons was that it was very reliable, easy to convert, didn't require anything extra to be installed on customer computers (such as BDE) and was faster than others shipped with delphi, including DBX (when using DisableControls).
Also as a side remark, if you want to use ODBC to configure the connection, you can use the ODBC manager to configure the values but read them from the registry and connect directly without ODBC. That helped us to do the switch.
If I have my own DBMS and am developing to ODBC software interface, what would I be working on?
making sure that one can access data from any database through my DBMS, OR
making sure that every database can access data from my database
I did not exactly understand this from the Wikipedia page.
In general, ODBC is the "catchall" driver, meant to work with a wide variety of databases at a basic (lowest common denominator) level. A wide variety of software contains ODBC drivers, so supporting ODBC means providing support for a wide variety of software.
In actual practice, it is more common now to use native drivers for Oracle, SQL Server, etc. ODBC is generally used only when there is no other alternative available.
If you're developing a DBMS I would expect that 'developing to ODBC software interface' means you're creating an ODBC driver. That driver allows applications to query your database, even if they don't know about your particular DBMS. If you like applications such as Excel to use your DBMS, provide an ODBC driver.
I suppose your DBMS could act as a "client" and use another DBMS' ODBC interface to get data or schema information, that doesn't sound like a typical DBMS feature.
The Microsoft link in the Wikipedia article is a bit clearer in my opinion, MSDN has details in you're really interested in developing a driver or a client.
I'm looking for suggestions as well as any benchmarks or observations people have. We are looking to rewrite our data access layer and are trying to decide between native C++ OLEDB or ADO.NET for connecting with databases. Currently we are specifically targeting Oracle which would mean we would use the Oracle OLE DB provider and the ODP.NET.
Requirements:
1. All applications will be in managed code so using native C++ OLEDB would require C++/CLI to work (no PInvoke way to slow).
2. Application must work with multiple databases in the future, currently just targeting Oracle specifically.
Question:
1. Would it be more performant to use ADO.NET to accomplish this or use native C++ OLE DB wrapped in a Managed C++ interface for managed code to access?
Any ideas, or help or places to look on the web would be greatly appreciated.
I don’t think it is possible to give a single answer that is generally applicable in this situation considering the fact that you are wanting a general solution for more than just Oracle. The problem is that one vendor’s .NET provider might be faster than their OLE DB provider and vice versa for another vendor. The architecture of both of those data access technologies is significantly different.
My gut feel is that the speed differences would not be that great, though. Since it sounds like you would put your own data access layer on top of OLE DB, it is hard compare directly until you wrote that. But in general, any data modification statement (e.g., UPDATE mytable set…) probably is not going to be all that different in either case. With both technologies, you specify parameter data if appropriate and then send the command to the server. The bulk of the cost is likely going to be network latency and server execution times. The biggest difference would probably come into play when reading data sets.
Reading the data is going to be the factor that could show a difference in speed. Depending on what you are planning, you may want to read the data at a low level. For example, with OLE DB, you may call IRowset::GetNextRows. With .NET, you would maybe read through the data sets via DbDataReader::Read(). I don’t know if it is typical, but in the code I worked on, the OLE DB GetNextRows() method was much more complex than the .NET Read() implementation. I am not sure if that necessarily translates to slower execution … but it might.
In my opinion, the best choice would be to use ADO.NET. Since it is Microsoft's current data access technology, I suspect that vendors will update their .NET provider more often than their OLE DB provider. So if there are performance problems in implementation, the .NET provider is likely going to be fixed while their OLE DB provider may not be fixed as promptly (or at all). Also, you get a lot more flexibility with the .NET provider if you need it (e.g., entity framework). If you want that with OLE DB, you are going to need to use the .NET provider for OLE DB providers, which is another layer on top of OLE DB (assuming it would even work, which I do not know).
We have a system written in C and running under Solaris & Linux that uses the Sybase CT-library to access a Sybase database.
We generate the table-definitions, indexes, stored procedures and C-code from an in-house developed DDL to reduce the amount of work and errors.
We would like to achieve database independence, so we can add (as a first start) Oracle support.
We're thinking about ODBC or ESQL/C, but having no experience with them.
What solution would you suggest (preferably a cheap and easy one, of course). Is it possible to have a single source solution?
I would highly recommend SQLAPI++ (with the downside, perhaps, that it is a C++ library). There is also unixODBC, though I have never used it in code -- only touched upon it while researching for portable database APIs. POCO also provides a uniform, portable API (though, again, in C++) for database operations, but last I checked it, that part of POCO was only in the initial stages of development.
ODBC will help you write a more portable system, but you will have to be careful to develop your SQL properly if you wish to leverage the underlying database, as the SQL itself may well not be 100% portable across databases, even with the different ODBC drivers.
iodbc
http://www.firstsql.com/iodbc/
or unix odbc
http://www.unixodbc.org/
Are probably among the "most portable" choices.
Regards
Friedrich
ODBC is going to give you far more portability options over ESQL/C.
I've been using iODBC to access SQL Server and mysql and have had pretty good results so far. I think it would work for Oracle as well, but that would depend on the ODBC driver and haven't had to try it so far.