It's an issue of what the client wants. If they don't use stored procs, then my class needs to accept T-SQL statements.



>I've never had a situation where I couldn't use a Stored Proc to do what I needed to do. Sometimes I had to be creative, but I've never had a need for dynamic SQL.
>
>>Ya, I probably will in this app. And stored procs are my prefered design, but I'm trying to make it generic so that if I run into a case where stored procs are not used.
>>
>>
>>
>>>If you always use Stored Procs to talk to your database, then you don't have to worry about this, do you? <g> This is supposed to be "best practice" anyway ... only using Stored Procs.
>>>
>>>~~Bonnie
>>>
>>>
>>>>In my Data Class I have the ExecuteQuery method shown below. It's possible to pass as 'sCommand' either a SELECT command or a stored procedure name.
>>>>
>>>>The question is, how do I tell the method that 'sCommand contains a sproc vs. a transaction statement?
>>>>
>>>>

>>>>public DataSet ExecuteQuery(string sCommand, string sTableName, SqlParameter[] colParameters)
>>>>{
>>>>    SqlCommand oCommand = _GetCommand(sCommand);
>>>>    SqlConnection oConn = _GetConnection(false);
>>>>
>>>>    if (sTableName == "")
>>>>    {
>>>>        sTableName = "";
>>>>    }
>>>>
>>>>    if (colParameters != null)
>>>>    {
>>>>        oCommand.Parameters.Clear();
>>>>        oCommand.Parameters.AddRange(colParameters);
>>>>        oCommand.CommandType = CommandType.StoredProcedure;
>>>>    }
>>>>
>>>>    
>>>>    DataSet oDataSet = new DataSet();
>>>>    _oAdapter = new SqlDataAdapter(sCommand, oConn);
>>>>
>>>>    SqlCommandBuilder oBuilder = new SqlCommandBuilder(_oAdapter);
>>>>
>>>>    _oAdapter.SelectCommand = oCommand;
>>>>
>>>>    try
>>>>    {
>>>>        _oAdapter.Fill(oDataSet, sTableName);
>>>>
>>>>    }
>>>>
>>>>    return oDataSet;
>>>>}
>>>>
>>>>