Database DevOps for Oracle

Using the Code Analysis for Oracle Command Line Preview

Note: Please contact us if you intend to use this preview feature, or if you have questions or feedback.


Code analysis is a formal automated process of scanning a piece of software code and deducing potential problems, issues and faults that may not be apparent to programmers at first glance. These could include mistakes that are easy to make for but hard to detect (such as copying and pasting something that is incorrect), the usage of obsolete elements in the code, or bad practices that, while technically correct, don’t produce the best or expected results.


Code Analysis for Oracle is free to try while in preview. The full release will require a Deployment Suite for Oracle license.


  • Supported on Windows or Linux using .NETCoreApp v2.2 (let us know if you have any problems getting this running on your preferred OS)

Release notes

  • (Preview) - April 8, 2019:
    • Parser errors output output stack trace to cao.exceptions  and no longer to console. By default parser errors don't cause a fail exit code. To enable this, use -reporterroroninternalexception
  • (Preview) - Feb 26, 2019:
    • Linux compatibility
    • Five new rules added: AvoidDistinctUseUnionAllUseHavingWithGroupBy, CreateTableStatement, TypeNameConvention (see documentation for more detail)

  • (Preview) - Jan 24, 2019:
    • Initial set of code analysis rules available on Windows command line


Run dotnet cao.cmd.dll without any parameters for help.

To analyze a specific script or a folder of .sql scripts, use the /source switch. The /outfile switch saves the code analysis results.

dotnet cao.cmd.dll /source:deployment_script.sql /outfile:CodeAnalysisResults.xml

dotnet cao.cmd.dll /source:MySQLScriptsFolder /outfile:CodeAnalysisResults.xml

To specify a subset of rules it is easiest to specify a settings file using /config:

dotnet cao.cmd.dll /config:myRules.cao.settings.xml /source:MySQLScripts /outfile:CodeAnalysisResults.xml

Supported rules

See the product documentation for a list of supported rules.


Each rule can be classified with the following severities: Ignore, Warning and Error. Ignored issues will not be reported. Warnings will be reported, but will not cause the command line to exit with an error code. If at least on Error is found, the exit code (%ERRORLEVEL%) will be "1", which means that this can be used to fail a build when running as part of a CI process.

Specify a subset of rules

By default all rules will be run and are set to the "Error" severity. To specify a subset, either use the /include, /exclude and /warning switches, or use /config with a configuration settings file. For your convenience a sample cao.settings.xml is included.  The command line comes with a sample xml file that you can edit.

Naming convention rules

These names should be provided in the form of a regular expression supported by the Regexp class. So if you want to exclude a Function where the name starts with ‘z’, you should write ^z.*, for example. For further hints on the Regular Expression language, read this Quick Reference.

Known issues and limitations

Please contact us if any limitations are causing inconvenience, or are outright blockers.

  • It is only possible to analyze SQL scripts, not a live database.

Didn't find what you were looking for?