Contents
Change History Repository - Tracking and Auditing Deployments and Changes

Storing Only General Package Info in the Change History Repository

The Change History Repository enables users to write deployment results to a central repository database and then view and search the outcome of previously deployed code packages. Two sets of data are stored in the repository - general package deployment info and detailed database changes. General package information consists of a single row for each package deployment, whereas detailed changes track all changes made to target databases during the package deployment. The detailed info stores a single row for each script and each target database. Additional information regarding the records stored in the repository can be found in the Overview section.

Users can configure Combine on their client machines to either:
- Write only general package info to the Change History Repository
- Write both general package info and detailed database changes to the repository

To instruct Combine to write only general package info to the Change History Repository, users should go to Tools → Option → Packages → Change History. First, users must enter the location of the Change History Repository database and provide the credentials that will be used to connect and use (i.e., read from or write to) the repository. Then, users should uncheck the checkbox Store Extended Package Deployment Details and click the Apply button in the Options dialog.




Figure 102.0a2:  Instructing Combine to not save the detailed DB change info.





If you choose to only store general deployment results, then Combine only writes a single row to the repository for each package deployment (you can still manually recover and populate the details from the general package info; for more info see the section titled Recovering Detailed DB Change Info from the General Package Info). In practice, this means that under the Change History tool (under Tools in the main menu) you will only see the general information relating to the execution of code packages. For example, if a code package contains 10 scripts and each script is executed against a Container with 5 target databases, then one row will be written to the repository. When viewing the deployment results as in the image below, all users that can read and search the repository will only see one row in the general info top grid for this deployment. This row contains the deployment start and end times, the name of the Environment on which the package was deployed, description of Environment Variable replacements (when applicable), the content of the Cre and the (wrapped) Cpa file, and other relevant fields (see the Overview section for complete details).




Figure 102.0a3:  Viewing deployment results after only saving the general package info.





Advantages and Disadvantages. When choosing whether to only store general package info or to also record the detailed database changes, users should consider the following two factors:

1. After a package is executed, if Combine is configured to only store the general package deployment results, then only one row is written to the repository. On the other hand, if Combine also stores the detailed database changes, then one row will be written to the repository for each script and target database pair. For example, when Combine stores detailed info and a package contains 100 scripts and each script is executed on 10 target databases, then Combine will write the one row containing the general info plus 1000 rows containing details of DB changes. Therefore, writing database change details will take longer than only writing the general deployment info.

2. When using the Change History tool to view past deployment results, users can search the repository to find exact deployment details (e.g., all scripts that were deployed on a certain database, scripts that were executed using a certain SQL login, and so on). However, if you choose to only store the general deployment info, then searches are limited in accuracy and capabilities.


Related Topics. Combine can also be configured to prompt and ask users whether deployment results should be written to the repository before a package is executed. Alternatively, users can instruct Combine to always write the deployment results. To set these options, go to Tools → Options → Packages → Auto Save Results and select the desired option from the drop-down menu next to the Change History Repository entry (see image below). If you select Prompt, then Combine will prompt and ask you whether you wish to store deployment results in the repository before a package is executed. On the other hand, you can set this option to True to always store the deployment results. The last option (i.e., False) allows you to choose to not be prompted and not store any execution results to the repository.




Figure 102.0a4:  Configuring Combine to prompt or always store deployment results.








© 2001-2017 JNetDirect, Inc. All Rights Reserved.