Home/ Questions/Q 398977
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T16:48:05+00:00

I want to take a poorly designed SQL statement that’s embedded in C# code

  • 0

I want to take a poorly designed SQL statement that’s embedded in C# code and rewrite it as a stored procedure (presumably), and am looking for an appropriate means to address the following pattern:

sql = "SELECT <whatever> FROM <table> WHERE 1=1";

if ( someCodition.HasValue )
{
    sql += " AND <some-field> = " + someCondition.Value;
}

This is a simplification. The actual statement is quite long and contains several such conditions, some of which include INNER JOIN‘s to other tables if the condition is present. This last part is key, otherwise I’d probably be able to solve all of them with:

WHERE <some-condition-value> IS NULL OR <some-field> = <some-condition-value>

I can think of a few possible approaches. I’m looking for the correct approach.

Edit:
I don’t want to perform concatenation in C#. I consider this a serious compromise to security.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If I understand the question properly, the idea is to replace a whole section of code in C# in charge of producing, “long hand”, a specific SQL statement corresponding to a list of search criteria, by a single call to a stored-procedure which would, SQL-side, use a generic template of the query aimed at handling all allowed combinations of search criteria in a uniform fashion.

    In addition to the difficulty of mapping expressions evaluated on the application-side (eg. someCondition.HasValue) to expressions evaluated on the SQL-side (eg “some-condition-value”), the solution you envision may be logically/functionally equivalent to a “hand-crafted” SQL statement, but slower and more demanding of SQL resources.

    Essentially, the C# code encapsulates specific knowledge about the “physical” layout of the database and its schema. It uses this info to figure-out when a particular JOIN may be required or when a particular application-level search criteria value translate to say a SQL “LIKE” rather than an “=” predictate. It may also encaspsulate business rules such as “when the ZIP code is supplied, search by that rather than by State”.

    You are right to attempt and decouple the data model (the way the application sees the data) from the data schema (the way it is declared and stored in SQL), but the proper mapping needs to be done somehow, somewhere.
    Doing this at the level of the application, with all the expressive power of C# as opposed to say T-SQL, is not necessarily a bad thing, provided it is done
      – in a module that is independent of other features of the application
    and, where practical,
      – it is somewhat data/configuration-driven as so to allow small changes in the data model (say the addition of a search criteria) to be implemented by changing a configuration file, rather than plugging this in somewhere in the middle of a long series of C# conditional statements.

    • 0