Question

Let me start by saying I am biased; I hate dynamic SQL under all circumstances. That being said, is this scenario considered good practice for dynamic SQL?

sqlDataSourceObject.SelectCommand = String.Concat(
                    "select top ", maxRows,
                    "   col1, ",
                    "   col2 as myData, ",
                    "   '' as blah, ",
                    "   col3 as Fromperson ",
                    "   'Corporate' as toPerson, ",
                    "   Convert(char(11), orderDate) as orderDate, ",
                    "   carrier, ",
                    sqlString1,
                    sqlString2,
                    sqlString3 + " AND areaCode = '" + currArea + "'"
                    );

This query may run once, then change the value for sqlString1,2,3, or currArea and run it again against a different SqlDataSource.

This code makes me angry to read. Its hard to read, it can change with the sqlString variables, I cant run it without copy/pasting into SSMS and I have to go track down several variables to make a single change.

But, like I said I am biased so I am asking you. Is this code, written in 2001 before LINQ, as good as a stored proc or some other technology, generally OK from a good practice perspective?

If not, how would you have improved it (remember no LINQ, this is 2001).

Answer 1

A point of clarification:

Dynamic SQL is normally taken to mean that the semantics of the statement change based on some external factor. In other words, the column names or even the base table(s) might be altered. This was common to do for pivot queries in the old days.

It’s kind of hard to tell because I don’t know what’s going into those awfully-named sqlStringX parameters, but I think that what I’m seeing here is really just inline SQL which happens to be riddled with SQL injection vulnerabilities. It is trivially easy to parameterize. Fix this ASAP, please. Inline SQL is fine but there is no reason to be using raw strings instead of parameters.