Single off-site customer with VERY slow reports

[Former Member]

My company's software is run by about 1500 customers across the US, Canada, and Australia. Of those customers, we have exactly one who is experiencing extremely slow report launches. A very simple report that takes between 2-5 seconds to preview on almost any other machine takes over two minutes on their machine.

Our software is a Windows Forms application built on C#.net using VS2008. We use Crystal 2008 SP4, launching stand-alone rpt files against a SQL Server 2005 db using the CrystalReportViewer control.

The machine itself is seemingly healthy, and appears to perform quite well overall. (It's running XP SP3, but that shouldn't matter as many machines in our office are running the same OS, and none of them have this issue.) Plenty of RAM, all Windows updates in place, and CR2008 SP4 has been updated as well. The machine does not exhibit any other notable performance issues as far as we can tell, including printer tests. Another, almost identical machine in the client's office does not exhibit the same lag in launching reports.

We've been digging for answers for three weeks now, and have tried all of the following:

1. Upgraded CR2008 to SP4.

2. Uninstalled and reinstalled our software and all CR components.

3. Ran a full Malwarebytes sweep. (nothing found)

4. Disabled all firewall, anti-virus, and anti-malware software.

5. Installed Process Monitor and recorded all the action, but have so far failed to identify what might be the culprit (log file available upon request).

6. Disabled the networking icon, and then the networking service entirely. (Procmon showed a lot of DHCP activity.)

7. Added <generatePublisherEvidence enabled="false"/> to the app's config file.

EDIT: I just recalled a few other things we did:

8. Turned off all disk indexing.

9. Uninstalled Windows Search.

10. Confirmed that bmp files are defaulted to open in Paint (we have a company logo linked as an OLE object in our reports).

As you can probably tell, we're down to clutching at straws at this point. Does anyone have any suggestions as to what else we might look at? I'll be happy to post that Procmon log if anyone cares to look it over.

Thanks!

Ron Moses

ConEst Software

Edited by: RonMoses on Feb 6, 2012 6:36 PM

[jasprit_singh5]

Could u do a a Trace Route and check the time taken for a packet to reach the BO system from that machine. It seems that the issue seems to be with the network.

[Former Member]

We establish a connection string directly to the SQL Server instance, which in this case is on the local machine, as is the application and the rpt files. So I'm not entirely clear where I would be doing a Trace Route to or from.

[Toby_Johnston]

Hi Ron,

First off, this is the wrong forum for this question. I'll move this post to the correct forum for you.

Some things to think about:

1) Does it take the same amount of time to refresh the report in CR2008 on the problematic machine? If not, there is an issue with the custom code or the way the code is behaving on these problem clients. We first need to rule out the custom code as being an issue (my suspicion is that the custom code is not the problem)

2) Do the clients that work vs the slow clients exist on the same exact network with same route to the database? Or are the slow clients connecting through a VPN or WAN connection? Try to rule out the network as being the problem. (changing the connection string to use localhost for SQL Server would be a good test)

3) Have you tried setting the report to use "no printer" or have you installed the same printer driver that the report was designed with on the problematic client machines? Sometimes, time will be spent by the print engine trying to load the printer driver and eventually it will revert to no printer. This could certainly be your issue.

4) Beyond this, you will need to enable tracing to understand what exactly is taking so long (CRPE issue, CRQE, report rendering, db driver / data fetch etc). You will however need help in interpreting these logs from SAP support.

Please open a message and they will advise how to enable to appropriate traces and will diagnose the problem using the trace to see which function calls are taking the most time. It should be a slam dunk with this information.

If you don't have a support contract then let us know and we can give you the required steps however it will be best to engage SAP support.

Regards,

Toby Johnston

SAP America, Inc.

[Former Member]

My apologies for posting to the wrong forum, I found the list of forum descriptions very confusing.

1) Does it take the same amount of time to refresh the report in CR2008 on the problematic machine?

Yes, it does. It doesn't appear to be a "first run lag" issue.

2) Do the clients that work vs the slow clients exist on the same exact network with same route to the database?

Same network, but they are not connecting to a db over the network. Each is connecting to their own local (default) server instance.

3) Have you tried setting the report to use "no printer" or have you installed the same printer driver that the report was designed with on the problematic client machines?

We have that on our list. The only thing that leads us to question that option is the fact that both machines are using the same printer driver, and only one is having slow performance.

4) Beyond this, you will need to enable tracing to understand what exactly is taking so long (CRPE issue, CRQE, report rendering, db driver / data fetch etc). You will however need help in interpreting these logs from SAP support.

We are in the process of opening a support case now. Thank you.

Ron Moses

[Toby_Johnston]

No worries. It sounds like the problem is with the print engine, CR, or the db driver / fetch. We just need to compare the logs from a working system vs a non-working system and this will provide root cause for the slowness.

Best Regards,

Toby Johnston

SAP America, Inc

[Former Member]

That sounds like a very good plan. Not to sound like an idiot, but could you tell me where I'd find these logs?

thanks

Ron Moses

[Toby_Johnston]

Please enable tracing per these kbases, then collect traces from a working client and a non-working client. You may attach the logs to this post and also attach to the support message,. When running these tests, do so from the CR2008 designer and not your custom application.

[1470978|https://service.sap.com/sap/support/notes/1470978] - How to enable/disable crpe logging for the Crystal Reports .NET SDK

[1603398|https://service.sap.com/sap/support/notes/1603398] - How To: Debugging database issues using crlogger logs in Crystal Reports 2008

Regards,

Toby

Edited by: Toby Johnston on Feb 7, 2012 9:34 PM

[Former Member]

Both links require a username and password. I've tried my email address and my forum name, neither lets me in with my forum password. If there's a different UN/PW I should have, I have no idea what it would be.

Please enable tracing per these kbases, then collect traces from a working client and a non-working client. ... When running these tests, do so from the CR2008 designer and not your custom application.

This may not be possible, as it would require flying about 1500 miles to the customer's site. We have no non-working clients in-house, nor have any been reported in realistic proximity to us. I'm hoping it will not become necessary to ship a copy of CR to the customer and try to teach an electrical contractor how to use the report designer.

Thank you for your patience.

Ron Moses

[Toby_Johnston]

Hi Ron,

To access those kbases, you must logon using your S-USER id. It would look something like this: S0090212384

Regarding the tracing, you could have the customer download a 30 day trial version of CR2008 and perform the test this way. The .NET SDK kbase I referred to should work with your custom application so this may also be an option.

Also, you could use Microsoft Remote Assitance to remote into the customer's computer. Alternatively, SAP support can use Netviewer or SAP Connect to create a web conference that would allow us to view the customer's computer.

Regards,

Toby

[Former Member]

...sigh... Well, I don't have an S-USER ID, but I did just spent an hour combing through the site trying to figure out how to request one. Many of the links required an S-USER ID to access, which is very funny, ha ha you guys. When I finally did find a place to request one, I find I need a Customer number, which isn't listed in Help>About so I guess I need to get it from my Partner? To our knowledge, we don't have a Partner. We just buy the software from you guys and use it, nothing fancier than that.

My employer is advising the customer to buy a new computer, so this topic may be closed shortly anyway.

Ron Moses

[Toby_Johnston]

Buy a new computer? Something tells me your customer won't be very happy about that.

You are assigned an S-USER when you purchase a support contract from SAP. This is how you access our [support site|http://service.sap.com].

If you purchased CR from a partner, they will have an S-USER and should be able to provide support for you.

I have attached the contents of the kbase, the formatting won't look very good however. Good luck.

Regards,

Toby

Edited by: Toby Johnston on Feb 7, 2012 10:55 PM

[Former Member]

Thank you.

Ron Moses

[former_member11696]

Hi Ron,

Before you do that open up one of the reports and and go to Page Setup and check on the No Default Printer and or check on the Dissociate... option. Try both or one at a time.

I believe the issue is CR is attempting to find the printer the report was created from which of course is not available and the delay is your network time out.

If that works and they have a local copy of Cr Designer then get them to update every report.

Just though of another possible delay, if your reports have any of the Verify On... options checked on this too can cause delays, the reports are trying to connect to the DB server originally designed on and if they are using ODBC that introduces another 1 minute time out. Go into Report Options and check off they also.

Don

Edited by: Don Williams on Feb 8, 2012 9:34 AM

Edited by: Don Williams on Feb 8, 2012 9:37 AM