If you’ve never worked with the report viewer control and the report designer in VS 2005, you should give it a try if you ever have a need for a reporting services report in your web application. Anyway, a colleague of mine at work was working on a report that I designed a few months earlier. Whenever I setup a reporting services report, I use the smart tag to create a datasource to start my design from. The smart tag will create a dataset which is what the report will in theory be bound to. At runtime, I always manually bind to a dataview that I get from a business layer class, and therefore only make use of the dataset name to tie my business class to the report. So in the method I use to run the report, I do something like this:
ReportDataSource rpds = new ReportDataSource();
rpds.Name = "DataSet1_DataTable1";
rpds.Value = dv;
ReportViewer1.LocalReport.DataSources.Clear();
ReportViewer1.LocalReport.DataSources.Add(rpds);
ReportViewer1.LocalReport.ReportPath = @"MyReport.rdlc";
where “DataSet1_DataTable1″ is the name of the dataset / datatable created using the report designer smart tag, and “dv” is the local variable holding a DataView returned by my business class.
Anyway, we had a problem where one of the fields was not displaying on the report. After an hour of scratching our heads, we determined that the field names (columns in the dataview) in the report appear to be case sensitive. Once we had the case of the column name returned by the business class match the case in the dataset, the field would then display on the report. I am not certain if this is a bug with the report designer, or just a strange coicidence that matching the case fixed the problem.
April 15, 2009 at 8:28 am |
This is very up-to-date info. I’ll share it on Delicious.
May 22, 2009 at 1:14 pm |
having recently just started to get to know using the Report Designer in Visual Studio 2005 i was having “learning curve” issues and in the process of figuring a bunch of stuff out i right clicked on the report i was working on an used open with xml editor. imagine my surprise when i realized the whole report is one somewhat large xml document that you can edit directly. noting that. the node contains information about all the fields in the dataset when first created. and since they are NOT quoted (example =Fields!fieldName.value) instead of like ADODB where it would be rst(“fieldName”).Value or SQL Client where it would be rst(“fieldName”) that would explain your issue.
another issue is that the code ReportViewer.LocalReport.DataSource.Clear() does NOT appear to actually remove all datasets from the report. if you iterate through the datasets in the report immediately after making this call you will find that they are all still in the collection!!! bah!!!!
this is why you have to use the same name for your datasets as you used when you created the form to attach datasets at runtime. this sucks! the ReportViewer.LocalReport.DataSource.Add(ds) where the ds.Name matches, fortunately, updates the existing collection element instead of adding another and updates it with the corrected query.
the problem with this is that if the query contains fields that are in a different order than the original “temporary” dataset then the report execution can still fail.
a second problem is if you wish to add fields to the dataset (using the VS IDE to do so) the original report “interpretation” of this dataset will not include the additional fields and will generate an execution error that the field is missing in “Main report”. you have to manually add the addtional nodes to the reports xml document fields. the VS IDE does NOT update this.
lastly, if you do the above manually with the report open in the designer, then VS IDE will crash to desktop! every time.
anyway, hope some of this helps and gives you some alternate ideas on how to handle these “quirks”.
May 27, 2009 at 7:26 am |
James: Thank you for posting your findings. I did not have the time to do that kind of research at the time I posted this….we found a “solution” without understanding why, and we moved on. I have since run in to other issues that your research sheds some light on. Thanks again.