Page Comparison

During project creation, choose whether to manage a single schema or multiple schema in the project. 

• Single schema: Project manages objects in a single schema.
  • The databaseChangeLog table is kept in the managed database schema.
• Multi-schema: Project manages objects in multiple schema.
  • The databaseChangeLog table is kept in a separate tracking schema that you choose or create.

It can be helpful to create a multi-schema project even if the project will manage one schema. It allows you to put the databaseChangeLog table in a schema other than the managed schema. 

Click Configure to select the schema to manage: one for single-schema projects, a list for multi-schema projects.

If you checked the "multiple database" option, use the form database.schema in the Select Schema from list. 

You can choose only for single-schema projects. Multi-schema projects are set to use Deployment Plan. 

•  Deployment Plan - select when schema names are the same across the databases for each step.
•  Deployment Step - select when schema names differ across the databases for each step.

•  Externalize Stored Logic

Place stored logic in external files rather than the changelog during the operation. If set to false, place them in the changelog. 

Note: if set to false, you may encounter excessive memory usage.  If you do, see Use Less Memory When Reloading Plan in Preferences . 

externalStoredLogic

[true | false]

•  Enable Accelerator for Oracle

Rows per Batch [10000]

•  Mark Columns as Unused...

Oracle only. Determine how to manage dropped columns.

• False - drop the column (set change type to dropColumn)
• True - mark the column as unused (set change type to markUnused). 

Forecast/Deploy

•  Require options for Forecast and Deploy

If set to true, the operation fails unless contexts and labels are specified. At least one of each must exist in the changesets being forecast or deployed. 

• Labels can be set on a project and a step
• Contexts can be set on a step.

requireOptions

[true | false]

•  Automatically generate SQL for Forecast, Deploy, and Rollback

autoGenSQL

[true | false]

•  Limit Forecast Profiling

If set to true, limit forecasting to only those objects affected by the changes. Otherwise profile all objects in the target database schema.

Note that some forecast and post-forecast rules may be skipped when this is true.

limitForecastProfiling

[true | false]

•  Enable Oracle SQL Parser

If set to true, use the SQL Parser on native Oracle SQL scripts (ddl_direct, sql, and sql_direct folders). 

See Using SQL Parser. 

•  Forecast Data Modification Changes - DML 

forecastDML

[true | false]

•  Set DDL_LOCK_TIMEOUT Value [0]

•  Set NLS_LANG Parameter

Sets the NLS_LANG environment variable on the system where Datical DB is installed when Forecast and Deploy operations are executed for the project. This setting does not persist in the environment after the operation completes.

See Writing SQL Scripts for Datical DB to learn more about when and how to use the NLS_LANG environment variable or project setting. 

To set the variable:

nlsLang "<valid_locale.valid_charset>"

To clear/unset the variable

nlsLang ""

•  Exact  

Collect accurate row counts using table scan. This method may be time consuming for large tables

enableRowCount

[exact | approximate | disabled]

•  Approximate

Collect estimated row counts using statistics. Uses database statistics as the source of information. You need to make sure the statistics are available and updated. The time saved varies, but can be significant for very large tables.

See Settings for Collecting Row Counts for the collection method for each database type. 

•  Disabled

Deployment Threshold

One of:

•  Stop Deployment on Validation Error
•  Stop Deployment on Validation Warning
•  Always Deploy (NOT RECOMMENDED)

deployThreshold

[stopOnError | stopOnWarn | deployAlways]

Stored Logic Validity Check

One of:

•  Disabled - Do not perform the Stored Logic Validity Check
•  Limited - Compile and validate objects targeted by a Deployment and their dependencies
•  Local Schema - Compile and validate objects in all schemas specified in the deployment plan
•  Global - Compile and Validate Objects in All Accessible Schema

storedLogicValidityCheck

[disabled | limited | local | global]

•  Fail Deployments that produce new invalid object errors. 

If a Stored Validity Check is performed (storedLogicValidityCheck or invalidsCheck), this storedLogicValidityAction option determines what happens when stored logic objects are found to be in an INVALID state.

Both existing objects already in the database and new objects being deployed are checked.  The VALID/INVALID state is checked prior to the deployment and then checked again after the deployment. The before and after validity state results are compared to determine whether a change of state was affected by the current deployment. 

• warn - print WARN message and continue
  • New objects that have INVALID state - print WARN message
  • Existing objects that have INVALID state - print WARN message
• fail - print WARN or ERROR message, depending on object state
  • New objects that have INVALID state - fail and print ERROR message
  • Existing objects that have INVALID state and were not affected by the current deploy operation - print WARN message
  • (7.7 & later) Existing objects that have INVALID state and were affected by the current deploy operation - fail and print ERROR message

If you are using storedLogicValidityAction=fail, we recommend setting storedLogicValidityCheck to either Local or Global (not Limited). 

Also note that there is a fix related to storedLogicValidityAction=fail in version 7.13 and higher.

Package operations: if the validity check action is set to fail and the validity check fails after deployment to REF, the package operation fails with an error and the database is restored to its state before the package operation was started. 

See also: Stored Logic Validity Check details

storedLogicValidityAction

[warn | fail]

•  Full Deploy - Perform Change Simulation and Rules Validation Before Deploying Change Sets
•  Quick Deploy - Only Deploy Change Sets

deployMode

[full| quick]

•  Specify Database Credentials at Operation Runtime

By default (false) database credentials are saved in the project file.

When set to true, any previously stored passwords are removed from all DbDefs (steps) in the project. You then use environment variables, CLI options, or user prompts to provide database credentials when an operation is run on the step. 

This project setting determines credential-checking for all databases used by the project.

• All managed databases in the project (dbdefs)
• Deployment Monitoring Console database (DMCDB) for the project. The project must be registered with a DMCDB.

Credentials are checked every time an operation accesses a database. All operations require credentials (package, forecast, deploy, rollback). 

We strongly recommend to use runtime credentials because it is more secure than stored credentials (due to the possibility of the stored password being decoded).

runTimeCredentials

[true | false]

Message shown is one of the following:

• DMC Database is not configured
• DMC Database is configured to connect to <URL> using user <username>
  Project is registered in the DMC Database

Click Configure DMC DB to configure the DMCDB database to use and provide credentials for the project to use when accessing it. Normally a DMCDB is used by all projects in an enterprise or large organization. 

We strongly recommend to use runtime credentials because it is more secure than stored credentials (due to the possibility of the stored password being decoded).

Click Manage Release Labels to add, edit, or remove labels that are set for the project.  All steps and operations share these labels. Note that other labels may be set during change packaging and deployment. 

Labels and contexts can also be set on a step. Set them when you create a step or click Edit Connection for the step. 

•  Reverse Substitute During diffChangelog