GP 9 Client Freezes

[foxforce5]

We are experiencing a problem with the GP 9 Client hanging on our terminal server clients and stand-alone clients. Users are reporting that the application freezes every once in a while. The freeze will last for random intervals of several seconds up to about 2-3 minutes at times. We are monitoring SQL via Profiler and also have Microsoft SCOM 2007 running on the SQL server to track any processor, memory, disk queue, etc. issues. So far, we haven't been able to pinpoint any real issues with the servers, SQL 2005, terminal servers, or clients that would provide a solid explanation of why the GP 9 Client seems to freeze on us.


GP 9 Version: 9.00.281

Let me know if you need more details on the client install.

We are using several 3rd party add-ons.
The Etho-Series
Extender
AvaTax
Encore RCB

Has anyone had any experience with this sort of issue? Do you have any suggestion of what may be causing the problem that we are having?

 

[jymm]

I saw this once in SOP. Turned out that someone had (accidently) changed the next number (and/or the next master number) and GP was scanning through to find the next open number. Can you isolate it to a specific module?

 

[klewis10367]

Try turinig off you Home Page auto refresh..see if that helps.

 

[foxforce5]

Thanks for the info. We had a more accurate report of the activities a user is doing when the freeze occurs. One user reported that the freeze happens when she transfers an order to an invoice. In this case the application froze for 4 minutes.

 

[jymm]

well - that sounds REALLY close to what was happening here and I did two things

Go into Tools->Setup->Sales->Sales Order Processing
1) "Track Master Numbers" - I turned this off since this was one of the issues - we do not use "Master Numbers" so it did not make one bit of difference to our day to day operation
2) click on the Order Button - then click on the Order Id at the top and choose what you call all of your orders (ours is called <cough> Orders). now look right under there - the "Order ID Next Number" was our culprit. I ran this code in mgmt studio

select max(sopnumbe)
from sop10100
where soptype = '2'

which told us the last order number used - and I bumped it up a few hundred... all was well...

in our case someone had set it to 0 and for the first few days it was fine - it would go to quote #1 or #2 --- then after a few days it would scan to order number 2,000 then eventually order 20,000 --- and it would find all of the holes in between... make sense?

this help or hinder?

 

[foxforce5]

I found another issue with the re-indexing routine. The tables are being reindexed with a fill-factor=0. Since the tables may have been initially created without a fill-factor, this will cause the index pages to be full.

The freezing that happened today was caused by 3 users at least trying to add data to SOP30200 which has a size of 280MB. Adding data to this table when the index pages are full, may lead to a lot of data being rearranged and may have caused this delay of almost 4-5 mins.

I changed the fill factor and it will be in effect starting tomorrow.