Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1058
  • Last Modified:

Difference between RDO AND DAO and much more

Can you list out the differences between RDO AND DAO AND DAO DIRECT. ADVANTAGES AND DISADVANTAGES.


Can you list out the advantages/disadvantages of OPTIMISTIC AND PESSIMISTIC LOCKING OF ROWS  with an illustration.

How many tables are allowed in linking for a query in crystal reports 4.5 version.

How to execute Stored Procedure from VB.

What is the difference between Activex Components and Activex Controls and Activex Documents.

What do you mean by "SQL PASS THRU QUERY " . In what situation you encounter this case , Give an illustration of the above case.
1 Solution
Hi, I got this for you.

Data Access Essentials

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

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.

DAO (Data Access Objects)

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


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.

RDO (Remote Data Objects)

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.

ADO (ActiveX Data Objects)

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.

So what do I do?

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.

MSDN Online News Editor.
FavouritesAuthor Commented:
The answer what I want is not the history of DAO and RDO, but instead a straight (point blank) answer to my queries esp. in interview point what would you say if these questions are posted to you,ie more in simplified technical means with an illustration would clear my doubts.
Anyway thanks a111a111a11 for your answer.
I need not know it in very generic terms, I need in a very specific manner/answer.

Although RDO has the capability to execute stored procedures that return parameters, DAO does not. It is possible to run these stored procedures with a little bit of creative SQL.

You can use Data Access Objects to manipulate databases in either the native Jet database engine .MDB format or in other installable ISAM database formats, including Fox, dBASE, Excel, Btrieve, Paradox, and delimited Text.
In addition, you can use the Microsoft Jet database engine to access Microsoft SQL Server and any other database that can be accessed with an ODBC driver using the same DAO code.
According to the online help, the Remote Data Object model is defined as follows:
With RDO and the RemoteData control, your applications can access ODBC data sources without using a local query processor. This can mean significantly higher performance and more flexibility when accessing remote database engines. Although you can access any ODBC data source with RDO and the RemoteData control, these features are designed to take advantage of database servers, like Microsoft SQL Server and Oracle, that use
sophisticated query engines.
By using RDO, you can create simple cursor-less result sets, or more complex cursors. You can also run queries that return any number of result sets, or execute stored procedures that return result sets with or without output parameters and return values. You can limit the number of rows returned and monitor all of the messages and errors generated by the remote data source without compromising the executing query. RDO also permits either synchronous or asynchronous operation so your application doesn't
need to be blocked while lengthy queries are executed.
The following are differences between DAO and RDO:
 - The DAO model is used for ISAM, Access and ODBC databases. The RDO model is designed for ODBC databases only, and it has been optimized for Microsoft SQL Server 6.0 and Oracle.
 - The RDO model can have better performance, with the processing being done by the server and not the local machine. Some processing is done locally with the DAO model, so performance may not be as good.
 - The DAO model uses the Jet Engine. The RDO model does not use Jet Engine, it uses the ODBC backend engine.
 - The RDO model has the capability to perform synchronous or asynchronous queries. The DAO model has limitations in performing these type of queries.
 - The RDO model can perform complex cursors, which are limited in the DAO model.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now