[OT] Visual Studio (rdlc) reports

DansDreams posted on Wednesday, August 30, 2006

I've been playing with the VS reports attempting to learn enough to decide between the various report writing alternatives.  Here's where I'm at in that analysis of rdlc reports - I'd like to get feedback from anybody that's used it.

The recurring data reports are based on a table control by definition.  It can do grouping and subtotaling and all that stuff, but the layout is based on a table (think Word or HTML table) control.  In some ways this greatly simplifies things, and the designer is pretty nice for making simple reports pretty efficiently.

But it also seems terribly limiting from a layout standpoint.  How many hours have we wasted trying to get a web page layout right when using tables, adding columns just to have a place to align things, merging cells to fix the alignment that causes when we didn't want it, etc. etc. ?

The two biggest points that limit things seem to be:

a - each cell in the table has a textbox control by default.  Delete the textbox control and Visual Studio just immediately puts another one in there.

b - the textbox control can not host some of the other ones, like the line.  So something so simple as just saying you want a line in a particular position above the subtotals for a group becomes one of those table layout formatting problems I described above.

I want to make sure I'm understanding this thing correctly and I'm being fair in my critique.  Any thoughts?

DansDreams replied on Wednesday, August 30, 2006

Never mind what I said before.  Especially points a and b.  You can effectively replace the textbox in a cell with a rectangle control in which you have freeform placement layout control.  It's still a bit more difficult than a totally freeform "band" canvas like in other report writers, but it gets the job done.

Additionally, the list and other controls gives you entirely different paradigms from the table for repeating data layout.

The biggest issue I still see is that there's a pretty convoluted relationship in the data sources going all the way from a business object to running an actual instance of the report.  There are steps you have to take to "synchronize" the data sources if you make changes to a business object used on a report.  Ugh.

There is a lot to like about this thing from what I've seen so far.  I'm pretty impressed, and it looks like it's going to the the report writer of choice for me going forward.

ajj3085 replied on Wednesday, August 30, 2006

I've only had one very simple use so far, displaying a 'report' which is basically just an index card with a contact's information on it.

I have liked it quite a bit though, and am looking forward to building more difficult reports with it.

mikeclimbs replied on Thursday, August 31, 2006

We've been playing with the reports also and they looking very promising.

We found 2 limitations crosstabs have limited groupings.  Also when formatting negative #'s, if you place parenthesis around the negative items they do not align correctly with the positive #'s

The neat thing we discovered is the report files are xml, so its possible to create reports from code.

Mike

ajj3085 replied on Thursday, August 31, 2006

One thing if you do use these reports.  There's a bug where you try to print, and you click on the print button, but nothing happens.  Clicking Print again works as expected.  If you experience this problem, there's a hotfix from MS.  See http://support.microsoft.com/kb/916812 for details.

Nicholas Trevatt replied on Sunday, June 24, 2007

Hi,

It's been 10 months since this thread was started but I am keen to hear from Dan or anyone else on any further tips, experiences or dificulties of the reports feature (rdlc) with BO's.  Also, any strong opinions or arguments about Rdlc, Crystal, Xtra, Active etc. would be great!

At the moment my immediate need is to find the best way to print envelopes and I'm confused on the direction to take a even after considerable time looking at help and examples.  The end user must be able to select their preferred size envelope (DL, No.10, custom) and I need to centre the address appropriately.  Also, I need to run these in a batch from my AddressList collection but can't figure out how to force one address per page using rdlc.  I'm wondering if System.Drawing.Printing would be a better solution for such a simple requirement?

Thanks for any input,
Nicholas

JoeFallon1 replied on Monday, June 25, 2007

I use Active Reports.Net 2.0.

It is a fine product and works well with CSLA BOs.

It is a "standard" report writing tool so if you are familiar with Access style reports it is pretty easy to use.

The one issue I have with it is that the report engine does not handle sorting/grouping so you must provide it with your data in a pre-sorted/grouped sequence. It just means you have to give your query a bit more thought.

Joe

 

bgilbert replied on Tuesday, October 23, 2007

Some more thoughts and questions regarding reporting...

My initial idea was to use rdlc's for reports that need to be driven from existing objects, like when you want to print what you're seeing on a form and to use SSRS for analysis reports, where existing objects don't exist. So far so good, but the devil's in the details.

For rdlc's, when you want to represent hierarchical data, things get very tricky. An example is an object that has a child property that is a collection. To render the child collection, you need to handle the report's subreportProcessing event, get the key from the parent object, and call the Get method for the sub property to fill the subreport. This works reasonably well once you've gone bald figuring out the ridiculous parameter architecture. Now that I have one report working, I want to make the WinPart that contains the ReportViewer generic so that I can pass any BLB-derived collection and its corresponding report and have it deal with the subReportProcessing event in a manner specific to the data. Now I'm headed down the path of using a generic delegate to point to a callback routine to get the subreport's data. Can open, worms everywhere!!!

The plot has thickened so much that I'm reconsidering my basic assumptions about this architecture. How about this: Use SSRS rdl reports, serialize my objects (and their child collections) to XML on the server and point the reports to these XML files. Sounds almost as nasty.

Has anyone tried to make a generic form or WinPart to handle multiple reports?

ajj3085 replied on Tuesday, October 23, 2007

Hi,

Here's what I've done, and where I think I should be going.

I agree; reporting on an object already in memory (say in my case, a Quote with LineItems) should use rdlcs.  That's all I'm using right now, actually.  I've even gone as far as to make objects just to get data to present in a report. 

That last part I'm rethinking, and I'm currently leaning on using SSRS in the future.  The reason is that if the database changes, I'll need to update my queries, then my reporting objects (the data portal parts). 
So what changes if I use SSRS?  I'll have to update my queries again, yes... but that's where it would likely end.  So far there's only one report where the BOs do more than just load data, and I think I could use SSAS to get that data together.  I'll take it case by case.

Anyway, back to your point.  I never ended up doing that whole subreport thing.  I haven't had the need to provide drill-downs or anything, especially since I'm using the "reports" not as reports so much but print layouts for order forms, invoices, etc.  What I have done is the BOs actually have a method called GetReport.  This method takes a LocalReport object as a parameter, and then works with it.. setting the report to use (based on a second parameter), the report parameters, etc.  It also is responsible for setting up the ReportDataSources for the local report.  You can have as many as you want, so I use the Quote as one datasource, the LineItems are another data source, and since my bill, ship and sold to are complex BOs as well, they all go in as DataSources as well.

It works pretty well, and I can enforce business rules this way... like you can't actually print or export the quote unless it has been locked, for example.

I have a generic form to display all my reports; the form exposes a LocalReport property, which is the LocalReport property off of the ReportViewer control, which is the sole control on the form, docking set to Fill.  The UI sets the forms Text, and the LocalReport property is what gets passed to the BO, so the BO can set the properties of the LocalReport.

All in all it works pretty well, although there are some changes I may make.  I may move the reporting (GetReport) method out of the Quote object itself into another class, just to seperate things a bit.  Otherwise, it seems to be working well, save for some glitches in ReportViewer / SSRS.

One, for example, drove me nuts.  It seems that although PNG should be a supported image type, if you actually save the report (via the RV control's export button) as a PDF, then print that PDF to a PostScript printer using PS drivers, you get errors.  A few lines print, then a blank page saying there was an error in the printing system.  The solution was to use JPGs.

Also, there's the issue with the Print dialog from the RV control looking like it has focus, but not really having focus.  There's a link to a hotfix in this thread I think.

Finally, sometimes the ReportViewer renders only the last page, and insists its the only page.. even though your Page x of y shows its 2 of 2.  Very wierd.  If it happens, clicking the Refresh button on the control fixes everything right up.

HTH
Andy

bgilbert replied on Tuesday, October 23, 2007

Andy,

Thanks for the reply. I have several approaches I'm researching concurrently, none of which is simple.

To make a report viewer user control that will receive any object derived from the BLB, I'll need to create a generic user control in which I pass the specific type as well as a generic callback delegate to allow the reportviewer to get the child collection. This seems like a lot of work, but I may pursue it.

A simpler, but less elegant method, would be to have a unique user control for each report.
 
Another approach is to do everything from SSRS and have my business classes expose an array of name/value pairs to be passed to the server report as parameters. The thing I haven't gotten my head around is what to do when I've filtered and/or sorted my collections in the UI using SortedBindingList or FilteredBindingList. The advantage of using rdl reports, though, is that you don't need subreports to render hierarchies.

Then there's the "serialize to local xml file and report against it" method. Something about this rubs me the wrong way, mainly because there is no simple way to serialize all objects and their child collections without writing custom code for each class.

My desire to create a reusable reportviewer UI seems like it should be fairly common, so I find it bizarre that I cannot find any references to it on the web. This is the point at which most people probably jump ship to a third-party reporting suite, but I find that concept hard to swallow at this point. By the way, VS 2008 doesn't seem to offer any help with these issues; a few enhancements to the control, but nothing that will help me.

Barry

Cslah replied on Tuesday, October 23, 2007

I've been using the reportviewer control for several years now and bind our business objects directly to the reports. I have changed my objects quite a bit and haven't had to go in and refresh any of the binding though, I had to think about that when someone on this thread pointed it out. Most of my reports have been there unchanged for quite a long time, yet the BO's have been changed a lot. Our larger application has some 80 reports using subreports, matrix, etc. We think of the rdlc files as another UI, a readonly one. Our objects do some calculations also (beyond the simple math you can do with the report viewer). You can't do any complex math from within SSRS since it's all sprocs. So, you'll want to take this into consideration.

I agree that reportviewer has a few problems, but using the 80/20 rule (probably 95/5 rule in this case) it more than gets the job done. We prefer to use .NET controls 100%, unless there's really something that we can't get. To date, we've been able to make everything work. ActiveReports is good, but they release a lot. You have to pay for the upgrades and you have to test for every service pack they put out. The same with MS, but they've only issued a service pack once.

For some good examples you can go here:
http://www.gotreportviewer.com

And, you definately need to get the latest service pack 1 for the reportviewer control. It fixes A LOT of issues, including the 'click print button twice' issue mentioned here. I did read that it fixes some image problems. The upgrade is here that you can post for your endusers that have it installed already:
http://www.microsoft.com/downloads/details.aspx?FamilyId=35F23B3C-3B3F-4377-9AE1-26321F99FDF0&displaylang=en

There's also an exe for a brand new install.

 

bgilbert replied on Wednesday, October 24, 2007

Thanks for the input. I got the update.

I also like the ReportViewer control. My only complaint has been the way subreports are rendered. It prevents me from being able to make a generic control that will accept any report.

For posterity, the solution I adopted was to have my WinPart receive a reportviewer control in its constructor. I build the instances of these controls in my calling UI code. In the generic WinPart, I've coded a subReportProcessing method for each report and then use a Case statement to determine which handler to add. It's a little clumsy, but it's better than the alternatives.

ozitraveller replied on Wednesday, October 24, 2007

Hi

I've using ReportViewer (rdlc) for some time now, and I find customising the toolbar an issue. I've played with the example and still have issues after customising: TotalPage count, margins, etc...