Upgrading and Converting to Access 2010 : TO CONVERT OR TO ENABLE

You have several things to consider when deciding whether to convert an application to the Access ACCDB file format. The primary reason to convert is to take advantage of the new features that require the ACCDB file format, such as the ability to work with complex data, the ease of collecting data from e-mail forms, linking to SharePoint Services, and creating Web applications.

To support some of the features added in Access 2007 and 2010, there are several new system tables that may or may not be used within an ACCDB file. Along with the new benefits, there are also limitations, such as the fact that the ACCDB file cannot be linked to by an MDB file, does not support replication, and does not support user-level security as was available in prior versions. However, Access 2010 continues to support MDB file format natively. Thus, an Access 2010 MDB will support several new features as long as the features do not depend on the file format — we'll discuss this shortly. If you are working in a mixed version environment, you will want to be mindful that although an ACCDB file can link to or import from an MDB file, the opposite is not true.

1. Common Terminology

Words such as "upgrade," "migrate," "convert," and "enable" are sometimes used interchangeably.

• Upgrade: You have Office and Access 2010 instead of some prior version. And, with purchases, "upgrade" is often associated with a discount based on owning a prior version. With this release, some of the documentation uses "upgrade" synonymously with "converting".

• Migrate: The process of converting or moving applications from earlier versions so that they can be used with newer versions of Access — in this case, Access 2010. It applies to scenarios in which you will be using Access 2010 and have some Access applications that were created in previous versions.

• Convert: The specific process that Access runs to change the database format from one version to another. Converting allows you to work with the database objects and to utilize the features of the specified version of Access, so by converting to the ACCDB format, your older applications can be enhanced to take advantage of new features.

• Enable: Enabling allows a newer version of Access to open a database created by a previous version of Access, but it does not change the file format. Access 2010 can work directly with Access 2000 and 2002−2003 file formats, and pre-95 formats must be converted, so only Access 95's or 97's format databases may be enabled. In some situations, the need to allow older versions of Access to use the database makes enabling the practical choice. F

2. Key Decision Factors

Now that we have established some common terminology, we can focus on the key factors for making the decisions about whether, when, and how to enable and/or convert. A pivotal factor is whether the situation involves multiple versions of Access sharing the same data file or using the same application. Other key issues to consider include:

• Will any new features from Access 2010 be incorporated into the application and will they need to be instantly available to all users? This was specifically worded to prompt consideration for situations where migration may proceed in stages that allow strategically timed deployment of the Access 2010 version by groups or by selected individuals.

• What file types do you have and what do you need? Will those files be converted to newer formats or do you need to keep the current formats for compatibility with older versions? For example, if you have an MDE file, you will need to use the original MDB format to convert the file.

• Are you working with user and group level security and using an MDW file?

• If the database is split, what version is the original application in, and what version is the data file?

• What time and resources are required to test and convert the applications? A quick cost/benefit analysis can help determine if it is appropriate, let alone necessary, to convert.

For the most part, it is straightforward to either enable or convert a legacy Access database to an Access ACCDB format. However, the process may involve additional steps if you need to accommodate features that are no longer available in the ACCDB format, notably user-level security and replication. Moving to the ACCDB format may necessitate developing a new approach that replaces the functionality provided by either of those features. Some of the alternatives may provide significant benefits in other areas, such as when using Sharepoint Services to replace replication or using 2010 data encryption features for securing data instead of User-Level Security.

A few other features are not supported in Access 2010, such as the calendar control and Data Access Pages. Toolbars are not available unless specifically configured in the startup options. These types of issues are covered in more detail later.

Barring the reliance on the few features that are no longer supported by Access 2010, an evaluation of the tradeoffs typically endorses the effort to convert. If you are considering some of the costs and time associated with rolling out a new version over a large user base, you have several options that include a mix of status quo such as enabling (running applications unchanged as MDB format) and converting.

If you are involved with making the decisions about migrating or staying with earlier versions of Access, we recommend that you carefully evaluate the benefits that you will gain by using Access 2010's new features and weigh that against the functionality that you might loose if you are relying on features that are no longer supported in 2010. You will also need to look at the big picture, including the costs associated with the purchase and with converting files (both application and data files), and also consider the issues associated with file compatibility. There can be significant tradeoffs whether you convert, maintain legacy file formats, or use a combination of both.

Microsoft has also provided a tool to help evaluate and plan the migration process, the Office Migration Planning Manager (OMPM). The OMPM identifies and provides information about the databases on a network. It lists the files, their locations, format, size, and even the number of objects. If you are converting from Access 97, the OMPM will also identify some of the common issues that may be encountered. To get more information about the OMPM, visit Microsoft's TechNet site or search on Microsoft.com.

3. Feature Sets and File Extensions: What's New, What's Replaced, What Happens

Obviously, in a controlled environment where everyone will be using Access 2010, it would be a shame to not convert databases from earlier versions so that everyone can take advantage of the new features of the ACCDB file format as well the new features offered in Access 2010. Beyond the mentioned issues of replication, user level security, and Data Access Pages, even large complex applications with large amounts of VBA code should run without issues or problems when you convert these applications to the new ACCDB format.

Features such as embedded macros, the new picture control, and report layouts with live data will significantly empower and improve the productivity of users. If people are already using the new Office Ribbon in Word and other programs, they will appreciate the consistency of using it in Access as well.

For applications heavily dependent upon user/group permissions or replication, it is best to establish and test a migration plan before attempting to convert in-service applications. Keep in mind that you will need to replace deprecated features such as Data Access Pages and the ActiveX calendar control.

In addition to Access 2010's capability to open and even make design changes to 2000 and 2002−2003 MDB file formats, it can also convert an ACCDB "back" to the earlier MDB file formats. With 2010, you can specify the file type so that it will work with the version of Access that will be opening it. However depending on which (new) features are present in the ACCDB file, Access will either convert and silently discard the unsupported features or it will provide an error message and abort the conversion process.

With dozens of new features, it is reassuring to know that MDB files will, for the most part, work as expected. The majority of the new features will be quietly ignored or will not appear when an Access 2010 MDB file is opened with an earlier version of Access.

3.1. File Extensions

Office Access 2010 supports and leverages the new file extensions that were introduced in Access 2007. For backward compatibility, Access 2010 continues to be able to use nearly all of the file extensions, including: .accdb, .accde, .accdt, .accdr, .laacdb, .ldb, .mdw, .mdb, .mde, and .adp. You probably recognize the meaning of each of these extensions, so we'll just mention two of the newer ones.

The .accdt file extension indicates a template. Developers can convert .accdb to .accdt. In 2007, developers had to download a separate add-in, Access Developer Extensions (ADE), but this is now included in 2010 natively. Changing an Access 2010 file's extension from .accdb to .accdr will cause the file to act as though it is in runtime mode — so users are unable to make design changes. However, all it takes is changing the extension back to .accdb and the design privileges are returned. So don't let this give you a false sense of protection. You can review the Access Help or MSDN for a complete list of file extensions and their effects on the file.

3.2. New Features Available Only with ACCDB File Format

The following features are available when using the ACCDB file format but are not accessible in an MDB file. If an MDB file is converted to an ACCDB file, these features become available:

• Attachment data type: New data type that provides efficient storage of binary streams which could be documents, pictures, or any kind of files.

• Append -only memo fields: Provides history of changes to memo field data; also integrates with the append-only text fields in a SharePoint list.

• Built-in integration with Microsoft Office SharePoint Server: 

• Encrypt with database password: Uses the Windows Crypto API to encrypt data.

• Linked tables to files in an ACCDB format: As in MDB format, we can link to other MDB files but not ACCDB files; ACCDB format allows us to link to both MDB and ACCDB formats.

• Multi-valued lookup fields: Also referred to as complex data fields.

• TempVars: Collection similar to global variables.

The following list details features that are available only in Access 2010 using the ACCDB file format. (Note that although the file will open in Access 2007, the features will not necessarily be available.)

• Access Services: Allows developers to author and publish Web applications (requires SharePoint 2010).

• Data macros: Create macros that runs based on when something changes in a table.

• Image Gallery: A pool of images that can be shared and used by several bound image controls.

• Navigation control: A new control that essentially combines a subform and tab control into a single control.

• Web browser control: Instead of using ActiveX control, we now have a native control that provides a frame into a Web browser and thus allows us to open a page right on the form.

• Web style buttons: Provide more formatting and customization options.

3.3. Access 2010 Is Based on 2007 File Format

As we mentioned earlier, Access 2007 and Access 2010 share the same file format (ACCDB). In fact, Access 2010 still refers to the .accdb file extension as "Access 2007 Database format" and there is no such thing as "Access 2010 Database format." However, Access 2010 has new features that are not available in Access 2007. The most significant change is that Access 2010 supports data macros and Web objects, and Access 2007 does not. If you attempt to open an ACCDB file that has Access 2010 data macros, Access 2007 (SP2 and later) will give you a message informing you that data macros are present, and the table will be opened as read-only in Access 2007. Because a data macro fires based on changes to the table, it will never fire for a read-only table.

3.4. Features Not Available with ACCDB Files

There are only a few features available in the MDB file format that the ACCDB file format does not support. Typically, this is because a more robust alternative has been provided. Although some of these features are still available if using an MDB format, others can be achieved only programmatically if at all. If you are relying on one of the deprecated features, it is likely that workarounds are, or will become, available.

The following features are no longer available, as of Access 2007:

• Designing Data Access Pages (DAPs)

• Microsoft Office XP Web Components

• Replication

• The UI for import and export in older formats

• User-Level Security and Workgroup Administrator

The following features are no longer available as of Access 2010:

• Calendar control (mscal.ocx)

• ISAM support, including Paradox, Lotus 1-2-3, and Jet 2.x or older

• Opening Data Access Pages (DAPs)

• Replication Conflict Viewer

• Snapshot format for report output

3.5. What Happens When a 2007/2010 MDB Is Opened by Prior Versions

Access 2010 and 2007 introduced a multitude of new features available to both the MDB and ACCDB file formats. When working with multiple versions of Access, it can be confusing to keep track of what will work for each version. The following table lists the new features and how they will behave in prior versions of Access. New features for Access 2007 or 2010 MDB files are also available for ACCDB files, but the reverse is not always true. Features that are available for ACCDB files but not for 2007 or 2010 MDB files are denoted by the statement "Not available to MDB files; only available in ACCDB file format."

2007/2010 NEW FEATURE	BEHAVIOR IN ACCESS 2000, 2002, AND 2003
ACCDB file format	Cannot be opened.
Access security and the Trust Center	Prompts with security warnings and does not have the capability to trust a file based on its location.
Add Existing Fields task pane	Field list floating dialog box.
Add new fields in Datasheet view	New fields must be created in table Design view.
Alternating row color (alternate Back Color property)	All rows appear the same color as the first row. Alternate Back Color property is ignored.
Append-only memo fields	Not available to MDB files; available only in ACCDB file format.
Attachments	Not available to MDB files; available only in ACCDB file format.
Complex data	Not available to MDB files; available only in ACCDB file format.
Control auto-resize and anchoring	Controls do not automatically resize or move.
Control layouts (stacked and tabular)	Behave like independent controls.
Create data collection e-mail	Older versions have no option to create or manage data collection e-mail.
Custom groups in the Navigation Pane	Navigation Pane converts to the database window, but custom groups are lost.
Database templates	Cannot be opened.
Datasheet user interface enhancements	Record selectors and selection.
Date picker	Does not appear.
Design in browse mode for forms and reports	Design via the Property Sheet only.
Edit list items command for combo boxes and list boxes	Does not appear.
Editable value lists	Value lists do not have a user interface for editing and are not automatically inherited from the table.
Encrypt with database password	Not available to MDB files; available only in ACCDB file format.
Filtering and sorting improvements	Previous filtering and sorting user interface.
Getting Started experience	Getting Started task pane.
Gridlines on layouts	No gridlines appear.
Improved accessibility	Datasheet, forms, and reports do not have the same support for accessibility aides.
Linked tables to ACCDBs	Cannot link to ACCDB files. Available only in ACCDB file format.
Linked tables to Excel 12 files (.xslx)	Linked tables to Excel 12 cannot be opened.
Linked tables to Windows SharePoint Services V3	Not all data types are fully supported. Some columns may be read-only or might not appear.
Macros embedded in event properties	Event properties appear to be blank instead of showing "[Embedded Macro]" and will not function.
Manage data collection replies	Does not appear.
Navigation Pane	Database container.
New Sorting and Grouping task pane	Sorting and grouping dialog box.
Access Options via the Backstage	Separate dialog boxes for Options, Startup, and AutoCorrect.
Offline support for Linked Tables to Windows SharePoint Services	MDBs cannot link to SharePoint tables. This is available in ACCDB file format only.
Property Sheet task pane	Property sheet floating dialog box.
Report Browse mode	Print Preview only.
Ribbon	Command bars.
Ribbon customizations	Do not appear.
Rich text	Appears as plain text with HTML tags.
Save Database As	Can convert to and from older file formats, but cannot convert to the newer 2007 file format.
Saved imports and exports	Only the import and export specifications supported in the older format will be converted and available.
Search box in record navigation user interface	Does not appear.
Share database on SharePoint	Does not appear.
SharePoint Site Manager	Does not appear.
Split views	Appears as a single item form.
Tabbed document mode (SDI)	Multiple windows (MDI).
Tables and Views mode	Does not appear.
Upsize database to SharePoint	Does not appear.

3.6. What Happens When a 2010 ACCDB Is Opened by 2007

As noted previously, Access 2010 uses the same file format as 2007 does. However, 2010 introduces several new features that may not be accessible by 2007 — not even in the ACCDB format. Depending on what the ACCDB file contains, Access 2007 may either work seamlessly with all of the features and objects, not be able to open the file at all, or be able to open the database but not use specific objects that were new in Access 2010. Generally speaking, a published Web database is not available to Access 2007, so it should be expected that Web objects would not be backward compatible even though there are few instances where 2007 can still open unpublished Web objects.

2010 NEW FEATURE	BEHAVIOR OF THE DATABASE IF OPENED IN ACCESS 2007 SP2
Access 2010 Encryption Compliance	The database will not open in Access 2007 SP2.
Application navigation control	The database opens, but forms that contain the Application navigation control do not open in Access 2007 SP2.
Application published to Access Services	When you create a Web database application using Access 2010 and publish it to a website, the database will not open in Access 2007 SP2. However, the backup file that is created during the publication process can be opened in Access 2007 SP2. And it remains that some Web objects cannot be modified in Access 2007 SP2.
Calculated Column	The database opens, but tables that contain Calculated Columns will not open in Access 2007 SP2. Forms or reports that reference a table that contain Calculated Columns can be opened and modified in Design view only.
Data Macro	The database opens, but tables that contain data macros are read-only. The user cannot enter data or modify the table using Access 2007 SP2. Forms or reports that reference a table that contains data macros can be opened and modified in Layout or Design view; however, data drawn from the table cannot be modified.
Database with Web objects	If the database contains Web objects that have not been published, it opens in Access 2007 SP2. However, some Web objects (ie, published ones) cannot be modified in Access 2007 SP2.[]
Linked tables with Connection strings that are longer than 512 characters	The database opens, but the linked tables with the long connection string cannot be opened in Access 2007 SP2.
New and updated database sort orders	The database will not open in Access 2007 SP2.
Web browser control	The database opens, but the forms that contain Web browser controls do not open in Access 2007 SP2.
[]

^[] Documentation, functionality and compatibility issues will continue to change, especially with major releases and service packs.

NOTE

When an ACCDB file contains any of the new 2010 features, it cannot be converted back into an MDB file. Similarly, even if an MDB file is opened in Access 2010, it will not be able to use new features that are specific to the ACCDB format.

4. Other Things to Consider

As with most projects, there are a lot of issues that you'll need to consider, such as converting a functional application, maintaining references, sharing data files, splitting databases, locking files, running multiple versions of Access, and new ways for working with various data sources.

Of course, there are situations that are not conducive to converting the file, such as when an application uses a feature that is not available with the ACCDB file format. If the replacement for the missing feature isn't an acceptable alternative, then the appropriate solution may be to enable the database. Keep in mind that it is acceptable to convert some applications and enable others. It is also feasible to use two versions of the same application; which allows some people to work with the converted file while others work with the original format. In that situation, the shared data files would need to remain in an MDB format compatible with the original application file. Regardless of other differences, you should compile the code before attempting to convert the file.

4.1. VBA References

Each version of Access has its own default VBA references. So when you change the file format, you should check the VBA references. By default, any Access applications will have at least four VBA references listed in the following order:

• Visual Basic for Applications

• Microsoft Access n.n Object Library

• OLE Automation

• Data Access Library(ies), as explained in the following list

Depending on which versions of Access the file was originally created under, the Data Access Libraries referenced may be:

• Microsoft Office n.n Access database engine Object Library

• Microsoft DAO n.n Object Library

• Microsoft ActiveX Data Objects n.n Library (aka ADO)

The n.n refers to the version of the library. For Microsoft Office libraries, the number will correspond to the version of Office. Thus, for an Access 2010 installation, the references will have "14.0" for n.n. Other libraries have different version numbering. For DAO and ADO, the latest versions are 3.6 and 6.0, respectively. You should also be aware that although Microsoft Office n.n Access database engine Object Library and Microsoft DAO n.n Object Library have different names, they are actually the same library, just a different version. You can choose either version, but you cannot have both versions; however, you can reference both DAO and ADO libraries within the same application. For simplicity, this section will refer to those libraries in general as the "Data Access Library."

Of the default references, the VBA and Microsoft Access Object Library can never be removed or modified by the user. And although you may remove the OLE Automation library and the data access library, doing so may break code, particularly if you remove the data access library. However, it may be desirable to change the data access library to the lowest version available to ensure that it will work uniformly across multiple versions of Access — given that all installations may not have the latest and newest version of the data access library. In a complex application, there may be additional references to extend the functionality — those will require the same care as working with data access libraries.

Normally, the VBA library and the Access Object Library will match the version of Access that is currently running. This is why having different versions of Access installed side-by-side on one computer will require a reconfiguration to update references each time a different version of Access is opened. Although all files inherit the applicable references from Access (see the previous list), the files retain their references to different versions of other libraries, including data access libraries.

NOTE

When working with multiple versions of Office, it is a good practice to validate and, if needed, repair references and test the database on the oldest version of Access, Office, and Windows that will use it.

Be aware that Access may update the references for a file that was opened in a different version of Access to be compatible with the currently running instance of Access. So, if you are working in an environment with multiple versions, it is a good habit to take a quick look and verify that the references are what you expect to see for the file. Blindly accepting the default does not guarantee that the code will work. There are also third party tools that are designed to manage side-by-side installations and make it easier to work with multiple versions of Access on the same computer.

If an application contains references to both DAO and ADO libraries in VBA code, it may be necessary to check the references and ensure that DAO is listed above ADO so that DAO will take precedence over ADO and thus avoid compilation errors. 

4.2. Shared Data Files

An ACCDB file can open and work with multiple data files and file formats, including those with ACCDB and MDB file formats. When linking to tables, it is important to remember that the data file must have the file format of the oldest version of Access that will open it. For MDB files that could be 2000, 2002−2003, or 2003 file formats — 95 and 97 are special cases. Access 2010 allows users to open previous files and save them in a specified file format.

4.3. Splitting a Database

Speaking of shared data files prompts a discussion of splitting the database, or moving the tables to their own file. It's not uncommon to initiate the database design with the tables in the same file as all the other objects. And although it works fine to keep it that way for small, single-user applications, it isn't advisable for larger applications or for multiple user applications. Although a combined (single-file) application can allow simultaneous use by multiple users, doing so can lead to significant performance and corruption issues. The easy way to avoid this is to split the database and have multiple front ends sharing one back-end data file.

Access 2010 can share files with earlier version of Access as long the file is saved as the earliest version's supported file formats. Be sure to create a copy of the file before initiating this process. The newly created back-end file will be in the same format as the original file, so if all users are moving to a newer version of Access, it can be helpful to convert the database first. However, if the data file will need to support an older version of Access, it is important to separate the tables before converting. The tables need to be in the format of the oldest version of Access that will use them. Splitting the database will not preserve password protection, so that would need to be added to the newly created back-end file if a password is desired.

NOTE

Splitting your databases is strongly recommended under all but the most simplistic single-user situations.

After the database has been split, it is reassuring to confirm that the tables are correctly linked. Two of the more common ways to identify the source data for a linked table is to hover over the table's name in the Navigation Pane and read the path from the control tip, or to use the Linked Table Manager.

Now, if you want to create multiple versions of the database application, you will be converting only the front end. You can convert the front-end file to whatever versions of Access that users will need. All of the front-end files can be linked to the back-end (data) file that was just created. 

If multiple versions of Access will be linked to the data file, the data file should be created in or converted to the oldest file format. And, you will want to use that same older version to run the periodic compact and repair on the data file. The application file cannot be from an older format version than the data file.

The capability to support multiple users sharing the same data file is the basis for some of the most powerful benefits that Access has to offer. However, it is a best practice to not share the front-end applications. An application file should only be available to one user at a time. This is an important point that is worth reiterating. An application (the front-end file) with simultaneous users will suffer both in performance and reliability, and it has an increased risk of experiencing data corruption.

4.4. Working with SQL Server

As in the past, Access 2010 continues to support integration with SQL Server, both by linking to a SQL Server database or by creating Access Data Projects (ADP). Access 2007 and 2010 can connect to SQL Server data by linking and by using Access Data Projects (ADPs). Because both of the 2010 file formats (MDB and ACCDB) can create read/write linked tables to SQL Server tables or views, linking is typically the preferred method for connecting to SQL Server. Linking allows the full flexibility of using local tables and queries for record sources while leveraging the capacity of SQL Server.

As we discussed earlier, most of the new features for Access 2007 and 2010 are available in both MDB and ACCDB file formats; however, ADP files benefit from very few of the new features. So there are a few key factors to consider when determining whether to use linked tables or ADP files when you enable or convert. Linking provides the ability for one front-end file to connect to multiple data sources, including any combination of SQL Server, MDB, and ACCDB files; along with local tables and other data sources, such as SharePoint, Excel, or any ODBC-compliant databases. Linking also allows the use of local and ad hoc queries, which Jet will optimize so that SQL Server will do as much of the processing as possible. On the flip side, linking does not allow you to modify the linked table. You need to use an ADP file or SQL Server's Enterprise Manager to make schema or design changes to SQL Server files.

4.5. Compiling the Code

Along with making a copy of the database, it is a good practice to be sure that code is compiled before initiating major changes. Not all applications or files have code, but most front-end applications do. Compiling will essentially clean up and compact the code. It identifies but does not fix errors. So if there are problems, you may need to debug the code before proceeding.

Use the Visual Basic Editor (VBE) to compact the code:

1. Open the VBE (press Alt+F11 or click the Visual Basic button on the Database Tools tab).

2. On the menu bar, click Debug.

3. Click the first option, which is Compile (current filename).

Ideally, everything works fine and there is nothing to debug. With small files it can be so fast that you don't know anything happened until you again click on the Debug menu and see that Compile is grayed out, indicating that the code is compiled.