For higher-end proprietary systems where the cost to perform and maintain custom modifications is very high, the general recommendation is to restrict the number of modifications, ideally to zero. With the Full Edition of Catalyst, however, changes can be made quickly and cost-effectively using the Microsoft® Access user interface. If the modifications are performed judiciously, it allows you the opportunity to fit the software to your business needs instead of finding a work-around or changing the way you do business. In some cases, the business process you are trying to support is where you derive your competitive advantage so changing the process is a much costlier option than changing the software. Fortunately, custom modifications can be made in Catalyst with relatively ease. That said, there are still a number of precautions to take when doing so to preserve your ability to upgrade to future releases. The following strategies can facilitate the upgrade process when making custom modifications:
- Document your changes. The change documentation should reference the name of the database object and a description of the change so the modification can be replicated in the new version. The documentation should be more detailed for modifications to existing database objects. For code changes, it's also helpful to enter comments around the new or revised code to help identify where changes have been made.
- Where possible, make modifications using new database objects (queries, reports, forms, etc.) rather than existing objects. Any changes made to existing objects will need to be replicated in the new release when you're ready to upgrade. The separate objects can just be imported into the new database with minimal integration effort.
- Where possible, use reports to meet user requirements instead of forms. Ad-hoc queries and reports are a low-cost alternative to more extensive system modifications. In addition, they are easily imported into another database during the upgrade process.
Note: After importing any database object with underlying code (e.g. forms, reports, and modules), it's always a good practice to compile and save the object code in the Visual Basic Editor. In some instances, if this is not done immediately after the import, the database can become corrupted. The bug occurs on systems where more than one version of Access is or has been installed.