The stagingcopy utility and the production database

The stagingcopy utility allows an administrator to copy data from the production database to the staging database. Use the stagingcopy utility for specific administrative situations, such as setting up a new staging server or recovering a corrupted staging server database.

Note: This information also applies to synchronizing on an authoring database if the workspace feature is enabled.

The stagingcopy utility ensures that the production and staging databases are synchronized. After the stagingcopy utility runs successfully, do not update the database tables that are managed by the staging server to the production database. Instead, update these tables on the staging server and then propagate the changes to the production database using the stagingprop utility. Updating staging server-managed tables on the production database will likely fail because of a potential key conflict or reference integrity violation. To update the staging server-managed tables in the production server database, use the stagingcopy utility to synchronize the staging and production databases.

To ensure that the staging-enabled tables are never updated on the production database, the tables must be under the control of a Site Administrator only. In some cases, the staging-enabled tables in your production database are updated by an individual customer or merchant after the data was copied by stagingcopy. For example, you cannot prohibit a merchant from modifying the OFFER table in the production database after copying to the production database. In this situation, the OFFER table cannot be managed by the staging server.

Introduced in Feature Pack 2 After the data is copied from the production database to the authoring database, you must run a full index build (di-preprocess and di-buildindex) on the authoring environment.

Managed files

Managed files use both database data and file assets. Since managed files are enabled in a workspace, the content of these files is saved in the database tables, for example in the CMFILE table. Managed files must be committed to the Commerce EAR for the WebSphere Commerce file-serving servlet to retrieve the file assets and to display the assets.

Managed files are handled differently in staging and production environments:

Staging environment - Management Center preview defaults to the data found in the database. If it is not found, it is retrieved from the EAR. The Staging environment contains data in the CMFILE, CMFILEDIR, CMSMALLFILE, and CMLARGEFILE tables. For example, if you load ImageA.jpeg in the Management Center, then go into workspace1 and overwrite ImageA.jpeg with a different image. When you preview the change in workspace1, the system displays the overwritten content. However, the storefront displays the original ImageA.
Production environment - Since there is no need to preview changes, every managed file is obtained from the EAR. The Production environment retrieves data from the CMFILE and CMFILEDIR tables, but not the CMSMALLFILE or CMLARGEFILE tables.

Because of these differences, the staging server utilities do not propagate managed files to the production database, they get sent to the production EAR.

Important: stagingcopy does not copy the data in the CMFILEDIR table from a production to a staging environment. If you want to publish managed files only to the production server, use the fileprop utility or supply the fileprop parameters in the stagingprop utility. If the fileprop parameters are not supplied, the stagingprop utility does not publish the managed files.