05-15-2012 07:07 AM - edited 05-15-2012 10:48 AM
One of my computers suddenly began to respond exceedingly slowly to all commands--so slowly in fact that it became disfunctional. After some research, I determined that the problem is that a service called Act.Service.host was eating hitting my hard disk more than all other programs combined and, together with the SQL server was using up virtually all of my 6 gigs of RAM. This happened even though I hadn't even started my Act Pro since the last time the computer started up.
I was able to address the problem temporarily by going into MSCONFIG and stopping the service from starting.
But, since I use Act, I need a better solution.
What should I do?
05-16-2012 07:36 AM
Background: 'Act.Server.host.exe' is the service supporting the Universal Search feature (Search option in upper right hand corner of Sage ACT!).
How large is your attachments folder?
And how many files does the folder contain?
Since you state that this 'suddenly began', you may want to try deleting the existing idex files for the service and then have ACT! recreate them. Here is an article that will show the location and folder to delete: KB Article 28454.
Starting the service and then opening the database will initiate the recreation of the folder. You may want to wait until you are leaving for lunch or done for the day before starting this process.
05-16-2012 10:38 AM - edited 05-16-2012 10:41 AM
Thanks for your answer. I think I may have identified the problem. Let me take a moment and explain. I discovered in the Knowledgebase that the the Act Server Host service has something to do with syncing databases.
That gave me a clue as I have had a lot of trouble with syncing because the sync process would say that all 2500 records had to be synced when in fact I had only changed a handful. As part of the procedure of debugging this issue, I would create a new client database and then unpack and restore it on the impacted computer. (I eventually learned that guilty culprit was the Connect routine, which reset the sync. When I uninstalled that routine, the problem disappeared.)
However, since I did not bother to uninstall or detach those other databases, I had about 7 attached databases. I hypothesized that, maybe, as long as they are attached, they keep using the SQL server and the Act Service Host. This morning, I tried detaching them, and that seemed to help, although I didn't have much time to check this out it before I went for the office. I'll post more here if I learn more or discover that detaching the old databases did not solve the problem.
05-16-2012 12:24 PM
05-17-2012 06:36 AM
Just confirm that detaching the databases did solve the problem. I think this might be worthy of a short Knowledgebase article as my computer was completely disabled to the point where I feared that I would have to do a complete reinstall.
05-17-2012 09:39 AM
My guess is that good Act practice should include detaching/deleting all unusued databases as we now understand that any attached database will degregate computer performance, paticularly since there is no real downside to merely detaching them, as reattaching them is a trivial exercise.
06-27-2013 09:41 AM
Hi Greg and contributors,
I know it is a while since this has been discussed, but I wanted to ask the following:
Providing we do not use Universal Search, is there any reason we cannot or should not turn off the Act.Server.Host service on the Server?
Having this on has made our server unusable in terms of memory eating etc. as per other contributors - turning it off as a service is literally the only thing that has stopped the issue.
For clarity - is Universal Search all that the Act Service Host/ Act.server.host.exe runs?
ACT seems to be working perfectly well without this service switched on and I hope I can keep it like this...
06-27-2013 10:18 AM
You are correct. It probably doesn't matter. But more fundamentally, the correct solution is to go in to Actdiag and unattach any databases that you are not using. It's easy to do and really does speed up performance dramatically, which is what you need.
06-27-2013 12:26 PM