W zależności od konkretnej implementacji mamy dwa ogólne podejścia do tego problemu:
1) Dynamicznie skompiluj instrukcję filtrowania dla zapytania SQL w kodzie, pomijając wszelkie parametry, które są puste. Jest to najlepsze podejście, jeśli pozwolisz użytkownikowi wybrać wiele wartości dla jednej kolumny (tj. wybrać 0 lub więcej z 50 stanów do filtrowania danych).
Na przykład:
Zakładając, że txtCondition1 i txtCondition2 są polami tekstowymi:
// Assuming conn is an open SqlConnection
System.Text.StringBuilder sbSQL = new StringBuilder(500);
List<SqlParameter> cParameters = new List<SqlParameter>();
// Add a default condition of 1=1 so that all subsequent conditions can be added
// with AND instead of having to check to see whether or not any other conditions
// were added before adding AND.
sbSQL.Append("SELECT * FROM MyTestTable WHERE 1 = 1 ");
if (!String.IsNullOrEmpty(txtCondition1.Text)) {
sbSQL.Append(" AND Column1 = @Column1");
cParameters.Add(new SqlParameter("@Column1", txtCondition1.Text));
}
if (!String.IsNullOrEmpty(txtCondition1.Text))
{
sbSQL.Append(" AND Column2 = @Column2");
cParameters.Add(new SqlParameter("@Column2", txtCondition2.Text));
}
SqlCommand oCommand = new SqlCommand(sbSQL.ToString, conn);
if (cParameters.Count != 0)
{
oCommand.Parameters.AddRange(cParameters.ToArray());
}
// Do something with oCommand
2) Jeśli wartości są bardziej ograniczone, zwykle przekazujemy je do procedury składowanej, która jest odpowiedzialna za określenie, czy wartość ma być oceniana przez testowanie parametru na „pustki”, albo null, pusty ciąg, 0 dla liczb itp.