ACC95: Overview of Conversion Issues

ID: Q136064

The information in this article applies to:

SUMMARY

Moderate: Requires basic macro, coding, and interoperability skills.

Microsoft Access for Windows 95 version 7.0 has many enhancements, such as 32-bit architecture, Visual Basic for Applications, the Microsoft Jet data base engine version 3.0, and a modified data access objects (DAO) model. To take full advantage of these features, you should convert your databases created in an earlier version of Microsoft Access to Microsoft Access version 7.0.

Most Microsoft Access version 2.0 (or 1.x) databases can convert to version 7.0 without difficulty. In rare cases, however, new features can conflict with existing objects and code. This article discusses the following few issues that you may encounter when converting a database to version 7.0:


MORE INFORMATION

Code Cannot Compile

When you convert a database to version 7.0, the conversion utility converts Access Basic code to Visual Basic for Applications and compiles the updated code. If any code does not successfully compile, you may receive the following error message after you convert a database to version 7.0:
There were compilation errors during the conversion or enabling of this database.

This database has not been saved in a compiled state. The performance of this database will be impaired because Microsoft Access will need to recompile the database for each session. For information on improving performance, click Help.

To resolve this error, open a module in Design view and click Compile All Modules on the Run menu. As Microsoft Access compiles your code, it stops at any line that contains an error. You can then modify the syntax to resolve the compile error.

NOTE: In rare instances, the conversion utility may fail to convert some syntax. For example, it may fail to modify a DoCmd statement, such as the following, 

   DoCmd OpenForm "MyForm"

into a DoCmd method: 

   DoCmd.OpenForm "MyForm"

You may also receive the compile error message if your Microsoft Access 2.0 database contains syntax errors. Therefore, it is good practice to fully compile your Microsoft Access 2.0 (or 1.x) databases before you convert them to Microsoft Access 7.0.

Conversion Process Is Slow

If you have a large database, the conversion process may take a long time or your computer may appear to stop responding (hang). The more objects that you have, the longer it takes to update the code and objects to version 7.0.

To speed the conversion process, try using the Import command instead of the Convert Database command by following these steps:
  1. Create a new Microsoft Access version 7.0 database.


  2. On the File menu, click Get External Data, and then click Import.


  3. In the Import dialog box, make sure Microsoft Access (.mdb) is selected in the Files Of Type box.


  4. Click the arrow to the right of the Look In box, select the drive and folder (directory) where the Microsoft Access database (.mdb) you want to import is located, and then double-click the database's icon.


  5. Click 20 or so objects to import.


  6. Click OK to import the selected objects.


  7. Repeat steps 2-6 until all the objects are imported into the new database. Note that Microsoft Access converts the object to the new version 7.0 format as it is imported.


Importing database objects may increase the size of your database; therefore, once the import is complete, compact the database. If you do choose to convert a large database, make sure that you compact it into a new file rather than replacing the original file.

16-bit API Calls Do Not Convert

If your modules contain 16-bit API calls, you may receive the following error message when you convert the database to version 7.0:
There are calls to 16-bit dynamic-link libraries (.dll) in modules in this database. These won't work under Microsoft Windows 95 or Microsoft Windows NT.

To resolve this error, you must change the API Declare statements in the converted database to their 32-bit equivalents. For more information about 32-bit equivalents for 16-bit API calls, search on the phrase "converting code," and then view "Converting code that calls a DLL" using the Answer Wizard from the Microsoft Access for Windows 95 Help menu.

Custom Controls Do Not Convert

When you convert to version 7.0, you may receive the following error message if your database contains an OLE custom control:
One or more forms or reports contains a 16-bit OLE Custom Control with no 32-bit equivalent. These controls will not function properly under Microsoft Windows 95 or Microsoft Windows NT.

Microsoft Access version 2.0 supports 16-bit OLE custom controls whereas Microsoft Access version 7.0 supports 32-bit OLE custom controls. When you convert a database that uses a 16-bit custom control to version 7.0, Microsoft Access can automatically update the control to its 32-bit version only if a 32-bit version exists and is registered on your computer. If you do not have a 32-bit version of a 16-bit control, then Microsoft Access may generate the error message listed above.

For more information about converting OLE custom controls, please see the following article in the Microsoft Knowledge Base:

Q138019 16-bit OLE Controls Not Supported in Version 7.0

Table Exceeds Limit of 32 Indexes

If your database contains a table with 32 or more indexes and relationships combined, you may receive the following error message when you convert to version 7.0:
Operation failed. There are too many indexes on table '<table name>'. Delete some of the indexes on the table and try the operation again.

The Microsoft Jet database engine version 3.0 has a limit of 32 indexes per table. When you create a relationship and enforce referential integrity, an index is created for the foreign key table. If the number of relationships exceeds 32, then the number of indexes on the "foreign key-side" also exceeds 32.

To resolve this error, open your database in version 2.0 (or 1.x) and modify your table design to reduce the number of relationships for the primary key table or remove some indexes from the foreign key table. Then, you can try to convert the database to version 7.0.

This resolution assumes that you have version 2.0 (or 1.x) installed on your computer, as well as version 7.0. If you replaced version 2.0 (or 1.x) with version 7.0 using the same folder (directory) on your computer, then you must re-install version 2.0 (or 1.x). You may want to re-install into a different folder so that you have both versions available for resolving the conversion problem.

Name Conflict Stops Conversion

If a module has the same name as a type library, such as "DAO", "VBA", or "Access," the conversion process stops and Microsoft Access displays the following error message:
Name conflicts with existing module, project, or object library.

To resolve this error, open the database in Microsoft Access version 2.0 (or 1.x) and rename the object.

This resolution assumes that you have version 2.0 (or 1.x) installed on your computer as well as version 7.0. If you replaced version 2.0 (or 1.x) with version 7.0 using the same folder on your computer, then you must re- install version 2.0 (or 1.x). You may want to re-install into a different folder so that you have both versions available for resolving the conversion problem.


REFERENCES

For more information about conversion and compatibility issues, search for "conversion and compatibility" using the Answer Wizard from the Microsoft Access 7.0 Help menu. 


Keywords          : kbusage 
Version           : 7.0
Platform          : WINDOWS 
Issue type        : kbinfo

Last Reviewed: April 14, 1999