The Crystal Reports® Underground

One of the perks of using Crystal Reports is the number of third party tools that have been developed to work with the software. My Product Links page has links to more than 70 items.

So it came as a surprise when a user pointed me to a free tool that I had never heard of. This user had asked me if there were tools that would run and export reports from the command line.  I pointed him to my ‘Viewers’ comparison page which has several options. He replied that he had decided to use Crystal Reports Helper which lets you run reports for the command line and export them to a handful of formats. Because it runs from the command line the scripts can be saved in .bat or .cmd files and run from a scheduler. It is a free tool and I had never heard of it.

Crystal Reports Helper was created by Big Ideas Computing Ltd. It was initially created for users of their software application, named dbFront. dbFront lets you quickly build simple web facing applications that allow users to enter and update data. Crystal Reports Helper has since been released it to everyone for free, all you have to do is request it from the vendor.

And thanks to Rich Head of the Greater Iowa Credit Union for sharing this link with me. I haven’t tried Crystal Reports Helper but Rich said it worked fine for him.

A few years ago I started documenting the syntax differences between the main flavors of SQL. This, eventually, turned into the SQL Functions cheat sheet I have made available on my site (and still refer to regularly).

The main challenge I had creating the cheat sheet was that I didn’t have all these databases installed to experiment with. I had to ask volunteers who worked in specific environments to provide syntax examples for their flavor of SQL.

I was recently researching SQL syntax when a poster linked to a “SQL Fiddle” he had created.  SQL Fiddle is a site that allows you to ‘fiddle’ with SQL statements online, using a variety of common SQL languages. In many cases you can test statements using multiple versions of the same language. That led me to a handful of other sites that do the same thing with a different mix of languages. Here are three of the most complete ones I found, along with the languages they support:

http://sqlfiddle.com
SQL Server, Oracle, MySQL, Postgre, SQLLite

https://dbfiddle.uk
SQL Server, Oracle, MySQL, Postgre, MariaDB, SQLLite, DB2, Firebird, TimeScaleDB, YugabyteDB

https://sqlize.online
SQL Server, Oracle, MySQL, Postgre, MariaDB10, SOQOL

Note, these databases don’t always come with sample tables. You might need to run a statement to create the table(s) you want. Or you may be able to run your queries against the system tables.

One of the managers at SAP recently shared a link with me that I had never seen before.   It is a comprehensive FAQ page for the Crystal Reports product family.  If looks like about 40 pages of material and covers a wide variety of topics.  (For instance, A5 has a searchable list of all the service packs and C5 links to the Knowledge Base).  Here is the outline:

A. Overview
A. 1. SAP Crystal Solutions Overview
A. 2. SAP Crystal Solutions Licensing
A. 3. SAP Crystal Solutions Hardware specs, minimum requirements, etc
A. 4. What is the numbering of versions
A. 5. SAP Crystal Solutions Service Packs
A. 6. SAP Crystal Solutions Product versions
A. 7. SAP Crystal Solutions Maintenance and Support
A. 8. SAP Crystal Solutions compatibility

B. Purchase
B. 1. SAP Store purchase
What versions of SAP Crystal Reports are available through the SAP Store?
What versions of SAP Crystal Server are available through the SAP Store?
SAP CR 2020 and SAP CR 2016 available on selected 3rd party marketplaces.
B. 2. SAP Store additional questions
B. 3. SAP Store Upgrades
B. 4. SAP Store Order Fulfillment
B. 5. End User license agreements (EULA)

C. Installation
C. 1. SAP Crystal Solutions Installation
C. 2. Lost license keys and registration numbers
C. 3. SAP Crystal Solutions How-to Guides
C. 4. SAP Crystal Solutions Videos and Tutorials
C. 5. SAP Crystal Solutions Guided Answers and KBAs
C. 6. SAP Crystal Solutions Third Party Training and Consulting

D. Developers
D. 1. SAP Crystal for Developers
D. 2. Retirement of the SAP Distribution Reselling and PartnerEdge Open Ecosystem

E. Error and Issues Handling
E. 1. SAP Crystal Solutions product tips and tricks
E. 2. Vulnerabilities

F. Other topics
F. 1. SAP Crystal Solutions Third Party Apps
F. 2. Ask your own question
F. 3. Recruitment with SAP Crystal skills

Some of the links in this FAQ, like the link to the knowledge base search, require an SAP “Universal ID” to get full access.  These are free.

I found an apparently longstanding bug in Crystal Reports recently. It can be demonstrated by creating a simple report with three formulas (A, B and X).  Formula A can reference any field. Formula B contains formula A. Formula X contains formula B and also uses either the Next() or Previous() function. For a very simple example, use these three formulas:

Formula A:  {table.field}

Formula B:  {@A}

Formula X:  Next ( {@B} )

Place these 3 formulas on the details band of the report, side by side. They should all return the same values, with X values one row ahead.

To see the bug, open Formula A and add or append a literal value to the existing field.  If the field is a string you can use:

{table.field} & ‘AnyText’

If your field is a numeric or a date you can add a number to it:

{table.field} +10

When you save Formula A with this change you will immediately see Formula A values change in preview.  You would expect to see the same change in Formula B, but because of this bug, Formula B will not change.  You can make any change to Formula A that doesn’t cause a refresh/recalculate, and Formula B won’t change – at least not right away.

Now go into Formula B and make a simple change.  For example, hit [Enter] to add a blank first line and save Formula B. Now Formula B displays the change and matches Formula A. The formula updates finally, but that update didn’t happen right away.

To see it again you can go back to Formula A and take out the added value. Again Formula B won’t change until you do something else to make the report recalculate or refresh.

Somehow, using the Previous()/Next() functions in this three-formula series confuses Crystal’s internal formula dependency.  The fields always get back in sync after a refresh, or whenever the report recalculates all the formulas.  But many minor formula changes don’t force the report to recalculate so things can be off for a while.  I discovered this bug while trying to troubleshoot a very complex report.  It took hours to isolate the behavior, confirm that the formulas were correct and identify Crystal as the source of the problem.

I also went back and tested CR v10 (2004) and CR v8.5 (2001) and found the exact same behavior, so this is not a new bug.  I have never noticed it before, but it might explain some of the unexplained gremlin situations I have encountered over the years.

One solution to this is to add “WhilePrintingRecords” to either Formula A or Formula B, but that adds significant limitations to how these formulas can be used.

So I have a report with a subreport. The subreport is in it’s own section. The link to the subreport is a formula in the main report that extracts a PO number from a long text field.

The report is 13 pages long but it kept stopping at page 8 with no error message. The total page count would say 8+ and if I tried to go to page 9 it would take me back to page one. I assumed there was some page number bug, so I checked all the properties that affect paging and found nothing. When I deleted the subreport I get all 13 pages.

So I checked the ‘suppress’ property for that subreport and suddenly the problem went away. This was very strange because the subreport has a suppress condition formula which should ignore the check mark.  Even with the suppress is checked the subreport still ran at all the correct places based on the formula condition, but for some reason the suppress check mark allowed it to page correctly to the end.  I was confused.

My only clue was that it always stopped on after page 8, so I figured there had to be something unique in one record on page 9. I started eliminating records until I had it narrowed it down to one record that caused the problem. Then I started to check the formulas related to the subreport.  I found that the formula I was using to link to the subreport would generate an error when I put it on the report. That was strange because the formula was already being actively used to link to subreport. But even though the formula was already being used, it would NOT generate an error message. Once placed on the report an error would appear. That allowed me to correct the error and now the report works fine. 

So I learned that a bad formula, when it is used only as a link to a subreport, can silently stop a report without generating an error message. When that happens you have to put the formula on the report (or use it in another formula) to see the error.  That gives us one more place to check when a report starts to behave strangely.

If you are using Sage 50 (PeachTree) on Windows 11 and your Crystal Report gets the SQL error below, I think I have a fix for you.

The error says:

Failed to retrieve data from the database
Details: ADO Error Code: 0x
Source: Pervasive PSQL OLE DB Provider
Description: [LNA][Pervasive][ODBC Engine Interface]Syntax error
[Database Vendor Code: 268435456]

The error means that Crystal is generating Pervasive SQL that has bad syntax. In the case I faced the same report would work on an older system but not on the Windows 11 system. Other reports were fine in Windows 11 but not this one.

First we were able to narrow it down to a subreport. Then I found that the subreport would work with no selection criteria so we knew it was an error in the WHERE clause. We took out each rule in turn to narrow it down to the Date criteria. The failure only occurred when there was a Date rule in the selection formula.

I took the faulty SQL that Crystal generated and tried running it as a command a few different ways until I figured out the Pervasive SQL was looking for a DateTime value instead of a Date Value. I changed the selection formula to use DateTime values and the syntax error went away. Here is the syntax I used with two date parameters:

{JrnlHdr.TransactionDate} in
DateTime({?FromDate}, Time(0,0,0)) to DateTime({?ToDate} , Time(0,0,0))

If you have a date range parameter you could use:

{JrnlHdr.TransactionDate} in
DateTime(Minimum({?DateRange}), Time(0,0,0)) to
DateTime(Maximum({?DateRange}), Time(0,0,0))

I can’t say for sure this error only occurs in Windows 11 since I found the exact same error in a forum question from 2018 (before Windows 11 was released).

Update – 6/24/2023:

In the forum discussion above a Sage specialist reports that the error is related to CR 2008 SP1, and that upgrading to CR 2008 SP2 solves the problem. You can check your version by looking up the full Crystal Reports version number on the [Help > About] screen.   If your version starts with  12.1 you are on CR 2008 SP1.  If it starts with 12.2 you are on SP2.   If your version doesn’t start with 12, then you aren’t using CR 2008. 

And thanks to John Dierkhising of Bottom Line Accounting for point this out.

I just wrote about installing 64-bit drivers to get CR 2020 to work with Raiser’s Edge legacy MDB files. Here are a few other things I learned:

1) If you modify a Raiser’s Edge report using CR 2020 you are saving it connected to a 64-bit data source. Raiser’s Edge will still run the report just fine using 32-bit connections. Apparently, when RE runs the report automatically replaces any connections in the report with the connection  configured in RE. This was a happy surprise.

2) When running reports from inside other applications you can export the report to .rpt format. This saves the report with data, letting you open it in Crystal Reports and page through the saved data. When I tried this from RE the saved data would generate an error. It appears that RE adds a new formula to the report when it is run.  This formula uses a proprietary custom function that is only available inside the RE environment. This prevents the report’s saved data from opening up in Crystal.

3) You can make most changes using CR 2020 without having to connect to the data at all. You wouldn’t be able to preview the changes in CR, and you wouldn’t be able to add any new tables, but most other changes can be made without a connection.

4) You can still purchase Crystal Reports 2016 and keep using the legacy connections. CR 2016 is still for sale from SAP and simplifies things when you are using legacy data like this. SAP’s web site shows that support for CR 2016 will no longer be available in 2025, but that isn’t an issue for most users. I have many customers using ‘unsupported’ versions, some from 20+ years ago, and the lack of SAP support has never been an issue.

Like many users, I have not yet upgraded to CR 2020. I connect to lots of legacy data using DAO connections (e.g. Raiser’s Edge export data). To do this using CR 2020 involves installing new 64-bit connectors and updating each report. I’ve written up instructions on installing the new drivers but I haven’t applied the steps here since I am still on CR 2016.

This week I heard from a user who has to read legacy MDB files from Raiser’s Edge, using CR 2020. They followed my instructions to download the new driver, but got an error message when they tried to install it. The error said:

“You cannot install the 32-bit version of Microsoft Access Database Engine 2016 because you currently have 64-bit Office products installed. If you want to install 32-bit Microsoft Access Database Engine 2016, you will first need to remove the 64-bit installation of Office products. After uninstalling the following product(s), rerun setup in order to install 32-bit version of Microsoft Access Database Engine 2016:”

The funny thing is that they also tried to install the 32-bit driver and got the opposite error. So even though I don’t have CR 2020 I downloaded the 64-bit Access driver and tried to install it. I got the same error.

After a bit of research I found a way to get the driver to install without having to uninstall anything, by running the install from the command line using the ‘quiet’ switch. Here are the steps I used:

1) Download the file to my downloads directory
2) open a command line window
3) change the directory in the command line window to \downloads
4) Run the command with the “quiet” switch. It will look something like this:

C:\Users\ken\Downloads>AccessDatabaseEngine_X64.exe /quiet

You can also read the discussion where I found this method here:

https://superuser.com/questions/1557350/

After testing it here I did the same thing for Raiser’s Edge user and got them working as well. 

I resolved another minor mystery recently after a question from a customer. It has to do with the behavior of variables whenever you open a new tab by doing a drill-down on a group. The same thing can happen when you double click on a subreport in preview mode to open the preview of that subreport.

What I had seen was that some variables would carry to the new tab others would reset to zero/blank. So when a customer explained that this was causing a problem in their report I did some digging and experimenting. I discovered that this problem only occurs with shared variables, which pass to and from subreports. Shared variables will not carry from the preview into the new tab, while default (global) variables carry just fine.

I did some more digging to find a workaround and only found a partial one. I say partial because it will work for group drill-downs but not subreport drill-downs.  If you drill down on a group, typically you will see the Group Header, the Group Footer and the details for that group. The workaround is to make a second copy of the subreport that generates the shared variable, and put it into the group header of that group. To make sure that subreport doesn’t run repeatedly you can either hide the group header, or suppress the subreport with a condition like this one:

DrillDownGroupLevel = 0

Either of these will keep the extra subreport from firing until you do the drill-down. Then one instance of the subreport will run inside the drill-down and the shared variable will carry to the details and group footer inside that drill-down tab.

The downsides are

1) The subreport will have to run again if you do another a drill-down.

2) It won’t work for a subreport because you can’t put one subreport inside another.

If you have any questions about using variables, call to schedule a session.

Added 4/2/2023 – Another solution, if you are willing to use a third party dll, is to use the “Key-Value pair” functionality in CUT Light. This allows you to “Set” and “Get” values that are independent of the report’s variable process, so they aren’t reset by the drill-down.
https://www.milletsoftware.com/CUT_Light_User_Manual/#uflLookupGetEntry()

I was recently reminded of how handy it can be to create a “NULL” value in a formula. I had to use this in two recent situations and thought a description of these two uses would make a great blog post. But, as happens so often, I looked at my past posts and found I had written about both of these before, one in 2016 and one in 2007. So rather than write them up again I am just going to link to those posts with some brief comments.

1) If you ever need to do a distinct count of values that meet a condition. This usually means an IF THEN ELSE formula and if you don’t use a NULL as your ‘ELSE’ your distinct count is likely to be inflated by one.

2) If you want to do a minimum or maximum of values that met a condition. Again you would need an IF THEN ELSE formula and the simplest approach I have found is to use a NULL as your ‘ELSE’ value.

Note 1: Don’t think that skipping the ELSE altogether will generate a NULL value.  It will generate a default value (empty string, zero, etc.).

Note 2:  These NULL formulas are strings, so if you need an else that is a NULL numeric you can use:

Val({@Null})

If your else value needs to be a date you can use:

Date (Val({@Null}),1,1 )

These will still be null values, but they will have the correct data type for your formula.