I built an SSRS report for a client who runs SQL Server 2012. I developed the report on my local machine with SQL Server 2016. We both use VS 2013 Shell (Integrated). When exporting the report from the reporting portal (browser) to Word, the tables have different widths. The difference is minimal (e.g. 0,03cm over the entire table), but messes up the layout:
Result my machine
Result client's PC
Does anyone know why this happens and how to fix it?
Related
Let me start off by saying how confused I am. I have a significant number of SSRS reports running in SharePoint Integrated mode on a SharePoint 2013 site. We are now switching to SharePoint 2019, which did away with integrated mode. I need to switch all of these reports to use the Report Viewer web part. The old reports ran using the following url appended with the path to the SSRS report: https://apps.abc.com/sites/abc/_layouts/15/ReportServer/RSViewerPage.aspx?rv:RelativeReportUrl=.
I believe the new process is to deploy the reports to a stand alone report server, along with the connections, datasets, etc.
How do I display these reports in SharePoint 2019?
Do I need to create a NEW web page for each set of reports and add a Report Viewer web part pointing to the report server report? (i.e. if I had a set of reports for Project A and Project B; would I have to create a web page for Project A and add a Report Server web part pointing to those reports?)
There's an issue with the way reports are being generated. The reports are generated through Crystal Reports 8.5 with parameters passed through an application developed in Clarion 6.3
The problem is that the first time the report is generated (client balance, for example) it's generated correctly: the amounts all show up with their respective decimal places according to the Crystal .rpt file. If this report is then exported to Excel via the Crystal interface (Export button), and then re-generated it shows up without the respective decimal places.
I haven't been able to replicate this behavior locally (running Windows 8.1, Crystal Reports 8.5, MS Excel 2013, SQL Server 2008-R2) but I have confirmed this behavior on a client's server, where the application and CR8.5 are installed. One difference I've noticed is that they're running MS Excel 2016, but haven't been able to establish a correlation to the presented behavior.
Has anyone else run into this type of problem before, or have heard of someone who has run into this? This has only been confirmed with two clients, both running the application and reporting tool on Windows Server 2012, the rest haven't seen this type of behavior while generating reports (any report that contains decimal places).
EDIT:
The first time the report is generated everything shows up fine, but if the report is then exported, to any other format (Excel, PDF, etc.) the subsequent "generations" have the decimals at .00 in the Crystal preview and the Excel or PDF export, even if previously they showed some value. NOTE: This behavior has been shown to happen only when connected via remote desktop. If the report is generated/exported on a local machine (laptop, workstation) this type of behavior cannot be replicated.
Are you saying that the decimals do not show up in Excel? Or that they show up in the preview in Crystal, show up in the Excel export, but when the preview is re-run after exporting to Excel they do not show up in the preview the second time?
Either way, Crystal Reports 8.5 is 16 years old according to:
https://en.wikipedia.org/wiki/Crystal_Reports
I can tell you that on CR11 this is not an issue I have experienced. Do you have the ability/license to update your software? Try updating your software and see if that solves your problem.
Thanks for the help, Jackson. At this time the client isn't able to upgrade to CR11, for some reason that they didn't quite specify, but I was able to identify the cause of the issue.
For some reason that I haven't been able to fully identify, the region of the machine comes into play. As I mentioned that the issue presents itself while accessing the application via Remote Desktop, if there is a difference between the region configuration on the host and remote machine, the decimals will reset to zero upon subsequent report generations. If the machines coincide in the region configuration, this doesn't happen.
I will still attempt to persuade the client to upgrade the reporting software and see if this issue is still present. Will do some local tests and research on the matter as well to determine if this deserves a ticket with SAP/BusinessObjects.
I have a standard crystal report from Epicor loaded into Visual Studio (specifically the purchase order report). Basically I would like to preview the purchase order for order #12345. How can I do this? It seems like the report data source is already setup although it doesn't seem to point to a database. This is the regular report that comes with Epicor. Any ideas? Thank you
The data for Epicor reports comes from a process that queries the database and generates either XML files (E9) or tables in a separate database (E10). As you are using Crystal Reports I assume you are using E9, as it is still supported in E10 but SSRS is standard.
You will need to run the report in Epicor and allow the Task agent to pick up the job to produce the data. You should then be able to use the XML files to provide data to your report designer.
I've been trying to figure out if it makes sense to use SSRS 2012 with PowerView vs using SSRS 2008.
I've following questions:
What's better in SSRS 2012 without PowerView(ie without using Sharepoint)?
What edition of SharePoint you need to make PowerView work for SSRS 2012?
Does it make sense to learn and use Sharepoint if you can barely utilize the pluses of SharePoint or PowerView instead of SSRS 2008 or SSRS 2012 without PowerView/SharePoint?
I can address the overall question but not the first two bullet points specifically as I have not used Sharepoint enough to give the version differences on it.
Powerview from everything I have ever done is a dll that allows a report like object to be created as an add on to Excel. These objects can then be hosted in Sharepoint in a library. The downside is you need to have the dll's and the add on to Sharepoint to use it. As far as I know you are committing to user's going to SharePoint with this option. They do make it kind of neat though as you generally make what I believe they call a 'PowerPivot' which is just like a client dataset made in the Excel file that you report off of. This option is good for a shop that works with Sharepoint Extensively. I have not heard of too many places using it for client facing front ends or external reporting.
SSRS's newest invocation is SSRS 2012 which from everything I have seen in development is the EXACT SAME THING as SSRS 2008R2 except they put a 2012 in the namespace. There may be minor tweaks on naming and intellisense and under the hood things but the langauge is almost identical. Saying that SSRS 2012 is free with advanced tools for SSRS now and can also port to most front ends you would want: HTML in a form talking to it's service, ASP.NET, a client app like WinForms or WPF. You basically created and host reports and you can access them anywhere.
The real question for most people is: "Which reports look cooler and are easier to use?" I would go with SSRS, but know it is more of learning curve of understanding SQL and a little bit of xml and Visual Studio(very light). However Powerview is more graphical with it's parameters and options to an end user and has highlighted some things it can do with mapping interactivity that SSRS cannot do. The biggest detractor for SSRS IMHO is two things:
It is not event based at all. This shows up whenever you are doing mapping or something you want to zoom or perform actions that then produce other actions or 'events'. It can do a 'click' do something but NOT on the same page necesarrily. Usually you trick it to open a new form for a 'drill through' or use javascript to trick it to do a cheap man's version of hover over reporting by opening a form when you click.
To continue off of one it is this way on default behaviors of values of parameters and passing them down. Everything with SSRS is made to happen once at execution and then anything else happens to leave the form, not stay there.
Saying all that I still like SSRS better. It tends to handle large datasets when PRESENTING them better. Not necessarily all the time at getting them as the PowerView optimizes the set locally but at the expense of huge excel files. Sort of like psuedo cubes. They are fast, but you have a big file size for that expense. But with a lot of data they tend to be clunky as they are Excel based. Yes the query at the end will return faster but you have a huge file. When in reality if you are skilled at SQL SERVER you could be creating a Report Warehouse that is well indexed off of metrics and a cube as well to do this stuff for MANY REPORTS. SSRS is more for developers of TSQL, versus PowerView is more for analysts that know a little SQL but love Excel. They want a 'Select * from (table)' and then form the data, not they know how to do advanced groupings on their set first and then want to present a finished product to someone.
To answer your questions one-by-one:
What's better in SSRS 2012 without PowerView(ie without using Sharepoint)?
In "native mode" SSRS, i.e. a non-Sharepoint installation, there's not an awful lot of new stuff. The renderer now supports Word/Excel 2007-2010 format (i.e. DOCX, XLSX) output and the addition of native mode Data Alerts seem to be the only real difference to 2008 R2.
What's new in SSRS 2012
What edition of SharePoint you need to make PowerView work for SSRS 2012?
Unfortunately, you need SharePoint Enterprise Edition.
Does it make sense to learn and use Sharepoint if you can barely utilize the pluses of SharePoint or PowerView instead of SSRS 2008 or SSRS 2012 without PowerView/SharePoint?
If you are only looking at SharePoint to host/share PowerView and SSRS, it's definitely not worth the investment, in my opinion. There are other alternatives now that are much more accessible to smaller organisations, or those who don't want to invest heavily in SharePoint infrastructure.
PowerView is built in to Excel 2013, which allows users to build their own PowerView reports. Until recently though, there was no way to share these other than passing the Excel files around. However, Microsoft have now released the preview of Power BI, which is an Office 365 based BI platform, essentially providing SMEs with a cheaper and easier alternative to setting up a SharePoint server, and allowing self-service BI. It enables users to upload their Excel files containing PowerViews and share them with their organisation. You can also share other creations, such as Power Query projects, and internal data sources. All without an on-site SharePoint installation.
If you really want to try out PowerView, I'd suggest getting yourself a trial of Excel 2013, or sign up to the Power BI preview and give it a shot. Personally, I wouldn't recommend upgrading to 2012 purely to upgrade your SSRS installation, the new native mode features aren't really worth the cost/effort. If you're looking at upgrading the rest of your infrastructure though, (SQL, SSAS, SSIS) then it's definitely worth doing.
also wanted to add that if your deploying from VS to sharepoint directly; you versions have to be close together i.e. 2008 ssrs on sharepoint 2009 etc. You may not be able to deploy a rdl built in 2008 on sharepoint 2012,13. We had similar issues at one of my previous projects.
Current Production Environment:
MOSS 2007
SQL Server 2008 Reporting Server running in Sharepoint integrated mode
Current Staging Environment:
Sharepoint 2010
SQL Server 2008R2 Reporting Server (Sharepoint integrated mode)
I would like to render (Excel) via a subscription a report from the Staging server to a document library on the current production MOSS 2007 server. The main reason is to utilise some of the new features (spark lines, named Excel sheets) immediately.
The full migration from 2007->2010 is going to take some time and is in several phases which the business cannot wait for.
The current SSRS2008 server I guess is irrelevant. Upgrading the report part on the existing environment is unfortunately not an option. Rendering to an email and that email being the destination document library is a consideration but I am worried I may lose the additional metadata (columns) on the destination XLS. It is currently setup to overwrite and store history.
Can you render the report on the staging server to a file share, and rather than a UNC path, provide the URL for the production document library?