Other than "Thank you!" and "You guys are great!", the most common phrase we hear doing support is "but it works in Crystal Reports!"... here is the loooooonnnnnnnnggggg answer to that phrase/question...
---
First off, we understand that it works in Crystal Reports. You would not be attempting to run it in our software if you had not first been successful designing and running it in Crystal Reports. The engine we use to run reports is the Crystal Reports runtime engine for .Net. This is the absolute latest engine available.
This runtime engine is developed by SAP (creators of Crystal Reports). We (Report Runner/Known Keep LLC) did not (re)create a Crystal Reports engine. What we created was really cool software wrapped around this Crystal Reports runtime engine. We currently recommend service pack 3 and service pack 20 (SP20) of the runtime in our full installer, because it is the least buggy (SP3, more on this shortly), but you can use any service pack/version of the runtime engine with our software.
There are common reasons why a report errors trying to run in our software, and we've documented those for you to look at first. If you've tried all but the very last option and the report still does not work, then it's the last reason in that list... the report is "corrupted"... at least in terms of being able to work with the latest runtime engine. While we're talking about the "latest runtime engine", let's talk about that and why other Crystal tools on the market might work and ours does not. Not all Crystal tools on the market use the same runtime engine. Many use very old runtime engines. We use the latest runtime engines. We build for the future, and we make sure our software works on current operating systems.
SAP (and prior owners of Crystal Reports like Seagate, Crystal Decisions, and Business Objects) have been releasing runtime engines for Crystal Report since the mid-90's. We (Report Runner/Known Keep LLC) has been shipping software utilizing this runtime engine since version 8.5 of Crystal Reports. We (Report Runner/Known Keep LLC) have been writing software utilizing the runtime engine since version 5 of Crystal Reports. Since 2000, we have released a viewer and scheduling product for versions 8.5, 10, XI/11, 2008, 2011, 2013, 2016, and now 2020 of Crystal Reports. We KNOW runtime engines. We KNOW Crystal Reports. Unfortunately, each version of the runtime engine has it's own quirks and bugs, and we do as much as possible to work around these issues. Ultimately though, we are at the mercy of SAP to fix any issues where the runtime engine will not run a report.
Now, you might ask, why don't you make all runtime engines available with your software? The basic answer is because the older runtime engines (and even Crystal Reports itself) were never written, designed, or intended to be used on these later Windows operating systems. In 2011, we released completely new, re-written version of our software that was designed specifically for Windows 7 and later, and Windows Server 2008 and later (we believe at least a 20 year timeframe). It was based on the latest .Net technology (that's what Microsoft will be supporting for the immediate future). In doing so, we HAD to use the latest edition of the Crystal runtime engine (which had also been rewritten in .Net). The good news was it was written for the future and reports designed in 2008 and later were MEANT to run on this runtime engine. And most older reports would work on this latest engine, but not all. That's where we get to the "corrupted" term we use when a report either can't be opened at all or won't run in the new software. Even though it runs in your version of Crystal Reports, it will not run on the later runtime engines. It might even run in your 2008 or 2011 version of Crystal Reports... it doesn't matter. Crystal Reports XXXX (whatever version) is NOT the same as the Crystal runtime engine. There are a lot of things that Crystal Reports, the designing application, does to auto-correct reports that are simply not made available in the runtime engine. We WISH there was a "CanAutoCorrect" setting we could turn on.
Even with the 2011 runtime engine, different service packs have different issues. For example, every service pack past SP3 has a random issue with XLS exports where the export crashes .Net. For those users doing XLS exports, you may be required to stay on SP3 of the runtime engine. There's nothing we can do to fix this. Starting with SP4 of the runtime engine, NULL parameters were allowed to be set. But if you want to do XLS exports and set NULL parameters, you've got a choice to make because some XLS exports will crash, and there's nothing we can do to fix it unless you move back to SP3. Do you see how dependent we are on the Crystal runtime engine working correctly? Oh, and now that we are in later service packs like SP20, these later versions seem to work better with later versions of SQL Server. Sometimes fixing a specific issue is out of our hands. Our recommendation is either stay on SP3 or if you must go past it, go to SP20 (or later).
Note: To be clear, while we refer to the Crystal runtime engine as the "2011 engine", this is the LATEST runtime engine available for Crystal Reports. SAP maintains this "2011" engine as the current/modern runtime engine. It has been updated over the years more than 25 times.
---
Now, let's have a quick talk about Microsoft .Net. Sometimes we have instances where a customer supposedly has two machines that are exactly the same, and our software works on one machine, but it doesn't work on the other. We do not have an answer for this. The basic answer is that it's impossible that those two machines are exactly the same. If they were the same, the software would work.
Our software runs the same on all Operating Systems. It's programmed/developed in .Net technology. Assuming, for example, a Windows 2003 Server and Windows 7 machine uses the exact same version/patch of .Net and they're running the same service pack of the Crystal runtime engine, they should function exactly the same. That's the purpose and design of .Net. If it doesn't function the same, it's basically Microsoft's fault, because it's not the same even though it's supposed to be.
We have thousands upon thousands of customers. If half of 1% of the machines in the world do not run our software correctly, there's nothing we can do to fix it. Again, the *PURPOSE* of .Net is so environments are the same (ie. stable and dependable). If it's not, it's the OS/machine/environment. We can't fix it. We don't do things different in our software based on the OS. Many times, if you were to install the software to a different machine, it magically works.
Read the "Design Principle" section so you'll know what we mean by "purpose" of .Net:
https://en.wikipedia.org/wiki/.NET_Framework
---
There is much more we could get into like the fact that the 2008 runtime engine was based on .Net 3.5 and the 2011 runtime engine is .Net 4 (.Net 4.x and later). Those two engines do not operate the same either. There are older reports that work on the 2008 engine that do not work on the 2011 engine, but if we supported only the 2008 engine, then there would be other reports that would work, because the report utilized a feature of 2011. The best that we can do as a software company is stay current with SAP and their Crystal runtime engines. If certain older reports do not work, our only advice is to recreate them in a later version of Crystal Reports.
---
In closing, when we "point the finger" at the Crystal runtime engine and say "it's out of our hands", we promise we're not being lazy or trying to be unhelpful. It really is out of our hands. We want nothing more than for all of your reports to work flawlessly. We try really, really hard to fix every report issue that's presented to us. If it's not possible for us to fix, though, we will say that. After reading this article, we hope you understand. Thanks!
