none
ASP.NET 2.0 ReportView Toolbar Error for DrillThrough reports RRS feed

  • Question

  • I can change ReportView to display 1 of the 4 main reports with no problems. I can follow the links from these main reports to a DrillThrough report and those reports display fine in the ReportView on the ASP.NET page.

     

    The issue is when you use the Toolbar while a DrillThrough report is displayed. Most of the actions taken by the Toolbar seem to apply to parent report and not the currently viewed DrillThrough report.

     

    The reports Export and fresh fine on the Report Server just not in the web app.

     

    Is this a bug? Or am I missing a step from my web app?

     

     

    The web page contains 5 controls 4 buttons and 1 ReportViewer. Clicking a button changes the report shown in the ReportViewer control. Source for the ASPX page looks like this

     

    <asp:Button ID="Customer_List" runat="server"

    <asp:Button ID="Ledger_Items" runat="server" …

    <asp:Button ID="Customer_List_2" runat="server" …

    <asp:Button ID="Reports" runat="server" …

    <rsweb:ReportViewer ID="ReportViewer1" runat="server"

    Font-Names="Verdana" Font-Size="8pt" Height="400px"

    ProcessingMode="Remote" Width="626px"

    style="position: absolute; left: 144px; top: 45px;" BackColor="Transparent" BorderColor="Blue"

    BorderStyle="None" LinkDisabledColor="Blue"

    PromptAreaCollapsed="True" ShowCredentialPrompts="False"

    ShowParameterPrompts="False" InternalBorderStyle="None"

    InternalBorderWidth="0px" ToolBarItemBorderStyle="None"

    ToolBarItemBorderWidth="0px" EnableTheming="True"/>

     

    The ASPX.VB file for this page contains very little code. The click event for each of the buttons call only one funcion passing the name of the reqired report like so

     

    I_Need_This_Report(sender.text())

     

    And that funtion is defind as follows

     

    Protected Sub I_Need_This_Report(ByVal ReportName As String)

     

    Dim ReportServerURI As System.Uri

     

    ReportServerURI = Nothing

     

    Me.ReportViewer1.Reset()

     

    System.Uri.TryCreate("http://BanDevApp07/reportserver", UriKind.Absolute, ReportServerURI)

     

    Me.ReportViewer1.ServerReport.ReportPath = "/CCv2/" & ReportName

     

    Me.ReportViewer1.ServerReport.ReportServerUrl = ReportServerURI

     

    Me.ReportViewer1.ServerReport.Refresh()

    End Sub

     

     

    Thursday, August 9, 2007 2:52 PM

Answers

  •  

    It looks like my issue is due to DLL hell! (Did not think this was a issue with .Net)

     

    I believed I was working with the latest version of Microsoft.ReportViewer.WebForms. I check the C:\WINDOWS\assembly folder and it said Microsoft.ReportViewer.WebForms version 8.0.0.0, all good and well I believed.

     

    I was wrong, I did a quick search of my machine and I found 3 version of the Microsoft.ReportViewer.WebForms that all report to be Assembly Version 8.0.0.0. It is not until you check the file version or product version of each of the DLLs that you notice a difference. All my issue was because I was using File Version 8.0.50727.762

     

    I’ve now installed File Version 8.0.50727.817 and my initial testing seems to show that my issue has been fixed.

     

     

    Microsoft.ReportViewer.WebForms.dll File Version 8.0.50727.817

    Microsoft.ReportViewer.WebForms.dll File Version 8.0.50727.762

    Microsoft.ReportViewer.WebForms.dll File Version 8.0.50727.42

     

     

    Wednesday, August 15, 2007 3:02 PM

All replies

  • It is likely a misunderstanding rather than a bug, although I am not sure <s>.

     

    If you search this forum for drillthrough  you will find close to 200 references.  Several revolve around things specific to server mode that perplex people -- for example http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=797781&SiteID=1 -- and several also talk about what is going on when a parent continues to display  -- for example http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=455975&SiteID=1.

     

    Do any of the messages that come up in such a search ring a bell with you?  I am not trying to be coy; I personally don't know what the answer is but think that it is likely to be one of a set of broad classifications that appear to keep coming up on this topic.

     

    Hope this helps a bit, anyway,

     

    >L<

     

    Friday, August 10, 2007 12:35 AM
  • Thanks you for that Lisa.

     

    I did the search on this form before posting and I did a few searched on yahoo and Google with no luck.

     

    Moving my code to The Page_PreInit event so that it loads a report the first time the page is view made no difference. When I followed the link on the report to the DrillThrough report and selected Export as excel option I got the parent report back and not the DrillThrough report is was viewing.

     

    Protected Sub Page_PreInit(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.PreInit

            I_Need_This_Report("Reports")

    End Sub

     

     

    Friday, August 10, 2007 8:38 AM
  • Sorry, Chris...

     

    But, looking at your code, I see one thing that perplexes me:

     

    >>

    Me.ReportViewer1.ServerReport.Refresh()

    <<

     

    Why are you calling .Refresh() and not .RefreshReport()?  Perhaps I misunderstand what you are trying to do...

     

    >L<

    Friday, August 10, 2007 3:02 PM
  • Simple really

     

     'RefreshReport' is not a member of 'Microsoft.Reporting.WebForms.ServerReport'

     

    That is why I’m not calling RefreshReport it not an option.

     

    In fact the only reason I have this line of code, Me.ReportViewer1.ServerReport.Refresh(), is because some article I read someplace recommend using it. I can include or remove that line and it does not make any difference to the application.

     

    I’m trying to great web app that displays reports from or report servers. The Web app is going to be deployed beyond our fire wall to allow external users access to limited selection of our reports.

     

    Friday, August 10, 2007 4:05 PM
  • Sorry, that is a "braino" I keep on having <s>.  And I keep having it because there is a "ReportRefresh" event for both the win and web form versions of the viewer ... which probably does nothing to help you.

     

    OK.

     

    You're calling Reset -- is the ReportName you're passing the sub report or the original?

     

    >L<

    Friday, August 10, 2007 5:25 PM
  • It is a very simple app. The end user selects which report he wants to by clicking one of 4 buttons on the page, the click event of these buttons call I_Need_This_Report passing the name of the report to display. I_Need_This_Report changes the report displayed in the ReportView, All reports come from the same report server which is on a different server to this application. This all works fine the issue come when they follow a link to a DrillThrough report from the main top level report. This action does not involve any of my own code it is all the default ReportView code. The Report displays fine but when the user tries to export the report in any format they end up getting the main top level report they just left and not the DrillThrough report they are viewing.

     

    Monday, August 13, 2007 9:16 AM
  •  

    OK, I'm sorry -- I have been somewhat thrown by your first message and your original answer.  Your code is only handling the original report name, the problem is at export not display time.

     

    Here is a post with the same issue http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1179867&SiteID=1 -- as you can see, the poster fixed the problem (in his/her case) by making sure there was a full postback from the reportviewer. 

     

    Somehow I doubt that your case is exactly the same -- you would have said something if there was an Ajax UpdatePanel involved in your simple app <g> -- but consider this:

     

    Even though you think the "action does not involve any of" your own code, the export is reliant on what the server currently knows about that report.  At the time of export, it knows what it was told at the last report load. 

     

    I am not sure why the drillthrough is not doing a postback and changing this value in your case, but I did point you at a thread that gives you a possible reason for this in my first response. http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=797781&SiteID=1 

     

    Scroll down to Brian H's answer in this thread and you may see what I'm thinking about here -- I'll quote it in full and add emphasis:

     

    [Brian Hartman] 

    Generally, the problem of the viewer ignoring the user interaction (for drillthrough, toggle, bookmark, or sort) is the result of the viewer thinking that the report definition has changed.  Any change to either ServerReport or LocalReport that happens after the LoadViewState event might cause the viewer to get into this state.  The most common problem is setting the ReportServerUrl for server mode or report definition for either mode (ReportPath, ReportEmbeddedResource, etc).

    There is a known issue with the viewer that it can be overly sensative to these property changes.  For example, it will sometimes think the definition has changed even if you set the ReportServerUrl property to its current value.  So it is best to avoid setting these properties on a postback unless you intend to change the report definition.

    Note also that it isn't strictly a report definition change that can cause this problem.  If you call SetParameters(), for example, that will cause the report to be reprocessed with the new parameter values.  As a result, the viewer will disregard any click from the user since it applied to the old processed report.

     

    So here is what I'm thinking: How often is that code that is setting the report name getting called? Can you put some debugging code in and find out? Is it possible that some other toolbar action -- such as setting a parameter -- is re-setting the report's "idea" of what report is the correct one.

     

    And here is what I'm thinking might be a possible resolution: Can you handle the drillthrough event and, in that event, do something like what you're doing programmatically now but set the report name to the *correct* report?

     

    HTH,

     

    >L<

     

     

    Monday, August 13, 2007 3:14 PM
  • The out come is that the ReportViewer control has a few bugs when it comes to dealing with DrillThrough reports.

     

    I created a new solution that contains a single apsx page called Default.aspx. On this page I placed one control which is Microsoft.Reporting.WebForms.ReportViewer control. I then set the following properties of that control;

     

    Height              600px

    Width               800px

    ProcessingMode           Remote

    ReportPath                   /ccv2/Report1

    ReportServerUrl           http://bandevapp07/reportserver

     

    I then built and deployed this application.

     

    When I run this Web application the first report displays great you can page through it with no problems, you can export it in any format you like. Click on a link in that report to a DrillThrough report and the report is displayed great but click the next page button on the tool bar and you are taken back to the first report and not the next page of the DrillThrough report.

     

    If you DrillThrough to a report that takes parameters and you click the show/hide parameters button you get the following error message and no report displayed;

    Execution 'oezcej55yyelqh4504mqkt55' cannot be found.

     

    Wednesday, August 15, 2007 10:25 AM
  •  

    It looks like my issue is due to DLL hell! (Did not think this was a issue with .Net)

     

    I believed I was working with the latest version of Microsoft.ReportViewer.WebForms. I check the C:\WINDOWS\assembly folder and it said Microsoft.ReportViewer.WebForms version 8.0.0.0, all good and well I believed.

     

    I was wrong, I did a quick search of my machine and I found 3 version of the Microsoft.ReportViewer.WebForms that all report to be Assembly Version 8.0.0.0. It is not until you check the file version or product version of each of the DLLs that you notice a difference. All my issue was because I was using File Version 8.0.50727.762

     

    I’ve now installed File Version 8.0.50727.817 and my initial testing seems to show that my issue has been fixed.

     

     

    Microsoft.ReportViewer.WebForms.dll File Version 8.0.50727.817

    Microsoft.ReportViewer.WebForms.dll File Version 8.0.50727.762

    Microsoft.ReportViewer.WebForms.dll File Version 8.0.50727.42

     

     

    Wednesday, August 15, 2007 3:02 PM
  •  

    Well good for you perservering and figuring it out!  "It's always something" <g>.

     

    >> (Did not think this  was an issue with .Net)

     

    Yeah, right...  insert a mention of the Brooklyn Bridge and its purchase price here...

     

     it's true that Versionitis is no longer the first question we raise when things go inexplicably wrong.  But that's because we have so many other possibilities, not because it's impossible <g>.

     

    >L<

    Wednesday, August 15, 2007 3:25 PM