Project settings define aspects what the project manages (schema) and how operations behave (forecast, deploy, rollback, snapshot, diffChangelog).
How to Change Project Settings
- Use the GUI or CLI tool to change project settings for a project defined on your local system where Datical DB is installed.
- Use Datical Service to change project settings for a project that was created on or imported into Datical Service.
Tool | Method | Figure |
---|---|---|
GUI | Select a project in the Deployment Plans list, then click the Settings tab. | |
CLI | Go to the project directory, then execute commands. The properties in the CLI column show properties that you manage through the | |
datical.project | In rare cases a setting must be set by hand. There is no setting in the GUI or command in the CLI. Use a text editor to edit the datical.project file. | Options are set in the |
Project Settings
Category (GUI) | Default | Description | CLI |
---|---|---|---|
Schema Management | |||
Single Schema vs Multi-Schema | N/A | During project creation, choose whether to manage a single schema or multiple schema in the project.
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. | |
Schema to be managed are in multiple databases (SQL Server Only) | No | Multi-Database project, SQL Server only. | |
Select Schema From: | Database that contains the schema. Select a database from the list. | ||
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. | ||
Tracking Schema | Click Configure to select the schema to use for the tracking database. The tracking database records operations performed on the project. | ||
Level at which Database Schema are specified | Deployment Plan | You can choose only for single-schema projects. Multi-schema projects are set to use Deployment Plan.
| |
Snapshot & Diff Settings | |||
| True | 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] |
| False | Useful when network bandwidth is a limiting factor (speed, contention, geographic separation). Works by compressing results on the database server before sending them. | |
Rows per Batch [10000] | 10000 | When using the Accelerator for Oracle, specifies the maximum number of rows to be processed at one time. If forecast or snapshot operations encounter memory errors, lowering this value can help. | |
| False | Oracle only. Determine how to manage dropped columns.
| |
Deployment Settings | |||
Forecast/Deploy | |||
| False | 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.
| requireOptions [true | false] |
| False | If true, generate the SQL code used for the operation. | autoGenSQL [true | false] |
| False | 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] |
Oracle SQL*Plus Settings | |||
| False | If set to true, use the SQL Parser on native Oracle SQL scripts (sql_direct folder). See Using SQL Parser. | N/A |
| False | If set to true, forecast whether DML changes will be successful (Oracle only). | forecastDML [true | false] |
| False | Oracle only: Set the time in seconds to wait for a locked database to become available. | |
| False | Sets the See Writing SQL Scripts for Datical DB to learn more about when and how to use the | To set the variable: nlsLang "<valid_locale.valid_charset>" To clear/unset the variable nlsLang "" |
Collect Row Counts During Forecast & Deploy | |||
| Collect accurate row counts using table scan. This method may be time consuming for large tables | enableRowCount [exact | approximate | disabled] | |
| 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. | ||
| Do not collect row counts. | ||
Deployment Threshold | |||
One of:
| Error | Set threshold condition for stopping a deployment: on error, on warning, or none (always deploy). | deployThreshold [stopOnError | stopOnWarn | deployAlways] |
Stored Logic Validity Check | |||
One of:
| Local | Determines whether and how to perform a validity check for stored logic. A validity check compiles the stored logic and validates it against the database objects. Validation fails if the stored logic references database objects incorrectly.
The Limited mode is recommended when environments are known and expected to have a large number of stored logic objects or persistently invalid stored logic objects. In the Limited mode, DaticalDB will only compile the stored logic objects that are determined to be targeted by changes included in the deployment, which may lead to significant performance improvements for deploy operations. However, for Oracle environments, objects that are valid after a deployment may be reported as invalid on the Deploy Report in some cases. This can occur when DaticalDB is unable to determine that the changes in the deployment are associated with the invalid object. For this reason, it is not recommended to use storedLogicValidityAction=FAIL when storedLogicValidityCheck=LIMITED for Oracle. See also: Stored Logic Validity Check details | storedLogicValidityCheck [disabled | limited | local | global] |
| Warn | If a Stored Validity Check is performed (invalidsCheck), determines what to do on failure. Both existing objects already in the database and new objects being deployed are checked.
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] |
Deployment Mode | |||
| Full | Determines whether to perform an internal forecast operation before deploying. If the internal forecast fails, the deploy operation does not run. | deployMode [full| quick] |
Credential Management | |||
| False | 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.
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] |
DMC Database | |||
Message shown is one of the following:
| |||
Configure DMC DB | N/A | 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). | |
Register Project | N/A | Click Register Project to register this project with the configured DMCDB. Once the project is registered, all operations on the project are logged in the DMCDB. | |
Clear DMC DB Configuration | N/A | Click Clear DMC DB Configuration to clear any previously configured connection and credentials information for DMC DB or the older Audit DB. | |
Force Sync | N/A | Click Force Sync to force a re-sync/re-base to DMC DB using the files currently active in the workspace. | forceSync |
Release Labels | |||
Manage Release Labels | N/A | 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. | modifyChangeSet |
Change Log Property Substitution | |||
Manage Properties | N/A | Click Manage Properties to add, edit, or remove properties set in the changelog. Typically properties are used along with property settings for deployment packager, especially the properties set in metadata.properties. | |
| False | When set to true, the properties are used in diffChangelog operations. |
Deploy with Options
You can override project options during deployment operation by specifying Deploy with Options.
See Deploying Changes for the list of options that can be overridden.
Preferences
To access other preferences:
- Open the Datical DB GUI
- Select File > Preferences.
- Select Changelogs in the left pane.
Changelog Preference | Default | Description |
---|---|---|
Check logicalFilePath attribute on load | On | |
Allow keywords to differ only in case (NOT RECOMMENDED) | Off | |
Use Less Memory When Reloading Plan | Off | Turn on if you encounter low-memory problems when using the GUI. Typically the following conditions may trigger excessive memory usage:
|