Is there a way to automatically print a SQL Server Reporting services (2005) report?
EDIT:
We needed to print a SSRS report at a network printer programmatically. Specifically, we wanted to fire this off from a stored procedure. We are currently using likeabanshee's method, and it is working. However, we would like something more managed, without the dependency on Adobe Acrobat and xp_cmdshell. We are looking into this method suggested by Paul G.
You should be able to make that happen programmatically using the built-in web service to render the report. Some sample code for SSRS 2000 is here, but it should be pretty close to what you'd need for 2005 as well I think:
If you use the Microsoft Business Intelligence Editor to create your SSRS, you can write code to fire off a print job.
This question was posted by a co-worker for me. My comments and resolution follow:
Background:
I essentially wanted to fire off SSRS reports to networked printers at our corporation through their UNCs. I have a real-time quality monitoring app (for an industrial manufacturing facility) running from SQL Server. As severe defects are detected I wanted to send a report to QA printers for them to analyze the defects. It also supplements our pager/email alerting system to stop problems as they are occuring.
Solution:
I wrote a SQL stored procedure to monitor the quality failures. As they are detected, the stored procedure calls a .Net console app using xp_cmdshell, passing the product ID, UNC path, report name, Adobe Reader file path (on the SQL Server) and a few other parameters. Note the console app resides on the same server as the SQL Server. The console app accepts the paramters and passes them to SSRS with an output format of PDF. The PDF is created and saved locally, then the console apps runs a command line using Adobe Reader's hidden run mode (/t). The file path and UNC path are passed as parameters, and voila - automatic printing of SSRS files.
An optional parameter tells the console app whether to delete the locally saved PDF.
Related
I have an SSRS report published to Report Manager, available to all Domain Users. The report's stored procedure executes a xp_cmdshell which outputs SQL data to an excel file in a shared file location. The issue is the report can't handle being run concurrently - anyone trying to run the report simultaneously with another user gets a blank file, or, worse, a file with missing data. I can't redevelop the solution right now, what I'm hoping to do is restrict the report to one user at a time, either within the SSRS report, via report manager config or the SharePoint link on our intranet (which users access the report by). Everything is on-prem.
I've tried the report config, RM config, our SharePoint developer and Google and none are helping. Thanks.
I have designed a SSIS project and deployed it to SQL server and also created the job to run on daily basis but its giving me this error when executing this as job (doesnt give any error within VS):
There is this CLSid in this error message but there is no application associated to it in
--> Component Services -> Computers -> My Computer -> DCOM Config
But this CLSid is registered inside registry editor
About this particular task on which this error is occurring: This is a script task which is modifying and deleting the un-wanted rows from the excel file in which I am trying to write SQL table data.
Script task code looks like this:
I have been working for hours now trying to fix this problem but no success. Kindly guide me how can I fix this issue. If any other information is required related to this project, please let me know....
Doing Excel automation in a SQL Server agent job is totally unsupported and probably won't work.
To have even a ghost of a chance of making this work you'll need to run a real desktop session on the server and automate Excel in that. Excel expects a real user to be logged in with a full profile. And Excel has failure conditions where it displays a popup window, which you'll need to be able to access via remote desktop.
You can read and write Excel files on a server with the OpenXML SDK, without actually having to run Excel. There's also a wrapper library called ClosedXML which you may find easier to use than using OpenXML directly.
tl;dr;
You need to install Office (Excel) on the server AND ensure that you install it in a manner that mirrors the SQL Agent's expected bit-edness. Default for Agent is going to be 64bit, default for Office is still 32 :(
Error guessing
You have a script task that uses the Office interop libraries to delete some rows (2 through 11?) out of a spreadsheet.
You have Office installed on your machine and therefore you have the libraries installed. Excel still has COM based "stuff" in it, thus the interop and errors shrieking about the CLSid, registry, etc but that's likely just secondary errors because there is no base "application is not installed" exception to be thrown.
If Office is installed, then ensure your agent execution model matches the version of Office. If 32 bit Excel is already installed, don't potentially break everyone else's stuff by uninstalling and reinstalling as 64 bit, just got the Advanced section of the SQL Agent Job Step and check the 32bit box.
Once all that's done, then if you're still getting errors but new ones, then the existing comments mentioning permissions may come into play - it depends on where the Excel document actually exists (on the computer where SQL agent can access vs on the computer where it cannot vs networked drive)
Good luck in not finding people on the sanctions lists.
I've seen this question asked several times but never with a satisfacory answer. I have read through all the posts I can related to this and tried as much as I possibly can.
I have an SSIS package that loops thru a network folder of Excel files, I won't explain what it does inseide the loop container as that is not relevant.
I refernce the folder via a UNC \servername\folder
The package works fine from within Visual Studio.
I deployed the package to the Integration Services Catalogs on the
server
After I deploy, I connect to the server from my local pc via SSMS and then I execute it from SSMS via "Integration Services Catalogs"... Execute - This fails.
However If I remote desktop onto the SQL Server box, then start SSMS, connect to the SQL Server using my own credentials and execute the package using exactly the same method as above it works fine.
When I look in the logs of the failed attempts I see a warning that "The For Each File enumerator is empty". I'm not sure if this is telling the full story as, if I rename the network folder, I get the same message, (I expected to see an error that the folder was not found) - this may or may not be relevant.
I've sketched up a quick overview of what works and what doesn't
NOTE The "script execution" method is just a t-sql script for running these packages. This is the method I will use eventually but at the moment I'm focusing on the simple right-click execute method as this essentially does the same thing.
Since I did this I have tried a few more things...
I've tried accessing the folder as a UNC, a mapped drive and also UNC using IP address instead of server name.
I recreated the issue on our development server so I could change
service accounts etc.
I tried the default accounts on both SSIS and SQL Agent services.
I tried changing these to domain accounts and network service accounts.
I get the package to log the folder name which is and expression - this always looks correct. I do the same with the user name which always shows me as the exection user.
I can change most things as I can test on the development server with the excpetion of testing with a domain admin account so any suggestions would be greatly appreciated.
I recently moved several reports over to a new server. Everything works fine displaying tables and data, but charts are not displaying properly. It looks like the image is not rendering properly. My initial thought was that this was a permissions issue, specifically that the service account used to run SSRS needed permissions to a certain folder on the server that is used to generated chart images, but I can not find anything about this in searching for a solution.
This happens with old reports that display fine on the original server and new reports I try making on the new server.
EDIT: SSRS logs are showing a generic error in GDI+. Looks like this may be the issue, especially since this is running on a virtual server:
http://social.technet.microsoft.com/Forums/en-US/37ed20b2-99bc-4e36-a14b-c9f8cc297be3/ssrs-2012-reports-with-charts-generic-error-in-gdi-?forum=sqlreportingservices
I am curious about a point made in this question:
2) Ensure write permissions on the "folder to which SSRS caches the charts"
Well, firstly, I have not found a single article on the net as to
where this folder is; however, I tested this locally on the server
while logged in as Administrator with full privileges. This doesn't
seem to apply to my situation either.
Does anyone know about this folder? I would imagine that running while logged in as an admin would not mean anything since the service account running SSRS would need the correct privileges.
Someone had a similar problem and the solution was to repair the SQL Server installation. I know it is quite long to run but it might be worth a try.
Equivalent topic in SO
You can try restarting the report server. That worked in my case with Sharepoint and SQL Server 2012. Or repair the SQL server installation on the server as some posts suggest.
SSRS 2012 Charts Not Rendering
I had the same issue when deploying a new report locally.
I restarted my Report Server service and the reports rendered fine.
A windows application that I wrote some years ago required some changes recently (originally written in VS2005, modified using VS2008, and now updated/modified as a VS2012 project).
The application contains a Microsoft report that contains two sub-reports. The sub report data is a dataset, populated during a ReportViewer1.LocalReport.SubreportProcessing event.
A new field was added to the main report, but the sub-reports were not modified. The report works as expected on the development PC, but when installed on the client laptop, the sub-reports fail with the message:-
Data retrieval failed for the sub-report, <report name>, located at <report...rdlc>. Please check the log files for more information
No log files are produced on the client laptop
I tried to manually install the CTP 2012 Microsoft Report viewer, but the install fails, reporting that a newer version is already present (possibly from SQL Server Express 2012, also installed at the same time).
The database used for testing is restored from a live backup, so the data is the same. The sub-report event that adds the ReportDataSource to the sub-reports contains a try-catch block which doesn't raise any exceptions
During development, when I opened the reports in VS2012, a dialog opened that asked if they should be updated to the 2012 format, which I allowed, althoug this probably has no bearing on the fault.
Has anyone come across this issue? Is there a way to force the physical output of a log file on the client laptop?
UPDATE
Putting some MessagesBoxes in the code I have found the reason that sub-reports do not process, but I now need to find out why.
The 'LocalReport_SubreportProcessing' event fires twice for my report - once for each sub-report.
In order to identify which sub-report needs the additional data source, I check the value of 'SubreportProcessingEventArgs.ReportPath'. In my dev system it has the name of the report (minus the .rdlc extension) but, on the client laptop the value is empty.
I can't see how the reports get built into the output. Tthe main report shows OK on the laptop (just missing the sub-reports), although from where it is displayed I don't know at present - more investigation required!
I have just stumbled upon the same problem. Don't you hate Microsoft sometimes for doing it to us?
Anyway I think that the best solution is to check SubreportProcessingEventArgs.DataSourceNames[0] instead of checking SubreportProcessingEventArgs.ReportPath. This will (I checked) have the name of the data source for the subreport.
If you name your datasources uniquely you can identify which subreport is calling an event and set the data source properly. I usualy name my data sources as {SubreportName}DataSet, so all my data source names have the subreport name in them. Good luck.