Okay, time for a stupid question.
When viewing the browser source code of a ssrs report there is a script tag that references Reserved.ReportViewerControl.axd. There is a query string parameter of the version. What installed component on the web server determines that version #? The reason I ask is I am trying to debug a situation where an installation of our web app (asp.net 3.5) cannot print a report ("Unable to load client control..."), but on our internal machines, we can. I do not have direct access to the web server/db server. I can confirm that I can print directly from the Report Manager. I am trying to piece together any differences b/t the two environments, and one thing I am noticing is the different version query string value.
Our internal says -
Reserved.ReportViewerWebControl.axd?OpType=Resource&Version=9.0.30729.4402&Name=Microsoft.Reporting.WebForms.Scripts.ReportViewer.js"
Client says -
Reserved.ReportViewerWebControl.axd?OpType=Resource&Version=9.0.30729.1&Name=Microsoft.Reporting.WebForms.Scripts.ReportViewer.js"
I am fairly sure it is the Microsoft Report Viewer Redistributable, but I want to make absolute sure. Anyone out there know?
This depends on whether you're using the .NET ReportViewer control on a custom ASP.NET page or whether you're simply using Reporting Services' out-of-the-box viewer. If it is the former, then most likely it's from the Report Viewer Redistributable. If it is the latter, it's from the SQL Server installation.
See if this SO post helps you with your print issue:
ReportViewer Client Print Control "Unable to load client print control"?
Related
I have a chicken-egg-problem when upgrading from SSRS2014 to SSRS2016.
I cannot move to the new reportviewer because I still have users on
IE. The new report viewer cannot print nicely on Internet Explorer:
if you click print, you can download a pdf and THEN print it.
Due to the large amount of reports we print, this is no feasable option.
I cannot migrate away from Internet Explorer because of the old report
viewer: The ActiveX print control only works in Internet Explorer.
So I want to migrate to the new report server, yet show the reports through the old viewer for IE-users. So my test web server has both the new and the old reporting component. If the client uses Internet Explorer, I serve the old one. Otherwise, they get the new one.
In my test environment, reports from SSRS 2016 are rendered correctly by the old reporting control. (Microsoft.ReportViewer.WebForms version 11.0.0.0) However, when I try to print, the client displays a dialog box "Unable to load client print control"
On my server, an exception is thrown:
The report server could not find the internal resource '2015.130.1601.05rsclientprint.cab'. (rsInternalResourceNotFoundError)
[ReportServerException: The report server could not find the internal resource '2015.130.1601.05rsclientprint.cab'. (rsInternalResourceNotFoundError)]
Microsoft.Reporting.WebForms.SoapReportExecutionService.WritePrintCab(ClientArchitecture arch, Stream stream) +797
Microsoft.Reporting.WebForms.ServerReport.WritePrintCab(ClientArchitecture arch, Stream stream) +75
Microsoft.Reporting.WebForms.HttpHandler.ProcessRequest(HttpContext context) +304
I know there is a new reporting control, making the ActiveX print control obsolete. However, I'd like to prevent a big bang implementation. Printing with the old control only works on Internet Explorer, so all users use IE. Printing with the new control DOESN'T work with IE.
(If 100+ users print 50+ reports a day, having to download a pdf and print that is a BIG difference.)
https://learn.microsoft.com/en-us/sql/reporting-services/report-server/enable-and-disable-client-side-printing-for-reporting-services says:
"Previous versions of Reporting Services used an ActiveX control that required downloading to the client computer from the report server. If you upgrade your report server to SQL Server 2016, the print control is not removed from the report server or client computers."
This suggests that ActiveX printing is also possible with the new server, probably through the old Report viewer control. If that works, I can put the new control next to the old one, and gradually migrate my users to a modern browser.
Did anybody get this to work without restarting and installing SQL Server 2014, and upgrading?
To migrate SSRS Reports from 2014 to 2016. Simply follow below steps:
Backup and restore original databases
Backup encryption key
Install Ssrs 2016 on new server with managed service account.
Restore databases and remove server key entry from key table in the report database.
Configure Ssrs 2016 to look at new restored databases on same new instance.
Restore keys from backup.
Or visit this link :https://www.mssqltips.com/sqlservertip/2692/migrating-sql-reporting-services-to-a-new-server-by-moving-the-reporting-services-databases/
I have a line of code that I can run locally as part of a service that works perfectly fine.
sReportPath = objCrystalUtils.ExportReportToPDF("Report Name", iReportInfoID)
This code is run as a part of a service, and when I unit test it by feeding it data, it ultimately builds the report and prints it.
When I run the exact same piece of code inside an .ashx from an ajax call. The reports are generated (I can see the pdf files being created on disk) but the printing is not happening.
oRpt.PrintToPrinter(objReport.DefaultAutoPrint, True, 0, 0)
In both scenarios the same code is used to print the report. (objReport.DefaultAutoPrint = 0 in both cases)
My only thought is that the location of the code that is calling this method is in a different spot relative to the location of the bills themselves.
The printer that I'm trying to print to is a network printer intalled on my machine, and I'm running Windows 7 IIS 6.1
Any thoughts?
Edit:
Here is a thought... if I'm running one as a unit test locally and im running the other through a web app that is running via IIS, is there a difference in user id and user access to the default printer?
Edit:
So I added my local ASP, IUSR and SYSTEM users to the printer security and allowed them to print... no dice. So I checked the EVERYONE user and it is set to access and NO users are denied... so I think that kinda kills that line of reasoning.
Edit:
I changed the name of this post since I no longer think that the issue is ajax related since If I try to do the same process in code bebehind from a post back instead of running it from an ajax call i still get the same problem.
Patrick, for me it is a known issue of crystal reports, printing a certain report from a running application via IIS.
I got the same issue before, and upon our search for that issue, we got the following;
Report to be generated, exported, and then to be downloaded to client machine,
so user can print it locally (say, report will be exported as PDf file,
user can use print option of PDF reader).
It's not Crystal Reports or other third party app's problem. It's usually the IIS_IUSER's permission problem because it has no access to any network printers. A possible solution is in Process.Start doesn't work in IIS
I have a seperate SQL(2008 R2) box and web server(IIS 7).
The IIS server is visible to the public the SQL box is not (as it should be)
On the web server there is a asp.net page with a report viewer control.
The reportview control picks up a report from Reporting Services on the SQL box and displays the report in the web page. But when I try to print I get the "Unable to load client print control" error message.
I've looked over all the many posts, and there are many, and have tried some of the "fixes" like updating with all the service packs, etc..
I can not have the end users adjust their security settings (this would number about 100,000 users)
There must be a definitive answer to this problem. I can not believe that MS would leave this so unusable.
Any suggestions or ideas?
TIA
John
New information **
I am able to log onto the web server and using IE on the Web server bring up the reportmanager on the SQL server and print successfully. I actually was able to see the print client download and I got the expected security prompts.
I tried bringing up the website in question the same way, i.e. using IE on the web server itself, the reports display but when I go to print I get the "Unable to load" error. This occurs on a machine that seconds before was able to download the activex and successfully print.
First thing I would say is you normally have to be a local admin on the machine to actually install the client print control, if they are'nt then i think they will get this error.
I did see an issue a while ago where the ActiveX killbits update broke the client print control, i have a feeling this was on 2005 but it might be worth checking?
We are using the Telerik RadEditor control, specifically for it's ability to render a PDF via the ExportToPDF() method on the control. We find that this works great in our development and test environments but fails as soon as we get to our client's environment. What I mean by fails is that typically when you execute the ExportToPDF() method, a dialog box pops up with the name of the PDF file, it's size, and whether you want to open it or save it. In our client's environment that dialog window appears, but the file size does not appear. If you save the file, it's a blank document. The machines / environments are equal in their setup (IIS 6 on Windows server 2003). The only exception is that our client's machine is in a secure environment with no access to the internet.
We are loading form letters into the control and then creating the PDF once the user clicks a button, so I don't think this is being caused by bad data / invalid characters causing the PDF not to generate.
My questions are: does anyone have experience running the ExportToPDF() command in an environment with no access to the internet? Could this be a permissions issue? I can't seem to find documentation on whether the ExportToPDF() functionality uses a temporary directory to write the PDF out to while it's rendering. It may be as simple as that, but I'm having a hard time researching this issue.
I've also put a try / catch block around the ExportToPDF() method and I know it's not throwing any errors.
We are running an older version of RadEditor - 2009.3.1208 - it runs in a large application with other Telerik tools so upgrading the entire RadControl suite is not trivial (b/c of testing, etc) and is taking some time.
Any suggestions on what to try next / has anyone encountered anything like this with this control?
Thanks for your help in advance!
Richard
I doubt that the export functionality needs an active internet connection. Most likely something in your secured environment is blocking silently the export and it does not simply happen. My recommendation is to check the permissions/processes you have on the user machine and test the same outside of the local environment to compare the results.
Trying to print an ASP.NET Charting control behind the scenes in my web app. I think it is a permissions issue with the printer as everything is ok up until the point where my code calls:
chart.Printing.Print(false);
bool finished = false;
while (!finished)
{
finished = File.Exists(settings.GetValue("statusfile")); // file which indicates document was printed
System.Threading.Thread.Sleep(1000);
}
At this point the page just freezes (or continues to load endlessly - infinite loop!) Understandably this is happening because I am 100% relying on the document being printed. I do intend to add a timeout, however, at the moment I am just trying to figure out why exactly the document is never being set to the printer!
I have given the account (which the AppPool is running under) permissions to all the relevant folders and even the pdf printer itself...Still nothing.
Am I missing something? Is there any issues with printing on the server side via ASP.NET? I have encountered some issues doing this via WindowsServices in the past not sure if it is a similar problem with ASP.NET websites.
Update
As suggested I updated the AppPool to give myself (admin) permissions and it is the same issue. So by the looks of things the job is never being sent to the printer. I can't seem to figure out why though...
Probably should have mentioned this in my original post....but I am invoking the printer through a referenced DLL, this code is not being called directly from my application (incase it matters). Also this runs fine on my Development machine which is running Windows 7 IIS7.0 where as the server is running Windows 2003 server with IIS6.0.
Update 2
I removed the while loop and just left in the chart.Printing.Print(false) line and turns out the document IS being sent to the printer. So the issue must be with the settings file not getting written which is why the loop never breaks out!
To isolate if this is indeed a permissions issue, you could try running the application using the Visual Studio web development server, which will run under your credentials. Or if that's not an option, temporarily change the IIS app pool so it uses your credentials. If things still do not work, you may have another issue. I'm not sure which charting library you're using (is it the newish Microsoft one?), but maybe Print wants to show a printer dialog.