When working with SSRS, seeing the report in browser is different from the export of a PDF. For now, I would design, run and then export to PDF. This is in the SSDT Visual Studio environment.
I have done some research that RS.exe can export the RDL to PDF. I am having trouble with the commandline. Can someone help me with the commandline to make this work properly?
how is the exported PDF different than the SSRS ?
Hi Yosiasz, when I see the SSRS report in the browser, it looks different than the exported version because of the page breaks. IE and Chrome display the reports differently so it is best to just view the PDF.
Then why have ssrs?
Because SSRS generates the report and export to PDF. SSRS is to review internally and when approved, we send the PDFs version out to our clients and billings.
The part that I am seeking is to use RS.exe to run the RDL file into PDF, not from the report server but from the development environment of SSDT.
By the way, here is one method of doing it.
Deploy the report first and then use this to export by URL:
http://LocalHost/ReportServer/Pages/ReportViewer.aspx?%2FReport+Project1%2FReport1&rs:Command=Render&rs:Format=PDF
I guess this would work. Still would like how to use the RS.exe method.
You could also try out of the box ssrs subscription. Schedule it to come by email to you or go to ssrs and click the download button and choose pdf?
What is the problem with rendering the report in SSDT (Preview) and then exporting the report to PDF to validate it? How would running a command line program make that process easier?
As far as reports are rendered differently - most like that is because you have not defined the page appropriately. In the report properties you need to define the report as portrait and set appropriate margins - and then in the report itself you must maintain the pallete within that size.
Normal portrait size is 8.5 x 11 with normal margins of 1in - which leaves a pallete size of 6.5 of working space. If the pallete in SSDT is 6.50001 you will get a secondary blank page for each page when rendered into PDF or even printed.
If you maintain the page size - then rendering to PDF will look exactly the same as when rendered to a browser. And to insure appropriate page breaks - modify the interactive size of the report so you get the same page breaks at the same locations.
Hi yosiasz, I need it in real time so subscription will not work for me.
[quote="jeffw8713, post:8, topic:14654, full:true"]
What is the problem with rendering the report in SSDT (Preview) and then exporting the report to PDF to validate it? How would running a command line program make that process easier?
[/quote]Hi Jeff, I was experimenting and was hoping that it would be faster to export as I preview, test and then export.
[quote="jeffw8713, post:8, topic:14654, full:true"]
As far as reports are rendered differently - most like that is because you have not defined the page appropriately. In the report properties you need to define the report as portrait and set appropriate margins - and then in the report itself you must maintain the pallete within that size.
Normal portrait size is 8.5 x 11 with normal margins of 1in - which leaves a pallete size of 6.5 of working space. If the pallete in SSDT is 6.50001 you will get a secondary blank page for each page when rendered into PDF or even printed.
If you maintain the page size - then rendering to PDF will look exactly the same as when rendered to a browser. And to insure appropriate page breaks - modify the interactive size of the report so you get the same page breaks at the same locations.
[/quote]Yes, I did pretty much all of that already. I am not having trouble with margins or page size, more of page breaks. The report is 16 pages long with dynamic data. All is working well. However, it page breaks on different parts of the group. And yes, I also have used "Keep It Together". What you see is one thing but when you export, the page breaks off shift everything. I am close to getting this right.
I have see somethings that are display on the browser and when export, the lines are shifted. When I find the example, i will post it on here.
Thanks
I expect that your margins are different between interactive size and page size which would cause rendering to an external format (PDF, Word, etc...) with different breaks. Either way - you can only fit so much on a single sheet of paper and if you exceed that amount it has to push to the next page.
There are ways to adjust that - you can set the line spacing, font sizes, margins and other parameters to fit more data per page...
I don't see how that would be any faster in SSDT - in fact, it probably will take longer since RS.EXE would have to extract the data again whereas SSDT has cached the data.
Thank you for the confirmation Jeff. I thought it would be more convenient to use RS.exe but yes, it may take longer.
"I have see somethings that are display on the browser and when export, the lines are shifted. When I find the example, i will post it on here."
Coincidentally here is an example of what you see on the browser is not what you see in PDF.
So today, I did something stupid. To make a short example, what I did was having two list controls. The first one's bottom overlapped the second one's top. All this time, I thought it was one list control but there are two list controls. So when I view it in the browser, it rendered properly, well, at least I thought so. But when I export to pdf, it pushed the second list control items on top of the first list control. It took me an hour to realize this and first thing I thought was this post. So to correct it, I moved everything from the second list control to the first list control and everything exported properly to PDF.
how is the exported PDF different than the SSRS?