dbLinter Archives - Philipp Salvisberg's Blog https://www.salvis.com/blog/tag/dblinter/ Database-centric development Wed, 18 Feb 2026 08:23:36 +0000 en-US hourly 1 https://wordpress.org/?v=6.9.4 https://www.salvis.com/blog/wp-content/uploads/2014/04/favicon.png dbLinter Archives - Philipp Salvisberg's Blog https://www.salvis.com/blog/tag/dblinter/ 32 32 Fighting Bad PL/SQL & SQL with VS Code https://www.salvis.com/blog/2026/01/02/fighting-bad-pl-sql-sql-with-vs-code/ Fri, 02 Jan 2026 21:05:10 +0000 https://www.salvis.com/blog/?p=14289 The success of a project or product depends largely on the quality of the code. But how can I improve security, maintainability or performance? More importantly, how can I prevent code with quality defects from entering production? In addition to testing, code analysis plays a central role. These days, code can be […]

The post Fighting Bad PL/SQL & SQL with VS Code appeared first on Philipp Salvisberg's Blog.

]]> The success of a project or product depends largely on the quality of the code. But how can I improve security, maintainability or performance? More importantly, how can I prevent code with quality defects from entering production? In addition to testing, code analysis plays a central role. These days, code can be checked not only in CI/CD pipelines, but also during development. Modern IDEs, such as Visual Studio Code, can automatically detect quality issues and offer quick fixes. The goal is a fast feedback loop.

This blog post is based on my German article with the same title, published in issue 1/2026 of the Red Stack Magazin.

Measuring Software Quality

Imagine you are part of a team where code changes to a feature or bug fix branch are only merged into the develop or main branch following a review. Sometimes you are the author and sometimes one of the reviewers. I am currently part of a team that works in this way. In addition to quality assurance, knowledge sharing is also an important aspect. But how can we assess code quality?

Figure 1: WTFs/m

This well-known meme by Thom Holwerda says, “The only valid measurement of code quality is WTFs per minute.” This seems to be a good metric. However, this metric does have some flaws.

  • It is subjective.
  • It does not provide any information about what is being assessed.
  • It does not help new team members to adapt quickly.
  • And it cannot be automated in a meaningful way.

Sooner or later, a team has no choice but to agree on a set of rules. They can be informal or formal. Typical coding guidelines cover topics such as naming conventions, formatting, code complexity, and language usage rules. The aim is to define and comply with quality standards relating to maintainability, reliability, performance and security. Written coding guidelines also simplify the onboarding of new team members.

Automation

Manually checking compliance with coding guidelines as part of a review is so time-consuming that no one can afford to do it properly. Therefore, we have to automate as many checks as possible. This is possible for many aspects. The rest still have to be checked manually.

In other words, we need a tool suite for automatic rule checking. dbLinter is such a tool suite. It is a new product developed and continuously improved by Grisselbav and United Codes. dbLinter uses the IslandSQL parser, which is updated quarterly with every release update of the Oracle AI Database for SQL, PL/SQL, SQL*Plus and SQLcl.

dbLinter is the successor to the decommissioned db* CODECOP suite. dbLinter consists of a central repository, a web GUI and client tools. These include a CLI, a SonarQube plugin and a VS Code extension.

Visual Studio Code Extension

The VS Code extension is compatible with all IDEs that implement the Visual Studio Code Extension API. Specifically: Visual Studio Code, Theia IDE, VSCodium, Cursor, Windsurf, Void, Kiro and Antigravity.

dbLinter for VS Code is available in both the Visual Studio Marketplace and the Open VSX Registry. Therefore, it can be conveniently installed directly from the IDE. The extension is free to use as part of the Anonymous and Starter plans (see dbLinter Pricing Plans).

It is important to note that your code is always analysed locally, meaning that it never leaves your network. The configuration is read from the central repository, enabling the client to identify the active rules and parameters. These configurations, along with others, are managed using the Web GUI.

Figure 2: dbLinter rule configuration in the Web GUI

dbLinter currently offers 187 rules. This includes all the rules from the decommissioned Trivadis PL/SQL & SQL Coding Guidelines. Figure 2 shows the configuration of my 14 favourite rules. A violation of one of these rules is a bug. There is almost no room for interpretation here. The following chapters provide two examples.

Top-N Queries with ROWNUM

The query in Listing 1 is based on the well-known EMP table owned by the database user SCOTT. It returns two rows.

Listing 1: Defective pre-12c-style top-n query
select ename,
       sal,
       hiredate,
       rownum as rank
  from emp
 where rownum <= 2
 order by sal desc;
ENAME             SAL HIREDATE         RANK
---------- ---------- ---------- ----------
ALLEN            1600 20.02.1981          2
SMITH             800 17.12.1980          1

However, the result barely meets the requirements. I would have expected the two employees with the highest salaries to be returned. Why is this not the case? The query is formulated in such a way that two rows are randomly selected and then sorted in descending order by salary. The result depends on the execution plan and the physical storage of the data.

Figure 3: Violation of rule G-3185 in VS Code

In VS Code, rule violations are displayed under Problems (see Figure 3). There is also a Core G-3185 link that opens the rule details in the Web GUI.

Figure 4: Rule G-3185 in the dbLinter Web GUI

Rule G-3185 in the web GUI is explained based on a similar case in the HR schema (see Figure 4). There are two solutions here. One that can be applied in all Oracle Database versions and one that works from version 12c onwards. Listing 2 shows the traditional solution, which uses an inline view. Of course, nowadays I would always prefer a solution using the row_limiting_clause.

We can also see that the rule is used in six configurations. Clicking on “(details)” opens a pop-up window in which changes can be made. This allows you to configure the rules directly from the IDE.

Listing 2: Fixed pre-12c-style top-n query
select e.*,
       rownum as rank
  from (
          select ename,
                 sal,
                 hiredate
            from emp
           order by sal desc
       ) e
 where rownum <= 2;
ENAME             SAL HIREDATE         RANK
---------- ---------- ---------- ----------
KING             5000 17.11.1981          1
SCOTT            3000 19.04.1987          2

NVL vs. COALESCE

One often underestimated rule is “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”. This rule is about performance, which is relevant to all of us, especially when it is poor. This is why this rule is important.

Listing 3: Bad performance with NVL
with
   function slow_function return integer is
   begin
      sys.dbms_session.sleep(0.2);
      return null;
   end slow_function;
select ename, nvl(mgr, slow_function()) as mgr
  from emp;

Listing 3 demonstrates a case in which the use of NVL results in an execution time of approximately 2.8 seconds. If COALESCE is used instead of NVL, the execution time is only about 0.2 seconds. The reason is that NVL always evaluates the second parameter, even if the first parameter is not null. COALESCE works differently: the second parameter is only evaluated if the first parameter is null. This performance difference originates from the fact that the EMP table contains 14 rows, but only one of these returns an empty MGR.

In this case, using COALESCE is definitely the better solution. So, should NVL always be replaced by COALESCE? No. There are two special cases:

  1. NVL supports implicit data type conversion.
    select nvl(mgr, '1') from emp works, but select coalesce(mgr, '1') from emp causes an ORA-00932 error. However, implicit type conversions should be avoided anyway. The code should be adjusted accordingly.
  2. Optimisations of NVL can lead to better execution plans.
    Such optimisations currently only exist for NVL and not for COALESCE. Therefore, it is better to continue using NVL in these cases. See The Magical NVL Function by Monika Lewandowska for an example.
Quick Fixes

dbLinter knows these special cases. It offers appropriate alternative solutions. See Figure 5.

Figure 5: Quick fixes for G-4230 violation in VS Code.

dbLinter can apply quick fixes to different sections. For example, for a single violation of a rule, for all violations of a rule, or for all violations of all rules in the editor window.

The “@dbLinter ignore markers” are special comments used to ignore rule violations. There are various legitimate reasons for doing this. For example, in the case of false positives (dbLinter bugs) or exceptions to the rule. A comment such as -- @dbLinter ignore(G-4230): NVL forever can have the following scopes: line, statement or file, depending on where the comment is positioned.

Code Analysis and AI

The solution proposals in Figure 5, indicated by the yellow lamp symbol, are quick fixes from dbLinter. However, the last two menu options come from GitHub Copilot.

When Copilot suggests a solution to a rule violation, dbLinter provides the necessary context, including the file and the exact location of the violation, as well as the name of the violated rule. This gives Copilot access to the rule definition online, enabling it to suggest a reasonable solution in many cases. In other words, dbLinter enhances the support offered by tools such as Copilot, Cline and Windsurf.

Rules are useful for AI tools. They provide a framework that leads to better results. However, there is no guarantee that all rules will be followed. Ultimately, code generated or expanded by AI becomes part of our code base. This is why it is important to check AI-generated code according to the same rules as manually created code.

In other words, AI does not enforce standards. But dbLinter can do that.

Conclusion

Software quality is a matter of definition. dbLinter offers many rules. Not all of them are useful and applicable to every project. The dbLinter rules can therefore be seen as a large buffet. You choose what you like and what is healthy. But not too much at once. Nevertheless, there are some rules that, in my opinion, should be followed in every project. I have presented two of them in this blog post.

Install dbLinter for VS Code to identify the rules that will be most helpful for your projects. The rules in Figure 2 are certainly a good starting point.

If you have any questions, please feel free to contact me. Alternatively, you can create issues directly in the dbLinter GitHub repository.

The post Fighting Bad PL/SQL & SQL with VS Code appeared first on Philipp Salvisberg's Blog.

]]> Outer Joining With ANSI SQL-89 and SQL-92 https://www.salvis.com/blog/2025/07/12/outer-joining-with-ansi-sql-89-and-sql-92/ Sat, 12 Jul 2025 15:20:05 +0000 https://www.salvis.com/blog/?p=13988 Introduction I recently implemented a quick fix for the rule G-3130 to transform queries to ANSI SQL-92 syntax. One of the challenges was to handle Oracle’s outer-join syntax (+). In ANSI SQL-89, join and filter criteria are part of the WHERE clause. It’s not easy to distinguish them. In this blog post, […]

The post Outer Joining With ANSI SQL-89 and SQL-92 appeared first on Philipp Salvisberg's Blog.

]]> Introduction

I recently implemented a quick fix for the rule G-3130 to transform queries to ANSI SQL-92 syntax. One of the challenges was to handle Oracle’s outer-join syntax (+). In ANSI SQL-89, join and filter criteria are part of the WHERE clause. It’s not easy to distinguish them. In this blog post, I explain why it is important to do that when using outer joins, regardless of which join syntax you prefer.

Data Setup

All examples in this blog post are based on the tables DEPT and EMP, that were originally present in every Oracle Database instance as part of the SCOTT schema. Here’s a script to create these tables. The script requires an Oracle Database 23ai.

1) Create table DEPT and EMP
create table if not exists dept as select * from (values
          (10, 'ACCOUNTING', 'NEW YORK'),
          (20, 'RESEARCH',   'DALLAS'),
          (30, 'SALES',      'CHICAGO'),
          (40, 'OPERATIONS', 'BOSTON')
       ) s (deptno, dname, loc);

create table if not exists emp as select * from (values
          (7839, 'KING',   'PRESIDENT', null, date '1981-11-17', 5000, null, 10),
          (7566, 'JONES',  'MANAGER',   7839, date '1981-04-02', 2975, null, 20),
          (7698, 'BLAKE',  'MANAGER',   7839, date '1981-05-01', 2850, null, 30),
          (7782, 'CLARK',  'MANAGER',   7839, date '1981-06-09', 2450, null, 10),
          (7788, 'SCOTT',  'ANALYST',   7566, date '1987-04-19', 3000, null, 20),
          (7902, 'FORD',   'ANALYST',   7566, date '1981-12-03', 3000, null, 20),
          (7499, 'ALLEN',  'SALESMAN',  7698, date '1981-02-20', 1600,  300, 30),
          (7521, 'WARD',   'SALESMAN',  7698, date '1981-02-22', 1250,  500, 30),
          (7654, 'MARTIN', 'SALESMAN',  7698, date '1981-09-28', 1250, 1400, 30),
          (7844, 'TURNER', 'SALESMAN',  7698, date '1981-09-08', 1500,    0, 30),
          (7900, 'JAMES',  'CLERK',     7698, date '1981-12-03',  950, null, 30),
          (7934, 'MILLER', 'CLERK',     7782, date '1982-01-23', 1300, null, 10),
          (7369, 'SMITH',  'CLERK',     7902, date '1980-12-17',  800, null, 20),
          (7876, 'ADAMS',  'CLERK',     7788, date '1987-05-23', 1100, null, 20)
       ) s (empno, ename, job, mgr, hiredate, sal, comm, deptno);

Joins

The predecessor of the ANSI SQL-92 standard is the ANSI SQL-89 standard. Based on that standard, you could write joins only like this:

2) ANSI SQL-89 Join
select dept.deptno, emp.ename
  from dept, emp
 where emp.deptno = dept.deptno
 order by dept.deptno, emp.ename;
    DEPTNO ENAME 
---------- ------
        10 CLARK 
        10 KING  
        10 MILLER
        20 ADAMS 
        20 FORD  
        20 JONES 
        20 SCOTT 
        20 SMITH 
        30 ALLEN 
        30 BLAKE 
        30 JAMES 
        30 MARTIN
        30 TURNER
        30 WARD  

14 rows selected.

In the FROM clause, we list the tables to be joined, and in the WHERE clause, we define the JOIN criteria. There are no filter criteria in this case.

There are several ways to transform this query to ANSI SQL-92. One rather silly way, but very similar to the original ANSI SQL-89 syntax, is the use of an explicit CROSS JOIN.

3) ANSI SQL-92 Cross Join 
select dept.deptno, emp.ename
  from dept cross join emp
 where emp.deptno = dept.deptno
 order by dept.deptno, emp.ename;

While this is technically an ANSI SQL-92 compliant query, it’s not a good option. Why? – ANSI SQL-92 allows us to define the join criteria for each join. Using a CROSS JOIN implies that there is no join criterion between these tables, which is wrong.

A better option is to use an INNER JOIN, like in the next example.

4) ANSI SQL-92 Inner Join
select dept.deptno, emp.ename
  from dept join emp on emp.deptno = dept.deptno
 order by dept.deptno, emp.ename;

We see that the WHERE clause is gone. Why? – Because we do not have filter criteria in this query. No WHERE clause, no filter. As simple as that.

Outer Joins

Now let’s write an outer join with ANSI SQL-89. As I mentioned before, the standard back then only defined INNER JOINs. So, we need to work around it. One way is something like this:

5) ANSI SQL-89 Outer Join
select dept.deptno, emp.ename
  from dept, emp
 where emp.deptno = dept.deptno
union all
select dept.deptno, null
  from dept
 where not exists (
          select 1
            from emp
           where emp.deptno = dept.deptno
       )
 order by deptno, ename;
    DEPTNO ENAME 
---------- ------
        10 CLARK 
        10 KING  
        10 MILLER
        20 ADAMS 
        20 FORD  
        20 JONES 
        20 SCOTT 
        20 SMITH 
        30 ALLEN 
        30 BLAKE 
        30 JAMES 
        30 MARTIN
        30 TURNER
        30 WARD  
        40       

15 rows selected.

Phew, that’s a lot of work. It’s no surprise that database vendors came up with proprietary solutions for outer joins. For example:

  • *= and =* operators in Sybase/SQL Server
  • (+) operator in Db2 and the Oracle Database

Let’s use the Oracle join syntax.

6) Oracle-style Outer Join
select dept.deptno, emp.ename
  from dept, emp
 where emp.deptno (+) = dept.deptno
 order by dept.deptno, emp.ename;

Much simpler. EMP is outer joined due to the (+) operator.

And here is an ANSI SQL-92 compliant variant:

7) ANSI SQL-92 Outer Join
select dept.deptno, emp.ename
  from dept left join emp on emp.deptno = dept.deptno
 order by dept.deptno, emp.ename;

No WHERE clause, no filter. So far, so good.

Outer Joins With Additional Filters

The problem starts as soon as you use outer join queries with filter predicates. Here’s an example.

8a) Outer Join With Filter – Oracle-style
select dept.deptno, emp.ename, emp.hiredate
  from dept, emp
 where emp.deptno (+) = dept.deptno
   and emp.hiredate (+) > date '1981-12-03'
 order by deptno, ename;
    DEPTNO ENAME  HIREDATE  
---------- ------ ----------
        10 MILLER 23.01.1982
        20 ADAMS  23.05.1987
        20 SCOTT  19.04.1987
        30                  
        40
8b) Outer Join With Filter – ANSI SQL-92
select dept.deptno, emp.ename, emp.hiredate
  from dept
  left join emp on emp.deptno = dept.deptno
   and emp.hiredate > date '1981-12-03'
 order by deptno, ename;
    DEPTNO ENAME  HIREDATE  
---------- ------ ----------
        10 MILLER 23.01.1982
        20 ADAMS  23.05.1987
        20 SCOTT  19.04.1987
        30                  
        40

Both query variants use the predicate emp.hiredate > date '1981-12-03' as part of the outer join criteria. As a result, the DEPT rows 30 and 40 are shown with empty EMP columns.

The result is correct. But is this the result we want?

I don’t think so. One option is that we don’t want an outer join at all. Something like this:

9a) Inner Join With Filter – ANSI SQL-89
select dept.deptno, emp.ename, emp.hiredate
  from dept, emp
 where emp.deptno = dept.deptno
   and emp.hiredate > date '1981-12-03'
 order by deptno, ename;
    DEPTNO ENAME  HIREDATE  
---------- ------ ----------
        10 MILLER 23.01.1982
        20 ADAMS  23.05.1987
        20 SCOTT  19.04.1987
9b) Inner Join With Filter – ANSI SQL-92
select dept.deptno, emp.ename, emp.hiredate
  from dept
  join emp on emp.deptno = dept.deptno
 where emp.hiredate > date '1981-12-03'
 order by deptno, ename;
    DEPTNO ENAME  HIREDATE  
---------- ------ ----------
        10 MILLER 23.01.1982
        20 ADAMS  23.05.1987
        20 SCOTT  19.04.1987

Now we use the predicate emp.hiredate > date '1981-12-03' as a filter criterion. It’s applied after the join. The result would be the same if we used a LEFT JOIN in 9b).

In most cases, join criteria are based only on the foreign key-primary key relationships. If I see something else, I typically need to dig deeper to understand what the requirements of the query are.

So, maybe we want to see only the employees that match the filter, including departments that have no employees. For that, we could rewrite the query as follows:

10a) Outer Join With Filter – Oracle-style
select dept.deptno, emp.ename, emp.hiredate
  from dept, emp
 where emp.deptno (+) = dept.deptno
   and (emp.hiredate > date '1981-12-03' or emp.deptno is null)
 order by deptno, ename;
    DEPTNO ENAME  HIREDATE  
---------- ------ ----------
        10 MILLER 23.01.1982
        20 ADAMS  23.05.1987
        20 SCOTT  19.04.1987
        40
10b) Outer Join With Filter – ANSI SQL-92
select dept.deptno, emp.ename, emp.hiredate
  from dept left join emp
    on emp.deptno = dept.deptno
 where (emp.hiredate > date '1981-12-03' or emp.deptno is null)
 order by deptno, ename;
    DEPTNO ENAME  HIREDATE  
---------- ------ ----------
        10 MILLER 23.01.1982
        20 ADAMS  23.05.1987
        20 SCOTT  19.04.1987
        40

This example shows why it’s important to distinguish between join criteria and filter criteria. The ANSI SQL-92 syntax makes this easier. Unfortunately, there are still a few bugs and limitations when using ANSI-92 syntax in every Oracle Database version. But there are fewer and fewer of these problems with each new version.

Therefore, I use the ANSI SQL-92 join syntax whenever possible and try to document the reason when I cannot.

Use dbLinter to Change Queries to ANSI SQL-92 Join Syntax

dbLinter can find queries that do not use ANSI SQL-92 join syntax. Simply put, it searches for multiple items in the FROM clause. It also provides a quick fix to convert ANSI SQL-89 and Oracle-style joins to ANSI SQL-92 syntax. Here’s a screenshot with the previously discussed queries:

dbLinter for VS Code showing G-3130 violations and the pop-up window to apply quick fixes

After applying the quick fix to all G-3130 violations in the file, the result looks like this:

dbLinter for VS Code after applying the quick fix for all G-3130 violations

The result looks quite good, except that the predicate in the 8a) example is not moved to the join condition (see red arrow in the screenshot above). Why is that the case? – The quick fix only moves equality predicates and predicates that are not part of a Boolean OR condition to the join condition. If there are leftover outer join operators (+) in the WHERE clause, they are surrounded by a TODO comment.

To get started with dbLinter, I recommend watching Philipp Harenfeller’s video. United Codes and Grisselbav are collaborating on this product.

Feedback is very much appreciated. Comment on this blog post or raise an issue on the dbLinter GitHub repository.

Thanks.

The post Outer Joining With ANSI SQL-89 and SQL-92 appeared first on Philipp Salvisberg's Blog.

]]> dbLinter Rules Repository https://www.salvis.com/blog/2025/03/18/dblinter-rules-repository/ Tue, 18 Mar 2025 20:31:42 +0000 https://www.salvis.com/blog/?p=13856 Introduction Today I proudly announce that the Joint Venture between United Codes and Grisselbav released the initial version of the dbLinter Rules Repository website. This is the first publicly available component of the dbLinter tool suite. What is dbLinter? dbLinter is a suite for checking and improving the quality of database applications. […]

The post dbLinter Rules Repository appeared first on Philipp Salvisberg's Blog.

]]> Introduction

Today I proudly announce that the Joint Venture between United Codes and Grisselbav released the initial version of the dbLinter Rules Repository website. This is the first publicly available component of the dbLinter tool suite.

What is dbLinter?

dbLinter is a suite for checking and improving the quality of database applications. Quality is assessed using static code analysis and database queries based on a configuration. A configuration is primarily centrally managed. It contains file patterns, rules, validators, SQL-based tests, parameters, and connect information for read-only database access within checks and tests.

Is it Free?

dbLinter is a commercial and subscription-based product. However, there are two free subscription plans foreseen. Anonymous without registration and Free requiring registration with a valid email address. You need a login to manage configurations.

Anonymous

Free

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

dbLinter VS Code extension

yes

yes

yes

yes

Run all accessible checks and tests

–

–

yes

yes

Quick fixes in dbLinter VS Code extension

–

–

yes

yes

Ignore chosen SQL-based test findings

–

–

yes

yes

dbLinter CLI with SonarCloud integration

–

–

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

And of course, access to the dbLinter Rules Repository website is also free.

What Are the Rules Based on?

Most of the rules are taken over from the decommissioned Trivadis PL/SQL & SQL Coding Guidelines. The origin is documented per rule under the Reference section. See for example G-1080: Avoid using the same expression on both sides of a relational comparison operator or a logical operator. This rule exists in 4 different rule repositories.

Over 180 Rules – This is Ridiculous!

You do not need to enable all rules. I compare it to a breakfast buffet. You pick what you like and how much you want.

Furthermore, not all rules have the same severity. The most important rules are marked as Blocker. Pick some of these to start with.

What’s Next?

Coding guidelines are really helpful, especially if you can use them to review your code automatically while it’s being developed in your favourite IDE. Of course you want them also as part of a CI/CD pipeline. However, finding problems while typing code is far more efficient.

Therefore the next component will be a VS Code extension. Here’s an example of how it will look like:

Stay tuned.

The post dbLinter Rules Repository appeared first on Philipp Salvisberg's Blog.

]]>