|
Another user posted this question on the web but I couldn't find any replies to it and am having the same problem:
I am dynamically creating a ReportViewer control and loading a local report in winforms. After adding appropriate datasources, the ReportViewer intermittently does
not show all the rows/records that should be displayed (e.g. only showing 2 when there should be 4). Refresh will usually correct the problem but that is not a preferred fix.
I am setting the datasource in code and the report has subreports with parameters and filtering. I'm also calling RefreshReport as the last call in my Report Preview Load method
Any info would be much appreciated.
Nicholas
|
| Nicdlt Friday, September 11, 2009 6:18 PM |
I am having this same problem on several reports. No subreports for me... just textboxes and (sometimes) lists. I dynamically change the datasource at runtime and when the report runs, sometimes it shows all the records and sometimes it does not. Whenever it doesn't show all records, it always stops at the first page. For example, if there's supposed to be five pages of data, it will never show just the first two (or three), it will always show either all five pages, or only the first page.
I've checked the actual dataset being fed to the datasource at runtime, and even when this "error" happens, the dataset still says it has all the records in them... so it's not a matter of the dataset not getting populated properly... the dataset always has the full amount of records... it's the reportviewer that just randomly decides not to show them all.
WATYF |
| WATYF Monday, September 14, 2009 4:50 PM |
This is the code I'm using:
'Reset the report
rvwRpts.Reset()
'Set the processing mode to reference a local (embedded) report
rvwRpts.ProcessingMode = ProcessingMode.Local
'Start With to make changes to LocalReport
With rvwRpts.LocalReport
.ReportEmbeddedResource = "FSFcst.rptByPart.rdlc"
sTbl = "tblFcst"
'Create a dataadapter that will be used to fill the dataset
da = New VistaDBDataAdapter(sSQL, con)
'Fill the new dataset
da.Fill(ds, sTbl)
'Set the datasource for the report by passing the dataset (loaded based on the generated SQL statement) and appropriate table name
rds.Name = "dsMain_" & sTbl
rds.Value = ds.Tables(sTbl)
.DataSources.Clear()
.DataSources.Add(rds)
End With
rvwRpts.RefreshReport()
rvwRpts.SetDisplayMode(DisplayMode.PrintLayout)
This code runs in the Form_Load of the report viewer container. At all times, the dataset "ds" reports the full amount of records (even when the ReportViewer only shows part of the records). If I add the "Refresh" button to the report, then repeatedly clicking it will toggle the report back and forth between having only part of the records and having all the records, so I know it's not anything in my code (since my code doesn't re-run during a Refresh).
WATYF
|
| WATYF Monday, September 14, 2009 4:57 PM |
This issue appears to be a bug in the Print Layout feature. If I remove the line from my code that forces it to the PrintLayout view, it shows all the records (always). But if I click on the Print Layout button once the report has already rendered (i.e. my code is already done running), then sometimes, it doesn't generate all of the pages in the Print Layout form. So there's some kind of pagination issue happening when Print Layout is activated. This is obviously disappointing, as I much prefer the print layout for giving an "accurate" idea of what will show up on the pages when I print them, but if it means not knowing whether or not all of the records are being displayed, then I'll just have to go with the default layout.
WATYF |
| WATYF Tuesday, September 15, 2009 7:43 PM |
I AGREEthere appears to be a bug in the Print Layout feature. This is very frustrating, and makes me wonder what quality control Microsoft has. I initialize my reports in Print Layout display mode because the default is even worse (it puts 70+ pages in 1 or 2). About one out of five times, Microsoft will produce a report "missing" the first few pages or the last few, and the navigation is messed up. Since my program follows the same path each time, I finally decided I wasn't causing this. As of this moment, I cannot get my program to fail. I did EDIT my RDLC files in WordPad. If you ever change or rename your dataset or source for a report, Microsoft stores EACH version of this information in the RDLC files, regardless of whether these sources STILL EXIST! I had three different datasets in one RDLC file describing the same data, and Microsoft got confused and couldn't render the report. After fixing the RDLC files, reports seem to work fine now, and I'm not observing the Print Layout problem, but who knows if the issues are related. |
| MattBar Wednesday, September 16, 2009 7:28 PM |
Famous last words. Fixing the RDLC files solves one problem, but not the Print Layout problem. For me, it's backkkkkkkkkk. |
| MattBar Wednesday, September 16, 2009 8:00 PM |
Do you have this problem when debugging the application in the IDE or when it has been deployed/installed on another machine, or both?
After many attempts to "hack" a way around this issue, I found that it didn't even occur once I took the app out of the dev environment and installed it on another machine. This might just be a bug with the IDE (at least, in my case, it appears that it was).
WATYF |
| WATYF Wednesday, September 16, 2009 8:04 PM |
I agree about the dataset/datasource issue, btw. The rdlc stores all that info permanently. Even if you accidentally drag a field from the wrong table onto a report and then immediately delete that field, the report will still store a whole host of connection information related to that table. Such an inefficient method. Especially considering that I don't even use a static dataset. It's always instatiated at run-time.
WATYF |
| WATYF Wednesday, September 16, 2009 8:08 PM |
The Print Layout problem occurs for me whether I'm in the IDE or not, but it seems not as frequent outside the IDE- 1 out of 20 times. I don't know if that's significant. I'm just running my app onmy local machine right now.I'm not using a static dataset either. I use a generic dataset and datatable with lots of fields and parameters to satisfy RDLC and then fill the ones I want at runtime. Best to separate the data source from the presentation, of course. |
| MattBar Thursday, September 17, 2009 1:40 PM |
You're right... it's still happening outside of the IDE, just not as often. Well that sucks. This is a pretty major issue/bug.
What use is a report control that randomly doesn't "report" all of your pages?
WATYF |
| WATYF Thursday, September 17, 2009 7:40 PM |
So how do we report this? What are the chances of this actually getting fixed?
WATYF
|
| WATYF Thursday, September 17, 2009 8:03 PM |
I agree with your assessments, but I think Microsoft does what it wants - rarely "fixing" things, but piling on with new code/features. Some new property, set in some obscure mode, documented to do something completely different will magically fix this. Sorry to be negative, but "sucks" is my frequent SOP.I was hoping one of theMicrosoft moderators would read this and say here's a work-around.
|
| MattBar Thursday, September 17, 2009 9:36 PM |
So.... we can't be the only two people who have noticed that the ReportViewer is functionally worthless since it doesn't always render all the pages. If the control is broken in all instances, I'm guessing no one would be using it, or MS would have published a fix. So the question is... is there something about the specific reports that we created that is "triggering" this bug? Is it some way we're grouping or something that made this happen just for us? Or is this bug fixed in newer versions of the .NET framework? I'm still working with 2.0. Could it be that this was fixed in 3.0/3.5?
There has to be something to be done. I've wasted a very long time designing a whole bunch of reports that are now useless to me, and redesigning them all over again in another report tool isn't too inviting.
WATYF |
| WATYF Monday, September 21, 2009 2:10 PM |
Well, scratch that last idea. I tried converting the project to VS2008 and still had the same issue.
WATYF
|
| WATYF Monday, September 21, 2009 7:08 PM |
I haven't checked back for a few days. I might have saved you the trouble. I've been using VS 2008, 3.5 .NET throughout this. I use C#. Your code at the top is VB, so none of this affects the problem. I have played with the VS 2010 Beta a bit. Crystal Reports (the more mature reporting tool) is missing entirely, and the UI for MS Reporting Services appears to me to be identical to VS 2008. It will convert RDLC files from a VS 2008 project just fine as I expected. I assume any big enhancements with occur in the production version. |
| MattBar Tuesday, September 22, 2009 1:27 PM |
So now it looks like I need to go find another reporting tool and recreate these reports yet again. I still can't believe MS included such a buggy, non-functional control in their framework. It's embarrassing.
WATYF |
| WATYF Tuesday, September 22, 2009 1:48 PM |
I've noticed other problems with MS Reports. Things that SHOULD be simple, that I assume will work. After I export reports, I need to copy and paste from them and insert the text/images into other documents, e.g. MS Word. You can see it does a lousy job of that. Microsoft screws up. Crystal Reports does not have a problem withcopy and paste. It's more mature. I've read somewhere that MS will introduce this new idea"sections" not in VS 2010, but sometime after that. CR has used sections from the beginning. Surely, MS will take over the reporting world and destroy CR in the process - that's their business model. But you're right: it's not just us struggling in the meantime. I can't believe either that these problems can go unnoticed. Where are all the MS representatives/experts who monitor this forum? |
| MattBar Tuesday, September 22, 2009 1:54 PM |
The thing that's worse for me is, I first created all these reports using Crystal Reports... and then when I got to the deployment process, I found that CR had some show-stopping issues. Not to mention that creating reports in CR is tedious and time consuming. So I bit the bullet and re-created all my reports using the .NET report control, which was much easier... but then, of course, found yet another show-stopping issue.
WATYF |
| WATYF Tuesday, September 22, 2009 2:02 PM |
I think we had the "answer" all along. Turn off the print layout display mode. End of problem. Yes, we both prefer it - it's looks better, the pages in regular view mode are awkward at best. But it doesn't work. Something to do with the initialization of the report while in print layout mode. I think we have enough other hurdles to deal with in order to crank out decent reports. I'll try to stay tuned to this forum. Maybe the question will get posed again. I'vebeen tempted to start a new question myself, but I doubt it will get adequately answered right now. |
| MattBar Tuesday, September 22, 2009 2:32 PM |
Yeah, I thought that might work... and I wish it were that easy. Unfortunately, I think this problem has more to do with the underlying print rendering/pagination function of the ReportViewer control than it does with the actual "PrintLayout" view. If you open a report in "Default" view and hit print (without activating PrintLayout), it doesn't always print all the pages... sometimes it just prints the first one. So the bug isn't so much in "PrintLayout" as it is in ReportViewer printing.
WATYF
|
| WATYF Tuesday, September 22, 2009 2:38 PM |
WATYF, why don't you start a new question? You can state it better than I can - basically what's in your latest statement. And ask the question about 10 times so it gets attention - once can get overlooked, this one has. I wish I could provide some insight to this problem, but I'm just stuckat the moment and I'm sorry I'm not helping. |
| MattBar Tuesday, September 22, 2009 3:27 PM |
Any luck with this? I'm having the same problem and have run out of ideas. |
| lwileczka Friday, October 09, 2009 1:33 PM |
Nope. This is a bug inherent in Microsoft's ReportViewer control. They'll need to fix it, if they want it to be even remotely useful.
WATYF |
| WATYF Friday, October 09, 2009 1:50 PM |
I've switched to trying out 3rd party reporting tools. Unfortunately, the design-mode and implementation of those tools is nowhere near as simple and well-integrated as the ReportViewer control. It really is a shame that it doesn't work.
WATYF |
| WATYF Friday, October 09, 2009 1:51 PM |
I think I've come up with a work around for this bug. This problem was happening to me about 25% of the time, but when I would click on the refresh button, it would always fix the problem. If I kept hitting the refresh button the problem never came up again unlike in your case where it would toggle between being broken and working. That being said, I'm not sure that this will fix the problem in your case. Basically, I added some code to the RenderingComplete handler of the ReportViewer so that if it was the first time rendering the report, it would refresh the report again. I've been testing this repeatedly for about an hour and the problem has not come up again! Here's the code that I added:
Private isFirstRefresh As Boolean = True
Private Sub ReportViewer1_RenderingComplete(ByVal sender As Object, ByVal e As Microsoft.Reporting.WinForms.RenderingCompleteEventArgs) Handles ReportViewer1.RenderingComplete
Try
If e.Exception Is Nothing Then
If isFirstRefresh Then
isFirstRefresh = False
' Work around for issue #1 (http://lovewindows.info/6/aba34cb9a332864a.html)
' This section was a fix for a separate but similar issue for the PrintLayout display mode
Dim t As Type = GetType(ReportViewer)
Dim fi As System.Reflection.FieldInfo = t.GetField("m_viewMode", System.Reflection.BindingFlags.NonPublic Or System.Reflection.BindingFlags.Instance)
Dim dm As DisplayMode = CType(fi.GetValue(ReportViewer1), DisplayMode)
If dm = DisplayMode.PrintLayout Then
Dim pageNo As Integer = ReportViewer1.CurrentPage
ReportViewer1.SetDisplayMode(DisplayMode.PrintLayout)
ReportViewer1.CurrentPage = pageNo
End If
' End work around for issue #1
ReportViewer1.RefreshReport()
ReportViewer1.Visible = True
End If
End If
Catch
End Try
End Sub - Proposed As Answer bylwileczka Friday, October 09, 2009 4:31 PM
-
|
| lwileczka Friday, October 09, 2009 4:04 PM |
I will give that a try. I'm not too hopeful, though, because several of my hacking attempts involved refreshing the report. Some even involved delayed timers that would wait for the report to finish loading and then force one (or more) refreshes (just so the refresh didn't happen in the same thread as the original load).
WATYF |
| WATYF Friday, October 09, 2009 4:36 PM |
No such luck, man. It only took two tries to get a report that only rendered the first page. Thanks for posting the idea, though.
WATYF |
| WATYF Friday, October 09, 2009 5:15 PM |
Dude... I don't want to jump the gun, but I think you may have pointed me in the right direction. You code didn't work, but someone else posted another "solution" in that thread you linked to, and I think it's working. I'm gonna try on a few other machines, but I haven't been able to get the error to happen on this one. The code was:
private void reportViewer1_RenderingComplete( object sender, RenderingCompleteEventArgs e)
{
reportViewer1.SetDisplayMode( DisplayMode .PrintLayout);
reportViewer1.ZoomMode = ZoomMode .PageWidth;
}
Apparently, setting the ZoomMode to PageWidth is what fixes the whole thing (both the incorrect total page count and the "only rendering the first page" issues). And it has to be done in the RenderingComplete event (i.e. doesn't work if you do it at form load or whatever).
WATYF |
| WATYF Friday, October 09, 2009 6:51 PM |
index > Visual Studio Report Controls > ReportViewer Control Local Report not showing all records/rows