Stat 6.2 - User Guide

Schema Objects

Quest® Stat® supports certain schema object definitions for Oracle® Applications environments. In the Oracle Applications change management module, schema objects are migrated by the Stat Oracle Agent. This allow Stat to enforce the migration order specified in the archive set.

Stat currently supports the following schema object types:

NOTE: Schema objects include a set of predefined true/false parameters that are executed before the definition of the object is captured in Stat. You can change the true/false values of these parameters in the Schema Object Parameters Maintenance table. For more information, see the Stat System Administration Guide, Chapter 4, “General Maintenance Tables.”

IMPORTANT: Stat only deletes and replaces schema objects that have drop/create operations in the script. If the schema object does not have drop in the script, then the migrator must delete the object from the target environment prior to migration.

Patch Objects

Quest® Stat® provides comprehensive patch support for Oracle® Applications. You can associate with a CSR any patch that has been downloaded from Metalink, Oracle’s web support service, and uploaded to the Stat Repository.

Like schema objects, you can lock patch objects on a CSR but you cannot archive or migrate them. Instead, you use the Stat Oracle Application Management Console to apply the patch you want to a specified target environment.

To associate Oracle patches to a CSR, the Patches tab must be enabled. The enabling of the Patches tab is determined by CSR type. For more information, see The Oracle Apps Management Console .

Object Locking and Reservations (Oracle Applications)

Object locking is an important part of any change management practice since it coordinates all of the efforts of the developer and prevents work from being overwritten. Quest® Stat® supports logical locking of objects in the Stat Repository, which means that the lock shows up in the Stat application, but developers can still go directly into their application environments and make changes to the object even if the lock on the object is not their lock. As long as the developers use a CSR to modify objects, the coordination of development is maintained.

Locks and reservations are issued to the developer assigned to the object, regardless of who actually requested the lock. That person may or may not be the assigned developer. This is a security measure determined by user class rights.

A lock indicates that the assigned developer has exclusive change/edit rights on the object. A reservation indicates that the object is currently locked by another developer and you are waiting for the object to become available. Once the object becomes available, Stat converts the reservation to a lock and notifies the holder of the new lock via email. Remember, the holder of the reservation is the developer assigned to the object in the CSR. If you request the lock but are not the assigned developer, you will not receive an email when the reservation turns into a lock.

All objects can be logically locked in the Stat Repository, but only by one user at a time.

The Object Locking Process

The object locking process has up to three phases.

When you associate an object with a CSR, Quest® Stat® automatically requests a lock for that object in the designated environments. Stat checks if there are existing locks or reservations on that object. If a lock or reservation exists, Stat issues a tentative reservation. If not, it issues a tentative lock. The lock or reservation remains tentative until you save the CSR.

Immediately after associating objects with a CSR, you should save your work. Upon saving, Stat checks for existing locks or reservations. If a lock or reservation exists, Stat issues a full reservation. If not, it issues a full lock.

The longer you wait to save your CSR, the greater the likelihood you will lose your place in the queue for that object. For example, while you have a tentative lock on an object, another user could add that same object to a CSR and receive a tentative reservation. If the second user then saves his or her CSR before you do, that user receives the full lock for that object, and when you save your CSR, you receive instead a full reservation.

When Stat issues a full lock, it automatically archives a “pre-change” version of the object to the Stat Repository. Archiving objects is discussed in Chapter 3.

The third phase is the conversion of reservations into locks. Stat releases an object lock when the status of the CSR changes to a closed-type status, or when the developer manually unlocks the object or the object is reassigned to another developer. After unlocking an object, the Stat Central Agent then determines if there are any pending reservations on the object. If reservations on the object have been given to more than one user, these reservations are handled in chronological order, based on the time each lock was requested. The Stat Central Agent converts the first reservation in line into a lock and performs any applicable object archiving.