/
CLI Commands

Liquibase Enterprise was formerly known as Datical DB.

CLI Commands

Nov 18, 2025

Database Credentials

The command descriptions assume that database credentials are stored in the project (the default) or in environment variables.

If you have runtimeCredentials set and the credentials are not stored in environment variables, then you need to specify the database credentials on the command line.

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).

See Database Credential Management. 

Single-credential

Commands that work on a single database (dbdef) require the -un <username> and -pw <password> options to specify the database credentials.

Two-credential

Commands that work on two databases require credentials for the reference (desired state) and target (changed) databases

  • Reference database:  Use -ru <username> and -rpw <password> options.

  • Target database:  Use -tu <username> and -tpw <password> options.

Getting Help

To get a list of available commands, run hammer help at a system command prompt. 

Datical DB CLI Help
USAGE: hammer [OPTION]... [COMMAND] [OPTIONS]... Use 'hammer help options' for available options Use 'hammer help [COMMAND] for more help on a command AVAILABLE COMMANDS: add-to-property: Add a path to a property. addContexts: Add contexts to change sets. addLabels: Add labels to change sets. assignMetadata: Assign metadata information to a label. changelogSync: Mark all changes as executed in the database. checkDrivers: Check that JDBC driver jars are installed or on the specified paths. checkRules: Compiles rules and reports any errors. clearCheckSums: Delete the checksums used to detect altered change sets from the tracking tables. dbshow: List all databases for a project, along with extra info about each. deploy: Deploy the changelog, updating the target database's schema to the latest version. deploy-autoRollback: Deploy the changelog to the target database; if an error occurs, rollback to the revision before the command was given. diff: Compares two databases and produces a report. diffChangelog: Compares two databases and produces a changelog. findChangeSets: Locates changesets based on label expression and script checksum forceSync: Force a re-sync/re-base to DMC DB using the files currently active in the workspace available to hammer. forecast: Simulate unexecuted change sets against the specified database. groovy: Run a script that can use Datical DB REPL commands using the Groovy script engine. help: Print help on available commands. history: Show the applied change set history of a database. installDrivers: Run the custom script 'installDrivers.groovy'. installLicense: Install a license file to allow continued use of Datical DB. modifyChangeSet: Modify changeset attributes. newDbDef: Creates a new dbDef based on the key/value pairs specified as arguments. registerProjectWithDMCDB: Register project with DMC database releaseLocks: Unlock a locked environment so that Datical/Liquibase commands can be run against it. removeContexts: Remove contexts from change sets. removeLabels: Remove labels from change sets. rollback: Roll the target database back to a previous state, using a variety of methods. runRules: Runs rules from the SQLRules folder on the specified SQL file or folder of SQL files. schemaStats: Display summary schema info. set: Set properties, database definitions, etc. See 'set help' for more information and sub commands. show: Display project properties, database definitions, etc. See 'show help' for more information and sub commands. snapshot: Captures a snapshot of a database as either a persistent object file or as a Liquibase changelog. status: Show the deployment status of a database. statusDetails: Show detailed status for each of the changesets in the changelog. testConnect: Test the connection for one or more databases. uninstallDrivers: Run the custom script 'uninstallDrivers.groovy'. validateStoredLogic: Compiles stored logic and reports any validation errors. versionChangeLog: Upgrades project changelog to the current version.



add-to-property

Add a path to a property

USAGE

add-to-property <property> <path>

EXAMPLE

add-to-property drivers /home/user/newdrivers

NOTES

This command appends a new path to an existing property that expects path values.



addContexts

Add contexts to changesets. Adds context attributes to a set of changesets in the changelog. The attributes are selected using a label expression. This command is used by the Deployment Packager to indicate that a group of changesets is ready to be deployed to a new environment.


Note

Starting with v4.32, please use the modifyChangeSet command. The addContexts command is deprecated and support may be removed in the future. 

USAGE

addContexts --lookupChangesets=<label-expression> --context=<contexts> [--scriptChecksum=<checksum>] [--matchAll=true|false]

OPTIONS

  • lookupChangesets - Label expression used to matchthe change sets (required)

  • context - Comma-separated list of contexts (required)

  • scriptChucksum - SQL script checksum value

  • matchAll - SQL Script checksums must match for change set lookup. Default value is true. 

NOTES

The value of the scriptChecksum parameter can be used to further qualify change sets that match the label expression. This is used primarily in the Deployment Packager to confirm that the change set was generated by the expected version of a script.

The value of the matchAll parameter impacts the matching behavior of the scriptChecksum parameter.

  • If matchAll is true, all change sets identified by the label expression must have a scriptChecksum attribute that matches the attribute passed on the command line.

  • If matchAll is false, only one change set returned by the label expression needs to have a matching scriptChecksum attribute.





addLabels

Add labels to changesets. Adds label attributes to a set of changesets in the changelog that are selected using a label expression.

Note

Starting with v4.32, please use the modifyChangeSet command. The addLabels command is deprecated and support may be removed in the future. 

USAGE

addLabels --lookupChangesets=<label-expression> --context=<contexts> [--scriptChecksum=<checksum>] [--matchAll=true|false]

OPTIONS

  • lookupChangesets - Label expression used to match the change sets (required)

  • labels - Comma-separated list of labels (required)

  • scriptChecksum - SQL script checksum value

  • matchAll - SQL Script checksums must match for change set lookup. Default value is true

NOTES

The value of the scriptChecksum parameter can be used to further qualify change sets that match the label expression. This is used primarily in the Deployment Packager to confirm that the change set was generated by the expected version of a script.

The value of the matchAll parameter impacts the matching behavior of the scriptChecksum parameter.

  • If matchAll is true, all change sets identified by the label expression must have a scriptChecksum attribute that matches the attribute passed on the command line.

  • If matchAll is false, only one change set returned by the label expression needs to have a matching scriptChecksum attribute.



assignMetadata

Assign metadata information to a label. Used to associate more information with a label than could be expressed in the label itself. The metadata is stored in the project’s associated DMC database, so this command requires that an DMC database has been configured for the project.

USAGE

assignMetadata --metdataLabel=<label name> --metadataFile=<path to file>

OPTIONS

  • metadataLabel - Name of the label

  • metadataFile  - Path to a properties file containing the metadata key-value pairs



changelogSync

Mark all change sets as executed in the database. Marks all changesets as applied to the specified database.

USAGE

changelogSync <dbdef> <options>

EXAMPLE

changelogSync myAppDev --mergeLabels=merge --pipeline=Feature1

OPTIONS

  • labels - Comma-separated list of labels

  • mergeLabels - Label merge strategy, one of override (default), merge (AND), append (OR). Specifies how to combine labels set on the command line with labels set on the step. 

  • pipeline - Specifies the pipeline associated with the changelogSync for reporting purposes.

    • If not set and the dbDef is a member of only one pipeline, then that pipeline is used.

    • If not set and the dbDef is a member of multiple pipelines, then an error is returned.

NOTES

USE CAUTION! Before running changelogSync, verify that the specified database is up to date!

Running changelogSync against a database that is not complete can lead to future deployment failures.





checkDrivers

Check that JDBC driver jars are installed or on the specified path. Scans the path(s) specified by the 'drivers' property for accessible JDBC drivers.

USAGE

checkDrivers

EXAMPLE OUTPUT

Found installed driver: com.ibm.db2.jcc.DB2Driver driver: (v3.63) jar: (v1.0.11.20181126111708)
Found installed driver: com.datical.jdbc.oracle.DaticalOracleDriver jar: (v0.0.60.20181126114644)
Found installed driver: com.microsoft.sqlserver.jdbc.SQLServerDriver driver: (v6.3) jar: (v1.0.11)
Found installed driver: oracle.jdbc.OracleDriver driver: (v18.3) jar: (v1.0.11)

NOTES

There are several ways to configure Datical DB to use the JDBC drivers that communicate with the databases being managed. The preferred method is to install the drivers into the OSGi environment using the installDrivers command. Drivers can also be found by creating a properties file in the project and then either

  • manually editing the file

  • using the command set property drivers <path-to-drivers>

For more information on setting the drivers property, see the help: help set property

Note

For backward compatibility, checkdrivers (all lowercase) also works. 



checkRules

Compiles rules and reports any errors.

USAGE

checkRules [PreForecast|Forecast|PostForecast|SqlRules]

EXAMPLE

checkRules PreForecast

OPTIONS

  • rulesFolder - specifies the folder to check, one of PreForecast, Forecast, PostForecast, SqlRules. These are the standard folders under the Rules folder for the project. If rulesFolder is not specified, then rules in all the standard folders are compiled.

NOTES

Run the command from a valid Datical DB project directory.



clearCheckSums

Delete the checksums used to detect altered change sets from the tracking tables.

USAGE

 clearCheckSums <dbdef>

EXAMPLE

clearCheckSums myAppDevDB

OPTIONS

NOTES

Use only under the direction of a Datical Support Engineer or if you are very experienced with Datical DB.

This command is helpful when you need to respond to a change to an existing object that is made outside of Datical DB. For example, someone uses a SQL script to change a database directly.  It allows you to update the change set that creates this object and clear the existing checksums to avoid validation errors. The checksums are recreated on the next deploy or changeLogSync command. 





create

Create various project artifacts.

USAGE

create <object> <options>

OBJECTS

  • DbDef <json_file> - create a new DbDef in the current project using <json_file>, a file containing JSON key-value pairs.

{ "DbDefClass":"OracleDbDef", "name":"MyNewOracleDB", "hostname":"127.0.0.1", "port":"1521", "username":"orclUser", "password":"hammer01@", "sid":"ORCLSID", "contexts":"DEV,QA" }


Keys

  • DbDefClass - Database type (OracleDbDef | Db2DbDef | MysqlDbDef | SqlServerDbDef | PostgresqlDbDef)

  • name - Name for the dbDef. Used as an alias in the command interpreter and the UI.

  • hostname - Host name or IP address of the target database server

  • port - Port number for JDBC connections to the target database server

  • username - Database user name to use for the connection

  • password - Password for the database user

  • database - (for MySQL, DB2, Postgres) The name of the database you wish to manage.

  • databaseName - (for SQLServer)  The name of the database you wish to manage.

  • instanceName - (for SQLServer)  The name of the instance you wish to manage.

  • applicationName - (for SQLServer)  The name of the database application you wish to manage.

  • sid - (for Oracle) - Oracle SID for the connection

  • serviceName - (for Oracle) - Oracle Service for the connection

  • defaultSchemaName - Name of the schema/catalog to manage.

  • contexts - Comma-separated list of contexts for the DbDef.



dbshow

List all databases for a project, along with extra info about each. 

USAGE

dbshow

dbshow <dbdef>...

EXAMPLE

dbshow DEVdb QAdb STAGEdb

NOTES

If you use the command without specifying a database, information for all dbdefs is shown.

To obtain information on a subset of database definitions, use their names as command line parameters.

OUTPUT

Lists the name, URL, database name, alternate schema, and default context.



debug export

Export and scrub sensitive data from files to be sent to Datical support for debugging or troubleshooting.

USAGE

debug export [--scrub=true|false] [--include=<searchstring>[,<searchstring>,...]] [--exclude=<searchstring>[,<searchstring>,...]] [--lastmodified=<N>] [--report=<path/file>]

EXAMPLE

debug export 



OPTIONS

  • --scrub=true|false - Default is true. When set, scrub will replace sensitive information (such as usernames, hostnames, ports) with generic strings (tokens). 

  • --include=<searchstring>[,<searchstring>,...] - include only files specified by one or more search strings (filters). 

  • --exclude=<searchstring>[,<searchstring>,...] - include all files except those specified by one or more search strings (filters). 

  • --lastmodified=<N> - include only files modified within the last <N> hours.Specifies the pipeline associated with the changelogSync for reporting purposes.

  • --report=<path/file> - put the resulting zip file in a specified file. By default it is placed in <project>/Reports/debug/<project>.zip

NOTES

Run the command at the root of a project directory, <project>. 

For use case scenarios and examples, see Assembling Data for Datical Support. 

To include an external file, place it in the project directory, preferably in the root, <project>.

Do not use : or / characters in <searchstring>. If you search for a URL, do not include the prefix (http://, https://)

OUTPUT

Creates a zip file of the specified project files. The zip file is placed in <project>/Reports/debug/<project>.zip by default. 



deploy

Deploy the changelog, updating the target database schema to the latest version. Deploys all change sets that have not been applied to the indicated database in the project.

USAGE

deploy <dbdef> [–log=] [--enableRowCount=exact|approximate|disabled] [--pipeline=<name>] [--report=<path>] [--context=context1,context2] [--labels=<label expression>][--mergeLabels=override|merge|append][--immutableProject=<true|false>][--invalidsAction=<warn|fail>]

EXAMPLE

deploy myAppDevDb --log=/home/user/dbadmin/daticallogs/ --report=/home/user/dbadmin/daticalreports --context=dev,integration --labels="JUN AND (poolApp or beachApp)" --invalidsAction=fail

DATICAL SERVICE OPTIONS

Use these options to access a project that is stored on Datical Service. 

  • --daticalServer=<cluster-name> - The cluster name set for Datical Service. The cluster name is set during Datical Service installation. 

  • --daticalUsername=<user> - User name, must be configured in Datical Service. Use the DATICAL_PASSWORD environment variable to provide the password. 

  • --projectKey=<projectRef> - Project to use, specified <projectRef>,  a project name or project key. The project key is defined in Datical Service only. 

OPTIONS

  • log - When set, the daticaldb.log file will be written to the directory specified. Log is written to Logs directory of project by default.

  • enableRowCount - exact | approximate | disabled, method for counting rows in tables. Default is disabled. 

    • Before v5.7 used true | false, with default as true. New default is disabled. Older projects are interpreted correctly and mapped to the new values. 

  • pipeline - Specifies the pipeline associated with the changelogSync for reporting purposes.

    • If not set and the dbDef is a member of only one pipeline, then that pipeline is used.

    • If not set and the dbDef is a member of multiple pipelines, then an error is returned.

  • report - When set, deploy report will be written to the directory specified. Report is written to the Reports directory by default.

  • context - When set, only change sets marked with the contexts specified will be executed. To run all contexts, specify $all.

  • labels - When set, only change sets marked with the label expression will be executed. To run all labels, specify $all.

  • mergeLabels - Label merge strategy, one of override (default), merge (AND), append (OR). Specifies how to combine labels set on the command line with labels set on the step. 

  • deployMode - Override the deployMode project setting, either full (default), which includes forecasting and rules checking, or quick.

  • limitForecast - Override the limitForecast project setting. Set to either false (default), where forecasting is done for all objects in the target database, or true, which limits forecasting to objects directly affected by the deployment. 

  • immutableProject - When running with Datical Service options, set to true to use the local project files rather than download the project information from Datical Service. Helpful in automated environments where project files are kept in artifact repositories. 

  • invalidsAction - Override the storedLogicValidityAction project setting for this deploy.

    • warn: Set to either warn (default), current behavior. New invalid stored logic will cause the Deploy to flag as deployment warning.

    • fail: New invalid stored logic will cause a deployment to be marked as a failure.
      Option would be applied when Stored Logic Validity Check is not disabled.



diff

Compare two databases and produce a report. Compares two database definitions in a project and produces a text report of the differences.

USAGE

diff <referenceDB> <targetDb> [--output=/path/to/report]

EXAMPLE

diff myAppDevDB myAppQaDB --output=<path>

OPTIONS

  • ddlExcludeList– comma-separated list of object types to exclude from the snapshot. Can be all, none, or a list containing any combination of procedure, function, package, packagebody, trigger, non_stored_logic, or view.

  • referenceDB - database that represents the desired state

  • targetDB - database that is out of synchronization and needs to be caught up to the state of referenceDB.

  • output - If present, specifies a file for the report. If not specified, the report is sent to STDOUT



diffChangelog

Compares two database definitions in a project and produces the change sets necessary to synchronize the databases.

USAGE

diffChangelog <referenceDB> <targetDb> [--output=<path>] [--assignLabels=<labels>] [--assignContexts=<contexts>] [–-scriptChecksum=<checksum>]

EXAMPLE

myAppDevDB myAppQaDB --output=/home/user/diffChangeLogsdir/diffChangeLog.xml --assignLabels=label1,label2 --assignContexts="(contextOne and contextTwo)" 

OPTIONS

  • referenceDB - database that represents the desired state, either a dbdef in the project or a snapshot file. 

  • targetDB - database that is out of synchronization and needs to be caught up to the state of referenceDB, either a dbdef in the project or a snapshot file

  • output - if present, specifies the file for the generated changelog. Use file extension .xml. If not specified, output is written to  the Reports/DiffChangeLogs subdirectory under the project directory. If the file exists, the results of the command (changesets) are appended to the existing file. 

  • ddlExcludeList – comma-separated list of object types to exclude from the snapshot. Can be all, none, or a list containing any combination of procedure, function, package, packagebody, trigger, non_stored_logic, or view.

  • assignLabels - apply this set of labels applied to all changesets created. Accepts a comma separated list of labels.

  • assignContexts - apply this set of contexts to to all changesets created. Accepts a complex context expression.

  • scriptChecksum - SQL script checksum value

forceSync

The forceSync forces a re-sync/re-base to DMC DB using the files currently active in the workspace available to hammer.  Note that some warning messages refer to this forcesync command as "the resync command in the CLI".

USAGE

forceSync

EXAMPLE

forceSync



forecast

Simulate unexecuted change sets and run rules against the specified database.

USAGE

forecast <dbdef> [--log=/path/to/log]  [--enableRowCount=exact|approximate|disabled] [--report=/path/to/report] [--context=context1,context2] [--labels=<label expression>][--mergeLabels=override|merge|append][--limitForecast=true|false][--immutableProject=<true|false]

EXAMPLE

forecast myAppDevDb --log=/home/user/logs/ --report=/home/user/reports --context=dev,qa --labels="JUN AND (poolApp or beachApp)" --limitForecast=true

DATICAL SERVICE OPTIONS

Use these options to access a project that is stored on Datical Service. 

  • --daticalServer=<cluster-name> - The cluster name set for Datical Service. The cluster name is set during Datical Service installation. 

  • --daticalUsername=<user> - User name, must be configured in Datical Service. Use the DATICAL_PASSWORD environment variable to provide the password. 

  • --projectKey=<projectRef> - Project to use, specified <projectRef>,  a project name or project key. The project key is defined in Datical Service only. 

OPTIONS

  • <dbdef> - project dbdef name of the database to use for forecasting

  • log - Location to write the daticaldb.log file. Log is written to Logs directory of project by default.

  • enableRowCount - exact | approximate | disabled, method for counting rows in tables. Default is disabled. 

    • Before v5.7 used true | false, with default as true. New default is disabled. Older projects are interpreted correctly and mapped to the new values. 

  • report - Location to write the forecast report. Report is written to the Reports directory by default.

  • context - Only change sets marked with the contexts specified are executed. To run all contexts, specify $all.

  • labels - When set, only change sets marked with the label expression are executed. To run all labels, specify $all.

  • mergeLabels - Label merge strategy, one of override (default), merge (AND), append (OR). Specifies how to combine labels set on the command line with labels set on the step. 

  • limitForecast - Override the limitForecast project setting. Set to either false (default), where forecasting is done for all objects in the target database, or true, which limits forecasting to objects directly affected by the potential deployment. 

  • immutableProject - When running with Datical Service options, set to true to use the local project files rather than download the project information from Datical Service. Helpful in automated environments where project files are kept in artifact repositories. 



groovy

Run a Groovy script. Runs a script of Datical DB commands using the Groovy script engine.  

USAGE

groovy <script-name> <script-options>

EXAMPLE

groovy myScript.groovy show(project, ["dbprop", "myProject", "enableStorageOptions"])

OPTIONS

  • <script-name> - path to a script name

  • <script-options> - Options to pass to the script

NOTES

To access Datical DB commands through the script, access them through the DaticalDb object. The parameters for a command are (project, List<String> <[parameters]>). Use the word "project" as shown below.

Exceptions: add-to-property is accessed by addToProperty and deploy-autoRollback is accessed by deploy-AutoRollback.

Copyright © Liquibase 2012-2022 - Proprietary and Confidential