My company is converting our homegrown reporting to SSRS and I need some help in recommending which path to go (full blown SSRS implementation with reports rendered via URL or SOAP) or a more limited approach using a report viewer control in our .Net applications. I've read a lot of the documentation but I still have some questions: 1. We have a standardized web and database template that gets ported for each new project that we're awarded. The reports ideally would be a part of the project so that out BI people can simply open up the "canned" reports and make changes to them based on the project requirements. The BI people do not and will not have our app's source control access. Is SSRS (without the .Net controls) the only way to go? 2. In the above scenario, is there a way to restrict what users can see in the the Report Manager so BI people can see the report builder but cannot create directories, move reports, etc... 3. Ideally, we'd like the ability to create "stupid" reports which are basically shells and will display whatever the dataset provides. Is this possible? It appears to me that there must be an .rdl file on the server with all of the information that the report will have, so is it possible to define a report and dataset at runtime and not use a pre-built report definition. 4. Can anyone point me to a really good book/tutorial etc.. about implementing SSRS and all of the considerations that need to be taken into account? Thanks for any insight anyone has.

Right up my (our) alley. Peter Blackburn and I have written a couple of books that can help get you on the right track. (See my sig). That said, let's see if I can hit the high points of your questions (but I expect a couple hours talking with your team would be the next step). There are always alternatives but SSRS is certainly a good way to go--lots of companies large and small have adopted this development paradigm. SSRS implements a catalog of reports and permits URL access to the directories based on user rights (that you configure). No client-side controls are needed as the report is rendered on the server and delivered in HTML form to a browser. AFA creating a "template" project that includes reports, that's a great idea that I expect has been implemented before by others with a similar development plan. BI projects can be included in a Visual Studio source-controlled project--including using VSS or Team System if the Team System Client is installed. Yes. The Report DBA can setup users that have varying degrees of rights (see Chapter 4 of our Reporting Services book). I'm not a fan of Report Builder as a development tool as the BI tools are far more flexible--the RB tool is more of an "executive" or end-user tool to tune pre-built reports. I've implemented this approach (to a limited extent) in Chapter 14 of my 7th Edition using the ReportViewer control. Of course, the whole idea behind the RV control is to have a code-generated DataSet passed to the local report processor. See below. In addition, I expect your team would benefit from the webinar I'm holding next Tue, Wed and Thur mornings. This is the 9-hour "Intermediate" course on reporting services that's been very well received by an number of IT organizations needing info on Reporting Services. See http://www.progressivebusinesstechnologytraining.com/training/sql-server-training.asp. I think there are still slots open. Feel free to contact me directly if you need more help.__________________________________________________________________ William Vaughn Mentor, Consultant, Trainer, MVP http://betav.com http://betav.com/blog/billva http://www.hitchhikerguides.net Hitchhikers Guide to Visual Studio and SQL Server (7th Edition) Please click the Mark as Answer button if a post solves your problem!