microsoft.com Home
http://www.microsoft.com/office/ork |
|
microsoft.com Home
|
|
|
|
||
|
http://www.microsoft.com/office/ork |
|||
An identifier causes an error.
I receive an error that a table exceeds the limit of 32 indexes.
I receive an out-of-memory error when converting a large database.
My 16-bit API calls do not convert.
My converted Access 2.0 report has different margins.
My ActiveX controls do not convert.
Time or date values in my query criteria return different results.
I receive an ODBC message when opening a form or report in a converted database.
I receive a message that my computer is missing at least one of the Access 97 object libraries.
Microsoft Access 97 or later supports some new Microsoft Visual Basic keywords, so you cannot use these keywords as identifiers in Access 2000. The following keywords are supported by Access 97 or later: AddressOf, Decimal, DefDec, Enum, Event, Friend, Implements, RaiseEvent, WithEvents. When you convert a previous-version Access database to Access 2000, existing identifiers that are the same as new Visual Basic keywords cause a compile error. To fix this problem, change existing identifiers so that they are not keywords.
In Access version 2.0, you can specify a name for a procedure that is the same as a module name. However, in Access 95 or later, a procedure and a module cannot have the same name. To fix this problem, rename the procedure or rename the module. Alternatively, you can avoid this error by using a fully qualified name for the procedure in your Visual Basic for Applications (VBA) code.
If your Access 2.0 database contains a table with 32 or more indexes and relationships combined, you might receive an error when you convert to Access 2000. To resolve this error, open your database in Access 2.0, and either 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 try to convert your database again.
Visual Basic for Applications (VBA) has a limit of 1,082 modules per Access database, which includes forms and reports with the HasModule property set to Yes. To fix this memory problem, reduce the number of objects in your Access database. Consider dividing your application into multiple databases. If you have modules with a large amount of code, consider using library databases to store the code.
If an Access 2.0 module contains 16-bit application programming interface (API) calls, you might receive an error message when you convert the database to Access 2000. You must change the API Declare statements in the converted database to their 32-bit equivalents.
When you convert an Access 2.0 database to Access 2000, the conversion utility converts Access Basic code to Visual Basic for Applications (VBA) code. If all code does not successfully compile, you might receive an error message after you convert to Access 2000.
In the converted Access database, open a module in Design view, and then on the Debug menu, click Compile ProjectName. As Access compiles, it stops at any line of code that contains an error. You can then modify the syntax to resolve the compile error.
In rare instances, the conversion utility might fail to convert some syntax. For example, it might fail to modify a DoCmd statement into a DoCmd method. You might also receive compile error messages, if your Access 2.0 database contains syntax errors. For this reason, it is a good idea to compile all of your previous-version database modules before you convert them to Access 2000.
Access 2000 does not support the DAO 2.5/3.x compatibility library. If you attempt to convert a database in which the code uses objects, methods, or properties that depend on the DAO 2.5/3.x compatibility library, you receive a message that there were compilation errors during the conversion of the database. Before you convert the database, update the code so that it does not depend on the DAO 2.5/3.x compatibility library. If you still receive a message that there were compilation errors during conversion, open the converted database in Access 2000, remove the reference to the missing DAO 2.5/3.x compatibility library, and then set a reference to the Microsoft DAO 3.6 Object Library.
You might encounter problems when you try to print or preview an Access 2000 report converted from an Access 2.0 report that has margins set to zero (0). When you convert an Access 2.0 report with margins set to 0, the converted report margins are set to the minimum margin that is valid for the default printer. This prevents the report from printing data in the nonprinting region of the printer.
To resolve this problem, reduce the column width, column spacing, or number of columns in the report so that the width of the columns plus the width of the default margins is less than the width of your paper.
When you convert an Access database that contains ActiveX controls to Access 2000, you might receive a message that ActiveX controls are not converted. Access 2.0 supports 16-bit ActiveX controls, but Access 95 or later supports 32-bit ActiveX controls. Access can automatically update a 16-bit control to its 32-bit version only when a 32-bit version exists and is registered on your computer.
When you convert an Access 2.0 database to Access 2000, a query that contains criteria based on specific time values in Date/Time fields might return different results than the query in earlier versions. This query result might also occur when you link tables from an Access 2.0 database to an Access 2000 database. Only the time portion of Date/Time fields is affected.
A query that contains criteria specifying dates between 1900 and 1929 might also return different results. For example, a date criteria of #01/01/15# in Access 2.0 and Access 95 represents January 1, 1915, while the same date criteria in Access 97 or later represents January 1, 2015. To work around this difference, modify the data in your criteria to specify the century — for example, #01/01/1915#.
The message “ODBC - connection to datasourcename failed” occurs when a table in your converted Access 1.x or 2.0 database is linked to an ODBC data source that uses a 16-bit driver and driver manager. Access 2000 can open only linked ODBC data sources that use the 32-bit versions of the appropriate ODBC driver and ODBC Driver Manager (Odbc32.dll). For example, the 32-bit version of Microsoft SQL Server™ ODBC driver (Sqlsrv32.dll).
To correct the situation, you must create a new, identically named 32-bit data source name (DSN) for each ODBC data source that is linked to the original Access 1.x or 2.0 database.
If you do not know the original name of the DSN, open the original database in the original version of Access, open the linked table in Design view, and then display the Table Properties sheet. The Description property of the table contains the definition of the ODBC connection string. The parameter following DSN= in the connection string is the name of the DSN. To view the complete DSN definition, in Microsoft Windows 95 or later, open Control Panel and double-click the ODBC icon [not the ODBC (32bit) icon]. To view the DSN definition, in the Data Sources (Driver) list, click the name of the DSN, and then click Setup.
To create a 32-bit ODBC data source, follow these steps
To fix the missing references in a converted database, follow these steps
Note Unlike Access 2000, Access 97 is not designed to work with ActiveX Data Objects (ADO).
Topic Contents | Previous | Next | Top Friday, March 5, 1999 © 1999 Microsoft Corporation. All rights reserved. Terms of use. | ||
|
License
|