>Ok, based on your other message, basically, if sp_executesql makes a better use of the execution plan, then, would it be better to use this approach instead of using the SQLParameter object to create parameters and use a regular SQL command through the SQLClient data provider to access SQL Server?

When parameters are used with SQL Server ODBC driver, they end up to be passed to the sp_executesql with a query itself. I don't know what .NET provider does. That's why I suggested to use SQL Server Profiler to see what actual SQL statement sent to the SQL Server from your application. It could be the sp_executesql as well.