Connect Access to SQL Server

Using ODBC driver or OLE DB provider

Connection strings have been around a long time. You can define a formatted connection string either in the Access user interface or in VBA code. A connection string (whether ODBC or OLE DB) passes information directly to the database, such as server location, database name, type of security, and other useful options. For example:

ODBC;DRIVER=SQL Server;SERVER="MyServer";DATABASE="MyHRdb";TRUSTED_CONNECTION=Yes

Provider=SQLOLEDB;Data Source=MyServer;Initial Catalog=MyHRdb; Integrated Security=SSPI;

At first, there was SQL Server Native Client (SNAC) a stand-alone library that contained ODBC and OLEDB technologies and is still available for SQL Server versions 2005 through 2012. Many legacy applications used SNAC and it is still supported for backward compatibility, but we don't recommend using it for new application development. You should use later individual, downloadable versions of the ODBC drivers.

ODBC drivers

Open Database Connectivity (ODBC) is a protocol that you use to connect an Access database to an external data source such as Microsoft SQL Server. Typically, you use file data sources (also called DSN files) to add a connection string, in which case, the FILEDSN keyword is used on the connection string, or stored in the registry, in which case, the DSN keyword is used. Alternatively, you can use VBA to set these properties using a "DSN-less" connection string.

Over the years, ODBC drivers have shipped in three phases:

• Prior to 2005, ODBC drivers shipped with Windows Data Access Components (WDAC), which originally was called Microsoft Data Access Components (MDAC). These components still ship with Windows for backward compatibility. For more information, see Microsoft or Windows Data Access Components.

• ODBC drivers shipped with SNAC for SQL Server 2005 through SQL Server 2012.

• After SQL Server 2012, ODBC Drivers have shipped individually and contain support for new SQL Server features.

For new development, avoid using ODBC drivers from the first two phases, and use ODBC drivers from the third phase.

OLE DB providers

Object Linking and Embedding, Database (OLE DB) is a more recent protocol that you use to connect an Access database to an external data source such as Microsoft SQL Server. OLE DB does not require a DSN and also provides full access to ODBC data sources and ODBC drivers.

Tip    Typically, you use the Data Link Properties dialog box to add an OLE DB connection string. Although there is no way from Access to open the Data Link Properties dialog box, in Windows Explorer, you can create an empty .txt file, change the file type to .udl, and then double-click the file. After you create a connection string, change the file type back to .txt.

Over the years, OLE DB providers have shipped in three phases:

• Prior to 2005, OLE DB providers shipped with Windows Data Access Components (WDAC), which originally was called Microsoft Data Access Components (MDAC).

• OLE DB providers shipped with SQL Server 2005 through SQL Server 2017. It was deprecated in 2011.

• In 2017, the SQL Server OLE DB provider was un-deprecated.

The currently recommended version for new solution development is OLE DB Driver 18 for SQL Server.

How to optimize performance with an ODBC connection string

To optimize performance, minimize network traffic, and reduce multi-user access to the SQL Server database, use as few connection strings as possible by sharing connection strings over multiple record sets. Although Ace simply passes on a connection string to the server, it does understand and use the following keywords: DSN, DATABASE, UID, PWD, and DRIVER to help minimize client/server communication.

Note    If an ODBC connection to an external data source is lost, Access automatically tries to reconnect to it. If the retry is successful, you can continue working. If the retry fails, you can still work with objects that don’t rely on the connection. To reconnect, close and re-open Access.

Recommendations when using both ODBC and OLE DB

Avoid mixing connection string and database access technologies. Use an ODBC connection string for DAO. Use an OLE DB connection string for ADO. If your application contains VBA code that uses both DAO and ADO, then use the ODBC driver for DAO and the OLE DB provider for ADO. Strive to get the latest feature and supports for both ODBC and OLEDB respectively.

ODBC uses the term driver and OLE DB uses the term provider. The terms describe the same type of software component but are not interchangeable in connection string syntax. Use the correct value as documented.

Top of Page

Programmatically interface to SQL Server from Access

There are two main ways to programmatically interface to an SQL Server database from Access.

DAO

A data access object (DAO) provides an abstract interface to a database. Microsoft Data Access Objects (DAO) is the native programming object model that lets you get at the heart of Access and SQL Server to create, delete, modify, and list objects, tables, fields, indexes, relations, queries, properties, and external databases.

For more information, see Microsoft Data Access Objects reference.

ADO

ActiveX Data Objects (ADO) provides a high-level programming model and is available in Access by a reference to a third party library. ADO is straightforward to learn and enables client applications to access and manipulate data from a variety of sources, including Access and SQL Server. Its primary benefits are ease of use, high speed, low memory overhead, and a small disk footprint. ADO also supports key features for building and Web-based applications.

For more information, see Microsoft ActiveX Data Objects reference and Microsoft ActiveX Data Objects (ADO).

Which one should you use?

In an Access solution that uses VBA code, you can use DAO, ADO or both as your database interface technology. DAO continues to be the default in Access. For example, all forms and reports and Access queries use DAO. But when you migrate to SQL Server, consider using ADO to make your solution more efficient. Here are general guidelines to help you decide when to use DAO or ADO.

Use DAO when you want to:

• Create a read/write, bound form without using VBA.

• Query local tables.

• Download data into temporary tables.

• Use pass-through queries as data sources for reports or forms in read-only mode.

• Define and use a TableDef or Querydef object in VBA.

Use ADO when you want to:

• Leverage extra ways to optimize, such as performing asynchronous operations.

• Run DDL and DML pass-through queries.

• Get to SQL Server data directly through recordsets in VBA.

• Write simpler code for certain tasks, such as streaming of Blobs.

• Call a stored procedure directly, with parameters, using a command object in VBA.

Top of Page

Summary of ODBC driver versions

The following table summarize important information about ODBC driver versions, download locations, and feature support. Make sure you use the correct bit version (64-bit or 32-bit) of the driver based on Windows and not Office. If you are running 32-bit Access on 64-bit Windows, install 64-bit drivers, which includes the 32-bit components needed for Access.

For more information, see Using Connection String Keywords with SQL Server Native Client, Release Notes for ODBC to SQL Server on Windows (V17), and Features of the Microsoft ODBC Driver for SQL Server on Windows (V13, 11).

Top of Page

Summary of OLE DB provider versions

The following table summarize important information about OLE DB providers versions, download locations, and feature support. Make sure you use the correct bit version (64-bit or 32-bit) of the driver based on Windows and not Office. If you are running 32-bit Access on 64-bit Windows, install 64-bit drivers, which includes the 32-bit components needed for Access.

For more information, see Using Connection String Keywords with SQL Server Native Client.

Top of Page

ODBC keyword summary

The following table summarizes the ODBC keywords recognized by SQL Server and their purpose. Only a subset are recognized by Access.

Top of Page

OLE DB keyword summary

The following table summarizes OLE DB keywords recognized by SQL Server and their purpose. Only a subset are recognized by Access.

Top of Page