Archive for the 'Bugs and Errors' Category



Script errors on the Crystal Reports start page and how to customize the start page

Saturday 11 January 2020 @ 5:48 pm

It has been 5 years since I first wrote about the script errors that affect the Crystal Reports start page. This issue comes up again periodically and several customers have had these issues recently. So if you are having issues with the start page here are the articles that should help:

https://kenhamady.com/cru/archives/2615
https://kenhamady.com/cru/archives/147

The fix is pretty simple and involves renaming two HTML pages in one of Crystal’s application folders. This prevents Crystal start page from trying to access the web.

Since the start page is  written in HTML I decided to have a look at how it worked. I was hoping to modify the page to show links to my most frequently used reports. After much experimenting I found a way to create hyperlinks that would open reports based on specified path and file name. The key was to ‘borrow’ the custom javascript function that is used to open your most recently used reports. The function is called fncrOpenReport.

So I edited the HTML in the start page and put in a few lines like this:

<A href="javascript:fncrOpenReport('C:/sample.rpt')">Sample Rpt</A>

The next time I started Crystal the start page included a section of new hyperlinks. The one above appears as the words “Sample Rpt”. When I click that hyperlink it opens the RPT specified in the fncrOpenReport function. This section works much like the “My Recent Reports” section but these reports won’t roll off the page as other reports are opened.

The only odd part about using this function is that reports opened this way cannot use “save as” until after you click “save”.  If you click “save as” without having clicked “save” the dialogue just doesn’t open.




PDF problems with Viewpoint’s Spectrum Software

Wednesday 18 December 2019 @ 10:28 pm

Any time Crystal Reports exports to PDF there is a slight reduction in font size. So when a customer complained that their fonts were exporting inconsistently to PDF, I figured it would center around this topic.  But, what I found was something different. The report was being run from within Viewpoint’s Spectrum Software for construction. The report looked fine if we exported it to RPT format and opened it in the Crystal Reports designer, but the PDF version had inconsistent font sizes.

One example was a large block of text with four paragraphs. It was all formatted with the same font and the same size in Crystal. In PDF format the first paragraph was in one size and all the other paragraphs were in a different size. I cut the first paragraph out to make it a separate text object and left the remaining three paragraphs in one text object.  But the font change just moved down to the next paragraph break.  I had to make each paragraph it’s own text object to avoid font changes.

A second problem was that text objects and field objects would end up being reduced by different amounts, even though they started out the same size. For example, just before the text objects was a database memo field that was supposed be the same font size. If I started them both at font size 9.5 in the report, the memo field would end up at 8.5 while the text object would end up at 8.  If reduced the memo field to 9 the font would end up as 7.5. I tried several other combinations and couldn’t find one where the text objects and fields would end up the same size in the PDF.

The odd part was that I couldn’t replicate any of these problems in my local environment.  I opened their rpt file saved with their data in my Crystal Reports designer and it exported just fine. I even tried it in Crystal v10 which is 15 years old and uses Adobe 4.0 format.  It still exported here with consistent font  sizes. So it sounds like this might have something to do with the runtime environment associated with Spectrum.

Conclusion: If you are using Viewpoint’s Spectrum Software, watch out for PDF font sizes.  If you need help with these issues, give me a call.




Sage 50 GetPeach() functions in Windows 10

Monday 9 December 2019 @ 7:38 pm

For some reason the combination of Sage 50 (PeachTree) and Windows 10 generated many calls from customers.  Most of these calls were for reports that used the special GetPeach() functions and that stopped working.  These functions have come with Sage/PeachTree for years. I was told by several Sage consultants that these functions would no longer work in the current versions of Sage 50.  But one of my customers ended up solving the problem on his own and has allowed me to share what he found (he didn’t want to be cited).

So here is how he got these functions working again:

  1. A system PATH variable must be assigned to C:\Program Files (x86)\Sage\Peachtree. This folder contains the DDFs (data dictionary files) for the interface between Peachtree and Crystal Reports and other special functions. Without these DDFs, any effort to run a report containing GetPeach() functions will fail with the error message “The Specified Module Could Not Be Found”.
  2. In a single user environment U2LPeach.dll and the associated .ini file (U2LPeach.ini) must be included in the folder C:\Windows\Crystal. This is the default location the files are placed by Sage 50 when data functions are updated.
  3. If operating in a terminal services environment, U2LPeach.dll and the associated .ini file (U2LPeach.ini) must be included in C:\Users\\Windows\Crystal.
  4. When U2LPeach.dll is loaded correctly, the .dll will appear in the list of dlls loaded by Crystal Reports. This list can be found by going to “Help > About Crystal Reports” and clicking “more information”. Alternately you can edit any formula and look in the additional functions node for the GetPeach functions.

If you are having problems with Sage 50, and the above doesn’t help you, let me know. I have several colleagues who are Sage 50 specialists so we should be able to resolve it for you.




Correction to “elapsed time string” formula

Saturday 9 November 2019 @ 11:54 pm

My web site has a page for commonly used formulas.  Many have been there for years.  Formula page 9 has two versions of a formula that will convert a number of seconds into an elapsed time string. The long version has days, hours, minutes and seconds.  The shorter version is just hours and minutes.

I was using the short version in a customer’s report and we noticed that the minutes value was sometimes off by one.  After some testing we found that if the remaining seconds were between 30 and 60 the formula would always round down because the formula used a Truncate() function. The Truncate() works correctly in the long version of the formula, because you truncate down to the whole minutes and then display any remaining seconds. But since the shorter version doesn’t display seconds it is more accurate to Round () the seconds to the nearest minute.  So I have updated the short version formula on my site to use the Round () function for minutes.

So those of you who have used that formula should update your reports by changing the last Truncate to a Round, or just taking the updated formula from page 9.




Literal values that include quotes

Saturday 26 October 2019 @ 12:25 am

I was recently working on a formula that had the crystal syntax for “is one of”.  It looked something like this:

{LastName} in [ "Smith","Jones","Thompson","Rutledge","Harris" ]

Each value goes in quotes (single or double). You separate the values with a comma and you put square brackets around the list. So I was surprised today when I saw that the formula was actually like this:

{LastName} in [ "Smith""Jones","Thompson","Rutledge","Harris" ]

Notice the comma missing between the first two values.  The report had been running for months without error messages which I didn’t understand, so I started testing.  My experiments pointed me to a syntax rule that I had read about but never used. It is for when your formula includes a literal string that you surround with double quotes, and when the literal string itself contains double quotes.  Crystal would assume the first quote is the ‘open’ and the second one is the close, even when you want the second one to be part of the visible output.   One solution is to use two consecutive double quotes within the literal. Whenever Crystal finds two consecutive double quotes within a literal surrounded by a pair of double quotes, Crystal will interpret the consecutive quotes as one literal quote and not as a closing quote.  This is much easier to explain with an example.  So if I wanted a formula to output this string:

The syntax for "is one of" uses brackets

I could write it like this inside the Crystal formula:

"The syntax for ""is one of"" uses square brackets"

The formula engine would only display one of the two consecutive double quotes in each pair.  That explains why my formula with the missing comma doesn’t generate an error.  Crystal treated the consecutive double quotes as a single literal and then combined the first two elements in the list as being the single value:

Smith"Jones

There was no error message, but the results would not have been correct.

BTW, the same principle applies to single quotes. If you put two consecutive single quotes in a string surrounded by single quotes, Crystal will ignore the first and treat the second as a literal quote.

The reason I didn’t think of this right away is that I have never used consecutive quotes in a formula. If I have a string that needs to contain single quotes I surround it with double quotes. And if the string needs to contain double quotes I surround it with single quotes. In the rare case that a string needs both I would split it into separate pieces and combine them. I find that using consecutive quote pairs makes the formula harder to follow.




Crystal crashes with no error message

Sunday 13 October 2019 @ 9:09 pm

MDB is the original Microsoft Access database format. It was replaced by the ACCDB format in 2007, but there still applications that use MDB files. For instance I have a handful of customers using Raiser’s Edge software for donor tracking, and this application still creates export files in MDB format.

One Raiser’s Edge customer recently contacted me about a report that kept crashing. There was no error message – Crystal would just shut down. The report had 32 tables and 31 joins. If he deleted one of the tables the report ran fine. As soon as he added the last table the report would crash.

In my testing I found that it didn’t matter which table was dropped. So it became apparent that the issue was a limit, somewhere on the number of tables or joins. But it was hard to determine where the problem lay without any error messages.

First I checked the SQL generated by Crystal Reports and that looked normal. I copied the SQL into a new SQL command but that had the same exact limit.

Next I tried the same report using different connection methods. Both OLEDB and ODBC failed in the same way as DAO.

Then I decided to see if the problem was in the MS Access engine so I copied the SQL From the report and pasted it into a new MS Access query. (I am one of those people who still use MS Access 2002.) The query would run fine in MS Access as long as I dropped one of the tables. If I added that last table the MS Access query would generate an error that said:

“Query is too complex”

I couldn’t find the official limits for MDB files but I did find a page that showed the limits for ACCDB files and it says that the number of tables in a query is limited to 32, which in some cases can be reduced even lower.  So apparently we hit the limit. And worse, when you exceed the limits for MS Access, the report can’t survive to give you an error message.  It just dies.




Column headings scrambled in Excel export

Monday 16 September 2019 @ 9:20 pm

I had a customer recently complain about a report not exporting correctly to Excel (Data Only). The column headings worked correctly in preview but were re-arranged in the spreadsheet in a seemingly random fashion.

My first thought was to make sure that they were all the same width as the field below them and precisely aligned with the fields, but this didn’t solve the problem. Then I aligned their bottom edges but again this didn’t solve the problem.

Then I noticed that the headings that moved to the right were all text objects that were either two rows or three rows deep, making them taller than the other headings. The tallest headings moved further to the right, which meant that it had something to do with the position of the top edge. So I made all the heading objects the same height and then aligned their top edges. At that poing they all exported to Excel in the correct order.

Note that this only affects Excel exports that are “Data Only”. Of course this is the option that I use 99% of the time.




Real rounding vs fake rounding

Sunday 8 September 2019 @ 8:00 pm

Crystal makes it easy to reduce the number of decimals that you display for numeric values. There are two buttons on the toolbar (near the percent sign) and these allow you to either reduce or increase the decimals displayed. When you reduce decimals the remaining digits will either round up or down based on the digits no longer displayed. In other words, if you are showing 75.28 and you click the button to reduce the decimals displayed by one, the value will display as 75.3. This is because the hidden 8 causes the value to round up to the next 1/10th.

However, this is deceptive. The underlying value in the report is still 75.28. And if you were to total that column or use that value in a calculation the value used would still be 75.28. This can give unexpected results, because the visible total at the end of the report might not reflect the sum of the visible values that go into that total. For that reason, I call this ‘fake’ rounding. You will find the same type of issue in Excel spreadsheets.

Most of the time, this isn’t an issue. And many people who read financial statements understand ‘rounding errors‘. But there are cases where you need ‘real’ rounding. Real Rounding requires writing a formula that uses the Round() function. For instance, if you have to apply a tax rate to a purchase and the calculated tax amount.  You could use a formula like this:

{Sales.Charge} * {Sales.TaxRate}

But if the tax value has more than two decimals, those extra decimals aren’t real.  Most transactions have to be rounded to the nearest penny. In these cases you would need a formula like this:

Round ( {Sales.Charge} * {Sales.TaxRate} , 2 )

This rounds the tax to the nearest penny.  If you used the first formula and created a total of the tax values, the total would include all the fictional fractions of a penny.  If everything was displayed with two decimals the total tax would not match the individual tac values, because those would be using fake rounding to display only two decimals.  But if you use the second formula and then create a total of that formula the total should reflect the visible values.  The total calculation is using values that display the same number of digits as the underlying value.




When that zero isn’t really a zero

Thursday 8 August 2019 @ 10:24 pm

Last week a customer was really befuddled. He had a formula that said:

if {@field} = 0 then ...

He could see lots of zero values but the formula didn’t work as expected.  He couldn’t figure it out so he sent it to me. The first thing I did was add a few more decimals to see if it was a rounding issue. That didn’t show anything, but the formula still insisted that the value was somehow NOT equal to zero.

So I went into the formula and multiplied the current value by one trillion. Then instead of zeros I started to see some small numbers.  I am not an expert on floating point values or database precision but I have seen this before in reports.  The solution is to round the value in the formula before comparing it to zero. In this case we rounded the value to two decimals like this:

if Round ({field}, 2) = 0 then ....

That made the formula behave as expected.  The odd part is that I have seen the same problem with two other customers in the past week. It could be just a coincidence, but I figured I would mention this and see if this is happening to more people.




Preventing the “division by zero” error

Friday 26 July 2019 @ 9:52 am

Crystal formulas can use 3 different divide operators:

  • Regular divide [ / ]
  • Integer divide [ \ ]
  • Percentage [ % ]

But all of these will fail if you follow the operators with a zero. The report will stop and Crystal will throw the error message “Division by Zero”.  The standard solution is to check and make sure the number you are dividing by is not zero before you do the calculation, something like this:

if {fieldA} = 0
then 0
else {fieldB} / {fieldA}

This way, whenever the bottom of the fraction (denominator) is a zero, the formula will print a zero and NOT try to do the calculation.

But even when customers use this formula pattern I still see the divide by zero error. Some users mistakenly check the top of the fraction (numerator) instead of the bottom (denominator).  Some do it correctly at first, but then change the denominator and forget to change the first line to match.  So I have developed the habit of using Local variables to make things easier. My normal pattern now looks like this:

Local Numbervar n:= {FieldA};//numerator
Local Numbervar d:= {FieldB}; //denominator
if d = 0 then 0 else n/d

This ensures that the value being checked is always the value on the bottom. Some other advantages of this method are:

1) If d is a subtotal or a long expression you only have to enter it in one place.
2) If you have to create a series of similar expressions, like for 12 different months, you can duplicate the first example and you only have to change the values at the top of the formula.




«« Previous Posts
Jeff-Net

Recrystallize Pro

Crystal Reports Server