Andy,
I've had horrible experiences with the one client I have that uses ReportingServices and would shy away from it if I could. However part of the issues were a not great dev/test infrastructure, little support, a few select personnel, and using it for the wrong thing. I inherited a project that was late and overdue and had 'reports' that turned out to be both formatted (like an invoice) and others that were really just 100k row data dumps.
It was miserable as the real requirement was a simple CSV file dump from the database for the big extracts, not a webpage.
However some of the improvements we made were quite useful. Once we were able to separate the data from the report things went well in terms of maintenance. Of course we were using sprocs and not businessObjects to join the data (big difference between reportingServices vs. the embedded VS report Viewer.). To filter out the business layer (done in PL/SQL for my app) I essentially did all my logic processing and then dumped the data back in to a simple flat temp table with a run_id column.
The reports were then written based on simple select * from tmpTableABC where run_id = 123. They were encapsulated in sProcs but they were simple nontheless. It worked well as we had 1 admin for the server, 1 developer for the web stuff, a different person for the reports, and me. So once I was able to encapsulate the data it worked well. The reports are then maintained outside the app and the database. Big changes (new column) could be done by adding a new column to the temp table and then the reporting guy could tweak the RDL file.
When I needed to show the report I pulled back the rdl filename from the database lookup table and we showed it on screen with the corresponding rpt_id. Worked really slick and we actually created a secondary reporting portal to manage long running reports and maintaining a reporting queue.
Ironically I'm now in the same position as you are on my current project. My current reports are in PowerBuilder libraries so I have to recreate them. I have purchased DataDynamics new Data Reports product (not their long standing Report tool) which is backwards compatible with RDL files. I had assumed I would either distribute all the report files as standalone file to be read in on demand or create a single reporting assembly that I would distribute independently...
Could you save some headaches by not mainting all the reporting file as a group vs. as an embeded resource in each BO?
I would be very keen to know what paths you go along...
Thanks
jack
Jack:
I've had horrible experiences with the one client I have that uses ReportingServices and would shy away from it if I could. However part of the issues were a not great dev/test infrastructure, little support, a few select personnel, and using it for the wrong thing. I inherited a project that was late and overdue and had 'reports' that turned out to be both formatted (like an invoice) and others that were really just 100k row data dumps.It was miserable as the real requirement was a simple CSV file dump from the database for the big extracts, not a webpage.
Well, was there something with SSRS that you didn't like, or was this a case of the wrong tool for the job? For a CVS dump, I would think SSIS would be the right path.
However some of the improvements we made were quite useful. Once we were able to separate the data from the report things went well in terms of maintenance. Of course we were using sprocs and not businessObjects to join the data (big difference between reportingServices vs. the embedded VS report Viewer.). To filter out the business layer (done in PL/SQL for my app) I essentially did all my logic processing and then dumped the data back in to a simple flat temp table with a run_id column.The reports were then written based on simple select * from tmpTableABC where run_id = 123. They were encapsulated in sProcs but they were simple nontheless. It worked well as we had 1 admin for the server, 1 developer for the web stuff, a different person for the reports, and me. So once I was able to encapsulate the data it worked well. The reports are then maintained outside the app and the database. Big changes (new column) could be done by adding a new column to the temp table and then the reporting guy could tweak the RDL file.
Ok, that's where I'd like to end up.. changing the reports outside of the application. If I went down the SSRS route, I'd use BIDS to create Data Sources, Data Source Views, etc.
When I needed to show the report I pulled back the rdl filename from the database lookup table and we showed it on screen with the corresponding rpt_id. Worked really slick and we actually created a secondary reporting portal to manage long running reports and maintaining a reporting queue.
I don't think I'll have any long running reports, fortunately... but this again sounds like where I'd like to go.
So do you basically just set properties on the ReportViewer.ServerReport object? Or did you load reports in another manner?
Ironically I'm now in the same position as you are on my current project. My current reports are in PowerBuilder libraries so I have to recreate them. I have purchased DataDynamics new Data Reports product (not their long standing Report tool) which is backwards compatible with RDL files. I had assumed I would either distribute all the report files as standalone file to be read in on demand or create a single reporting assembly that I would distribute independently...Could you save some headaches by not maintaining all the reporting file as a group vs. as an embedded resource in each BO?
I would be very keen to know what paths you go along...
Well, my main problem is that in order to update or create reports, I need to deploy a whole new version of my application. That is a pain, as it seems like a fairly silly reason to do a deploy. I'm also sick of writing BOs which basically just pull the data back and shape it to match what the report needs. It's almost all boiler plate code, but I have to maintain it. (Don't have any code gen).
I would defiantly separate all reporting into one assembly though. Currently the reports and report BOs live in the same assembly as the related business objects. Also, my BOs that can be printed have a GetReport method which accepts a LocalReport object... and it actually coordinates with the reporting BOs to properly setup the LocalReport object. I was never too crazy about that solution though, as technically the BO is now tied to a specific reporting setup, which is itself a UI layer (Microsoft.Reporting.WinForms).
The other problem is that without SSRS, I have no way to enable end users to do their own reporting. That's something I'd like to allow them to do as well. Also, I'd prefer to use SSRS over buying something else... really because we already own it, and I'd like to get the most value out of Sql server as I can.
Thanks!
Andy
We were using ReportingServices 2005 but out source data was an
Oracle database so SSIS woldn’t have helped. The worst problems
were around deploying and testing.
1)
Our dev server was virtual and I spend huge amounts of time
waiting for navigation through the hierarchy. I would finally get the
report I needed, the parms would take forever to load, and then the report wasn’t
the lastest version. There was some caching issues that the developer
would deploy but it wouldn’t show up for a while. It also got worse
if people ran reports and they crapped out then we had no idea where the issues
were.
2)
The options for ‘params’ are lousy, you have no
control over the basic layout out of the out of the box controls (dropdown
lists).
3)
We had issues everytime we deployed we lost the settings on default
parameter values, required/null setting etc.
I have no experience with BIDS or is capabilities. I had
to google just to find out what it meant J
To load our reports we had a couple of ASP pages with the
embedded control. I haven’t actually seen the control but I just
pass the path to the RDL file and it loads it up. I can confirm or get a
code snippit if you like next time I’m in that office (Monday).
From your last statement I would wonder why you are not doing
all that logic in a StoredProc? I know TSQL/SQLServer isn’t as robust
as Oracle but I wouldn’t want to do anything in .net that I could do in
the database J. Of course I’m a data-centric guy though with my
expertise more in the database side.
As for users doing reports – the DataDynamic tools seem to
have some end-user stuff – I think ActiveReports does. Its nice to
say ‘use the inhouse’ tool, which was exactly why I was stuck with
it, but sometimes its best to just get something quick and cheap.
From: ajj3085
[mailto:cslanet@lhotka.net]
Sent: Thursday, December 11, 2008 11:02 AM
To: jaddington@alexandergracie.com
Subject: Re: [CSLA .NET] OT: Reporting Services
I've had horrible experiences with the one client I have that uses ReportingServices and would shy away from it if I could. However part of the issues were a not great dev/test infrastructure, little support, a few select personnel, and using it for the wrong thing. I inherited a project that was late and overdue and had 'reports' that turned out to be both formatted (like an invoice) and others that were really just 100k row data dumps.
It was miserable as the real requirement was a simple CSV file dump from the database for the big extracts, not a webpage.
Well, was there something with SSRS that you didn't like, or was this a case
of the wrong tool for the job? For a CVS dump, I would think SSIS would
be the right path.
However some of the improvements we made were quite useful. Once we were able to separate the data from the report things went well in terms of maintenance. Of course we were using sprocs and not businessObjects to join the data (big difference between reportingServices vs. the embedded VS report Viewer.). To filter out the business layer (done in PL/SQL for my app) I essentially did all my logic processing and then dumped the data back in to a simple flat temp table with a run_id column.
The reports were then written based on simple select * from tmpTableABC where run_id = 123. They were encapsulated in sProcs but they were simple nontheless. It worked well as we had 1 admin for the server, 1 developer for the web stuff, a different person for the reports, and me. So once I was able to encapsulate the data it worked well. The reports are then maintained outside the app and the database. Big changes (new column) could be done by adding a new column to the temp table and then the reporting guy could tweak the RDL file.
Ok, that's where I'd like to end up.. changing the reports outside of the
application. If I went down the SSRS route, I'd use BIDS to create Data
Sources, Data Source Views, etc.
When I needed to show the report I pulled back the rdl filename from the database lookup table and we showed it on screen with the corresponding rpt_id. Worked really slick and we actually created a secondary reporting portal to manage long running reports and maintaining a reporting queue.
I don't think I'll have any long running reports, fortunately... but this
again sounds like where I'd like to go.
So do you basically just set properties on the ReportViewer.ServerReport
object? Or did you load reports in another manner?
Ironically I'm now in the same position as you are on my current project. My current reports are in PowerBuilder libraries so I have to recreate them. I have purchased DataDynamics new Data Reports product (not their long standing Report tool) which is backwards compatible with RDL files. I had assumed I would either distribute all the report files as standalone file to be read in on demand or create a single reporting assembly that I would distribute independently...
Could you save some headaches by not maintaining all the reporting file as a group vs. as an embedded resource in each BO?
I would be very keen to know what paths you go along...
Well, my main problem is that in order to update or create reports, I need
to deploy a whole new version of my application. That is a pain, as it
seems like a fairly silly reason to do a deploy. I'm also sick of writing
BOs which basically just pull the data back and shape it to match what the
report needs. It's almost all boiler plate code, but I have to maintain
it. (Don't have any code gen).
The other problem is that without SSRS, I have no way to enable end users to
do their own reporting. That's something I'd like to allow them to do as
well. Also, I'd prefer to use SSRS over buying something else... really
because we already own it, and I'd like to get the most value out of Sql server
as I can.
Thanks!
Andy
We were using ReportingServices 2005 but out source data was an Oracle database so SSIS woldn’t have helped. The worst problems were around deploying and testing.
What do you mean by navigate through the hierarchy? Also, were you letting the report prompt for the parameters? Can you still specify them problematically? That's what I do with local reports.. specify everything the report needs to run up front, then let it process. Does the reportviewer VS control cache the reports locally? Or was it a web browser?Our dev server was virtual and I spend huge amounts of time waiting for navigation through the hierarchy. I would finally get the report I needed, the parms would take forever to load, and then the report wasn’t the lastest version. There was some caching issues that the developer would deploy but it wouldn’t show up for a while. It also got worse if people ran reports and they crapped out then we had no idea where the issues were.
Drop down lists? Didn't see them. :-)The options for ‘params’ are lousy, you have no control over the basic layout out of the out of the box controls (dropdown lists).
Ouch.. isn't that stored in the rdl?We had issues everytime we deployed we lost the settings on default parameter values, required/null setting etc.
Ha.. it's just a VS shell you get with Sql Server.I have no experience with BIDS or is capabilities. I had to google just to find out what it meant J
Ahh.. sounds like the WebForms ReportViewer control. I plan on sticking with the WinForms one.. maybe that will make things different.To load our reports we had a couple of ASP pages with the embedded control. I haven’t actually seen the control but I just pass the path to the RDL file and it loads it up. I can confirm or get a code snippit if you like next time I’m in that office (Monday).
Well, inteperating the data I usually consider business code, and so it ends up in the business layer. I was thinking of reports as another use case, and thus build Csla BOs around them.From your last statement I would wonder why you are not doing all that logic in a StoredProc? I know TSQL/SQLServer isn’t as robust as Oracle but I wouldn’t want to do anything in .net that I could do in the database J. Of course I’m a data-centric guy though with my expertise more in the database side.
Well, either way will require me coming up to speed on the technology.. moreso with DD, since I've already done rdlc's, which are fairly similar, just run on the client. And $0 is always going to beat out > $0. :-)As for users doing reports – the DataDynamic tools seem to have some end-user stuff – I think ActiveReports does. Its nice to say ‘use the inhouse’ tool, which was exactly why I was stuck with it, but sometimes its best to just get something quick and cheap.
Why not spawn an ASP page with the reports (WPF has a IE pluging
no)? – or setup a service to take the report request – run the
report, PDF it, and present/email it to the users. I’ve done that
strategy too. ActivePDF has a great PDF Toolkit that you can intercept
any print function and do PDF wonders with it before sending it back to the
user.
SSRS can spawn a PDF as well – I’m not sure well
that can be automated though. I’ve heard 2008 is much better than
2005 although my web guy’s favourite line is – it’s a bug but
fixed in the new version J.
I’m starting to get a bit worried about what I’m
going to do J. I’m also ditching winforms for Silverlight/WPF and
hoping to bypass as much ASP as possible. Granted the reportViewer I just
bought with DataDynamics is winforms/ASP so I’m going to have a hybrid
solution as well unless I do it all under the covers and just return PDF’s
or excel dumps.
From: ajj3085
[mailto:cslanet@lhotka.net]
Sent: Thursday, December 11, 2008 11:08 AM
To: jaddington@alexandergracie.com
Subject: Re: [CSLA .NET] OT: Reporting Services
I haven't looked that much into SSRS. I'd like to move
away from my current approach.
What's bringing this to light is that I'm trying to keep my Wpf application
clean of WinForms... and so I have no report viewer. I'm getting around
this by embedding the reportviewer into a window in my common Wpf library, so
the rest of Wpf needn't worry about it.. but this is posing other problems, for
example the LocalReport.ReportEmbeddedResource (or whatever) needs to be set in
the same assembly in which the report lives.. which is exactly where I'm trying
to prevent ReportViewer code from appearing!
Why not spawn an ASP page with the reports (WPF has a IE pluging no)? – or setup a service to take the report request – run the report, PDF it, and present/email it to the users. I’ve done that strategy too. ActivePDF has a great PDF Toolkit that you can intercept any print function and do PDF wonders with it before sending it back to the user.
I’m starting to get a bit worried about what I’m going to do J. I’m also ditching winforms for Silverlight/WPF and hoping to bypass as much ASP as possible. Granted the reportViewer I just bought with DataDynamics is winforms/ASP so I’m going to have a hybrid solution as well unless I do it all under the covers and just return PDF’s or excel dumps.
![Smile [:)]](/emoticons/emotion-1.gif)
The webform control that links with SSRS has all the export
capabilities. If you just had the control as 100% of the IE window the users
would never even know. I don’t know if there are more/less features in the web
vs. win control. But if it’s a static report who cares.
From: ajj3085
[mailto:cslanet@lhotka.net]
Sent: Thursday, December 11, 2008 12:59 PM
To: jaddington@alexandergracie.com
Subject: Re: [CSLA .NET] RE: OT: Reporting Services
Why not spawn an ASP page with the reports (WPF has a IE pluging no)? – or setup a service to take the report request – run the report, PDF it, and present/email it to the users. I’ve done that strategy too. ActivePDF has a great PDF Toolkit that you can intercept any print function and do PDF wonders with it before sending it back to the user.
I could pop IE into a Wpf window, but I'd like to keep as much rich client
functionality as I can. Using the existing winform control would be
closer to that then trying to embed a web page. Plus, the Winform control
has an export to PDF built in as well... and its what my users are already used
to.
Jack:
I’m starting to get a bit worried about what I’m going
to do J. I’m also ditching winforms for Silverlight/WPF and hoping to
bypass as much ASP as possible. Granted the reportViewer I just bought
with DataDynamics is winforms/ASP so I’m going to have a hybrid solution as
well unless I do it all under the covers and just return PDF’s or excel
dumps.
Ha... reports are the worst part of building this application. It's
tedious and boring. I also feel like it's time to re-think what I'm
currently doing for reports. I've embedded report viewer too much into
the BOs, and I think moving them out of assemblies will allow me to create new
reports more easily in the future. One assembly is 2.57 MB... and 2.2 of
that is the RDLCs embedded inside! Some of those files have embedded
images, which is why they are so large.
Also, I'm going to have to give users a way to build at least limited reports
in the future... I wouldn't mind creating a new Data Source view to bring
together what they need... but writing the report is something they should be
able to handle. I have enough as it is. ">
You might consider a third party package like Crystal Reports. This would give your clients the ability customize your reports and, depending on what your are supporting, add additional reports to your application.
There may be other packages that are better, but this is the one I am familiar with.
Something else to think about is using WebServices as your
datasource. You could still use your BO to do all the datamanipulation and
then just dump the data out. I’ve never used it but that might be a way to
go. Then you just deploy your RDL’s to the reporting server but get your data
from the webService.
I’m sure 2008 version has lots of fun bells & whistles that
you could piggyback on but you would definitely separate your logic &
presentation layers.
You can even then setup standard reports that users can get
directly from the repository vs. using your app but they share the same source.
From: ajj3085
[mailto:cslanet@lhotka.net]
Sent: Thursday, December 11, 2008 1:39 PM
To: jaddington@alexandergracie.com
Subject: Re: [CSLA .NET] OT: Reporting Services
I used crystal in the late 90s. Actually creating the
RDLC was fairly similar, at least from what I remember. I'm checking out
this link currently, since I suspect they are competing products:
http://www.crystalreportsbook.com/SSRSandCR_ExecSummary.asp
Of course, one I already have, and one will cost more... can't ignore that
either. ">
It was new to 2005 -> http://technet.microsoft.com/en-us/library/aa964129.aspx
Copyright (c) Marimer LLC