The Weird and The Wonderful

PIEBALDconsult wrote:

As with Jörgen's post, an IN with hard-coded values I especially discourage; they reek of the "magic numbers" code smell. A subquery on some table would at least improve maintainability.

Jörgen Andersson wrote:

list as a parameter

db.Command.CommandText = "SELECT * FROM Account WHERE ID IN ( SELECT ID FROM @IDs )" ;
                
System.Data.SqlClient.SqlParameter p = 
    new System.Data.SqlClient.SqlParameter 
    ( "@IDs" , System.Data.SqlDbType.Structured ) ;

p.TypeName = "dbo.IDdef" ;

p.Value = dt ;

db.Command.Parameters.Add ( p ) ;
               
db.Open() ;
                
System.Data.IDataReader dr = db.Command.ExecuteReader 
    ( System.Data.CommandBehavior.CloseConnection ) ;

PIEBALDconsult wrote:

Personally I wouldn't. I wouldn't use IN at all, I'd find a way to have a table on which to JOIN instead.

PIEBALDconsult wrote:

The statement you present is a symptom of a poorly implemented system.

string query = "select * from table where ID in (@value1, @value2, @value3)";
SqlCommand cmd = new SqlCommand(query);
cmd.Parameters.Add("@value1", 123);
cmd.Parameters.Add("@value2", 124);
cmd.Parameters.Add("@value3", 125);

string query = "select * from table where (ID = @value1 or ID = @value2 or ID = @value3)";
SqlCommand cmd = new SqlCommand(query);
cmd.Parameters.Add("@value1", 123);
cmd.Parameters.Add("@value2", 124);
cmd.Parameters.Add("@value3", 125);

public static DataSet ArtikelHelpListe(int auswahl, string artnr, string artbez, string lnam, 
                                       string lnr, string lartnr, string wg, string mkenz,
                                       string ean, string gab, bool ges, bool bug, bool bau,
                                       bool eks, int stanort, string uid)
{
    // Here be dragons ( thousands of lines of totally worthless code)
    ....
}

VectorX wrote:

just appending