Staging server limitations

Staging database

• It is recommended that you use the WebSphere Commerce Management Center to change your staging database. If you connect to the database directly, you can break some of the limitations that are required by staging. For example, if you change the category for a catalog entry within Management Center, first the old relationship is deleted. Then, a new relationship is inserted. If you connect to the database directly, only an update is performed. The staging server does not find the ID of the record, as it is changed. You can modify your triggers to perform a delete and insert, however it is not recommended.
• You cannot use the staging server with the buyer organization self-administration features.
• The MEMBER_ID column of all staging tables (excluding MEMBER, MBRREL, MBRROLE, and MBRATTRVAL) must be organizations or member groups, and not users. Users are indicated by a value of U in the type column of the MEMBER table. If the MEMBER_ID references a user in the MEMBER table, stagingcopy might fail. For example, the PARTICIPNT table has a foreign key to the MEMBER table. When a contract participant is created, the value in the MEMBER_ID column in the PARTICIPNT table cannot reference a MEMBER_ID in the MEMBER table that has a value of U in the type column. For more information, see Troubleshooting: Staging server.
• For all site tables, the MEMBER_ID must be -2001 or 0. For all tables that contain both site and merchant data, the MEMBER_ID for rows that are related to site data must be 0 or -2001.
• Do not delete any WebSphere Commerce object that involves the MEMBER table from the production-ready data. These objects include users, organizations, customer segments, member groups, customer territory groups, or customer price groups. If you attempt to delete these objects, the objects do not delete.

  You can delete WebSphere Commerce objects that involve the MEMBER table from a workspace, if the objects are available in a workspace. If you want to publish these deletions to the production server, you must turn off SQL batch update when you are running the stagingprop utility. Turn off SQL batch updates by specifying setting the -batchsize parameter to 0.

  To learn what WebSphere Commerce objects involve the MEMBER table, review the WebSphere Commerce data model documentation.

• You cannot create or update RFQs on a staging server. If you use RFQs, they must be managed on the production server only.
• You cannot use the stagingcopy utility if you are using RFQ features on your production system. Before you launch your production site, create the staging server and set up production-ready data. Deploy and test your data on the staging server. Then, propagate to the production server by using the stagingprop utility.
• You must manually propagate database schema changes from the staging to the production database. For example, if you create a new index or table in a production-ready data, you must manually create the index or table in the production database.
• Triggers are not created on all Commerce tables. In specific, the Product Advisor search space tables do not have triggers set up by default. You must configure the triggers manually. For example, to see which tables have triggers, issue the following SQL command:
  

  select DISTINCT(TABNAME) from SYSCAT.TRIGGERS where
  TRIGNAME like 'STAG%' and TRIGSCHEMA='SCHEMA_NAME'

  For more information about migrating Product Advisor data from a staging server to a production server, see staging database migration.
• The stagingprop utility cannot propagate records that are loaded by the Loader package (load mode) or the DB2 load utility since both bypass the staging triggers. If you used either utility, use the stagingcopy utility to resynchronize your database tables. You must never use the loading utilities (load mode) or the DB2 load utility on a production-ready data or a production database while the stagingprop, or stagingcopy utilities are running.
• Do not run the Database Cleanup utility on the staging server except to clean the STAGLOG table.
• To delete a WebSphere Commerce object from the MEMBER table, review the following scenarios:
  • If the deletion is not to be staged, drop the staging triggers before you run the deletion. Restore the staging triggers after the deletion is completed.
  • If the deletion is to be staged, complete the following tasks:
    1. Delete all the related record in the child tables of MEMBER.
    2. Delete the MEMBER record.
• If you delete categories on your staging server and you want to publish these changes to your production server, you must turn off SQL batch updates when you run the stagingprop utility. Turn SQL batch updates off by specifying setting the -batchsize parameter to 0.

Staging database migration

You cannot migrate your staging database. See Creating a staging server on a migrated environment for more information.

Key splitting

If your site uses a staging server, data changes to content are typically made on the staging server and propagated to the production server. Depending on the scenario, you might need to change content on both the staging server and the production server. Updating the same content on both servers however can potentially cause a primary key collision. If the production server and staging server use the same keyrange, the same primary key can be allocated for the same table on the separate servers. This allocation on both servers causes a primary key collision. As a result, this keyrange must be split so the keyrange on each server is mutually exclusive. For more information, see Key splitting.

Updating primary keys

The stagingprop utility does not support updating primary keys. The primary key of a table can be referenced by other data by using either explicit foreign keys or implicit ID. Because of this referencing, changing the primary key has many implications. Database management systems do not allow primary key changes when the primary key is referenced by a foreign key. To update the primary key, you can delete it or, you can update all child rows in every child table to use another primary key.