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

When you set up Windows you get to select a Regional Format for things like dates and times. For instance, English(US) format will show today’s date as 7/21/2021 while English (UK) will show today’s date as 21/7/2021. In Crystal, certain date objects can be assigned to use these formats, so that they automatically change from one format to another based on the regional format setting of the PC running the report. This is handy if you have users in different countries. To use this feature, right-click on the date field, choose “Format Field” and on the “Date” tab select the “System Default Long/Short Format”.

However, I just had a user complain to me that he couldn’t get CR 2016 date fields to respond to the regional setting. So, I did a quick test in my own environment and found that changing my regional Format from English (United States) to English (United Kingdom) had no effect on date format in CR 2016. I closed Crystal and reopened it, created a brand new simple report and put the print date in the Page Header – and it still showed in US Format. To make sure I was using the right setting I tried the same test in CRv10 and the print date came up in UK format. I repeated the test in CRv8.5 and it also came up in UK format – but not in CR 2016.

I did an online search and found an SAP thread where someone else had the same issue when they upgraded to CR 2016. SAP’s response focused on the database client (?), but the issue didn’t appear to have been resolved.

I wonder if Crystal is somehow pulling the regional format correctly when it is installed, but then isn’t updating the region if it is changed after the install. If anyone is seeing different behavior or has insight to share, please let me know.

I have written before about using the ExtractString function. This function is found in the “Additional Functions” of Crystal because it comes from a UFL. But this UFL has come with Crystal Reports for a long time.

Today I found out that this function has an undocumented limit -it can return a maximum of 510 characters. If you need to allow for more than that you will have to use an alternative approach. Here is the formula that I used before I discovered the ExtractString() function. It will also work if you need more than 510 characters.

Local stringVar x := {Your.Field};
Local stringVar Beg := "BeginString";
Local stringVar End := "EndString";

Local NumberVar BegPos := Instr(x,Beg );
Local NumberVar EndPos := Instr(x,End );
Local Numbervar BegLen := Length(Beg);

if BegPos > 0 and EndPos > 0 and EndPos > BegPos
then trim(x [ BegPos+BegLen to EndPos-1 ])
else ''

In the first 3 lines you put in the name of the field, and then the two strings that mark the beginning and the end of the string you want to return. You shouldn’t need to modify the other lines.

The formula will then return everything between those two strings but will not include the strings themselves.

I just figured out how to solve an annoying Crystal bug that I have seen, on and off, for years. This bug has to do with text objects that are added using the default font of Arial 10. I don’t see this issue every day but it happens regularly with some customers and even on my own machine.

What happens is that a new text object gets horizontally squished. The characters are sized correctly, but the horizontal space from one character to the next is only about 10% of what it should be, so the characters overlap. You don’t see the problem while you are typing the text (Before), but as soon as you click outside the text object you see the squish (After).

Today I found a report that had this issue, and took the time to experiment.  Here are some factors that might contribute to the problem:

• The report is opened on a PC that uses a different printer driver than the design PC.
• The report is opened on a PC that has a different version of Crystal.
• Your default font for text objects is set to Arial 10 (and possibly other fonts).

If you add a new text object to the report under these conditions, you might see the squish.  For a long time I would have to change the font, change the style (to bold) or change the font size to correct the problem. But now I know two quick ways to eliminate the squish.

1) Go into File > Page Setup, don’t change anything, and click OK.

or

2) Save the report, close it and reopen it.

Either of these should get the font calculations back in line with the new printer driver.

If anyone runs into this situation (or something similar) and the above methods don’t work, please let me know.

I have written several times in the past about script errors on the Crystal Reports “Start” page. The message is:

“An error has occurred in the script of this page”

I have seen at least 3 customers experience this problem in the past week so I figure it is time to mention this again. You will see this error when you first open Crystal Reports or when you close a report and Crystal Reports reverts to the “Start” page.  Some users think there is a problem with the report they are trying to open, but in truth this error is unrelated to any reports.

The error is usually caused by one of SAP’s servers having a problem.  If you want to prevent this error you can follow the directions in this blog post on how to prevent Crystal from requesting an internet connection.