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;
>>}
>>
>>