Upgrading and Converting to Access 2010 : ENABLING A DATABASE, ACCESS 2010: 64-BIT CONSIDERATIONS

1. ENABLING A DATABASE

Access 2010 can work with Access 95 and 97 files. Basically, there are two options for working with the file: convert it or enable it. Converting creates a copy of the file in a newer format, as discussed earlier. However, in order to work with the file without converting it, you will need to enable the database.

There are some logical limitations when working with an enabled database. Considering that databases are not forward compatible, it makes sense that although you can use Access 2010 to work with an Access 95 or 97 file, you cannot use an Access 95 or 97 file to link to a table in an Access 2000 or newer database. Access 2010 will not convert a file to an Access 95 or 97 file format nor will it export the tables to an Access 95 or 97 file. However, you can move or copy (most) data from an Access 2010 table and paste it directly into a table in a legacy database.

Other concerns deal with the file format, mostly because many of the features of the new file formats were not available or supported in Access 95 or 97. For example, data that relies on Unicode compression may not convert correctly. And, Access 95 and 97 had a 256-character set, so they may not have equivalent characters for some of the characters in the new format. Additionally, in the 95 and 97 formats, Number fields do not have properties for Decimal Places and Field Size. These properties must be changed prior to conversion; the typical alternatives include Single or Double or changing the data type to Currency.

1.1. Enabling the Experience: Opening 95 or 97 Files with Access 2010

When Access 2010 opens an Access 95 or 97 file, it will display the Database Enhancement dialog box. This might be perceived as a polite way of encouraging users to convert (termed upgrade in this dialog box) the database so that it can take advantage of the new features. If you choose Yes (Proceed With Enhancement), Access 2010 will convert the file to the specified file format. Considering the age of the file, it is likely that it would benefit from a thorough review of the code and external dependencies. If the database is not enhanced, Access 2010 can still open the file and update records, but users will not be able to make any design changes. Remember that a data file should not be converted to a format that is newer than the oldest applications (front-end files) that will use it.

To enable the database, follow these steps:

If errors are encountered, a message box will advise you that a table of conversion errors has been created. Here's an example of what you might see:

−3831: The current file format no longer supports user-level security. The
conversion or compaction process has removed any user-level permissions.

For those rare situations in which users still require a 95 or 97 file format, the only option is to enable the file. Enabling the database will let Access 2010 use the file, and the file will still be compatible with Access 95 and 97. It is remarkably quick and easy, using the following steps:

This works well for entering data and for connecting to a data file that is used by Access 95 or 97. The objects can be seen in Design view and the VBA Editor will display the code. Users can even make temporary modifications to objects, such as adding a text box to a form. However, when the object is closed, the design changes will not be saved.

2. ACCESS 2010: 64-BIT CONSIDERATIONS

As 64-bit systems become more mainstream, Microsoft has started to release both 32-bit and 64-bit versions of Office, providing you with an important decision to make at deployment. By default, Office 2010 will install the 32-bit version; which means that it requires an explicit choice and act to install a 64-bit version.

However, computers with 64-bit hardware must also have a 64-bit operating system in order to install the 64-bit version of Office. But that doesn't mean that just because a computer is running on a 64-bit hardware with a 64-bit operating system, that it is forced to run 64-bit applications. Indeed, it may be desirable to install 32-bit applications (software) on 64-bit systems.

64-bit Windows supports running 32-bit software in a special environment known as WOW64, or "Windows on Windows 64-bit." By installing 32-bit Office 2010 onto a 64-bit system, you can maintain compatibility with legacy databases that still depend on 32-bit components. This is especially important when the Access application uses ActiveX controls, COM Add-ins and objects, linked tables that depend on an ODBC driver, or API calls. Although there are 64-bit replacements available for ActiveX controls, COM Add-ins/objects, or ODBC drivers, you also need to consider that many users have not yet migrated to the 64-bit systems. Such factors could be very compelling arguments for choosing to stick to 32-bit Office 2010 even when you have a 64-bit system available. As you can see, switching to or integrating with 64-bit platforms and systems introduces numerous complex issues that will require further research if you are facing such a situation.

SharePoint 2010 requires a 64-bit system, and it is available only in 64-bit. This can be a significant factor to consider when moving to a new platform — especially if you might potentially host your own SharePoint site. Alternatively, you can use a hosted service and avoid the platform issues. Office 2010, both 32- and 64-bit, can publish to SharePoint with no restrictions. So from an Access perspective, you can use all of the new 2010 features without being concerned about whether it is 32- or 64-bit.

Practically speaking, the benefit of installing 64-bit Office distills down to this: You can make use of larger memory space, which is beneficial when you deal with large sets of data. The 32-bit system allows you to address 4GB of memory (less the amount needed by the operating system). Because the benefits of 64-bit become most evident when the processing requirements exceed 4GB, most of the databases may not realize much of a performance gain from being run within a 64-bit application, not even those with total records in the hundreds of thousands. This is another possible benefit, albeit indirect: The 64-bit Office enables Excel 2010 to handle much larger amount of data in its workbooks. So, if your Access database depends on automating Excel and dumping large amounts of data into Excel, you may see some benefits from using the 64-bit version of the Office.

It also should be noted that the decision to install a 32-bit or 64-bit Office is an either/or proposition; you cannot install both side-by-side. And, you may also encounter further restrictions based on other components present on the system. For example, if a 32-bit version of Excel Viewer or Access database engine (both available as a separate download from www.microsoft.com), is installed on the system, it may block 64-bit ap-plications from being installed. 

2.1. Porting an Access Application to a 64-bit Plat-form

If a decision is reached that an application should be ported to or at least made available on a 64-bit platform, there are a few steps that may be required. For an ACCDB file that contains only Access objects and (most) VBA code, it is typically a simple matter of recompiling the VBA (which may be done automatically), and the file will be ready to use on a 64-bit platform. However, if an Access application links to an ODBC (or other) data source, you will need to provide drivers that match the bitness (32 or 64 bit) of the Access application.

In case of linked tables, the link may depend on ODBC drivers that are 32-bit. Generally speaking, the driver's bitness must match that of the client's. Therefore, there must be 64-bit drivers to replace 32-bit drivers. If no such drivers exist, then a 64-bit application will not be able to link to the source. In such situations, it may be best to remain on a 32-bit application. Fortunately, whenever a 64-bit version exists for the driver, there is usually no need to update the connection string of the linked tables.

Like the drivers, the bitness of the ActiveX controls and COM Add-ins must also match, so a suitable replacement should be found whenever an application uses any of those objects. You may contact the vendors who provided the tools for a 64-bit version, look for a replacement that is available in 64-bit, or, once again, stay with 32-bit applications.

Fortunately, API calls on VBA are fixable and do not require one to hope for the availability of 64-bit counterparts as Microsoft has already made most APIs available on the 64-bit platforms. However, there are two things you need to do to make the file acceptable on a 64-bit platform. First, you need to replace any references to a pointer data type from the usual Long data type to the LongPtr data type. Second, you need to mark the API calls as "safe." These two steps are necessary because, by convention, the data type of the pointer is dimensioned based on the platform it runs. So on a 32-bit platform, the pointer would be 4 bytes and likewise, on 64-bit, the same pointer would be 8 bytes. By design, Visual Basic aims to free developers from being concerned with managing pointers and manual memory management, a fruitful source for many bugs.

In the past, Visual Basic and VBA already had a 4-byte data type prior to transition from 16-bit to 32-bit so that was a non-issue for developers during that transition. However, you must now cope with the fact that VBA is introducing a pointer data type. So instead of using a Long data type, which would always be 4 bytes regardless of which platform it may run on, you should review API documentation and update the API declaration to use a LongPtr data type whenever a pointer or a handle is called out. For an example of how you would update your API declare, let's take a look at a type used by the ShellExecuteEx API function, SHELLEXECUTEINFO. Here's the declaration as you would have done in past:

Public Type SHELLEXECUTEINFO
  cbSize       As Long
  fMask        As Long
  Hwnd         As Long
  lpVerb       As String
  lpFile       As String
  lpParameters As String
  lpDirectory  As String
  nShow        As Long
  hInstApp     As Long
  lpIDList     As Long
  lpClass      As String
  hkeyClass    As Long
  dwHotKey     As Long
  hIcon        As Long
  hProcess     As Long
End Type

It may be immediately obvious that the Hwnd parameter refers to a handle, which is a pointer, but there are also a few more. Here's the updated declaration for the same type:

Public Type SHELLEXECUTEINFO
  cbSize       As Long
  fMask        As Long
  Hwnd         As LongPtr
  lpVerb       As String
  lpFile       As String
  lpParameters As String
  lpDirectory  As String
  nShow        As Long
  hInstApp     As LongPtr
  lpIDList     As LongPtr
  lpClass      As String
  hkeyClass    As LongPtr
  dwHotKey     As Long
  hIcon        As LongPtr
  hProcess     As LongPtr
 End Type

So six parameters refer to a pointer data type and thus require you to use LongPtr instead. Note that you don't change other integer data types, even though VBA supports a new 8-byte integer data type, LongLong. Recall that the pointer data type is dimensioned based on the platform it runs. That does not happen for a plain integer data type so you should continue to use the same dimension as declared in the API at least until the API is revised explicitly to run only on the 64-bit platform. Also, if you look at the documentation, cbSize is of DWORD type, which is always 4 bytes regardless of the platform it is on. Therefore, using a LongPtr would not have been appropriate for this parameter, so you can't just replace every Long with a LongPtr.

There is one more aspect to consider: the cbSize parameter is used to determine the size of the structure and traditionally you have done this by using the Len() function, which will calculate the data types' size to provide the complete size for the SHELLEXECUTEINFO type as whole. On a 64-bit platform, this will no longer be reliable because of how the type has a Long followed by a LongPtr and this happens twice in the type. The members are aligned by an 8-byte boundary on a 64-bit platform and thus 4-byte padding is added to each Long parameter. Doing a Len() upon the SHELLEXECUTEINFO type would give you 104, which is 8 bytes too short. Thus, you should take care to use the LenB() function which counts bytes instead of characters and thus will account for the padding created and return the correct 112-byte length required for the cbSize parameter.

After you've accounted for all pointer data types, you will need to determine if the API needs to know the structure size. If so, you need to replace the Len() function with the LenB() function in those instances. That brings you to the final step, which is relatively easy: you'll need to mark the API calls as safe for pointers. For example, if you use the ShellExecuteEx function (which requires the type), the function would have been declared as follows in a 32-bit platform:

Declare Function ShellExecuteEx Lib "shell32.dll" Alias "ShellExecuteEx" _
  (SEI As SHELLEXECUTEINFO) As Long

You would add the PtrSafe keyword as shown here:

Declare PtrSafe Function ShellExecuteEx Lib "shell32.dll" Alias "ShellExecuteEx" _
  (SEI As SHELLEXECUTEINFO) As Long

					  

Now the Declare statement is compatible for 64-bit. Note that you do not change the return value to LongPtr because it does not return a handle. Had you used the ShellExecute function instead, which does return a handle, you would have to change the return data type in the declaration.

2.1.1. Working in Mixed Bitness

It is possible that in some situations, you have some users who have 64-bit Office installed working beside others who are using 32-bit Office. Microsoft has provided some tools for you to develop applications that can be compatible across different platforms. A 64-bit ACCDB file with some VBA and no external dependencies can be seamlessly ported to 32-bit platforms and vice versa.

However, as discussed in the previous section, accommodations must be made for the file that has external dependencies. Microsoft has provided two compilation flags to use in helping to support both 32-bit and 64-bit platforms, WIN64 and VBA7. Within an environment where Access 2010 is used exclusively, you can make use of the WIN64 flag to help the application use the correct ActiveX control where the 64-bit replacements exist. With regard to drivers that are used to manage linked tables, if a 64-bit counterpart exists, the connection string need not be changed or updated as the new 64-bit driver will appear to have the same identity as its 32-bit counterpart; thus, it will be used correctly on both platforms. If, for whatever reasons, the 64-bit driver is not a direct replacement of its 32-bit driver and thus it is identified differently, you might prefer to treat it in the same way as ActiveX controls, using the WIN64 flag to determine which drivers to use and manually re-link the tables via VBA code or using different DSNs to support both configurations.

Regarding API calls, PtrSafe keyword is required for the 64-bit platform. With that in mind, we strongly encourage you to take time to update all API declarations within the application to use the new pointer data type and thus make it compatible for both the 32-bit and 64-bit platforms for Access 2010. Thus, the modified ShellExecuteEx function sample dis-cussed previously will run on both platforms.

In cases where you must support mixed bitness and mixed versions, however, you must also make use of the VBA7 flag to rectify the fact that earlier VBA versions do not support either the new PtrSafe keyword or the LongPtr data type. If you go back to the ShellExecuteEx function example, you would have to keep both declarations separated out by the VBA7 flag. 

For ACCDE files, you must create a version that is compatible with the target system. You can create only a 32-bit version ACCDE on a 32-bit machine, and create only a 64-bit version ACCDE on a 64-bit machine. This means you cannot interchange the ACCDE version between 32- and 64-bit systems as you can with ACCDB files. So, if you intend to deploy ACCDE files to both platforms, you must maintain two ACCDE files for each of the platforms. It should also be noted that while Office 2010 supports converting MDB files to MDE files, the 32-bit version of Access cannot run a MDE created by 64-bit Access 2010.