Macola ES - Crystal Reports and SQL Lag

[BMoscato]

I recently migrated from Macola Progression 7.6.xxx to Macola ES 9.5.600; I’m going to 9.5.700 this weekend. Since the migration I’ve noticed a lot of issues with Crystal Reports. Everything from slowness of running a report and how running certain reports (Aging) lock you out of Pivot Analysis in eSynergy until the Crystal Report is finished processing. Also, some reports report data incorrectly when in Cash Flow; a debit will display as a credit. Check registry will display voided checks as if they’re not voided…

I’ve replaced switches, wiring, servers, workstations to combat the lag issues that I have. I’ve reconfigured SQL servers to different versions (Currently SQL 2008 R2)… All of these changes have done nothing to combat my speed issues.

I’ve been dealing with Macola and general ERP applications for upwards of 20 years; both as a user or reseller. I’ve logged 15+ bugs with Macola since April 2012; some of which are being released in 9.5.700. How is it possible that my company is the only company experiencing these issues?

Bryan Moscato

 

[jbelk11]

You are not the only person to experience performance issues with some reports in Macola. It is pretty safe to say that many Macola ES customers have speed/locking issues from time to time. The culprit tends to be the methodology/database design around the accounting modules of ES...I know I wouldn't have designed it that way. I would say many of us have just learned to live with it....or we've found other ways to accomplish our tasks more efficiently.

One possible reason to explain your general slowness with the Crystal reports is the methodology Exact is using for reporting. In some cases (tho not all), Exact has chosen to create a "reporting table" and then reports off the new table. This is especially true of the aging reports. If you create your own report, utilizing your own queries, you can drastically change the amount of time needed to run them. I have taken my AR aging report to about 45 seconds to be displayed.

I have heard of others improving some performance by having a DBA analyze the queries and optimizing the worst offenders. This tends to be true for anything that affects the general ledger. In my database, the infamous gbkmut table takes up about 58% of the size of my overall database. Until they decide to listen to their customers and come up with a way to purge that data, we will be forced to continue to find workarounds to things.

I can't necessarily comment on the stock Macola reports as we don't use them any more. I have pretty much rewritten all of the important ones to minimize the pain of running the stock reports.

You aren't alone...I hear you. If I can offer any further advice, just PM me.

Jen