Norvin Leach
MSDN Online News Editor
October 13, 1997
Last week I got mail from a developer who complained about our confusing array of acronyms referring to data access—ADO, RDO, DAO. Yup, there sure are a lot of them. But this is an area that will be strategically vital to you, wherever you work, so it's important that we make things clear.
Our world has a problem with data access. All the big database vendors—Microsoft, IBM, Oracle—recognize this. There's too much information out there, spread out over too many types of databases.
Companies like IBM and Oracle say that the solution is to move everything into a single database structure. Nice ideal, but we don't think that's practical. Instead, we want to provide a common way to get at data stored in different formats. We want to focus on the access rather than on the database. This means you can use the same front end to access a relational database, a mainframe database, an Excel spreadsheet, and a text document, all stored in different places.
We're going to do this through ADO and OLE DB. You've heard of them before, as part of our Universal Data Access strategy, but I think we need to show how they evolved from all of our other data access strategies. This is particularly important, because there's a compatibility gap between the current favorite interface (RDO) and the next generation (ADO). If you understand the history, you'll have a better idea of when, how, and if you should shift your code from RDO to ADO.
What I want to do here is run through the history of the relevant data access technologies over the past six years, one by one. (For you purists, yes, I'm skipping a few, like ESQL C.)
This was an old interface between VB and SQL Server. It was built on the C-based DB Library, which comes from the days when we were working with Sybase on SQL Server. It'll work with the upcoming version of SQL Server, but it won't support the new features. If you're using this, it's time to move on. The same applies to DB Library itself.
ODBC is probably the most widely used interface to relational data. It gives you widespread access, but it's a low-level interface, and you pay for access with more complex applications. Also, it's not good for getting to nonrelational data. We've found that developers generally prefer to access ODBC through higher-level object interfaces such as DAO, ODBCDirect, RDO, or ADO.
This was our first object-based interface, introduced in Visual Basic. It encapsulated functions of Jet, the Access database engine. It also let you create data-bound, or data-aware, controls. Millions of people use this today. Its only drawback is lack of scalability. It accesses SQL data through Jet, which adds overhead.
This is a variation on DAO that lets you get to ODBC without going through the Jet database engine—it really just uses RDO, with DAO object names.
This was a tight, lightweight interface to ODBC that we introduced a couple of years ago. It was patterned after the DAO object model, and made it easier for developers to get at the low-level power of ODBC. While it's very popular for SQL Server access, it's limited in its ability to get at Jet or ISAM data. Also, it can only access relational databases through existing ODBC drivers. We're moving beyond RDO, but if you have an RDO application that works well today, there's no reason to change it. I'll talk a little more about this later.
Welcome to our paradigm. This is the gateway to our Universal Data Access model. It's a low-level object-based interface that's not restricted to relational data, ISAM, Jet or anything. It can deal with any type of information. It's also something that you'll rarely encounter directly, unless you develop data stores or database engines. You'll access it through ADO, and will talk to a data store through an OLE DB provider.
This is the application-level interface to OLE-DB. It looks like RDO and DAO (in other words, it has a similar object model, so you can learn it fairly easily), but will be a superset of those technologies. You can use it to get at data through OLE DB service providers as well as existing ODBC drivers through the OLE DB for ODBC interface. It's the future. It gives you much broader access than any of our other interfaces, and we recommend that you start using this technology for future projects. There's only one problem. It's not backward compatible with RDO. It's similar, so you can learn it quickly, but you won't be able to mix your code.
It won't be a snap to convert RDO code to ADO, but it's not rocket science either. Don't convert if you don't have to, but don't be afraid of learning a new skill. If you have RDO applications that are running today, just let them run. We will continue to support RDO. This will suffice for most existing applications. But in the future, start looking at ADO as the preferred way of accessing data. If you must convert your code from RDO to ADO, we'll be providing guidelines for doing that. They're not ready yet—this is still next year's technology. But MSDN Online will let you know when they're posted.
For more information today, check our Universal Data Access Web site(http://www.microsoft.com/data/).
Comments? Send them to me.