Choosing a Data Access Strategy

There are a number of questions to consider as you choose a data access technology:

Is this a new design or a modification to an existing application using "old" data access technology? For a modification, it's tempting to continue with the application's old data access methods. For the immediate future, this seems like a reasonable and cost-effective decision. However, the downside is programming difficulty as the application stretches toward new and different data sources, and eventual obsolescence. For a new design, you should use ADO.
Where is the data? Is it on the Web, on a remote server, or simply stored locally on the user's system? If the data is simply stored on the user's local system, the need to build a separate server to manage it might be considered overkill. If the data is remote, what about connection management? What happens when your application cannot connect? Should you be using an asynchronous data access technology such as ADO or RDO?
What are the developers trained to use? Do they already have experience with ADO, RDO, DAO, or ODBC? Is it worth the modest one-time cost and effort to train the entire staff to use ADO? If you begin using ADO, can you reasonably anticipate a maintenance cost reduction in the near future?
Does your application require data access to both relational and nonrelational data sources? Do you have an OLE DB provider for each? If so, you should use ADO.
Are you planning to use Microsoft^® Transaction Server (MTS)? If this is the case, you need to choose one of the data access technologies that can be executed on the server and act as a "resource manager" (an MTS term for a component that implements its set of resource manager interfaces). For example, ADO, RDO, and ODBC can act as MTS resource managers. The DAO interface is not capable of being a resource manager. You should also consider if the component must be thread safe (such as with ADO and RDO), since this is a requirement for most MTS-managed components if you expect reasonable resource use and performance.
Does every application already use the ODBC API? If you continue with ODBC, how will your application access other kinds of data sources in the future?

You can use the differing data access technologies to implement many useful data access and application communication strategies. These are listed in the following table.

Your best choice is…	If your application requires…	Remarks
ADO	Mainframe data or program communications.	With Microsoft^® SNA Server, you can set up OLE DB data providers for mainframe data sources such as VSAM, CICS, IMS, and AS/400 files.
	Reengineering.	For existing applications, you should consider reengineering with ADO. As an alternative, you could continue with previous data access methods.
	New development.	For all new development you should use Microsoft's ADO data access technology.
	Uniform access to a variety of data sources and data types.	ADO is a common interface for all data access requirements.
	Fast development.	ADO helps minimize development cost because it is uniform, consistent, and easy to use. You can train your developers once and benefit continuously thereafter.
	High performance.	ADO is very fast.
	Internet Information Server's (IIS) Active Server Pages (ASP).	If your application uses IIS with ASP to generate browser-independent HTML from databases, you must use ADO.
OLE DB	Custom file access.	You can write custom OLE DB data providers for virtually any data source. You can then use ADO as the data access technology.
RDO	Fast access to existing ODBC data.	RDO is very fast.
ODBCDirect	Access to ODBC data.	ODBCDirect provides a performance improvement over the older DAO data access technology.
DAO	Enhancements to existing DAO data access.	DAO provides a consistent programming model for situations where some of the data access services must be provided using Microsoft Jet. If you already have large amounts of DAO code, and are willing to overlook the design, coding, and performance benefits provided by ADO, there's no reason to change it.
	Running within a 16-bit environment.	DAO is the only choice.
ODBC	Fast access to existing ODBC data.	If you're willing to develop and maintain complex code using the ODBC API, this is a good choice.