Parse error with T-SQL plugin in sonar scanner for SQL files

Hello,
I’m using Developer Edition Version 7.7 (build 23042) with built-in SonarTSQL plugin v1.4 (build 3334) is installed.
I faced with "WARN: Unable to parse file … : Parse error at line 50 column 13: ", and I’m getting this error for many sql files. These files are skipped from scanning process. These are both large (more then 1300 strings) and small files.
Could you please advice how to avoid it.
Screen shots attached
Thanks.

Hello Maksim,

Thank you for your feedback!
To give you some context, when we created our TSQL analyzer, due to the large syntax of the language, we decided to focus on the most commonly used syntax first, so as to bring the most value to our users. We are currently in a phase where we are iteratively improving our analyzer and increasing the number of statements it can parse.

The problem you are facing falls in the case of a syntax we haven’t supported yet: our parser fails to recognize the $action keyword inside an expression of an OUTPUT clause.
I created the following ticket for fixing this: SONARTSQL-229.

Don’t hesitate to report any other parsing issue you encounter, so that we can improve our analyzer even further. Note that you can activate rule “tsql:S2260 Track parsing failures” in your quality profile on SonarQube to be able to easily monitor and report such errors.

Best,
-Chris

1 Like

Hello Christophe,
Thanks for the information.
Here the results of parsing the file with errors, there are some more new ones, as a picture to keep formatting:

image

Thanks in advance

Hello Maksim,

Thanks for the additional feedback!

I created following tickets to address the issues you reported:

Support CREATE SELECTIVE XML INDEX statement: SONARTSQL-230
Support Scripting variables syntax: SONARTSQL-231
Support Service Broker related statements:

For the 3 parse errors on the following snippets:

:r .\ReferenceData.PostDeployment.sql

:r .\Cleanup\PurgeDataHistory.Cleanup.Jobs.sql

INDEX [UX_CacheVersions] UNIQUE NONCLUSTERED (...

I cannot determine what the root causes of these issues are without additional context. If you can share the whole statements causing these errors, it would be great.

Thanks.

Best,
-Chris

Hello Christophe,
According to our developers, the use of syntax :r described here: https://docs.microsoft.com/en-us/sql/tools/sqlcmd-utility?view=sql-server-2017 .
INDEX [UX_CacheVersions] UNIQUE NONCLUSTERED (… - this is the same as index creation, but syntax is slightly different and CacheVersions - this is In-memory table.

Thanks,
Max

Hello Maksim,

The :r sqlcmd syntax should already be supported by our parser. For instance, the following snippet can be parsed correctly:

:r .\ReferenceData.PostDeployment.sql
:r .\Cleanup\PurgeDataHistory.Cleanup.Jobs.sql
SELECT col1 from myTable;

I suspect the error is coming from the preceding statement. That’s why I would need additional context (1-2 preceding statement(s)) in order to find what is causing the error.

Our analyzer supports index creation as described in the documentation. If the syntax used is different, can you please provide a link to the one you are using. I could not find anywhere a case where the options UNIQUE / NONCLUSTERED are used after the INDEX keyword.

Thanks.

Best,
-Chris

Hello Christophe,

https://docs.microsoft.com/en-us/sql/t-sql/statements/create-table-transact-sql?view=sql-server-2017

Since T-SQL plugin is built-in, should I update SonarQube to 7.9?

Hello Maksim,

Thanks for the link. Indeed, I could reproduce the parsing error when attempting to create a UNIQUE index inside a CREATE TABLE statement. Here’s the related ticket: SONARTSQL-239.

It is not necessary to update SonarQube version to get the latest version of the TSQL plugin. You can follow the normal procedure to update/install a plugin from the marketplace to update to the latest version of SonarTSQL plugin.
However from what you mentioned in your first post:

You are already using the latest version of our plugin.

As mentioned in my previous post, the parse error is most likely due to the previous statement(s?). If you can either share the previous statement or a self-contained reproducer, that would help us determine the root of the error.

Best,
-Chtis