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()

My customers often use large, high-resolution monitors.  Sometimes the icons and menu options are microscopic – even to the local user. It is even worse for me since I am seeing their screen through GoToMeeting which reduces the screen even further.

But recently, one of my colleagues pointed me to a video that might help. It shows how to change a compatibility setting specific to high-resolution monitors.

If you are seeing microscopic icons on your Crystal toolbar, check out the video and see if it helps. And thanks to Gordon Portanier with the Crystalize consulting group in Canada for sharing this tip.  And also to Mike Pieczynski of OnPoint Consulting for sharing the video.

If you want to change the properties of a section, you go into the Section Expert(“Report” menu). You can also get to the “Section Expert” by right-clicking on a section name and selecting the option “Section Expert” from the “Flyout” menu. This menu also gives you a few properties you can change for a section without going into the Section Expert, like hiding, suppressing or deleting a section.

But I’ve noticed something strange in recent versions of CR. This flyout menu doesn’t always respond to user choices. I have noticed it both in my own environment and also when working remotely with several customers. It can be annoying to repeatedly right-click on a section name and have your choice ignored. One customer just stopped using the flyout menu altogether and just started navigating the main menu to open the Section Expert.

Now I think I have figured out a pattern for this behavior. If I right-click on a section quickly, without moving the mouse at all, the flyout menu will appear but it won’t respond to my choice. If, however, I right-click on a section and hold the cursor while dragging down a bit before I (left) click on my choice,  then the menu will respond to my choice.

I am guessing this is a bug, since I have not seen this problem with any other flyout menu in Crystal.

Crystal Reports is a great tool, but it isn’t perfect. One of my long standing complaints is how hard it can be to grab the sizing handles on an object using the mouse. The active zone around the sizing handle is tiny, so you have to be very precise or you end up dragging the object around instead of sizing it. You would think that zooming in would make the active zone bigger, but it doesn’t.

So I was very happy when I discovered, years ago, that you could size objects with the keyboard. If you hold down the shift key and hit the left/right arrow keys you can make the object’s right side move in and out. If you hold down the shift key and hit the up/down arrow keys you can make the objects bottom edge move up and down. If instead you hold the CTRL key while you hit the arrow keys, the entire object moves in one of the 4 directions but the size doesn’t change.

But soon after I started using Shift-Arrow I found that it didn’t work half the time. It was just this past week when I figured out the two situations where you can’t use Shift -Arrow to size objects:

1) When you are in Preview mode. For some reason using Shift-Arrow only works in Design mode. This is odd because using CTRL-Arrow to move objects can be done in both design and preview. That may be a bug but I found it true in all the versions I tested.

2) When the edge of the object snaps to a guideline. Once an object is ‘snapped’ to a vertical or horizontal guideline, the snapped edge can’t be moved using Shift-Arrow.  But following the pattern mentioned above, guidelines snapped to the top or left side do not prevent using CTRL-Arrow to move objects.

I was working with a customer’s report on my PC and trying to change a parameter. Instead of showing me a list of values I was presented with an unusual dialogue, looking for credentials. This dialogue didn’t look familiar and it took me a few minutes to figure out why it was there. The parameter I was using was a dynamic parameter and it was trying to pull a list of values from the database. That database didn’t exist on my PC, of course, so this is the window I saw:

As you can see it doesn’t allow you to change the name of the server or the DB. It does allow you to log in but that won’t help because I suspect you will only see this when the DB doesn’t exist. To get by this you have cancel and then change the dynamic parameter to pull form a local source.

So if you see a strange login that has “Enter Values” at the top and “Use Single Signon Key” at the bottom, check to see if your dynamic parameters can find their data.

A long time ago I wrote about a bug in Crystal Reports that affects two special fields:

• Modification Date
• Modification Time.

These fields show you when that report was last modified. If you open and refresh a report without changing anything the modification date and time should not change. This works most of the time, but it doesn’t work if you have a subreport.

This came up again this past week and after some discussion I thought of another article that I wrote in January about the options setting ‘Verify on first refresh”.  I ran a quick test and found that turning this setting off solved the problem. Apparently, doing that “Verify Database” counts as a report modification – but ONLY if there is a subreport in the report.  The behavior is different if there is no subreport.  This inconsistency is why I categorize this as a bug.

So if you are using the modification date (or modification time) in a report that has one or more subreports, you might want to turn this setting off.  It is found in File > Report Options.

And, if anyone finds an issue with turning off this setting, please let me know. I can’t think of one.

I had a customer this week who updated a report to read Oracle instead of SQL Server. The report was based on a command and the SQL was virtually identical. But for some reason the Oracle version would take a full 5 minutes to refresh while the SQL Server version only took a few seconds.

Once the report was run in Oracle the first time it could be refreshed using different parameters and it would only take a few seconds. I had the customer check for indexes but those had been set up to match SQL Server. I wondered if it was a data cache, but that didn’t explain why setting new parameters would be fast.

The only other thing that I could think of that was unique to the first refresh was a setting in Crystal that does a “Verify Database” on the first refresh. This usually takes a few seconds and isn’t noticeable, but as a test I turned that feature off. The first refresh was now as fast as SQL Server. Apparently, something in their environment caused the “Verify” process to take 5 minutes to complete.

If you run into something similar, go into File > Report Options and look for the check mark that says “Verify on First Refresh”.  Unless your environment is changing frequently, this doesn’t need to be checked, although in most environments you won’t notice a difference.

If you aren’t familiar with the “Verify” feature you can invoke it at any time by using the option in the database menu. This forces Crystal to poll the database for a complete list of fields for every table used by the report, including the data types.  Crystal stores this info in the report, which gives you a full field list even when you aren’t connected to the database.  Whenever fields are added, removed or their data type is changed this list needs to be updated . That is what it means to “Verify Database”.

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 recently heard from Gordon Portanier (from the Crystalize consulting group in Canada). He was doing something I have seen several customer do over the years. He would start certain formula names with a symbol so those formulas would sort to the top of the field explorer list. Gordon happened to use the @ symbol.

When he upgraded to CR 2020 these reports ran fine, but he found that he could not create a new formula that had an @ symbol in the name. A message told him that four characters [ @ { } ? ] were now considered reserved characters and could no longer be used anywhere within the name of a formula field.

Existing formulas, however, are not affected unless you try to rename them. So Gordon found another report that had the formula names he needed and copied them to the current report. The formulas work fine.

Up through CRv12(CR 2008) a formula name could include ANY character in any position. But when I tested this in CRv14.2 (CR 2016) I got the same warning as Gordon. My guess is that this restriction started with CRv14 (CR 2011) and so it would also affect CRv14.1 (CR 2103) and all later versions.  If any of you are using CRv14 (CR 2011) or CRv14.1 (CR 2103) you can confirm this by trying to add a formula with an @ in the name.  Let me know what happens.

An interesting point. This rule only applies to formula names. It does not affect the names of SQL expressions, parameters or running totals.

Another interesting point is that the @ (which represents formulas) and the ? ( which represents parameters) are reserved. But you can still use the % symbol (which represents SQL Expressions) and also the # (which represents running totals).