Using Templates to Replicate Design Changes

Although it is relatively easy to make changes to a database's design, propagating those changes can be problematic if the database is distributed among many servers. You can use the design process to make changes to a database that is already in production as long as the design is stored in a template file (or files) on the server and the production database or its elements are set to inherit the design. As pointed out earlier, this can be done for all design elements in the database or for individual design elements.

For obvious reasons, you would not typically make design changes to a database that is in production unless the changes have been thoroughly tested. Mistakes could have far-reaching and potentially disastrous consequences. It is therefore much better to make a copy of the production database and make the changes to the copy. After the changes have been tested and are working in the test copy, the design of the production database can be updated.

Updating a production database should always be done using a template. You now know that a database automatically is updated from its template each night, but what if you have a crisis and your design changes can't wait overnight?

You can apply the changes manually in two ways after a template is created:

• Replace the design of the production database by choosing File, Database, Replace Design from the menu. Choose the appropriate template from the list presented.
• Refresh the design of the production database by choosing File, Database, Refresh Design from the menu.

CAUTION

Replacing the design of the database causes all the design elements to be replaced with the template, even if there have been no changes. This could cause the next replication of the database with other servers or mobile users to take considerably longer than usual because all the design elements will be replaced when they replicate. Refreshing the design is a better way to go whenever possible.

Using a template is not the only way to propagate design changes. A replica copy of the production database can be created and modified locally. When the changes have been tested thoroughly, replication can be used to change the design of the production copy. This is not the best way to work, however, and there might be design elements ” especially server-based scheduled or new mail agents and mail-enabled features ”that cannot be tested properly unless the database is on a server. In this case, a database copy (not a replica) must be placed on the server for testing. Never make a second replica of a database on a server. The two databases will attempt to replicate, and this can have a disastrous effect. A template is also the only way to upgrade the design of a database when the design is hidden, as described earlier in this chapter.

Templates can be replicated just like any other database. If each server in your organization has a replica of the template, changes to the template can be replicated throughout an organization by placing or updating the template on a hub server. The Design task that runs nightly on the server will make the changes to all the different replicas of the template, and ultimately each database's design throughout the enterprise will be updated.