Page 1 of 1

Purchase orders particularly bad in Job Costing v8

Posted: 23 Mar 2015, 09:03
by GravityMan
First of all, apologies if I've posted this in the wrong section.

I provide IT Support for two sibling companies that share the same office space/IT infrastructure. At a glance:

* We run both Sage Line 50 V10 (no problems) and Sage Job Costing v8
* There are up to 20 employees who use Job Costing at one time, with half of them using it frequently (at least 5 minutes every half hour).
* Probably goes without saying, but two company files are used, with #1 having a larger database than #2
* All of the workstations are running Windows 7 64-Bit


A few months ago, we migrated the domain server from Windows Server 2003 to Zentyal 4.0 (an Ubuntu/Linux based server distro) which uses a samba file server.

Now Job Costing wasn't particularly quick to begin with, but this changeover left it especially slow. We had problems like report generation hanging for up to an hour, missing records, and Job Costing closing without warning. After a little digging, we determined that Job Costing was sending out large numbers of small file packets, which samba didn't seem to like. We decided to try out a NAS box, so we moved all of the Sage data onto a FreeNAS CIFS/SMB share. This performed much better than the previous setup, and a lot of the problems stopped happening.

However, there's still a problem with entering purchase order details. When someone is entering a purchase order and they go to enter a job number, the program hangs for an unreasonable amount of time (10+ minutes). It only appears to be happening with company file #1 (the one with the larger database, though the purchase order portion is smaller than a lot of the other portions), and only on (as far as I've been told) two workstations. Both of these workstations should be well-equipped to handle Job Costing (4GB+ RAM, 1Gbps Network Card - one of the workstations was able to write to the file share at over 700Mbps).

We carried out the same purchase order procedure on another workstation (same specs), but that didn't have any problems. I've tried tweaking the workstation network card settings and the CIFS/SMB settings, but neither of those seem to make any difference.

I'm hoping that someone here has experienced something similar, or has a few ideas of what to try next. Is there some aspect of Job Costing that could cause one component to perform so much worse than the others?

Thanks in advance!

Re: Purchase orders particularly bad in Job Costing v8

Posted: 24 Mar 2015, 10:33
by brucedenney
Windows 7 by default uses SMB2, does the Samba server you installed support SMB2?.

If not then enable SMB2 support in Samba or disable SMB2 support in Windows 7.

If SMB2 support is enabled the has Windows 7 had SMB2 support disabled ? In which case you need to re-enable SMB2 support on the workstations.

Let me know how you get on.

Bruce

Re: Purchase orders particularly bad in Job Costing v8

Posted: 29 Mar 2015, 21:27
by GravityMan
Thanks for the prompt reply Bruce.

Yes, the Samba server supports SMB2, and that is set as the minimum protocol. As far as I can tell, SMB2 support hasn't been disabled on any of the workstations. I tried enabling it on one of them, but that doesn't seem to have made a difference.

Re: Purchase orders particularly bad in Job Costing v8

Posted: 30 Mar 2015, 08:51
by brucedenney
Look for SMB2ToggleToo it is a neat tool for checking/changing SMB2 configuration.

If it is not SMB2 then my next, check would be DNS is the gateway set to the Samba server or the router?

Re: Purchase orders particularly bad in Job Costing v8

Posted: 31 Mar 2015, 21:40
by GravityMan
Perfect. I'll give that tool a try and report back. As for your DNS question, the gateway is set to the router.

Re: Purchase orders particularly bad in Job Costing v8

Posted: 01 Apr 2015, 16:29
by brucedenney
Sorry, I meant the DNS and DHCP servers not the gateway!

The command

Code: Select all

IPCONFIG / ALL
at an administrative command prompt will list everything.

I am thinking all the little packets are dns requests going to the router asking it where the local server is and it, being a proxy to the internet, forwards them out and waits for replies that never come because the internet doesn't know jack bout your local server. Somehow windows works out DNS is not working and finds another way, but keeps trying DNS and failing so making everything slow.

You need the DNS server to be your Linux box and you need it to act as a proxy for DNS and as the DHCP server.

The reason for this is that the server can track where all resources are and clients can then use DNS to find any needed resource.

The DHCP server in the router needs to be disabled.

You need to be sure everything is properly configured for both IP4 and IP6

This might really be more of a Zentyal 4.0 / Networking support question, you might not be noticing it with other applications, but they will all be suffering.