Sort of like this:
Status Items Jobs
Status #1: 50000 15
Status #2: 25251 3
I want the user to see this summary information, but also have drill down capability. I'd like the ability to print the summary or just a drill-down.
I'm also considering using Dundas Charts for RS on the report.
Can I accomplish this with Reporting Services? If so, any tips on how to do it? If this a bunch of sub-reports? Can I sum the # of jobs on a sub-report? Should I be looking at BI for this?
Or should I be working on a Forms-based?
Thanks!
Brian
bes7252 wrote:
I'm also considering using Dundas Charts for RS on the report.
Why would you need a chart for this? Basically you would use either a table or matrix for this.
Can I accomplish this with Reporting Services? If so, any tips on how to do it? If this a bunch of sub-reports?
Yes, you can accomplish this with RS. You need to craft the proper SQL query that will give you the data you need for the table. If you get stuck, there are many SQL pros here that can help you. This doesn't have to be a bunch of sub-reports. It could be as little as two -- one to drilldown on the Item field and one to drilldown on the Jobs field.
Tips:
1. Create the parent report and get the data for the report that you need using a SQL query.
2. Create the subreport layout and pass parameters as needed from the parent report to subreport.
Can I sum the # of jobs on a sub-report? Should I be looking at BI for this?
1. Yes
2. If you want to, but it isn't necessary.
You will find that the power of these reports is SQL. If you aren't comfortable with SQL, you probably won't be very comfortable doing this.
|||> Why would you need a chart for this? Basically you would use either a table or matrix for this.I should have used the word Gague instead of Chart. The report is sort of a dashboard look at a section of our business. I figured if I wanted to provide more info for each status (like avg jobs/day over the last 2 weeks) then a gague might provide a nice visual.
I am comfortable with SQL, but an not familiar with all the ways to use MSSQL. It seems like every time I figure out a way to do something, someone shows me a better way. I think you're suggesting I create the columns in the SELECT statement like this:
SELECT (SELECT COUNT(*) AS EXPR1
FROM Person.Contact
WHERE (EmailPromotion = '1') AND (LastName > 'S')) AS col1,
(SELECT COUNT(*) AS EXPR1
FROM Person.Contact AS Contact_1
WHERE (EmailPromotion = '0') AND (LastName <= 'S')) AS col2
Assuming I've done this correctly, I have a concern. One of the reasons I considered a sub-reports is then I know the data from each subreport will match the total on the parent. If I use a WHERE condition (like shown above), can I make sure the drill-down data always uses the same condition? Maybe store it in a variable? I'm concerned that down the road we'll change the condition in the parent, but forget to change the detailed view.
Brian
|||
> If I use a WHERE condition (like shown above), can I make sure the drill-down data always uses the same condition? Maybe store it in a variable? I'm concerned that down the road we'll change the condition in the parent, but forget to change the detailed view. Brian
The where condition shown above is what we call a 'hard-coded' value. You would want to create parameters in place of those values. In reporting services, we typically use parameters (similar to variables).
It would be something like WHERE EmailPromotion = @.emailPromotion AND LastName <= @.lastName.
When I use parameters, I like to put them in a stored procedure (as opposed to a text query).
The final step to this (once you get a stored procedure working in the parent report with parameters) is to pass the values by right clicking on the chart -> properties -> navigation. Here you can pass the parameters to the drill down.
In the drill down you would use a similar approach:
WHERE EmailPromotion = @.emailPromotion AND LastName <= @.lastName
Therefore, it would get the passed parameters from the parent report. Then the values are not "hard-coded".
|||Greg,
That makes sense. Can I define the entire Where clause as a parameter? Then pass it in to the stored procedure and have the SQL built on the fly?
(This one might be outside the scope of this forum.) I'll probably use a ReportViewer control embedded in a WPF application. Once the user drills down he'll see job numbers. When the user clicks on a job #, can I have launch a form? Perhaps this would involve some kind of event binding between my code and the ReportViewer control?
Brian
|||
Can I define the entire Where clause as a parameter? Then pass it in to the stored procedure and have the SQL built on the fly?
I would just use the parameters that I indicated with @. signs as parameters. I wouldn't pass the entire where clause as a parameter.
When the user clicks on a job #, can I have launch a form? Perhaps this would involve some kind of event binding between my code and the ReportViewer control?
I use Visual Studio to handle all of the event binding. Do you have Visual Studio 2005 or just SQL 2005? Visual Studio handles this quite well.
|||>> I would just use the parameters that I indicated with @. signs as parameters. I wouldn't pass the entire where clause as a parameter.
Will I suffer performance loss if I do this? I ask because the WHERE clause for each status will be drastically different. I'd prefer to guarentee the parent always matches the child by storing the entire string in a parameter.
>> I use Visual Studio to handle all of the event binding. Do you have Visual Studio 2005 or just SQL 2005? Visual Studio handles this quite well.
I have VS2005 Pro. The app uses WPF for the interface, but the ReportViewer is inside a Winform control. (I can't remeber what it's called). I'll look through the event bindings.
Thanks much for your help.
Brian
No comments:
Post a Comment