=== on 30 Sep 2019, 08:47:32 Andrei Epure wrote:
\[~nicolas.harraudeau] - we need to decide the scope of "SQL keywords". For .NET, we could take the https://docs.microsoft.com/en-us/sql/t-sql/language-elements/reserved-keywords-transact-sql?view=sql-server-2017[SQL Server and Azure SQL Data Warehouse reserved keywords] - is it too much?


As we've discussed, there is a need to take into consideration SQL keywords to identify a SQL statement string. I guess we need to be case sensitive when doing the keyword matching, right?


Also, we can have:


----
string select = "SELECT p.fname," + // No space, but ok
        "p.lname," +  // No space, but ok
        "p.street1," +  // No space, but ok
        "p.street2" +
        " FROM person p" +
        " WHERE p.id = 1";
----

Alternatively, we can just make an exception for ``++,++`` and consider the comma like a space ?

=== on 30 Sep 2019, 11:53:34 Andrei Epure wrote:
* take into consideration only files referencing the SQL libraries we currently support for Sonar Security (check ``++using++`` statements)
* consider the hardcoded string concatenations in this file which starts with any of these keywords
** BULK INSERT (Transact-SQL)
** SELECT (Transact-SQL)
** DELETE (Transact-SQL)
** UPDATE (Transact-SQL)
** INSERT (Transact-SQL)
** UPDATETEXT (Transact-SQL)
** MERGE (Transact-SQL)
** WRITETEXT (Transact-SQL)
** READTEXT (Transact-SQL)
* we raise issues only if the previous string ends with an alphanumeric character or ``++*++`` or ``++@++`` and the next one starts with an alphanumeric character (if we have non-alphanumeric characters, we're not sure of the intended behavior - e.g. parentheses, comparisons etc)

Out of scope: concatenation of hardcoded strings and variables


So we will raise on:

----
"SELECT x" + // Noncompliant
"FROM y" + // Noncompliant
"WHERE z =" + var;
----
But we won't raise on

----
"SELECT x" + // compliant
variable +
"WHERE z =" + var;
----

include::../comments-and-links.adoc[]
