Hi there, I am struggeling with my Report Manager. I am forced to use the Report Manager to build/maintain reports for my company. Previously I used MsAccess to make my Reports, but the company policy has changed some years ago and now I am only allowed to use the Report Manager, Visual Studio and/or Report Builder. Also it is not allowed to make executables. The company idea is that maintance would be easier for another programmer than silly old me. For years I am busy trying to convert my Access Reports to Report Manager equivalents. I can tell you: it is no easy task. The reports I build/maintain in Visual Studio R2008 R2 at the moment. At the moment I have basically 2 methods for building a dataset for my reports: 1) The TSql solution: Using Stored Procedures written in TSQL mainly that render an Sql-table. The TSQL I build/maintain in SSMS R2008 R2. 2) CLR-routines: Using Stored Procedures that call a CLR-routine in Assemblies. The routines I build/maintain in Visual Studio 2008 at the moment using SQL server projects. The latter I choose because an increasingly bigger part of the reports require actual programming such as using arrays. As you know: TSQL does not support arrays as TSQL is not intended to be used as a programming language, but rather as what I call a command language. However maintaining these CLR-routines is nearly impossible for the following reasons: 1. In VS: in debugging mode the Edit/Continue does not work, because 64-bit applications cannot be editted. I have tried to switch to 32-bit, but that causes even more problems. 2. After making the sleightest modification all CLR-routines are deployed to the SQL server database, including those that were not changed at all. I have tried to set the option "Projects and Soltions" -> "Build and Run" -> "Only build startup projects and dependencies on Run", but then I get a compile error. http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/bd37d309-1e93-41aa-854f-fa896784b31e 3. Deploying the CLR-routines from my testserver to the production server cannot be automized. The VS on the testserver always puts them in the SQL database of the testserver not in the production server. I have to manually disconnect the testserver database in order to force the VS to ask for another target location. http://social.msdn.microsoft.com/Forums/en-US/clr/thread/2c26cd02-4566-4605-909b-6a9e35d06a46 4. The CLR-routine cannot be debugged in the Report Manager. Microsoft assumes that after testing the routine is VS it will behave the same in the Report Manager, which is a wrong assumption as the testserver is/might be different from the production server to mention just one thing. http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/227f4892-6419-44eb-8a27-57cf76c3101f 5. I have not sufficient control over the Report Parameters. This is a known issue for the Report Manager. 6. To implement dynamic Reports based on dynamic SQL is extremly programmer unfriendly. Practically one would have to generate a .rdl file, but this is not doable because of version complications switching to .rdlc for example. At this point I like to say that most of the reports fall in 2 catagories: 1. Normal Reports to be printed and used directly by the enduser 2. Flat Reports that are intended to be exported to Excel, so the enduser can edit the filtering of rows and columns, insert subtotals or grafics at will. So I am looking for another way to create/maintain a dataset: Using a shared datasource reference. Type "BSTD": <Extension Name="BSTD" Type="BaanstedeData.BaanstedeData,BaanstedeData.BaanstedeDataExtension"/> This would call a .dll (this is allowed by my company) that supplies the dataset. But perhaps there are other possibilties: . Create a webpage to be loaded in the Report Manager. . Create a Excel xlsa file to be loaded in the Report Manager that calls the .dll . .... Any suggestion would be greatly appreciated.... Regards, JosI'll be back

hi, You can create an embedded dataset for use in a single report or a shared dataset to save to a report server, for use by multiple reports. http://msdn.microsoft.com/en-us/library/dd239345.aspx