Greetings, I have a customer reporting slowness of printing a Report - it's a third part invoice from a product developed by our in house development team (IRSOPBlankHistoryForm)
They sent in some logs from the support debugging tool but I'm wondering if this approach is a good place to start? If so, what data would I look for to find a possible suspect impacting performance?
Thanks
*This post is locked for comments
It is just this report. They have over 4 years of data with a large volume of sales lines. Server performance has supposedly been monitored with no significant resource bottleneck observed. SQL Maintenance is scheduled and runs weekly.
This brings me back to the original question of how to troubleshoot. SQL Profiler, SDBT ?? If profiler, then what are the key criteria to look for?
Have you tried running SQL Profiler on the user running these reports? Is it just this report or is the overall GP performance slow. How many years of data do they have. Is it possible that this report is perfoming a SQL union on several very large tables? I would look a the server performance before the user starts to run the run and while the user is running the report. If there is no difference it may be a poorly designed report. You could also run some DBCC routines just to make the underlying database is healthy.
Thanks for the reply Mike. Actually, we have a 3rd party invoicing product. We do use the same SOP tables as GP plus we have additional COMP tables. It's a dex report; in fact one of the reports is an alternate SOP Blank Invoice form.
Yes there is much data to dig through. In fact the slowness is evident in only one of the 27 companies that this client has. Not surprisingly, the slow company is much much larger than any of the others. The performance hit however seemed to come nearly over night about 2 months ago (unless that was just the first it was reported after 5 years?)
At any rate - we're headed down that much maligned path of troubleshooting where the problem truly exists. It wouldn't surprise me if it's an inefficient key or poorly constructed call but the question comes back to how to troubleshoot this. What type of logging can\should be done and then what to look for one we have these logs.
The client just tried the SDBT and those logs because it was more convenient than contacting the remote IT staff for a SQL trace.
Not sure if this is right or wrong. Again, I'm interested in knowing how to assess any of these logs for something that might reveal our performance bottleneck. thanks to anyone with advice on this topic.
Todd,
From what I can gather in your post, I'm guessing your organization is using some kind of reporting tool (Crystal Reports or SRS) to render some kind of historical invoice. Is this correct?
If so, those historical tables can contain a lot of data for those reporting tools to dig through. One of the things to explore with this is to use a SQL view or stored procedure to compile the data instead of relying on the tools built in linking tools.
Let us know and I'll see if I can help from the reporting end. I'm not familiar enough with the SDT to know if this will provide the insight you need.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,269
Super User 2024 Season 2
#2
Martin Dráb
230,198
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (