Other Considerations When Converting
Keep in mind that saving to a different file format is only a small part of the process. As already discussed, there may be issues involving code, references, macros, security, and integrating with other applications. Moving to newer versions is certainly easier than moving backward. Newer features may be lost or have only part of their functionality. Custom features may not be recognized or implemented as expected. Despite those concerns, it is certainly handy to have the ability to save a file in an older format when it's needed.
And, what about times that only some of objects are needed? Instead of converting an entire database, there is also the option of importing database objects into an Access 2007 file, either an .mdb or .accdb format. This process does not automatically import references to libraries, so the references may need to be set in the new Access file.
When converting a database that contains linked tables, it is a good practice to ensure that the linked tables are still in the location specified in the Table properties. Using the Linked Table Manager to relink to the current tables is a fast, easy way to refresh or update the links. After the database has been converted, the tables can be moved and the Linked Table Manager can be used to relink to the tables in their new location.
To convert a database, it must be closed, meaning that no users can be accessing the database, and you essentially need to have the equivalent of Administrator permissions for the database. Fortunately, the default mode for an unsecured database is for users to have these permissions. There will be more about permissions in the section on converting a secured database, which is discussed later in this appendix.
Post a comment