Skip to content
dbLinter

check

This command runs a static code analysis using a configuration that is defined in the Web GUI. This feature is only available with an Essential or Professional Subscription.

Syntax

Section titled “Syntax”
dblinter [<options>] check [<args>]

Options

Section titled “Options”

See Options. Mandatory options are tenantName, userName, accessToken and configName.

Argument Syntax

Section titled “Argument Syntax”
--<argument>=<value>

Arguments

Section titled “Arguments”

It is not possible to set arguments using environment variables. Beside that, in dbLinter, both arguments and options are treated in the same way. Therefore, they can be used in any order. For example, they can be used before or after the command name. The only exception is <paths...>, which must always be placed at the end. We use options when the semantics are identical for each applicable command. Arguments are used when the semantics change for a command.

  • outputFormats
    A comma-separated list of the output formats to be produced. All formats are considered by default. The following formats are supported:

    • vscode: dbLinter Check Report as Markdown for VS Code. This report will open automatically when the analysis is run via the VS Code extension.
    • sonarqube: SonarQube Generic formatted issue report to import issues in any SonarQube edition without any plugin.
    • sarif: Static Analysis Results Interchange Format (SARIF) to visualise issues in various tools. See also Viewers.
    • checkstyle: Checkstyle XML report.
    • github: Workflow commands for GitHub Actions. These commands (annotations) are interpreted when printed to stdout.
    • gitlab: GitLab quality report.

  • outputName
    This is the relative path from the working directory to the base name of the output files. Missing target directories will be created. For example, if you use the name check for an outputName, a file called check.vscode.md will be created in the working directory. The default is dblinter.

  • parallel
    The number of files analysed in parallel. The default is 1. To achieve better performance with higher values, you need enough free system resources. Also consider increasing the maximum heap space using the JAVA_OPTS environment variable. For example, export JAVA_OPTS=-Xmx=32G to set the maximum heap size to 32GB. The default maximum heap size for a system with 64 GB of RAM is 16 GB (one quarter), which is sensible for desktop systems. In CI/CD environments, however, higher values can improve performance, especially when processing large files.

  • <paths...>
    The files and directories to analyse. By default, all files in the workspace are included/excluded according to the glob patterns defined in the configuration. Any files and directories that are passed are treated as an additional filter. In other words, files and directories outside of the workspace cannot be analysed.

Example

Section titled “Example”
Terminal window
dbLinter-Demo % dbLinter check \
    --tenantName=Demo \
    --userName=philipp.salvisberg+42@gmail.com \
    --accessToken=*** \
    --configName=Default \
    --outputFormats=vscode,github \
    --outputName=check \
    --parallel=2 \
    ./*.sql examples/Core-G-1*.sql

The console output for the dbLinter-Demo project on GitHub looks like this:

Using connection to jdbc:oracle:thin:@localhost:1521/freepdb1 with user DBL_READ
Processed examples/Core-G-1010.sql (1/25) in 0.148 sec. Found 4 issues.
Processed examples/Core-G-1020.sql (2/25) in 0.403 sec. Found 8 issues.
Processed examples/Core-G-1030.sql (3/25) in 0.280 sec. Found 2 issues.
Processed examples/Core-G-1050.sql (4/25) in 0.023 sec. Found 3 issues.
Processed examples/Core-G-1060.sql (5/25) in 0.014 sec. Found 2 issues.
Processed examples/Core-G-1070.sql (6/25) in 0.005 sec. Found 2 issues.
Processed examples/Core-G-1080.sql (7/25) in 0.041 sec. Found 1 issue.
Processed examples/Core-G-1110.sql (8/25) in 0.027 sec. Found 2 issues.
Processed examples/Core-G-1120.sql (9/25) in 0.003 sec.
Processed examples/Core-G-1130.sql (10/25) in 0.003 sec.
Processed examples/Core-G-1140.sql (11/25) in 0.001 sec.
Processed examples/Core-G-1150.sql (12/25) in 0.001 sec.
Processed examples/Core-G-1210.sql (13/25) in 0.027 sec.
Processed examples/Core-G-1040.sql (14/25) in 0.186 sec. Found 8 issues.
Processed examples/Core-G-1220.sql (15/25) in 0.054 sec.
Processed examples/Core-G-1230.sql (16/25) in 0.110 sec. Found 2 issues.
Processed examples/Core-G-1240.sql (17/25) in 0.071 sec. Found 2 issues.
Processed examples/Core-G-1260.sql (18/25) in 0.009 sec. Found 1 issue.
Processed examples/Core-G-1250.sql (19/25) in 0.017 sec. Found 2 issues.
Processed examples/Core-G-1270.sql (20/25) in 0.008 sec. Found 1 issue.
Processed examples/Core-G-1310.sql (21/25) in 0.004 sec. Found 1 issue.
Processed examples/Core-G-1280.sql (22/25) in 0.009 sec. Found 1 issue.
Processed examples/Core-G-1920.sql (23/25) in 0.003 sec. Found 1 issue.
Processed examples/Core-G-1910.sql (24/25) in 0.014 sec. Found 2 issues.
Processed install.sql (25/25) in 0.235 sec.
Check Summary
- Duration:                   0.964 sec.
- Files:                      25
- Characters:                 17,073
- Lines:                      590
- Lines of code:              279
- Statements:                 47
- PL/SQL units:               4
- Functions:                  5
- Comment line density:       7.4%
- Cyclomatic complexity (CC): 8
- Max CC per unit:            3
- Avg CC per unit:            2
- Errors:                     15
- Warnings:                   29
- Infos:                      1