MS SQL REPORTING 2000 - Changing Commandtext during runtime

10 parameters is not a big deal for RS, looks horrible on the selection but it could work.
And parameters selection options can be tied to previous parameter selections, simply by including the parameter name in the where clause of the dataset for the second parameter. The second parameters list won't get populated until the first is parameter is selected.

Secondly, building SQL queries on the fly as you have in your example, is not efficient as the command has to be compiled at run-time. The more complex the query, the more of an issue this becomes.
Try and put as much of the SQL in a stored procedure to which you can pass parameters (NB: multi-valued parameters can't be passed to stored procs though!). Stored procedures are pre-compiled and run much faster. If you still feel it's too complex to fit into one routine, put it into several procs, then in RS, using standard SQL call the appropriate proc, e.g.;

If @Param1 = 'Red'
    Exec procRed @Param2

If @Param2 = 'Green'
    Exec procGreen @Param3, @Param4

For multi-valued parameters, consider using views. Again these are pre-compiled queries but you can use them as a table in a query. E.g.;
   Select * From vwABC Where Field1 In (@Param7)

Where vwABC would be

Create View As vwABC
As
  Select Field1, Sum(Field2) From Table1 Group By Field1
Go

This shows the view doing some totalling work so RS doesn't have to.

I have done some very complex reports in RS over nearly 3 years now and have been able to achieve everything within standard RS. The trick is to make SQL do the hard work. Use views and stored procedures to do as much of the work as possible.

Cheers
Chris

The requirement was such that the end user wanted to be provided with 10 multiselect options to generate reports.

We used a stored procedure with a text parameter. And withing the SP we called the view that joins all the necessary tables for the Report.

We made a front end ASP.net query builder that allows the user to select any combination of paramters from the multiselect list boxes etc, and this query builder provides the where condition in a text string. This text string when passed to the stored  procedure as the text parameter, helps to return matching records from the view.

Works!

Hi Kalrani,
As we say,  there is more than one way to skin a cat!
If it works, that's fine.
But I was pointing out that passing snippets of SQL as strings to build up a full query string is highly inefficient. If you are dealing with many tables and/or lots of data, then you will see the problem.
I still think you can use RS and SQL to do all this as standard, without resorting to 'Dynamic SQL'. I understand why you might want another web page as a front end though. But again, multi-select parameters is standard in RS2005 and works well enough.

Let me know if you need me to elaborate.

Cheers
Chris

I did answer the question fully, kalrani just chose not to try it in my view.

Cheers
Chris

I've just re-read the thread, it looks like the poster resolved it before I answered. I have no objections to what ever you see fit.

Cheers
Chris