Archive for December, 2021
It is time for my annual comparison of formula function libraries. If you aren’t familiar with User Function Libraries (or UFLs) they are DLL files that add new formula functions to your Crystal Reports formula editor. With these functions your formulas can do some pretty amazing things like:
1) Carry values from today’s report to tomorrow’s report
2) Carry values from one report to another.
3) Append lines of text to an external text file.
4) Automatically copy a value to the clipboard.
5) Check the user name of the user running the report.
6) See if a file or folder exists (on your network or on the internet).
7) Rename/copy/delete a file on your hard drive or network drive.
8) Launch an application or run a batch file.
9) Execute a SQL statement (Select/Insert/Delete).
10) Send an Email using information in the report.
11) Create a table of contents or an index for your report.
12) Generate bar codes without having to install any fonts
If this sounds interesting you can read my complete comparison including a list of all the functions provided by each DLL. The five UFL providers are:
Bjarke Viksoe (U2lwin32)
Maginus Software (CRUFLMAG)
Millet Software (CUT Light)
Chelsea Tech (File Mgt, Text, Share and others)
CrystalKiwi (Export, Table of Contents)
The only product that has changed since last year is CUT Light, which added some new functions and is now available in a 64-bit version for users of CR 2020.
If you need help deploying one of these functions in a project let me know.
Everyone has been talking about the new Java security vulnerability called Log4j. I have been talking to colleagues to determine if this affects Crystal Reports, Crystal Enterprise or anything else in the Crystal ecosystem. SAP put out a note that states that this vulnerability does not affect SAP Business Intelligence 4.2 or 4.3. It doesn’t mention earlier BI versions but these are no longer supported.
There was a support note about this topic, but nothing in the support note mentions Crystal Reports or the Crystal runtime engine used by third party applications. One of my colleagues said that since this is a Java vulnerability, it should not affect stand alone Crystal Reports, and I tend to agree. I also believe that if Crystal Reports were affected it would be mentioned in that support note. The same goes for the Crystal runtime files, but it would be nice if SAP responded specifically to these questions in the discussion above.
Last, thanks to Andrew Baines of Pursuit Technology and Danny Shahrabani of rePORTAL Software for helping me track down and make sense of the SAP support note. If anyone else has info to share on this topic, please let me know.
I received this question several times, recently:
We have a legacy app that uses the Crystal Reports runtime. We want to use a later version of Crystal Reports, but still need the reports to work in our application. Is this possible?
The short answer is “probably not”. The longer answer involves a bit of history.
Crystal Reports, right from the beginning, provided a runtime engine that let you invoke reports from applications. First there was the Print Engine API (1991) which used files like crpe.h, crpe32m.lib and direct calls like PEOpenEngine(),PEOpenPrintJob(). Then in 1995 they released an Active X component using the file Crystal32.OCX (this was included for free with Visual Basic). In 1997 they released something called the Automation server using CPEAUT32.dll. These three different integration approaches worked side by side until 2001 when Crystal introduced the Report Design Component (RDC) which used the file CrAxDrt.dll.
The next year, when CRv9 was released, the RDC became the only supported integration method and the files for the other three methods were no longer provided. Since CRv9 rpt files were not backward compatible, users had to choose between using their legacy code or upgrading Crystal Reports. If they wanted to use the latest version of Crystal Reports they would have to rewrite their application. Many chose to freeze their Crystal version, and some are still using CRv8x and one of the original three runtime engines.
Then in 2003 Crystal released a runtime engine for .NET. For the next few versions of CR you could choose either the RDC or the .NET runtime engine. But in 2008, when CRv12 came out, Crystal no longer supported the RDC. Again users had to choose. If you wanted your application to support the new features in CR 2008 you had to rewrite your application in .NET. But, there was one difference. A crystal report created in CR 2008 (or even CR 2016) is backward compatible all the way back to CRv9. So these later reports can still be run from RDC based applications. However, if the reports use any features that are new after CR 2008 (optional parameters, vertical alignment, etc) these won’t work unless you are using the .NET runtime.
And this is where we are today. The only runtime engine that supports all the features in the current versions of Crystal is the .NET engine. There isn’t anything available in any recent version of Crystal that will work with legacy code from the other 4 integration methods. If you have an application that uses one of these methods your choices are:
1) Stay with your legacy code and use an old version of Crystal to maintain the reports.
2) Rewrite your code using the .NET runtime engine.
Years ago I put out a guide for using the .NET engine in applications. Although it was written in 2003, the basic object model hasn’t changed significantly since then. It is free and you can download a copy – if you think it will help.