Activesearch on a network machine

[insomnai]

Hi, we're running Sage Accounts 50 2012 with the latest updates on all of the machines. We have a Windows 7 Pro 64bit system running a quad core processor, 8gb of ram, always maintained and updated, and restarted every 24 hours so that the machine isn't ever bogged down.

After that, we have 6 satellite systems connecting to the main 'server/network share' for it's database information. These are also Windows 7 Professional 64bit systems.

Running on a gigabit network through a gigabit switch, each of the machines are connected to the switch using cat6 cabling which is monitored for issues.

OK, here lies the problem.

When running the database locally, sage runs super quick. Activesearch runs fine, using what is being typed as filter etc and we can whittle through data input very quickly.

Using one of the networked machines, using 'sales order list' and creating a new order, activesearch locks sage up for up to 30 seconds, it varies, but at any one time there can be up to 6 machines connected to sage at this point which suffer from the same issue. When we turn the option off in the 'parameters' section, it runs normally, but the users prefer to have activesearch running as it is helpful.

These systems have been run in safe mode with networking and there is no difference in the locking up.

Sage have a habit of blaming the machines, but after following ALL of there tech advice, there is absolutely no evidence that there is an issue with the machines. Which I fully doubt in either case as every other network based program runs absolutely fine.

Can anyone shed some light on this? A registry fix that might have been overlooked? A hidden beta patch? Anything at all?

Antivirus is set to ignore sage completely, firewalls are open to allow the program to run, tcp connections have been increased and we've also tried running the machines in 'clean' mode so no other programs can interfere.

Cheers.

EDIT: today we noticed that even through there are only 30k quotes in the table, when we open the table, it searches through nearly 90k records. Our database was archived for year end today as part of the troubleshooting and again, no difference.

backing up, reindexing, compressing and reindexing again haven't helped either.

[brucedenney]

The bottleneck when running active search should be the network.

Can you confirm that whilst running the search the network activity is very high?

Can you do something such as copy a large file and see network max out?

the task manager network monitoring tool should be adequate for this.

[insomnai]

Hi, thanks for helping me confirming a suspicion. After another detailed check it turns out that one of the staff machines has a wireless connection (rather than the RJ45 which had been unplugged) which was running to the server via the 100mbps router that we have. This router is then connected to the gigabit switch which in turn connects to the 'server'.

So basically, the computer was running at a max of 100mbps connection to the 'server' and slowing a few things down.

After reinserting the cabling and giving activesearch another run for its money it seems to be working much faster with fewer lockups.

Amazingly there are still a number of lockups during tasks like quotation etc where everyone is stopped from working until the table has opened...

Thanks

[brucedenney]

So the problem was a hardware issue.
I would never run Sage on a wireless network, as well as being really slow it is very prone to corruption.

I would expect tables to only be locked momentarily.

It is generally either the the operating system that locks files for excessive periods or a copy of sage that has locked up on its PC.

I have seen a lot of locking issues in environments that have a mixture of SMB and SMB2 clients however as you have only Win7 on your system, that is only possible if the registry tweaks to disable SMB2 had been applied. The easy way to check SMB2 status and to switch it on and off is to use SMB2 Toggle Too form mikes tool set
http://www.symantec.com/connect/downloa ... s-tool-set

[insomnai]

Thanks for the reply, however, I must disagree with your statement that it is a hardware issue. As I have mentioned, every other network stored program works absolutely fine with zero hickups. Just Sage that has these issues.

The wireless router is dual band wireless N, with peripherals running on one side while data uses another, so N300 on each side. I know in reality that throughput on a wireless network can be reduced so real data transfer can be as little as 3.25MB per sec (or 4.5ish MB per sec if you reduce encryption) but even so, with the wifi card of the affected computer running an N series card also, the problem should not exist.

Yes, having access to the gigabit network has helped but it is still locking up. The SMB registry fix had also been done, it was advised during the nightmare that was Sage 50 2011.

We're currently looking at other avenues such as Terminal Server etc to rule out networking issues, but, let's be honest. Sage is a glorified database with lots of links into other databases. Nothing more. It absolutely shouldn't be causing me this much of a headache....

What to do next. Pulling my hair out.

[brucedenney]

The SMB2 Fix is not a fix.... It is only an issue in mixed environments. If you are now exclusively SMB2 and no longer have and SMB1 limited workstations running Sage 50 then SMB2 should be enabled on all workstations and the server in order to get best performance form your network.

A Terminal server with SSD's will fly compared to running Sage 50 over a network.

You are, welcome to disagree about the hardware issue. The program has a twentieth of the recommended bandwidth available to it, as a result goes 20 times slower. All applications have bottleneck in hardware at some point. Sage is known to have that bottleneck in networking, there is no secret about this.

Any other networked program of the sort that Sage 50 is, one that reads large flat files, will perform just as badly.

If you wanted a high volume, high performance accounting system, then selecting Sage 50 was an error, they should have gone for a product with an SQL database back end such as Sage 200, OpenERP etc.

[insomnai]

I appreciate your comments and your clear explanations, even as techies there are things we can miss and in this case, the wifi connection managed to elude me. Of course the RJ45 connection instantly gave us a speed boost

Just a shame that the program is hindered by something so trivial. (Plus i'm defensive/embarrassed due to missing that wifi connected system)

What is the performance boost when using something like Sage 200 rather than Sage 50? As you can appreciate that is a large smackdown to the wallet to move to this program.

Regards

[brucedenney]

I have no experiance of Sage 200, I only help people on Sage 50.

Sage 50 can work well in networked environments, however, there is no getting away from the fact that it is a network hungry beast.

Terminal servers are, I think, less expensive than Sage 200 (plus all the additional costs of training & support).

The main things with TS is to make sure the hardware is properly specified. You need more memory than you might think to run well. With SSD's it is blisteringly fast (even with Sage 50). There are issues with access rights if you do not set it up properly. There is now a citrix configuration utility. http://support.makingithappen.co.uk/dow ... tility.pdf to make this easier