A.2. Key Decision Factors

Having established some common terminology, we can focus on the key factors for making the decision to enable or to convert. A pivotal factor is dealing with multiple versions of Access that need to utilize the same data file or application. Other key issues include: Will any new features from Access 2003 be incorporated into the application? Is an MDE file required? What version is the original application in, and of course, what would the time and resources or cost/benefit be?

For the most part, it is very straightforward to either enable or convert a database to 2003. User-level security will require extra steps, but if the situation warrants a secured database, the effort is well worth it. And, as always, replication proves to be a special case. However, an evaluation of the trade-offs typically supports the effort to convert. If you are considering some of the costs and time associated with rolling out a new version over a vast network, it is very handy to have several options that are a mix of status quo, enabling and converting. And, if you are responsible for making the decision about upgrading or staying with earlier versions of Access, we strongly recommend that you focus on how Access 2003's new features can pay for themselves and provide a significant return on investment. Before converting, you will definitely want to spend some time getting familiar with the various security features incorporated in Access 2003. Again, special consideration needs to be taken to address secured applications and replication. Although this appendix refers to various security features, the focus is on factors dealing with upgrading. For help with security issues when upgrading, you should review the new security features that are highlighted in Chapter 20, "Macro Security," as well as Chapter 16, "Database Security." There is also additional information available online, such as through MSDN and Microsoft Access Online Help.

A.2.1. Networks with Only One Version of Access

Obviously, in a controlled environment where everyone will be using Access 2003, it would be a shame to not convert and take advantage of the new features in Access 2003. Well, except (yes, the exception will prove the rule), if the application in question is 2000 or 2002, it does everything that you want it do, it is working fine, and you don't want to incorporate any of the Access 2003 features. In that case, you may choose to enable rather than to convert.

Moving from Access 2002 to Access 2003 is almost a freebie. Yes, it is really that easy. 2002 databases do not need to be converted because the file format is the same for 2002 and 2003. So, you can just open the 2002 database with Access 2003 and start working. This is essentially the case for MDEs, MDBs with or without code, and for DAPs (data access pages).

Note: Pay me now or Pay me later – Just because the program was Access 2002, it does not mean that the file was 2002 format. Remember that Access 2002 was often set up to use Access 2000 as the default file format. Thankfully, the price for "later" is pretty low.

Access 2003 can convert a database from Access 2.0, 95, 97, and 2000 to Access 2003 (2002–2003 file format). It can also convert an Access 2003 file format to 2000 or 97 file formats, but not to 95 or 2.0. Figure A-1 shows the display for selecting the conversion path. Keep in mind that merely converting the file does not ensure that the application will function properly. The guidelines, cautions, and tips in this appendix will help to ensure a smooth transition. But you may also need to work with some of the code, special toolbars, and other features after converting a file to or from a different version of Access.

Figure A.1. Figure A-1

A.2.2. Networks Having Multiple Versions of Access

In the real world, companies often have multiple versions of Access (preferably installed on different computers). Although not ideal, it is often better to allow some of the people to upgrade than it is to hold everyone back pending a complete network roll-out. There are a few options for working with multiple versions of Access. Let's identify some options and benefits.

This is really where it is appropriate to thoroughly review the trade-offs associated with enabling or converting. Upgrading often requires an investment of time and resources into both the purchase and the deployment of the new program. Then, if you decide to convert (now we're talking about changing the file format) an application, there may be additional time required to update the code, work with the MDW (the workgroup information file), and deal the new 2003 security features. In addition to time and costs, it is important to remember that once a file has been converted, it cannot be opened by older versions of Access. Again there is an exception: 2002 can open a 2003 database. These factors could all be considered as part of the cost of converting.

At the top of the list of benefits from converting is the opportunity to enjoy the new features. And, Access 2003 has some pretty awesome (read that as powerful) timesaving tools, wizards, and functionality. As a developer, you definitely want to benefit from the ADE (Access Developer Extensions), which is discussed in Chapter 19. As you know, you need to use the "original" version of Access to create an MDE, so you'll need to convert to 2003 if you want to use 2003 to create your MDE files. Another key reason to convert is the peace of mind associated with having everyone using the same file format. Why introduce the potential for unnecessary (and often hidden) complications?

As with many things, converting does not have to be an either–or decision. It is likely that a combination of original, converted, and enabled applications could be appropriate. With the scenario of a multiuser environment with the back end and the application in Access 97, it is possible for an Access 2003 application to share the data. In fact, you can both keep the application in a 97 format and convert (create a copy of) the application in Access 2003. So, people with Access 97 can continue to use their original files and a new application file could be created by converting the 97 file to Access 2003. Then, it is possible to add functionality to the new file by incorporating Access 2003 features. You could also provide an enabled file for users who have 2000, 2002, or 2003 and who don't need the new features. The key is that users would need to open the file associated with their version of Access. All versions would connect to the same data file, which would be maintained in the original (or oldest version maintained) file format.

Instead of converting an entire database, there is an option of importing database objects into an Access 2003 file. This is particularly handy if you only want to retain or convert some of the objects. This process does not automatically import references to libraries, so the references may need to be set in the new Access file.

Another item to consider is that when converting an Access 2000 file with DAPs, the pages are not automatically converted to the Microsoft Office 2002 Web Components format. This is the format shared by Access 2002 and 2003. However, when a DAP is opened in Design view, Access will convert it to the most recent version of Web Components and make a backup of the original page.

A.2.3. Splitting a Database

There may be a situation where multiple users actually share one database file that contains both the user interface (UI) and the data. Let's hope that this is a very rare situation, because it is a scenario that is prone to database corruption. But, having the data in the same file as the forms and reports becomes a significant limitation if users want to use different versions of Access. This situation has plenty of other limitations, particularly those related to performance and corruption. One reasonably straightforward solution is to spilt the database and have multiple front ends sharing one back-end data file.

Here's how to split the a single database into front-end (UI) and back-end (data) files:

Now, if you want to create multiple versions of the database, you will only be converting 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.