|
|
You're in the
sql server reporting services
group:SP1a ?
sql server reporting services:
Is Microsoft intending to release SP1a for Reporting Services? Given the issues I've read in this group, my firm is reluctant to deploy SP1. The PC we have trialled it on has had DLL and functionality issues like other people have described. SP1 has been a disaster - we await SP1a to smooth over the issues.
Are you using 15 tables in your query or 15 report tables? If it is the =
query than RS has nothing to do with it, query are completely pass = through. If it is report tables then we can look into it. You are = correct that 15 tables was not a design goal for V1. While there are = not built in limitations this was not a core scenario. What formatting = options do you think are lacking? --=20 This posting is provided "AS IS" with no warranties, and confers no = rights. [quoted text, click to view] "Kevin" <kevin@misnet.info> wrote in message = As well, we are getting more reluctant about being able to use RS in a =news:%23akgGayXEHA.1656@TK2MSFTNGP09.phx.gbl... production environment. I will say, that RS 1.0 is a very good first = release - if you expect first releases to have lots of promise and lots = of "quirks". RS isn't ready for deployment in all organizations. =20 We have been working with it for over a month, and so far, it has a = hard time handling complex reports (with 15+ tables). One of our = applicions is highly normalized and it requires 25 tables to "capture" = the necessary data to display in a report. We are currently using = Crystal Reports 8.5 - and it does a good job. BUT...we would like to = make the switch to RS - but it just can't handle it...at least not with = this release. =20 Given the amount of questions in this newsgroup, it is apparent that = there are several more problems with RS that need to be corrected before = it can be considered as truly a competitve reporting tool like Crystal = Reports. =20 Before I get flamed, our developers are trying to make RS work - it = just doesn't work on complex reports...simple reports, yes...large and = complex reports, no. We am willing to keep working at it though and I = an anxious to see a SP1a - or a version 2.0 - or whatever, and wait = until it is really giving Crystal Reports a run for the money. As far as RS stands today - it is off to a very good start and has = many promising features. It really lacks flexible formatting or the = formatting options just don't do enough (same thing?). For a free = product - I suppose you can't complain! But I suppose that will change = eventually. It would be nice to think that RS would always be free with = SQL license. =20 My advise to Microsoft - learn how to use Crystal Reports and you'll = see the type of functionality and capabilities that are missing within = RS. Again - this isn't a slam...I want RS to work well and I want it be = highly competitive with ReportSmith, Businss Objects, and Crystal = Reports. ...so...this is "constructive" directions! For all of the = Microsoft employees - Thanks for giving us a promising reporting system, = but please listen to all of the users in this forum. There are many = good ideas that (if incorporated) will begin to be competitve on the = same level. =20 ...just my 2 cents... -Kevin [quoted text, click to view] "BrettF" <BrettF@discussions.microsoft.com> wrote in message = Given the issues I've read in this group, my firm is reluctant to deploy =news:04CA7FA7-19E1-4343-9D3C-9AC7E2DD5BD5@microsoft.com... > Is Microsoft intending to release SP1a for Reporting Services? = SP1. The PC we have trialled it on has had DLL and functionality issues = like other people have described. SP1 has been a disaster - we await = SP1a to smooth over the issues.
While there have been some upgrade issues (cached copies of DLLs is the
primary one), I don't know of any new problems with SP1 other than some [quoted text, click to view] Excel rendering issues (which are due to the fact that we basically rewrote the Excel extension). We certainly didn't fix every bug in RTM but it should be much better in certain areas. If this is not the case, then we want to make sure these get into the next round of fixes. There are no plans for SP1a but we will have started planning SP2. -- Brian Welcker Group Program Manager SQL Server Reporting Services This posting is provided "AS IS" with no warranties, and confers no rights. [quoted text, click to view] "BrettF" <BrettF@discussions.microsoft.com> wrote in message news:04CA7FA7-19E1-4343-9D3C-9AC7E2DD5BD5@microsoft.com... > Is Microsoft intending to release SP1a for Reporting Services? Given the > issues I've read in this group, my firm is reluctant to deploy SP1. The > PC we have trialled it on has had DLL and functionality issues like other > people have described. SP1 has been a disaster - we await SP1a to smooth > over the issues. >
I would say, declaring SP1 as an desaster is a bit too harsh. SP1 has fixed
a couple of issues (lot's of them I've never seen) but has brought new problems. That's true. I cannot comment on possible bottlenecks RS has with ~15 tables in a report. My maximum was 6 and it worked pretty good. I agree on the lecks of export functionalities and other functionalities (aggregate functions in charts, derived datasets,...) However, RS _1.0_ is a well done thing for me, what could be better, of course. But it makes curious for things to come. roland
If you look at the issues questions most of them are either more on the
fringe or pretty specialized obscure stuff, or people just learning. For instance the guy that responded about 25 tables (still not sure on that one). You will also hear about people with 1,000 page report have performance problems (Duh). There is a learning curve with any product and some of that is what you are seeing. Another issue is people are converting reports and want it to look and act exactly the same. Would they have designed the report the way they did in Crystal if they were designing it for the first time in RS, probably not. All reports have different strengths and weaknesses. I guarantee you there are things that are very easy to do in RS that are not as easy with other products. The ability to do drill through is incredible easy. The ability to integrate with either web services or URL. Also, keep in mind there are lots of configuration and security possibilities. By my following of things they usually get resolved and installed. For instance web farm, kerberos, etc. Plus if setting up for internet (versus intranet) there are definitely steps you need to follow. A lot of what you are seeing is people learning how to configure the system. I have worked with releases that caused more problems than they solved and SP1 is definitely not one of those. I have had no issues with it. Bruce L-C [quoted text, click to view] "BrettF" <BrettF@discussions.microsoft.com> wrote in message issues I've read in this group, my firm is reluctant to deploy SP1. The PCnews:04CA7FA7-19E1-4343-9D3C-9AC7E2DD5BD5@microsoft.com... > Is Microsoft intending to release SP1a for Reporting Services? Given the we have trialled it on has had DLL and functionality issues like other people have described. SP1 has been a disaster - we await SP1a to smooth over the issues. [quoted text, click to view] >
Very nice point about 1,000 pages. I understand the difficulty of trying to get people to understand that a 1,000 page report is totaly useless. Who is going to read 1,000 pages and what are you going to do with it.
I agree that RS is far from perfect but after all the HUGE problems I had with Crystal when trying to build reports from complicated datasets and SPs(When running an SP Crystal would intermittently just not work). I was relieved by how well RS has worked for our organization. CR still has some advantages over RS but unless there are some major changes in how CR and particularly CE work RS should cut significantly into their market share. [quoted text, click to view] "Bruce Loehle-Conger" wrote:
> If you look at the issues questions most of them are either more on the > fringe or pretty specialized obscure stuff, or people just learning. For > instance the guy that responded about 25 tables (still not sure on that > one). You will also hear about people with 1,000 page report have > performance problems (Duh). There is a learning curve with any product and > some of that is what you are seeing. Another issue is people are converting > reports and want it to look and act exactly the same. Would they have > designed the report the way they did in Crystal if they were designing it > for the first time in RS, probably not. All reports have different strengths > and weaknesses. I guarantee you there are things that are very easy to do in > RS that are not as easy with other products. The ability to do drill through > is incredible easy. The ability to integrate with either web services or > URL. > > Also, keep in mind there are lots of configuration and security > possibilities. By my following of things they usually get resolved and > installed. For instance web farm, kerberos, etc. Plus if setting up for > internet (versus intranet) there are definitely steps you need to follow. A > lot of what you are seeing is people learning how to configure the system. > > I have worked with releases that caused more problems than they solved and > SP1 is definitely not one of those. I have had no issues with it. > > Bruce L-C > > "BrettF" <BrettF@discussions.microsoft.com> wrote in message > news:04CA7FA7-19E1-4343-9D3C-9AC7E2DD5BD5@microsoft.com... > > Is Microsoft intending to release SP1a for Reporting Services? Given the > issues I've read in this group, my firm is reluctant to deploy SP1. The PC > we have trialled it on has had DLL and functionality issues like other > people have described. SP1 has been a disaster - we await SP1a to smooth > over the issues. > > > >
"One of our applicions is highly normalized and it requires 25 tables to =
"capture" the necessary data to display in a report." Cant you just wrap this SQL up in a view, or stored procedure. We never = ( hardly ever ) write a report to the actual schema - instead we write a = view or proc for every report. Easier to maintain.
Reporting Services is a very Good and Promising Product.Nothing is PERFECT in this world. For our organization the RS is working quite well and don't see any show stopper limitation in the orginal version unless we want to get 1000+ page report from 25+ tables located at MARS and MOON.
Vijay Tripathi. [quoted text, click to view] "johnE" wrote:
> Very nice point about 1,000 pages. I understand the difficulty of trying to get people to understand that a 1,000 page report is totaly useless. Who is going to read 1,000 pages and what are you going to do with it. > I agree that RS is far from perfect but after all the HUGE problems I had with Crystal when trying to build reports from complicated datasets and SPs(When running an SP Crystal would intermittently just not work). I was relieved by how well RS has worked for our organization. CR still has some advantages over RS but unless there are some major changes in how CR and particularly CE work RS should cut significantly into their market share. > > "Bruce Loehle-Conger" wrote: > > > If you look at the issues questions most of them are either more on the > > fringe or pretty specialized obscure stuff, or people just learning. For > > instance the guy that responded about 25 tables (still not sure on that > > one). You will also hear about people with 1,000 page report have > > performance problems (Duh). There is a learning curve with any product and > > some of that is what you are seeing. Another issue is people are converting > > reports and want it to look and act exactly the same. Would they have > > designed the report the way they did in Crystal if they were designing it > > for the first time in RS, probably not. All reports have different strengths > > and weaknesses. I guarantee you there are things that are very easy to do in > > RS that are not as easy with other products. The ability to do drill through > > is incredible easy. The ability to integrate with either web services or > > URL. > > > > Also, keep in mind there are lots of configuration and security > > possibilities. By my following of things they usually get resolved and > > installed. For instance web farm, kerberos, etc. Plus if setting up for > > internet (versus intranet) there are definitely steps you need to follow. A > > lot of what you are seeing is people learning how to configure the system. > > > > I have worked with releases that caused more problems than they solved and > > SP1 is definitely not one of those. I have had no issues with it. > > > > Bruce L-C > > > > "BrettF" <BrettF@discussions.microsoft.com> wrote in message > > news:04CA7FA7-19E1-4343-9D3C-9AC7E2DD5BD5@microsoft.com... > > > Is Microsoft intending to release SP1a for Reporting Services? Given the > > issues I've read in this group, my firm is reluctant to deploy SP1. The PC > > we have trialled it on has had DLL and functionality issues like other > > people have described. SP1 has been a disaster - we await SP1a to smooth > > over the issues. > > > > > > >
As well, we are getting more reluctant about being able to use RS in a =
production environment. I will say, that RS 1.0 is a very good first = release - if you expect first releases to have lots of promise and lots = of "quirks". RS isn't ready for deployment in all organizations. =20 We have been working with it for over a month, and so far, it has a hard = time handling complex reports (with 15+ tables). One of our applicions = is highly normalized and it requires 25 tables to "capture" the = necessary data to display in a report. We are currently using Crystal = Reports 8.5 - and it does a good job. BUT...we would like to make the = switch to RS - but it just can't handle it...at least not with this = release. =20 Given the amount of questions in this newsgroup, it is apparent that = there are several more problems with RS that need to be corrected before = it can be considered as truly a competitve reporting tool like Crystal = Reports. =20 Before I get flamed, our developers are trying to make RS work - it just = doesn't work on complex reports...simple reports, yes...large and = complex reports, no. We am willing to keep working at it though and I = an anxious to see a SP1a - or a version 2.0 - or whatever, and wait = until it is really giving Crystal Reports a run for the money. As far as RS stands today - it is off to a very good start and has many = promising features. It really lacks flexible formatting or the = formatting options just don't do enough (same thing?). For a free = product - I suppose you can't complain! But I suppose that will change = eventually. It would be nice to think that RS would always be free with = SQL license. =20 My advise to Microsoft - learn how to use Crystal Reports and you'll see = the type of functionality and capabilities that are missing within RS. = Again - this isn't a slam...I want RS to work well and I want it be = highly competitive with ReportSmith, Businss Objects, and Crystal = Reports. ...so...this is "constructive" directions! For all of the = Microsoft employees - Thanks for giving us a promising reporting system, = but please listen to all of the users in this forum. There are many = good ideas that (if incorporated) will begin to be competitve on the = same level. =20 ....just my 2 cents... -Kevin [quoted text, click to view] "BrettF" <BrettF@discussions.microsoft.com> wrote in message = the issues I've read in this group, my firm is reluctant to deploy SP1. =news:04CA7FA7-19E1-4343-9D3C-9AC7E2DD5BD5@microsoft.com... > Is Microsoft intending to release SP1a for Reporting Services? Given = The PC we have trialled it on has had DLL and functionality issues like = other people have described. SP1 has been a disaster - we await SP1a to = smooth over the issues.
I'm sorry. Didn't convince me. The reports are for users. Users will never
look at a 1,000 page report. The database should do the summary and then you should do a drill through for the user to get to the specific information. This design might have been the only solution in the past but with drill through I just don't see it. I do summary, subtotals etc all the time. Then the user clicks on something of interest and drills through to that point of interest. Drill down is nice but if there is a lot of data (think a 10,000 pages) then the performance would be awful. Basic design tenant. You limit the amount of data coming down. Let the database do the processing. There are different solutions to what is wanted and to blame the product for a fringe (and I guarantee you it is fringe) need might be an indication that you should rethink your solution. Drill throughs are great. Very easy to do and very intuitive for the user. Anyone who has used the interest immediately understands how to do them. Bruce L-C "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in message news:40e666e9$0$315$7a628cd7@news.club-internet.fr... [quoted text, click to view] > Heard about report bursting? 1,000 is a very low boundary whenever you > schedule reports that each must have subtotallers or any information > relative to the entire report that must be added to each and every section. > > Technically speaking you need to compute the entire report before you start > rendering it. Creating small report based on profile just doesn't fit this > scenario since you are losing the information in context. As an example, > take a "current page" field : don't you think that a 1,000 page report with > such fields will produce different results than if section reports are > computed and rendered independently. > Results are simply wrong. Now add cross-report linking to this? How is this > supposed to work if you never computed the whole 1,000 page report in the > first place? > There are many such scenarios. > > Again, a 1,000 page report scenario is not an abusive or irrelevant use of > the product. > > > > "johnE" <johnE@discussions.microsoft.com> a écrit dans le message de > news:804F4334-CA7E-4861-98B0-77B6BE0D2D28@microsoft.com... > > Very nice point about 1,000 pages. I understand the difficulty of trying > to get people to understand that a 1,000 page report is totaly useless. Who > is going to read 1,000 pages and what are you going to do with it. > > I agree that RS is far from perfect but after all the HUGE problems I had > with Crystal when trying to build reports from complicated datasets and > SPs(When running an SP Crystal would intermittently just not work). I was > relieved by how well RS has worked for our organization. CR still has some > advantages over RS but unless there are some major changes in how CR and > particularly CE work RS should cut significantly into their market share. > > > > "Bruce Loehle-Conger" wrote: > > > > > If you look at the issues questions most of them are either more on the > > > fringe or pretty specialized obscure stuff, or people just learning. For > > > instance the guy that responded about 25 tables (still not sure on that > > > one). You will also hear about people with 1,000 page report have > > > performance problems (Duh). There is a learning curve with any product > and > > > some of that is what you are seeing. Another issue is people are > converting > > > reports and want it to look and act exactly the same. Would they have > > > designed the report the way they did in Crystal if they were designing > it > > > for the first time in RS, probably not. All reports have different > strengths > > > and weaknesses. I guarantee you there are things that are very easy to > do in > > > RS that are not as easy with other products. The ability to do drill > through > > > is incredible easy. The ability to integrate with either web services or > > > URL. > > > > > > Also, keep in mind there are lots of configuration and security > > > possibilities. By my following of things they usually get resolved and > > > installed. For instance web farm, kerberos, etc. Plus if setting up for > > > internet (versus intranet) there are definitely steps you need to > follow. A > > > lot of what you are seeing is people learning how to configure the > system. > > > > > > I have worked with releases that caused more problems than they solved > and > > > SP1 is definitely not one of those. I have had no issues with it. > > > > > > Bruce L-C > > > > > > "BrettF" <BrettF@discussions.microsoft.com> wrote in message > > > news:04CA7FA7-19E1-4343-9D3C-9AC7E2DD5BD5@microsoft.com... > > > > Is Microsoft intending to release SP1a for Reporting Services? Given > the > > > issues I've read in this group, my firm is reluctant to deploy SP1. The > PC > > > we have trialled it on has had DLL and functionality issues like other > > > people have described. SP1 has been a disaster - we await SP1a to > smooth > > > over the issues. > > > > > > > > > > > > > > >
Heard about report bursting? 1,000 is a very low boundary whenever you
schedule reports that each must have subtotallers or any information relative to the entire report that must be added to each and every section. Technically speaking you need to compute the entire report before you start rendering it. Creating small report based on profile just doesn't fit this scenario since you are losing the information in context. As an example, take a "current page" field : don't you think that a 1,000 page report with such fields will produce different results than if section reports are computed and rendered independently. Results are simply wrong. Now add cross-report linking to this? How is this supposed to work if you never computed the whole 1,000 page report in the first place? There are many such scenarios. Again, a 1,000 page report scenario is not an abusive or irrelevant use of the product. "johnE" <johnE@discussions.microsoft.com> a écrit dans le message de news:804F4334-CA7E-4861-98B0-77B6BE0D2D28@microsoft.com... [quoted text, click to view] > Very nice point about 1,000 pages. I understand the difficulty of trying to get people to understand that a 1,000 page report is totaly useless. Whois going to read 1,000 pages and what are you going to do with it. [quoted text, click to view] > I agree that RS is far from perfect but after all the HUGE problems I had with Crystal when trying to build reports from complicated datasets andSPs(When running an SP Crystal would intermittently just not work). I was relieved by how well RS has worked for our organization. CR still has some advantages over RS but unless there are some major changes in how CR and particularly CE work RS should cut significantly into their market share. [quoted text, click to view] > > "Bruce Loehle-Conger" wrote: > > > If you look at the issues questions most of them are either more on the > > fringe or pretty specialized obscure stuff, or people just learning. For > > instance the guy that responded about 25 tables (still not sure on that > > one). You will also hear about people with 1,000 page report have > > performance problems (Duh). There is a learning curve with any product and > > some of that is what you are seeing. Another issue is people are converting > > reports and want it to look and act exactly the same. Would they have > > designed the report the way they did in Crystal if they were designing it > > for the first time in RS, probably not. All reports have different strengths > > and weaknesses. I guarantee you there are things that are very easy to do in > > RS that are not as easy with other products. The ability to do drill through > > is incredible easy. The ability to integrate with either web services or > > URL. > > > > Also, keep in mind there are lots of configuration and security > > possibilities. By my following of things they usually get resolved and > > installed. For instance web farm, kerberos, etc. Plus if setting up for > > internet (versus intranet) there are definitely steps you need to follow. A > > lot of what you are seeing is people learning how to configure the system. > > > > I have worked with releases that caused more problems than they solved and > > SP1 is definitely not one of those. I have had no issues with it. > > > > Bruce L-C > > > > "BrettF" <BrettF@discussions.microsoft.com> wrote in message > > news:04CA7FA7-19E1-4343-9D3C-9AC7E2DD5BD5@microsoft.com... > > > Is Microsoft intending to release SP1a for Reporting Services? Given the > > issues I've read in this group, my firm is reluctant to deploy SP1. The PC > > we have trialled it on has had DLL and functionality issues like other > > people have described. SP1 has been a disaster - we await SP1a to smooth > > over the issues. > > > > > > > > >
I see what you are saying but the only way I see to do this the way you
envision in RS is to to use report filters and have a whole lot of data. Depending on how many different ways you slice the report you might be better off to have the user profile be included as a parameter to the query. If you are generating the report in advance then you would need to do it as many different ways as you have profiles. Bruce L-C "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in message news:40e6b747$0$313$7a628cd7@news.club-internet.fr... [quoted text, click to view] >
> Sorry, you missed the point. Report bursting produce large reports as part > of the processing chain on the backend only. Reports are eventually sliced > (usually a user profile for each section), and those small slices are then > delivered to actual users. > > Each of those slices may contain data whose value is really related to the > entire report, not only the slice. > > With respect to interactive actions, it's a different matter. I agree that > large reports are not particularly practicable regardless the file format. > Nevertheless, you can provide a great user experience with intelligent > algorithms like sending through the wire only the objects that are necessary > and are not in the cache already ; provide a consistent UI interface, for > instance a More... button ; use chunks through the wire ; allow for download > then offline mode usage. And so on... > > > > > "Bruce Loehle-Conger" <bruce_lcNOSPAM@hotmail.com> a écrit dans le message > de news:%23Kl4VmPYEHA.2908@TK2MSFTNGP10.phx.gbl... > > I'm sorry. Didn't convince me. The reports are for users. Users will never > > look at a 1,000 page report. The database should do the summary and then > you > > should do a drill through for the user to get to the specific information. > > This design might have been the only solution in the past but with drill > > through I just don't see it. I do summary, subtotals etc all the time. > Then > > the user clicks on something of interest and drills through to that point > of > > interest. Drill down is nice but if there is a lot of data (think a 10,000 > > pages) then the performance would be awful. Basic design tenant. You limit > > the amount of data coming down. Let the database do the processing. There > > are different solutions to what is wanted and to blame the product for a > > fringe (and I guarantee you it is fringe) need might be an indication that > > you should rethink your solution. Drill throughs are great. Very easy to > do > > and very intuitive for the user. Anyone who has used the interest > > immediately understands how to do them. > > > > Bruce L-C > > > > "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in > > message news:40e666e9$0$315$7a628cd7@news.club-internet.fr... > > > Heard about report bursting? 1,000 is a very low boundary whenever you > > > schedule reports that each must have subtotallers or any information > > > relative to the entire report that must be added to each and every > > section. > > > > > > Technically speaking you need to compute the entire report before you > > start > > > rendering it. Creating small report based on profile just doesn't fit > this > > > scenario since you are losing the information in context. As an example, > > > take a "current page" field : don't you think that a 1,000 page report > > with > > > such fields will produce different results than if section reports are > > > computed and rendered independently. > > > Results are simply wrong. Now add cross-report linking to this? How is > > this > > > supposed to work if you never computed the whole 1,000 page report in > the > > > first place? > > > There are many such scenarios. > > > > > > Again, a 1,000 page report scenario is not an abusive or irrelevant use > of > > > the product. > > > > > > > > > > > > "johnE" <johnE@discussions.microsoft.com> a écrit dans le message de > > > news:804F4334-CA7E-4861-98B0-77B6BE0D2D28@microsoft.com... > > > > Very nice point about 1,000 pages. I understand the difficulty of > > trying > > > to get people to understand that a 1,000 page report is totaly useless. > > Who > > > is going to read 1,000 pages and what are you going to do with it. > > > > I agree that RS is far from perfect but after all the HUGE problems I > > had > > > with Crystal when trying to build reports from complicated datasets and > > > SPs(When running an SP Crystal would intermittently just not work). I > was > > > relieved by how well RS has worked for our organization. CR still has > > some > > > advantages over RS but unless there are some major changes in how CR and > > > particularly CE work RS should cut significantly into their market > share. > > > > > > > > "Bruce Loehle-Conger" wrote: > > > > > > > > > If you look at the issues questions most of them are either more on > > the > > > > > fringe or pretty specialized obscure stuff, or people just learning. > > For > > > > > instance the guy that responded about 25 tables (still not sure on > > that > > > > > one). You will also hear about people with 1,000 page report have > > > > > performance problems (Duh). There is a learning curve with any > product > > > and > > > > > some of that is what you are seeing. Another issue is people are > > > converting > > > > > reports and want it to look and act exactly the same. Would they > have > > > > > designed the report the way they did in Crystal if they were > designing > > > it > > > > > for the first time in RS, probably not. All reports have different > > > strengths > > > > > and weaknesses. I guarantee you there are things that are very easy > to > > > do in > > > > > RS that are not as easy with other products. The ability to do drill > > > through > > > > > is incredible easy. The ability to integrate with either web > services > > or > > > > > URL. > > > > > > > > > > Also, keep in mind there are lots of configuration and security > > > > > possibilities. By my following of things they usually get resolved > and > > > > > installed. For instance web farm, kerberos, etc. Plus if setting up > > for > > > > > internet (versus intranet) there are definitely steps you need to > > > follow. A > > > > > lot of what you are seeing is people learning how to configure the > > > system. > > > > > > > > > > I have worked with releases that caused more problems than they > solved > > > and > > > > > SP1 is definitely not one of those. I have had no issues with it. > > > > > > > > > > Bruce L-C > > > > > > > > > > "BrettF" <BrettF@discussions.microsoft.com> wrote in message > > > > > news:04CA7FA7-19E1-4343-9D3C-9AC7E2DD5BD5@microsoft.com... > > > > > > Is Microsoft intending to release SP1a for Reporting Services? > > Given > > > the
Sorry, you missed the point. Report bursting produce large reports as part of the processing chain on the backend only. Reports are eventually sliced (usually a user profile for each section), and those small slices are then delivered to actual users. Each of those slices may contain data whose value is really related to the entire report, not only the slice. With respect to interactive actions, it's a different matter. I agree that large reports are not particularly practicable regardless the file format. Nevertheless, you can provide a great user experience with intelligent algorithms like sending through the wire only the objects that are necessary and are not in the cache already ; provide a consistent UI interface, for instance a More... button ; use chunks through the wire ; allow for download then offline mode usage. And so on... "Bruce Loehle-Conger" <bruce_lcNOSPAM@hotmail.com> a écrit dans le message de news:%23Kl4VmPYEHA.2908@TK2MSFTNGP10.phx.gbl... [quoted text, click to view] > I'm sorry. Didn't convince me. The reports are for users. Users will never > look at a 1,000 page report. The database should do the summary and then you > should do a drill through for the user to get to the specific information. > This design might have been the only solution in the past but with drill > through I just don't see it. I do summary, subtotals etc all the time. Then > the user clicks on something of interest and drills through to that point of > interest. Drill down is nice but if there is a lot of data (think a 10,000 > pages) then the performance would be awful. Basic design tenant. You limit > the amount of data coming down. Let the database do the processing. There > are different solutions to what is wanted and to blame the product for a > fringe (and I guarantee you it is fringe) need might be an indication that > you should rethink your solution. Drill throughs are great. Very easy to do > and very intuitive for the user. Anyone who has used the interest > immediately understands how to do them. > > Bruce L-C > > "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in > message news:40e666e9$0$315$7a628cd7@news.club-internet.fr... > > Heard about report bursting? 1,000 is a very low boundary whenever you > > schedule reports that each must have subtotallers or any information > > relative to the entire report that must be added to each and every > section. > > > > Technically speaking you need to compute the entire report before you > start > > rendering it. Creating small report based on profile just doesn't fit this > > scenario since you are losing the information in context. As an example, > > take a "current page" field : don't you think that a 1,000 page report > with > > such fields will produce different results than if section reports are > > computed and rendered independently. > > Results are simply wrong. Now add cross-report linking to this? How is > this > > supposed to work if you never computed the whole 1,000 page report in the > > first place? > > There are many such scenarios. > > > > Again, a 1,000 page report scenario is not an abusive or irrelevant use of > > the product. > > > > > > > > "johnE" <johnE@discussions.microsoft.com> a écrit dans le message de > > news:804F4334-CA7E-4861-98B0-77B6BE0D2D28@microsoft.com... > > > Very nice point about 1,000 pages. I understand the difficulty of > trying > > to get people to understand that a 1,000 page report is totaly useless. > Who > > is going to read 1,000 pages and what are you going to do with it. > > > I agree that RS is far from perfect but after all the HUGE problems I > had > > with Crystal when trying to build reports from complicated datasets and > > SPs(When running an SP Crystal would intermittently just not work). I was > > relieved by how well RS has worked for our organization. CR still has > some > > advantages over RS but unless there are some major changes in how CR and > > particularly CE work RS should cut significantly into their market share. > > > > > > "Bruce Loehle-Conger" wrote: > > > > > > > If you look at the issues questions most of them are either more on > the > > > > fringe or pretty specialized obscure stuff, or people just learning. > For > > > > instance the guy that responded about 25 tables (still not sure on > that > > > > one). You will also hear about people with 1,000 page report have > > > > performance problems (Duh). There is a learning curve with any product > > and > > > > some of that is what you are seeing. Another issue is people are > > converting > > > > reports and want it to look and act exactly the same. Would they have > > > > designed the report the way they did in Crystal if they were designing > > it > > > > for the first time in RS, probably not. All reports have different > > strengths > > > > and weaknesses. I guarantee you there are things that are very easy to > > do in > > > > RS that are not as easy with other products. The ability to do drill > > through > > > > is incredible easy. The ability to integrate with either web services > or > > > > URL. > > > > > > > > Also, keep in mind there are lots of configuration and security > > > > possibilities. By my following of things they usually get resolved and > > > > installed. For instance web farm, kerberos, etc. Plus if setting up > for > > > > internet (versus intranet) there are definitely steps you need to > > follow. A > > > > lot of what you are seeing is people learning how to configure the > > system. > > > > > > > > I have worked with releases that caused more problems than they solved > > and > > > > SP1 is definitely not one of those. I have had no issues with it. > > > > > > > > Bruce L-C > > > > > > > > "BrettF" <BrettF@discussions.microsoft.com> wrote in message > > > > news:04CA7FA7-19E1-4343-9D3C-9AC7E2DD5BD5@microsoft.com... > > > > > Is Microsoft intending to release SP1a for Reporting Services? > Given > > the > > > > issues I've read in this group, my firm is reluctant to deploy SP1. > The > > PC > > > > we have trialled it on has had DLL and functionality issues like other > > > > people have described. SP1 has been a disaster - we await SP1a to > > smooth > > > > over the issues. > > > > > > > > > > > > > > > > > > > > > > >
What you describe is simply a performance optimization. Sometimes the
fastest way to deliver 1,000 single page reports is to render a single 1,000 page "report" and then split it into multiple pieces. This still doesn't mean that 1,000 pages in a single unit is a useful thing to provide to end users. That being said, there are lots of performance optimizations for delivering these types of reports (storing aggregates, refiltering data, etc.) There are certainly scenarios where you need to produce massive reports such as a credit card billing run that is routed to a high volume printer bank. We did not optimize Reporting Services V1 for these scenarios but they are something that we are definitely interested in long term. -- Brian Welcker Group Program Manager SQL Server Reporting Services This posting is provided "AS IS" with no warranties, and confers no rights. "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in message news:40e6b747$0$313$7a628cd7@news.club-internet.fr... [quoted text, click to view] >
> Sorry, you missed the point. Report bursting produce large reports as part > of the processing chain on the backend only. Reports are eventually sliced > (usually a user profile for each section), and those small slices are then > delivered to actual users. > > Each of those slices may contain data whose value is really related to the > entire report, not only the slice. > > With respect to interactive actions, it's a different matter. I agree that > large reports are not particularly practicable regardless the file format. > Nevertheless, you can provide a great user experience with intelligent > algorithms like sending through the wire only the objects that are > necessary > and are not in the cache already ; provide a consistent UI interface, for > instance a More... button ; use chunks through the wire ; allow for > download > then offline mode usage. And so on... > > > > > "Bruce Loehle-Conger" <bruce_lcNOSPAM@hotmail.com> a écrit dans le message > de news:%23Kl4VmPYEHA.2908@TK2MSFTNGP10.phx.gbl... >> I'm sorry. Didn't convince me. The reports are for users. Users will >> never >> look at a 1,000 page report. The database should do the summary and then > you >> should do a drill through for the user to get to the specific >> information. >> This design might have been the only solution in the past but with drill >> through I just don't see it. I do summary, subtotals etc all the time. > Then >> the user clicks on something of interest and drills through to that point > of >> interest. Drill down is nice but if there is a lot of data (think a >> 10,000 >> pages) then the performance would be awful. Basic design tenant. You >> limit >> the amount of data coming down. Let the database do the processing. There >> are different solutions to what is wanted and to blame the product for a >> fringe (and I guarantee you it is fringe) need might be an indication >> that >> you should rethink your solution. Drill throughs are great. Very easy to > do >> and very intuitive for the user. Anyone who has used the interest >> immediately understands how to do them. >> >> Bruce L-C >> >> "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in >> message news:40e666e9$0$315$7a628cd7@news.club-internet.fr... >> > Heard about report bursting? 1,000 is a very low boundary whenever you >> > schedule reports that each must have subtotallers or any information >> > relative to the entire report that must be added to each and every >> section. >> > >> > Technically speaking you need to compute the entire report before you >> start >> > rendering it. Creating small report based on profile just doesn't fit > this >> > scenario since you are losing the information in context. As an >> > example, >> > take a "current page" field : don't you think that a 1,000 page report >> with >> > such fields will produce different results than if section reports are >> > computed and rendered independently. >> > Results are simply wrong. Now add cross-report linking to this? How is >> this >> > supposed to work if you never computed the whole 1,000 page report in > the >> > first place? >> > There are many such scenarios. >> > >> > Again, a 1,000 page report scenario is not an abusive or irrelevant use > of >> > the product. >> > >> > >> > >> > "johnE" <johnE@discussions.microsoft.com> a écrit dans le message de >> > news:804F4334-CA7E-4861-98B0-77B6BE0D2D28@microsoft.com... >> > > Very nice point about 1,000 pages. I understand the difficulty of >> trying >> > to get people to understand that a 1,000 page report is totaly useless. >> Who >> > is going to read 1,000 pages and what are you going to do with it. >> > > I agree that RS is far from perfect but after all the HUGE problems >> > > I >> had >> > with Crystal when trying to build reports from complicated datasets and >> > SPs(When running an SP Crystal would intermittently just not work). I > was >> > relieved by how well RS has worked for our organization. CR still has >> some >> > advantages over RS but unless there are some major changes in how CR >> > and >> > particularly CE work RS should cut significantly into their market > share. >> > > >> > > "Bruce Loehle-Conger" wrote: >> > > >> > > > If you look at the issues questions most of them are either more on >> the >> > > > fringe or pretty specialized obscure stuff, or people just >> > > > learning. >> For >> > > > instance the guy that responded about 25 tables (still not sure on >> that >> > > > one). You will also hear about people with 1,000 page report have >> > > > performance problems (Duh). There is a learning curve with any > product >> > and >> > > > some of that is what you are seeing. Another issue is people are >> > converting >> > > > reports and want it to look and act exactly the same. Would they > have >> > > > designed the report the way they did in Crystal if they were > designing >> > it >> > > > for the first time in RS, probably not. All reports have different >> > strengths >> > > > and weaknesses. I guarantee you there are things that are very easy > to >> > do in >> > > > RS that are not as easy with other products. The ability to do >> > > > drill >> > through >> > > > is incredible easy. The ability to integrate with either web > services >> or >> > > > URL. >> > > > >> > > > Also, keep in mind there are lots of configuration and security >> > > > possibilities. By my following of things they usually get resolved > and >> > > > installed. For instance web farm, kerberos, etc. Plus if setting up >> for >> > > > internet (versus intranet) there are definitely steps you need to >> > follow. A >> > > > lot of what you are seeing is people learning how to configure the >> > system. >> > > > >> > > > I have worked with releases that caused more problems than they
Why do you say it has nothing to do with performance? If I can create 1000
reports to 1000 people, why does it matter if they were sections of a large report or individualy created reports as long as they have consistent data? If you ask end users of reporting applications whether they want bursting, they will have no idea what you are talking about. Busting is a technique to accomplish another scenario, that is, personalized delivery. -- Brian Welcker Group Program Manager SQL Server Reporting Services This posting is provided "AS IS" with no warranties, and confers no rights. "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in message news:40e80521$0$313$7a628cd7@news.club-internet.fr... [quoted text, click to view] >
> No, report bursting has nothing to do with performance optimization. Note > I > don't prejudge the ability of MSRS to support this kind of scenario, I was > only explaining a real world enterprise reporting scenario. > > > > "Brian Welcker [MSFT]" <bwelcker@online.microsoft.com> wrote in message > news:OtUBnaZYEHA.4008@TK2MSFTNGP09.phx.gbl... >> What you describe is simply a performance optimization. Sometimes the >> fastest way to deliver 1,000 single page reports is to render a single > 1,000 >> page "report" and then split it into multiple pieces. This still doesn't >> mean that 1,000 pages in a single unit is a useful thing to provide to >> end >> users. That being said, there are lots of performance optimizations for >> delivering these types of reports (storing aggregates, refiltering data, >> etc.) >> >> There are certainly scenarios where you need to produce massive reports > such >> as a credit card billing run that is routed to a high volume printer >> bank. >> We did not optimize Reporting Services V1 for these scenarios but they >> are >> something that we are definitely interested in long term. >> >> >> -- >> Brian Welcker >> Group Program Manager >> SQL Server Reporting Services >> >> This posting is provided "AS IS" with no warranties, and confers no > rights. >> >> "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in >> message news:40e6b747$0$313$7a628cd7@news.club-internet.fr... >> > >> > Sorry, you missed the point. Report bursting produce large reports as > part >> > of the processing chain on the backend only. Reports are eventually > sliced >> > (usually a user profile for each section), and those small slices are > then >> > delivered to actual users. >> > >> > Each of those slices may contain data whose value is really related to > the >> > entire report, not only the slice. >> > >> > With respect to interactive actions, it's a different matter. I agree > that >> > large reports are not particularly practicable regardless the file > format. >> > Nevertheless, you can provide a great user experience with intelligent >> > algorithms like sending through the wire only the objects that are >> > necessary >> > and are not in the cache already ; provide a consistent UI interface, > for >> > instance a More... button ; use chunks through the wire ; allow for >> > download >> > then offline mode usage. And so on... >> > >> > >> > >> > >> > "Bruce Loehle-Conger" <bruce_lcNOSPAM@hotmail.com> a écrit dans le > message >> > de news:%23Kl4VmPYEHA.2908@TK2MSFTNGP10.phx.gbl... >> >> I'm sorry. Didn't convince me. The reports are for users. Users will >> >> never >> >> look at a 1,000 page report. The database should do the summary and > then >> > you >> >> should do a drill through for the user to get to the specific >> >> information. >> >> This design might have been the only solution in the past but with > drill >> >> through I just don't see it. I do summary, subtotals etc all the time. >> > Then >> >> the user clicks on something of interest and drills through to that > point >> > of >> >> interest. Drill down is nice but if there is a lot of data (think a >> >> 10,000 >> >> pages) then the performance would be awful. Basic design tenant. You >> >> limit >> >> the amount of data coming down. Let the database do the processing. > There >> >> are different solutions to what is wanted and to blame the product for > a >> >> fringe (and I guarantee you it is fringe) need might be an indication >> >> that >> >> you should rethink your solution. Drill throughs are great. Very easy > to >> > do >> >> and very intuitive for the user. Anyone who has used the interest >> >> immediately understands how to do them. >> >> >> >> Bruce L-C >> >> >> >> "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in >> >> message news:40e666e9$0$315$7a628cd7@news.club-internet.fr... >> >> > Heard about report bursting? 1,000 is a very low boundary whenever > you >> >> > schedule reports that each must have subtotallers or any information >> >> > relative to the entire report that must be added to each and every >> >> section. >> >> > >> >> > Technically speaking you need to compute the entire report before >> >> > you >> >> start >> >> > rendering it. Creating small report based on profile just doesn't >> >> > fit >> > this >> >> > scenario since you are losing the information in context. As an >> >> > example, >> >> > take a "current page" field : don't you think that a 1,000 page > report >> >> with >> >> > such fields will produce different results than if section reports > are >> >> > computed and rendered independently. >> >> > Results are simply wrong. Now add cross-report linking to this? How > is >> >> this >> >> > supposed to work if you never computed the whole 1,000 page report >> >> > in >> > the >> >> > first place? >> >> > There are many such scenarios. >> >> > >> >> > Again, a 1,000 page report scenario is not an abusive or irrelevant > use >> > of >> >> > the product. >> >> > >> >> > >> >> > >> >> > "johnE" <johnE@discussions.microsoft.com> a écrit dans le message de >> >> > news:804F4334-CA7E-4861-98B0-77B6BE0D2D28@microsoft.com... >> >> > > Very nice point about 1,000 pages. I understand the difficulty of >> >> trying >> >> > to get people to understand that a 1,000 page report is totaly > useless. >> >> Who >> >> > is going to read 1,000 pages and what are you going to do with it. >> >> > > I agree that RS is far from perfect but after all the HUGE > problems >> >> > > I >> >> had >> >> > with Crystal when trying to build reports from complicated datasets > and >> >> > SPs(When running an SP Crystal would intermittently just not work). > I >> > was >> >> > relieved by how well RS has worked for our organization. CR still > has >> >> some >> >> > advantages over RS but unless there are some major changes in how CR >> >> > and >> >> > particularly CE work RS should cut significantly into their market >> > share. >> >> > > >> >> > > "Bruce Loehle-Conger" wrote: >> >> > >
No, report bursting has nothing to do with performance optimization. Note I don't prejudge the ability of MSRS to support this kind of scenario, I was only explaining a real world enterprise reporting scenario. [quoted text, click to view] "Brian Welcker [MSFT]" <bwelcker@online.microsoft.com> wrote in message
news:OtUBnaZYEHA.4008@TK2MSFTNGP09.phx.gbl... > What you describe is simply a performance optimization. Sometimes the > fastest way to deliver 1,000 single page reports is to render a single 1,000 > page "report" and then split it into multiple pieces. This still doesn't > mean that 1,000 pages in a single unit is a useful thing to provide to end > users. That being said, there are lots of performance optimizations for > delivering these types of reports (storing aggregates, refiltering data, > etc.) > > There are certainly scenarios where you need to produce massive reports such > as a credit card billing run that is routed to a high volume printer bank. > We did not optimize Reporting Services V1 for these scenarios but they are > something that we are definitely interested in long term. > > > -- > Brian Welcker > Group Program Manager > SQL Server Reporting Services > > This posting is provided "AS IS" with no warranties, and confers no rights. > > "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in > message news:40e6b747$0$313$7a628cd7@news.club-internet.fr... > > > > Sorry, you missed the point. Report bursting produce large reports as part > > of the processing chain on the backend only. Reports are eventually sliced > > (usually a user profile for each section), and those small slices are then > > delivered to actual users. > > > > Each of those slices may contain data whose value is really related to the > > entire report, not only the slice. > > > > With respect to interactive actions, it's a different matter. I agree that > > large reports are not particularly practicable regardless the file format. > > Nevertheless, you can provide a great user experience with intelligent > > algorithms like sending through the wire only the objects that are > > necessary > > and are not in the cache already ; provide a consistent UI interface, for > > instance a More... button ; use chunks through the wire ; allow for > > download > > then offline mode usage. And so on... > > > > > > > > > > "Bruce Loehle-Conger" <bruce_lcNOSPAM@hotmail.com> a écrit dans le message > > de news:%23Kl4VmPYEHA.2908@TK2MSFTNGP10.phx.gbl... > >> I'm sorry. Didn't convince me. The reports are for users. Users will > >> never > >> look at a 1,000 page report. The database should do the summary and then > > you > >> should do a drill through for the user to get to the specific > >> information. > >> This design might have been the only solution in the past but with drill > >> through I just don't see it. I do summary, subtotals etc all the time. > > Then > >> the user clicks on something of interest and drills through to that point > > of > >> interest. Drill down is nice but if there is a lot of data (think a > >> 10,000 > >> pages) then the performance would be awful. Basic design tenant. You > >> limit > >> the amount of data coming down. Let the database do the processing. There > >> are different solutions to what is wanted and to blame the product for a > >> fringe (and I guarantee you it is fringe) need might be an indication > >> that > >> you should rethink your solution. Drill throughs are great. Very easy to > > do > >> and very intuitive for the user. Anyone who has used the interest > >> immediately understands how to do them. > >> > >> Bruce L-C > >> > >> "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in > >> message news:40e666e9$0$315$7a628cd7@news.club-internet.fr... > >> > Heard about report bursting? 1,000 is a very low boundary whenever you > >> > schedule reports that each must have subtotallers or any information > >> > relative to the entire report that must be added to each and every > >> section. > >> > > >> > Technically speaking you need to compute the entire report before you > >> start > >> > rendering it. Creating small report based on profile just doesn't fit > > this > >> > scenario since you are losing the information in context. As an > >> > example, > >> > take a "current page" field : don't you think that a 1,000 page report > >> with > >> > such fields will produce different results than if section reports are > >> > computed and rendered independently. > >> > Results are simply wrong. Now add cross-report linking to this? How is > >> this > >> > supposed to work if you never computed the whole 1,000 page report in > > the > >> > first place? > >> > There are many such scenarios. > >> > > >> > Again, a 1,000 page report scenario is not an abusive or irrelevant use > > of > >> > the product. > >> > > >> > > >> > > >> > "johnE" <johnE@discussions.microsoft.com> a écrit dans le message de > >> > news:804F4334-CA7E-4861-98B0-77B6BE0D2D28@microsoft.com... > >> > > Very nice point about 1,000 pages. I understand the difficulty of > >> trying > >> > to get people to understand that a 1,000 page report is totaly useless. > >> Who > >> > is going to read 1,000 pages and what are you going to do with it. > >> > > I agree that RS is far from perfect but after all the HUGE problems > >> > > I > >> had > >> > with Crystal when trying to build reports from complicated datasets and > >> > SPs(When running an SP Crystal would intermittently just not work). I > > was > >> > relieved by how well RS has worked for our organization. CR still has > >> some > >> > advantages over RS but unless there are some major changes in how CR > >> > and > >> > particularly CE work RS should cut significantly into their market > > share. > >> > > > >> > > "Bruce Loehle-Conger" wrote: > >> > > > >> > > > If you look at the issues questions most of them are either more on > >> the > >> > > > fringe or pretty specialized obscure stuff, or people just > >> > > > learning. > >> For > >> > > > instance the guy that responded about 25 tables (still not sure on > >> that > >> > > > one). You will also hear about people with 1,000 page report have > >> > > > performance problems (Duh). There is a learning curve with any > > product > >> > and > >> > > > some of that is what you are seeing. Another issue is people are > >> > converting > >> > > > reports and want it to look and act exactly the same. Would they > > have > >> > > > designed the report the way they did in Crystal if they were > > designing > >> > it > >> > > > for the first time in RS, probably not. All reports have different > >> > strengths > >> > > > and weaknesses. I guarantee you there are things that are very easy > > to > >> > do in > >> > > > RS that are not as easy with other products. The ability to do > >> > > > drill
[quoted text, click to view]
> Why do you say it has nothing to do with performance? (...) Bursting is a technique to > accomplish __another__ scenario, that is, personalized delivery. That's exactly what I am saying since the beginning.
[quoted text, click to view] >If I can create 1000 data?>reports to 1000 people, why does it matter if they were sections of a large >report or individualy created reports as long as they have __consistent__ The problem is about the consistent data as you said pretty well, and I don't know how to emphasize it more. Let's take a POC : I want to compute a 1,000 page report. Each section is meant to be delivered to a particular user and, as such, the blocks in each of these sections has conditional formulas depending on the user name. But in addition to this, the section has a field $(CURRENTPAGE) / $(PAGECOUNT). Please tell me how you compute the $(PAGECOUNT) (and even the current page by the way) if sections are computed independently, that is if the report engine computes those sections on __prefiltered data_ for performance reasons, or for more convenience, or because of the limitations of the report engine ? You need introspection and impact analysis at precomputation-time IMHO. [quoted text, click to view] "Brian Welcker [MSFT]" <bwelcker@online.microsoft.com> wrote in message
news:O6uwGYeYEHA.2456@TK2MSFTNGP10.phx.gbl... > Why do you say it has nothing to do with performance? If I can create 1000 > reports to 1000 people, why does it matter if they were sections of a large > report or individualy created reports as long as they have consistent data? > If you ask end users of reporting applications whether they want bursting, > they will have no idea what you are talking about. Busting is a technique to > accomplish another scenario, that is, personalized delivery. > > -- > Brian Welcker > Group Program Manager > SQL Server Reporting Services > > This posting is provided "AS IS" with no warranties, and confers no rights. > > "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in > message news:40e80521$0$313$7a628cd7@news.club-internet.fr... > > > > No, report bursting has nothing to do with performance optimization. Note > > I > > don't prejudge the ability of MSRS to support this kind of scenario, I was > > only explaining a real world enterprise reporting scenario. > > > > > > > > "Brian Welcker [MSFT]" <bwelcker@online.microsoft.com> wrote in message > > news:OtUBnaZYEHA.4008@TK2MSFTNGP09.phx.gbl... > >> What you describe is simply a performance optimization. Sometimes the > >> fastest way to deliver 1,000 single page reports is to render a single > > 1,000 > >> page "report" and then split it into multiple pieces. This still doesn't > >> mean that 1,000 pages in a single unit is a useful thing to provide to > >> end > >> users. That being said, there are lots of performance optimizations for > >> delivering these types of reports (storing aggregates, refiltering data, > >> etc.) > >> > >> There are certainly scenarios where you need to produce massive reports > > such > >> as a credit card billing run that is routed to a high volume printer > >> bank. > >> We did not optimize Reporting Services V1 for these scenarios but they > >> are > >> something that we are definitely interested in long term. > >> > >> > >> -- > >> Brian Welcker > >> Group Program Manager > >> SQL Server Reporting Services > >> > >> This posting is provided "AS IS" with no warranties, and confers no > > rights. > >> > >> "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in > >> message news:40e6b747$0$313$7a628cd7@news.club-internet.fr... > >> > > >> > Sorry, you missed the point. Report bursting produce large reports as > > part > >> > of the processing chain on the backend only. Reports are eventually > > sliced > >> > (usually a user profile for each section), and those small slices are > > then > >> > delivered to actual users. > >> > > >> > Each of those slices may contain data whose value is really related to > > the > >> > entire report, not only the slice. > >> > > >> > With respect to interactive actions, it's a different matter. I agree > > that > >> > large reports are not particularly practicable regardless the file > > format. > >> > Nevertheless, you can provide a great user experience with intelligent > >> > algorithms like sending through the wire only the objects that are > >> > necessary > >> > and are not in the cache already ; provide a consistent UI interface, > > for > >> > instance a More... button ; use chunks through the wire ; allow for > >> > download > >> > then offline mode usage. And so on... > >> > > >> > > >> > > >> > > >> > "Bruce Loehle-Conger" <bruce_lcNOSPAM@hotmail.com> a écrit dans le > > message > >> > de news:%23Kl4VmPYEHA.2908@TK2MSFTNGP10.phx.gbl... > >> >> I'm sorry. Didn't convince me. The reports are for users. Users will > >> >> never > >> >> look at a 1,000 page report. The database should do the summary and > > then > >> > you > >> >> should do a drill through for the user to get to the specific > >> >> information. > >> >> This design might have been the only solution in the past but with > > drill > >> >> through I just don't see it. I do summary, subtotals etc all the time. > >> > Then > >> >> the user clicks on something of interest and drills through to that > > point > >> > of > >> >> interest. Drill down is nice but if there is a lot of data (think a > >> >> 10,000 > >> >> pages) then the performance would be awful. Basic design tenant. You > >> >> limit > >> >> the amount of data coming down. Let the database do the processing. > > There > >> >> are different solutions to what is wanted and to blame the product for > > a > >> >> fringe (and I guarantee you it is fringe) need might be an indication > >> >> that > >> >> you should rethink your solution. Drill throughs are great. Very easy > > to > >> > do > >> >> and very intuitive for the user. Anyone who has used the interest > >> >> immediately understands how to do them. > >> >> > >> >> Bruce L-C > >> >> > >> >> "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in > >> >> message news:40e666e9$0$315$7a628cd7@news.club-internet.fr... > >> >> > Heard about report bursting? 1,000 is a very low boundary whenever > > you > >> >> > schedule reports that each must have subtotallers or any information > >> >> > relative to the entire report that must be added to each and every > >> >> section. > >> >> > > >> >> > Technically speaking you need to compute the entire report before > >> >> > you > >> >> start > >> >> > rendering it. Creating small report based on profile just doesn't > >> >> > fit > >> > this > >> >> > scenario since you are losing the information in context. As an > >> >> > example, > >> >> > take a "current page" field : don't you think that a 1,000 page > > report > >> >> with > >> >> > such fields will produce different results than if section reports > > are > >> >> > computed and rendered independently. > >> >> > Results are simply wrong. Now add cross-report linking to this? How > > is
Are you saying that you would actually want a user to see that they have
page 458 - 502 / 1000? Why would a user need to know they got a set of pages in the middle of the run? I still don't see why you are think this needs to be built as a 1,000 page report. There are a variety of ways to maintain data consistency, you don't need to build it as a single contiguous report. -- Brian Welcker Group Program Manager SQL Server Reporting Services This posting is provided "AS IS" with no warranties, and confers no rights. "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in message news:40e85060$0$308$7a628cd7@news.club-internet.fr... [quoted text, click to view] >
>>If I can create 1000 >>reports to 1000 people, why does it matter if they were sections of a >>large >>report or individualy created reports as long as they have __consistent__ > data? > > The problem is about the consistent data as you said pretty well, and I > don't know how to emphasize it more. > > Let's take a POC : I want to compute a 1,000 page report. Each section is > meant to be delivered to a particular user and, as such, the blocks in > each > of these sections has conditional formulas depending on the user name. But > in addition to this, the section has a field $(CURRENTPAGE) / > $(PAGECOUNT). > > Please tell me how you compute the $(PAGECOUNT) (and even the current page > by the way) if sections are computed independently, that is if the report > engine computes those sections on __prefiltered data_ for performance > reasons, or for more convenience, or because of the limitations of the > report engine ? > > You need introspection and impact analysis at precomputation-time IMHO. > > > > "Brian Welcker [MSFT]" <bwelcker@online.microsoft.com> wrote in message > news:O6uwGYeYEHA.2456@TK2MSFTNGP10.phx.gbl... >> Why do you say it has nothing to do with performance? If I can create >> 1000 >> reports to 1000 people, why does it matter if they were sections of a > large >> report or individualy created reports as long as they have consistent > data? >> If you ask end users of reporting applications whether they want >> bursting, >> they will have no idea what you are talking about. Busting is a technique > to >> accomplish another scenario, that is, personalized delivery. >> >> -- >> Brian Welcker >> Group Program Manager >> SQL Server Reporting Services >> >> This posting is provided "AS IS" with no warranties, and confers no > rights. >> >> "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in >> message news:40e80521$0$313$7a628cd7@news.club-internet.fr... >> > >> > No, report bursting has nothing to do with performance optimization. > Note >> > I >> > don't prejudge the ability of MSRS to support this kind of scenario, I > was >> > only explaining a real world enterprise reporting scenario. >> > >> > >> > >> > "Brian Welcker [MSFT]" <bwelcker@online.microsoft.com> wrote in message >> > news:OtUBnaZYEHA.4008@TK2MSFTNGP09.phx.gbl... >> >> What you describe is simply a performance optimization. Sometimes the >> >> fastest way to deliver 1,000 single page reports is to render a single >> > 1,000 >> >> page "report" and then split it into multiple pieces. This still > doesn't >> >> mean that 1,000 pages in a single unit is a useful thing to provide to >> >> end >> >> users. That being said, there are lots of performance optimizations >> >> for >> >> delivering these types of reports (storing aggregates, refiltering > data, >> >> etc.) >> >> >> >> There are certainly scenarios where you need to produce massive >> >> reports >> > such >> >> as a credit card billing run that is routed to a high volume printer >> >> bank. >> >> We did not optimize Reporting Services V1 for these scenarios but they >> >> are >> >> something that we are definitely interested in long term. >> >> >> >> >> >> -- >> >> Brian Welcker >> >> Group Program Manager >> >> SQL Server Reporting Services >> >> >> >> This posting is provided "AS IS" with no warranties, and confers no >> > rights. >> >> >> >> "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in >> >> message news:40e6b747$0$313$7a628cd7@news.club-internet.fr... >> >> > >> >> > Sorry, you missed the point. Report bursting produce large reports >> >> > as >> > part >> >> > of the processing chain on the backend only. Reports are eventually >> > sliced >> >> > (usually a user profile for each section), and those small slices >> >> > are >> > then >> >> > delivered to actual users. >> >> > >> >> > Each of those slices may contain data whose value is really related > to >> > the >> >> > entire report, not only the slice. >> >> > >> >> > With respect to interactive actions, it's a different matter. I >> >> > agree >> > that >> >> > large reports are not particularly practicable regardless the file >> > format. >> >> > Nevertheless, you can provide a great user experience with > intelligent >> >> > algorithms like sending through the wire only the objects that are >> >> > necessary >> >> > and are not in the cache already ; provide a consistent UI >> >> > interface, >> > for >> >> > instance a More... button ; use chunks through the wire ; allow for >> >> > download >> >> > then offline mode usage. And so on... >> >> > >> >> > >> >> > >> >> > >> >> > "Bruce Loehle-Conger" <bruce_lcNOSPAM@hotmail.com> a écrit dans le >> > message >> >> > de news:%23Kl4VmPYEHA.2908@TK2MSFTNGP10.phx.gbl... >> >> >> I'm sorry. Didn't convince me. The reports are for users. Users >> >> >> will >> >> >> never >> >> >> look at a 1,000 page report. The database should do the summary and >> > then >> >> > you >> >> >> should do a drill through for the user to get to the specific >> >> >> information. >> >> >> This design might have been the only solution in the past but with >> > drill >> >> >> through I just don't see it. I do summary, subtotals etc all the > time. >> >> > Then >> >> >> the user clicks on something of interest and drills through to that >> > point >> >> > of >> >> >> interest. Drill down is nice but if there is a lot of data (think a >> >> >> 10,000 >> >> >> pages) then the performance would be awful. Basic design tenant. >> >> >> You >> >> >> limit >> >> >> the amount of data coming down. Let the database do the processing. >> > There >> >> >> are different solutions to what is wanted and to blame the product > for >> > a >> >> >> fringe (and I guarantee you it is fringe) need might be an > indication >> >> >> that >> >> >> you should rethink your solution. Drill throughs are great. Very > easy >> > to >> >> > do >> >> >> and very intuitive for the user. Anyone who has used the interest >> >> >> immediately understands how to do them. >> >> >> >> >> >> Bruce L-C >> >> >> >> >> >> "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote > in
Which is easier...maintaing procs/views that could "break" reports, or =
maintaining the reports themselves? My thinking is that if the report works - you don't have to "re-visit" = to make a correction. If you change a view/proc, you could affect (who = knows how many) reports that use that proc/view. JMHO... -KB [quoted text, click to view] "Chris Brooksbank" <NoSpam@Ta.com> wrote in message = "One of our applicions is highly normalized and it requires 25 tables =news:%23Lg0PA2XEHA.3112@tk2msftngp13.phx.gbl... to "capture" the necessary data to display in a report." Cant you just wrap this SQL up in a view, or stored procedure. We = never ( hardly ever ) write a report to the actual schema - instead we = write a view or proc for every report. Easier to maintain.
Just glance over the discussion. Though very late and the people arguring in
the past may not read this message, I have to give my 2 cents. For dicing and slicing, use OLAP tools, such as MS OLAP service, Cognos Transformer and PowerPlay. Reporting tools such as Crystal Reports, Cognos Imprompt, and MS Reporting Serive is not a right fit. A OLAP cube equals 100 reports. User can create 100 pages reports from a single cube easily by drag and drop. Right task, right tool. As I said befoer in this forum, Reporting Service is the best reporting tool, compared with Crystal Reports and Cognos. [quoted text, click to view] "Stephane Rodriguez" wrote:
> > No, report bursting has nothing to do with performance optimization. Note I > don't prejudge the ability of MSRS to support this kind of scenario, I was > only explaining a real world enterprise reporting scenario. > > > > "Brian Welcker [MSFT]" <bwelcker@online.microsoft.com> wrote in message > news:OtUBnaZYEHA.4008@TK2MSFTNGP09.phx.gbl... > > What you describe is simply a performance optimization. Sometimes the > > fastest way to deliver 1,000 single page reports is to render a single > 1,000 > > page "report" and then split it into multiple pieces. This still doesn't > > mean that 1,000 pages in a single unit is a useful thing to provide to end > > users. That being said, there are lots of performance optimizations for > > delivering these types of reports (storing aggregates, refiltering data, > > etc.) > > > > There are certainly scenarios where you need to produce massive reports > such > > as a credit card billing run that is routed to a high volume printer bank. > > We did not optimize Reporting Services V1 for these scenarios but they are > > something that we are definitely interested in long term. > > > > > > -- > > Brian Welcker > > Group Program Manager > > SQL Server Reporting Services > > > > This posting is provided "AS IS" with no warranties, and confers no > rights. > > > > "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in > > message news:40e6b747$0$313$7a628cd7@news.club-internet.fr... > > > > > > Sorry, you missed the point. Report bursting produce large reports as > part > > > of the processing chain on the backend only. Reports are eventually > sliced > > > (usually a user profile for each section), and those small slices are > then > > > delivered to actual users. > > > > > > Each of those slices may contain data whose value is really related to > the > > > entire report, not only the slice. > > > > > > With respect to interactive actions, it's a different matter. I agree > that > > > large reports are not particularly practicable regardless the file > format. > > > Nevertheless, you can provide a great user experience with intelligent > > > algorithms like sending through the wire only the objects that are > > > necessary > > > and are not in the cache already ; provide a consistent UI interface, > for > > > instance a More... button ; use chunks through the wire ; allow for > > > download > > > then offline mode usage. And so on... > > > > > > > > > > > > > > > "Bruce Loehle-Conger" <bruce_lcNOSPAM@hotmail.com> a écrit dans le > message > > > de news:%23Kl4VmPYEHA.2908@TK2MSFTNGP10.phx.gbl... > > >> I'm sorry. Didn't convince me. The reports are for users. Users will > > >> never > > >> look at a 1,000 page report. The database should do the summary and > then > > > you > > >> should do a drill through for the user to get to the specific > > >> information. > > >> This design might have been the only solution in the past but with > drill > > >> through I just don't see it. I do summary, subtotals etc all the time. > > > Then > > >> the user clicks on something of interest and drills through to that > point > > > of > > >> interest. Drill down is nice but if there is a lot of data (think a > > >> 10,000 > > >> pages) then the performance would be awful. Basic design tenant. You > > >> limit > > >> the amount of data coming down. Let the database do the processing. > There > > >> are different solutions to what is wanted and to blame the product for > a > > >> fringe (and I guarantee you it is fringe) need might be an indication > > >> that > > >> you should rethink your solution. Drill throughs are great. Very easy > to > > > do > > >> and very intuitive for the user. Anyone who has used the interest > > >> immediately understands how to do them. > > >> > > >> Bruce L-C > > >> > > >> "Stephane Rodriguez" <srodriguez@club-internet__NOSPAM__.fr> wrote in > > >> message news:40e666e9$0$315$7a628cd7@news.club-internet.fr... > > >> > Heard about report bursting? 1,000 is a very low boundary whenever > you > > >> > schedule reports that each must have subtotallers or any information > > >> > relative to the entire report that must be added to each and every > > >> section. > > >> > > > >> > Technically speaking you need to compute the entire report before you > > >> start > > >> > rendering it. Creating small report based on profile just doesn't fit > > > this > > >> > scenario since you are losing the information in context. As an > > >> > example, > > >> > take a "current page" field : don't you think that a 1,000 page > report > > >> with > > >> > such fields will produce different results than if section reports > are > > >> > computed and rendered independently. > > >> > Results are simply wrong. Now add cross-report linking to this? How > is > > >> this > > >> > supposed to work if you never computed the whole 1,000 page report in > > > the > > >> > first place? > > >> > There are many such scenarios. > > >> > > > >> > Again, a 1,000 page report scenario is not an abusive or irrelevant > use > > > of > > >> > the product. > > >> > > > >> > > > >> > > > >> > "johnE" <johnE@discussions.microsoft.com> a écrit dans le message de > > >> > news:804F4334-CA7E-4861-98B0-77B6BE0D2D28@microsoft.com... > > >> > > Very nice point about 1,000 pages. I understand the difficulty of > > >> trying > > >> > to get people to understand that a 1,000 page report is totaly > useless. > > >> Who > > >> > is going to read 1,000 pages and what are you going to do with it. > > >> > > I agree that RS is far from perfect but after all the HUGE > problems > > >> > > I > > >> had > > >> > with Crystal when trying to build reports from complicated datasets > and > > >> > SPs(When running an SP Crystal would intermittently just not work). > I > > > was > > >> > relieved by how well RS has worked for our organization. CR still > has > > >> some > > >> > advantages over RS but unless there are some major changes in how CR > > >> > and > > >> > particularly CE work RS should cut significantly into their market > > > share. > > >> > > > > >> > > "Bruce Loehle-Conger" wrote: > > >> > >
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |