dbLinter

What Is dbLinter?

dbLinter is a tool suite for checking and improving the quality of database applications. Quality is assessed using static code analysis and database queries based on a centrally managed configuration.

dbLinter targets all versions of Oracle Database and PostgreSQL using a predefined, configurable ruleset that is based on the Trivadis Coding Guidelines.

Key Features

Static Code Analysis

Analyse your SQL, PL/SQL, PL/pgSQL, SQL*Plus, SQLcl and psql files. Without connecting to a database.

SQL-based Tests

Run SQL queries against your database. Each result row represents a problem that needs to be solved.

Quick Fixes

Automatically apply quick fixes, migration scripts or mark problems to be ignored in subsequent analyses or test runs.

IDE Integration

Highlight problems while you code in VS Code, Cursor, Windsurf or Theia IDE. Providing explanations with links to coding guidelines and suggested fixes.

CI/CD Pipeline Integration

Integrating dbLinter into your build pipeline helps to block any changes that cause severe problems from reaching production.

SonarQube Integration

Provides seamless integration with any on-prem SonarQube edition. Enabling rule configuration, issue browsing, and enforcement through quality gates considering new code.

Predefined Rules

Extensive set of 180+ predefined rules, that can be enabled/disabled and parametrised. A rule is implemented as static code analysis check and/or SQL-based test.

Custom Rules

If the predefined rules are not enough, define your own. Either as static code analysis check, or SQL-based test, or both.

Subscriptions

dbLinter is a joint project between Grisselbav and United Codes. You can get commercial subscriptions through United Codes. See the dbLinter product site for details.

Here are the features that come with the different subscription plans:

Feature	Anonymous	Starter	Essential	Professional
Number of seats	unlimited	1	1-n	1-n
Number of configurations	-	1	unlimited	unlimited
View rules and related data	yes	yes	yes	yes
Manage configurations	-	yes	yes	yes
Run checks	yes	yes	yes	yes
Run SQL-based tests	-	yes	yes	yes
Ignore chosen SQL-based test findings	-	yes	yes	yes
dbLinter VS Code extension	yes	yes	yes	yes
Run all accessible checks and tests	(preview)	(preview)	yes	yes
Quick fixes in dbLinter VS Code extension	(preview)	(preview)	yes	yes
dbLinter CLI with SonarCloud integration	-	(preview)	yes	yes
Manage user access	-	-	yes	yes
dbLinter SonarQube plugin	-	-	-	yes
Access to dbLinter test repository	-	-	-	yes
Custom rules, checks and SQL-based tests	-	-	-	yes
Generate Java project for checks and SQL-based tests	-	-	-	yes
Manage custom validators (plugins)	-	-	-	yes
Export rules and configurations	-	-	-	yes
Import rules and configurations	-	-	-	yes

The features marked with (preview) are only available during the preview phase.

Rules

The Anonymous plan is active when you use the dbLinter VS Code extension without setting up a dbLinter account. Only those rules that should be applicable to any project without any configuration are enabled in this plan.

The free Starter plan includes all other rules, except for those reserved for the paid Essential and Professional plans.

To enable, disable and configure rules you need to create a dbLinter account. Visit the dbLinter Web-GUI click on Sign in and then on Sign up and follow the instructions.

Rule	Anonymous	Starter	Essential	Professional
G-1010: Try to label your sub blocks.	-	yes	yes	yes
G-1020: Always have a matching loop or block label.	-	yes	yes	yes
G-1030: Avoid defining variables that are not used.	yes	yes	yes	yes
G-1040: Avoid dead code.	yes	yes	yes	yes
G-1050: Avoid using literals in your code.	-	yes	yes	yes
G-1060: Avoid storing ROWIDs or UROWIDs in database tables.	yes	yes	yes	yes
G-1070: Avoid nesting comment blocks.	-	yes	yes	yes
G-1080: Avoid using the same expression on both sides of a relational comparison operator or a logical operator.	yes	yes	yes	yes
G-1110: Avoid connect users that own database objects.	-	yes	yes	yes
G-1120: Avoid granting system privileges to connect users.	-	yes	yes	yes
G-1130: Avoid granting table access to API roles.	-	yes	yes	yes
G-1140: Avoid granting object privileges directly to connect users.	-	yes	yes	yes
G-1150: Always limit privileges of schema owners according to principle of least privileges.	-	yes	yes	yes
G-1210: Never create a table without a primary key.	-	yes	yes	yes
G-1220: Avoid composite primary keys.	-	yes	yes	yes
G-1230: Avoid tables without relationships.	-	yes	yes	yes
G-1240: Try to index foreign key columns.	-	yes	yes	yes
G-1250: Try to define a business key for each table.	-	yes	yes	yes
G-1260: Try to define a comment for each table.	-	yes	yes	yes
G-1270: Try to define a comment for each column.	-	yes	yes	yes
G-1280: Try to use domains instead of raw datatypes for table columns.	-	yes	yes	yes
G-1310: Never keep database objects in an invalid state.	-	yes	yes	yes
G-1910: Avoid using the NOSONAR marker.	-	yes	yes	yes
G-1920: Avoid syntax errors.	yes	yes	yes	yes
G-1930: Avoid long parsing times.	-	yes	yes	yes
G-1940: Avoid long checking times.	-	yes	yes	yes
G-2110: Try to use anchored declarations for variables, constants and types.	-	yes	yes	yes
G-2120: Try to have a single location to define your types.	-	yes	yes	yes
G-2130: Try to use subtypes for constructs used often in your code.	-	yes	yes	yes
G-2135: Avoid assigning values to local variables that are not used by a subsequent statement.	yes	yes	yes	yes
G-2140: Never initialize variables with NULL.	yes	yes	yes	yes
G-2145: Never self-assign a variable.	yes	yes	yes	yes
G-2150: Avoid comparisons with NULL value, consider using IS [NOT] NULL.	yes	yes	yes	yes
G-2160: Avoid initializing variables using functions in the declaration section.	-	yes	yes	yes
G-2170: Never overload variables.	yes	yes	yes	yes
G-2180: Never use quoted identifiers.	yes	yes	yes	yes
G-2185: Avoid using overly short names for explicitly or implicitly declared identifiers.	-	yes	yes	yes
G-2190: Avoid using ROWID or UROWID.	yes	yes	yes	yes
G-2210: Avoid declaring NUMBER variables, constants or subtypes with no precision.	yes	yes	yes	yes
G-2220: Try to use PLS_INTEGER instead of NUMBER for arithmetic operations with integer values.	yes	yes	yes	yes
G-2230: Try to use SIMPLE_INTEGER datatype when appropriate.	yes	yes	yes	yes
G-2310: Avoid using CHAR data type.	yes	yes	yes	yes
G-2320: Never use VARCHAR data type.	yes	yes	yes	yes
G-2330: Never use zero-length strings to substitute NULL.	yes	yes	yes	yes
G-2340: Always define your VARCHAR2 variables using CHAR SEMANTIC (if not defined anchored).	yes	yes	yes	yes
G-2410: Try to use boolean data type for values with dual meaning.	-	yes	yes	yes
G-2510: Avoid using the LONG and LONG RAW data types.	yes	yes	yes	yes
G-2610: Never use self-defined weak ref cursor types.	yes	yes	yes	yes
G-3110: Always specify the target columns when coding an insert statement.	yes	yes	yes	yes
G-3115: Avoid self-assigning a column.	yes	yes	yes	yes
G-3120: Always use table aliases when your SQL statement involves more than one source.	yes	yes	yes	yes
G-3130: Try to use ANSI SQL-92 join syntax.	-	yes	yes	yes
G-3140: Try to use anchored records as targets for your cursors.	-	yes	yes	yes
G-3145: Avoid using SELECT * directly from a table or view.	yes	yes	yes	yes
G-3150: Try to use identity columns for surrogate keys.	-	yes	yes	yes
G-3160: Avoid visible virtual columns.	-	yes	yes	yes
G-3170: Always use DEFAULT ON NULL declarations to assign default values to table columns if you refuse to store NULL values.	(preview)	(preview)	yes	yes
G-3180: Always specify column names instead of positional references in ORDER BY clauses.	yes	yes	yes	yes
G-3182: Always specify column names/aliases instead of positional references in GROUP BY clauses.	yes	yes	yes	yes
G-3183: Always specify column aliases instead of expressions in GROUP BY clauses.	-	yes	yes	yes
G-3185: Never use ROWNUM at the same query level as ORDER BY.	yes	yes	yes	yes
G-3190: Avoid using NATURAL JOIN.	yes	yes	yes	yes
G-3195: Always use wildcards in a LIKE clause.	yes	yes	yes	yes
G-3210: Always use BULK OPERATIONS (BULK COLLECT, FORALL) whenever you have to execute a DML statement for more than 4 times.	-	yes	yes	yes
G-3220: Always process saved exceptions from a FORALL statement.	yes	yes	yes	yes
G-3310: Never commit within a cursor loop.	yes	yes	yes	yes
G-3320: Try to move transactions within a non-cursor loop into procedures.	-	yes	yes	yes
G-3330: Avoid autonomous transactions.	(preview)	(preview)	yes	yes
G-4110: Always use %NOTFOUND instead of NOT %FOUND to check whether a cursor returned data.	-	yes	yes	yes
G-4120: Avoid using %NOTFOUND directly after the FETCH when working with BULK OPERATIONS and LIMIT clause.	(preview)	(preview)	yes	yes
G-4130: Always close locally opened cursors.	yes	yes	yes	yes
G-4140: Avoid executing any statements between a SQL operation and the usage of an implicit cursor attribute.	(preview)	(preview)	yes	yes
G-4210: Try to use CASE rather than an IF statement with multiple ELSIF paths.	-	yes	yes	yes
G-4220: Try to use CASE rather than DECODE.	-	yes	yes	yes
G-4230: Always use a COALESCE instead of a NVL command, if parameter 2 of the NVL function is a function call or a SELECT statement.	yes	yes	yes	yes
G-4240: Always use a CASE instead of a NVL2 command if parameter 2 or 3 of NVL2 is either a function call or a SELECT statement.	(preview)	(preview)	yes	yes
G-4250: Avoid using identical conditions in different branches of the same IF or CASE statement.	yes	yes	yes	yes
G-4260: Avoid inverting boolean conditions with NOT.	-	yes	yes	yes
G-4270: Avoid comparing boolean values to boolean literals.	-	yes	yes	yes
G-4310: Never use GOTO statements in your code.	yes	yes	yes	yes
G-4320: Always label your loops.	-	yes	yes	yes
G-4325: Never reuse labels in inner scope.	yes	yes	yes	yes
G-4330: Always use a CURSOR FOR loop to process the complete cursor results unless you are using bulk operations.	-	yes	yes	yes
G-4340: Always use a NUMERIC FOR loop to process a dense array.	-	yes	yes	yes
G-4350: Always use 1 as lower and COUNT() as upper bound when looping through a dense array.	(preview)	(preview)	yes	yes
G-4360: Always use a WHILE loop to process a loose array.	yes	yes	yes	yes
G-4365: Never use unconditional CONTINUE or EXIT in a loop.	-	yes	yes	yes
G-4370: Avoid using EXIT to stop loop processing unless you are in a basic loop.	-	yes	yes	yes
G-4375: Always use EXIT WHEN instead of an IF statement to exit from a loop.	-	yes	yes	yes
G-4380: Try to label your EXIT WHEN statements.	-	yes	yes	yes
G-4385: Never use a cursor for loop to check whether a cursor returns data.	(preview)	(preview)	yes	yes
G-4387: Never use a FOR LOOP for a query that should return not more than one row.	(preview)	(preview)	yes	yes
G-4390: Avoid use of unreferenced FOR loop indexes.	-	yes	yes	yes
G-4395: Avoid hard-coded upper or lower bound values with FOR loops.	-	yes	yes	yes
G-5010: Try to use a error/logging framework for your application.	-	yes	yes	yes
G-5020: Never handle unnamed exceptions using the error number.	(preview)	(preview)	yes	yes
G-5030: Never assign predefined exception names to user defined exceptions.	yes	yes	yes	yes
G-5040: Avoid use of WHEN OTHERS clause in an exception section without any other specific handlers.	-	yes	yes	yes
G-5050: Avoid use of the RAISE_APPLICATION_ERROR built-in procedure with a hard-coded 20nnn error number or hard-coded message.	-	yes	yes	yes
G-5060: Avoid unhandled exceptions.	-	yes	yes	yes
G-5070: Avoid using Oracle predefined exceptions.	yes	yes	yes	yes
G-5080: Always use FORMAT_ERROR_BACKTRACE when using FORMAT_ERROR_STACK or SQLERRM.	yes	yes	yes	yes
G-6010: Always use a character variable to execute dynamic SQL.	-	yes	yes	yes
G-6020: Try to use output bind arguments in the RETURNING INTO clause of dynamic DML statements rather than the USING clause.	-	yes	yes	yes
G-7110: Try to use named notation when calling program units.	-	yes	yes	yes
G-7120: Always add the name of the program unit to its end keyword.	-	yes	yes	yes
G-7125: Always use CREATE OR REPLACE instead of CREATE alone.	-	yes	yes	yes
G-7130: Always use parameters or pull in definitions rather than referencing external variables in a local program unit.	-	yes	yes	yes
G-7140: Always ensure that locally defined procedures or functions are referenced.	yes	yes	yes	yes
G-7150: Try to remove unused parameters.	-	yes	yes	yes
G-7160: Always explicitly state parameter mode.	-	yes	yes	yes
G-7170: Avoid using an IN OUT parameter as IN or OUT only.	-	yes	yes	yes
G-7180: Try to keep the complexity of functions, procedures and triggers simple.	-	yes	yes	yes
G-7210: Try to keep your packages small. Include only few procedures and functions that are used in the same context.	-	yes	yes	yes
G-7220: Always use forward declaration for private functions and procedures.	-	yes	yes	yes
G-7230: Avoid declaring global variables public.	yes	yes	yes	yes
G-7250: Never use RETURN in package initialization block.	-	yes	yes	yes
G-7310: Avoid standalone procedures – put your procedures in packages.	-	yes	yes	yes
G-7320: Avoid using RETURN statements in a PROCEDURE.	-	yes	yes	yes
G-7330: Always assign values to OUT parameters.	yes	yes	yes	yes
G-7410: Avoid standalone functions – put your functions in packages.	-	yes	yes	yes
G-7420: Always make the RETURN statement the last statement of your function.	-	yes	yes	yes
G-7430: Try to use no more than one RETURN statement within a function.	-	yes	yes	yes
G-7440: Never use OUT parameters to return values from a function.	-	yes	yes	yes
G-7450: Never return a NULL value from a BOOLEAN function.	(preview)	(preview)	yes	yes
G-7460: Try to define your packaged/standalone function deterministic if appropriate.	-	yes	yes	yes
G-7510: Always prefix Oracle supplied packages with owner schema name.	-	(preview)	yes	yes
G-7520: Avoid using deprecated units in your own code.	-	yes	yes	yes
G-7710: Avoid cascading triggers.	-	yes	yes	yes
G-7720: Never use multiple UPDATE OF in trigger event clause.	yes	yes	yes	yes
G-7730: Avoid multiple DML events per trigger.	-	yes	yes	yes
G-7740: Never handle multiple DML events per trigger if primary key is assigned in trigger.	-	(preview)	yes	yes
G-7810: Never use SQL inside PL/SQL to read sequence numbers (or SYSDATE).	yes	yes	yes	yes
G-7910: Never use DML within a SQL macro.	(preview)	(preview)	yes	yes
G-8110: Never use SELECT COUNT(*) if you are only interested in the existence of a row.	(preview)	(preview)	yes	yes
G-8120: Never check existence of a row to decide whether to create it or not.	(preview)	(preview)	yes	yes
G-8210: Always use synonyms when accessing objects of another application schema.	-	yes	yes	yes
G-8310: Always validate input parameter size by assigning the parameter to a size limited variable in the declaration section of program unit.	-	yes	yes	yes
G-8410: Always use application locks to ensure a program unit is only running once at a given time.	-	yes	yes	yes
G-8510: Always use dbms_application_info to track program process transiently.	-	yes	yes	yes
G-9010: Always use a format model in string to date/time conversion functions.	yes	yes	yes	yes
G-9020: Try to use a format model and NLS_NUMERIC_CHARACTERS in string to number conversion functions.	-	yes	yes	yes
G-9030: Try to define a default value on conversion errors.	-	yes	yes	yes
G-9040: Try using FX in string to date/time conversion format model to avoid fuzzy conversion.	(preview)	(preview)	yes	yes
G-9101: Always follow naming conventions for global variables.	-	yes	yes	yes
G-9102: Always follow naming conventions for local variables.	-	yes	yes	yes
G-9103: Always follow naming conventions for cursor variables.	-	yes	yes	yes
G-9104: Always follow naming conventions for record variables.	-	yes	yes	yes
G-9105: Always follow naming conventions for collection variables (arrays/tables).	-	yes	yes	yes
G-9106: Always follow naming conventions for object variables.	-	yes	yes	yes
G-9107: Always follow naming conventions for cursor parameters.	-	yes	yes	yes
G-9108: Always follow naming conventions for IN parameters of functions and procedures.	-	yes	yes	yes
G-9109: Always follow naming conventions for OUT parameters of functions and procedures.	-	yes	yes	yes
G-9110: Always follow naming conventions for IN/OUT parameters of functions and procedures.	-	yes	yes	yes
G-9111: Always follow naming conventions for record type definitions.	-	yes	yes	yes
G-9112: Always follow naming conventions for collection type definitions (arrays/tables).	-	yes	yes	yes
G-9113: Always follow naming conventions for exceptions.	-	yes	yes	yes
G-9114: Always follow naming conventions for constants.	-	yes	yes	yes
G-9115: Always follow naming conventions for subtypes.	-	yes	yes	yes
G-9116: Always follow naming conventions for record fields.	-	yes	yes	yes
G-9201: Always follow naming conventions for tables.	-	yes	yes	yes
G-9202: Always follow naming conventions for table/view columns.	-	yes	yes	yes
G-9203: Always follow naming conventions for indexes.	-	yes	yes	yes
G-9204: Always follow naming conventions for primary key constraints.	-	yes	yes	yes
G-9205: Always follow naming conventions for unique constraints.	-	yes	yes	yes
G-9206: Always follow naming conventions for foreign key constraints.	-	yes	yes	yes
G-9207: Always follow naming conventions for check constraints.	-	yes	yes	yes
G-9208: Always follow naming conventions for assertions.	-	yes	yes	yes
G-9209: Always follow naming conventions for global temporary tables.	-	yes	yes	yes
G-9210: Always follow naming conventions for views.	-	yes	yes	yes
G-9211: Always follow naming conventions for sequences.	-	yes	yes	yes
G-9212: Always follow naming conventions for synonyms.	-	yes	yes	yes
G-9213: Always follow naming conventions for triggers.	-	yes	yes	yes
G-9214: Always follow naming conventions for PL/SQL packages.	-	yes	yes	yes
G-9215: Always follow naming conventions for functions.	-	yes	yes	yes
G-9216: Always follow naming conventions for procedures.	-	yes	yes	yes
G-9217: Always follow naming conventions for object types.	-	yes	yes	yes
G-9218: Always follow naming conventions for object type attributes.	-	yes	yes	yes
G-9219: Always follow naming conventions for collection types.	-	yes	yes	yes
G-9501: Never use parameter in string expression of dynamic SQL. Use asserted local variable instead.	(preview)	(preview)	yes	yes
G-9600: Never define more than one comment with hints.	(preview)	(preview)	yes	yes
G-9601: Never use unknown hints.	yes	yes	yes	yes
G-9602: Always use the alias name instead of the table name.	(preview)	(preview)	yes	yes
G-9603: Never reference an unknown table/alias.	(preview)	(preview)	yes	yes
G-9604: Never use an invalid stats method.	(preview)	(preview)	yes	yes
G-9605: Never use an invalid stats keyword.	(preview)	(preview)	yes	yes

The rules marked with (preview) for the Anonymous and Starter plans are only available during the preview phase.