I have ACT! 2008 Premium (10.01). My database contains 40000 contact's records and 1000 company's records. I need to wait 6-8 seconds for Company layout every time when I click company name field in the Contact layout.
I use really good computers and network for ACT! (Pentium Core Duo with 4 Gb of RAM as a server, and Pentium CORE Duo with 2 Gb of RAM as a workstations, LAN speed is 100 Mbit/sec).
I know that ACTDIAG uility has a set of SQL parameters. Anybody knows which parameters can help me to increase the speed of changing layouts?
We're having a similar problem as the original post. We just upgraded from ACT 9 Premium Workgroup EX -to- ACT 10 Premium Workgroup ST. Our users are experienceing an 8 or so second delay when pulling up task lists, or generally any activity that appears to query the database, or save entered data.
Our server is a Dell Poweredge 2800, 2.8Ghz Zeon, 4GB RAM, 3-drive SCSI Raid 5 array. The CPU (with 20 simultaneous users) floats around 2-4% utilization. Network utilization is under 1%. We have a brand new gigabit network with CAT6 wiring.
Our workstations are Dell Optiplex machines with 2.8 ` 3.0 Ghz, 512MB to 1GB Ram.. Running Peachtree accounting, ACT, Outlook, and Excel simultaneously.
We have 3 company databases open in ACT. The largest has 14000 customer records.
I'm wondering what is causing this delay at the client workstations as it's affecting our productivity as a call center.
I've changed the Memory Usage Performance setting on the server (Windows 2003 STD) to "System Cache". That didn't appear to help much, if any.
SQL is using around 1.6GB Ram on the Server. There is 1.8GB Ram free. We have two page files (1 fixed on C: drive, the other dymamic on the D: drive). Both partitions are on the Raid 5 array.
On at least one workstation, I'm witttnessing ACTSage.exe consume memory without releasing it. I've seen it use 472 MB Ram at one time and the workstation was literally crawling. Rebooting cleared that up but it appears to progressively get slower throughout the day.. I checked the workstation 30 mins ago and ACTSage was using 140MB, it is now 236MB.
Theoretically I think 1 would be the "fastest" value as 0 indicates to ignore pre-loading.
Regardless, I didn't think this would help as it should only apply to first load (i.e. if it was slow for you on FIRST load then fast after that, lowering this value to 10 or so might have helped). This value indicates how many seconds after contact-detail view is loaded to wait until background-loading the particular view.
Both your issue and the new issue posted on this thread seem to revolve around large databases (although not all that large). I assume you can both verify that if you use a small/example database the performance problems do not manifest? How about using the demo database?
Bryan, can you narrow your issue down any further, perhaps to specific areas within ACT!? For instance it sounds like Vad's problem revolves around the Company view loading.
Of course getting to at least 1GB RAM on your client machines should help, especially when running other programs. It does sound like your problem is on the client rather than the server.
Also be sure to upgrade to 10.02 which will be available very soon... it should have some performance improvements.
We currently have a Certified ACT Consultant here working with Tech Support (1st level so far).
We've tried copying the DB to the local PC - same problem. The tech support engineer tried the ACT Demo DB - same problem. We've removed ACT, SQL, and .NET (all versions) and now ACT won't reinstall. Error 1935 during setup.
I agree that it looks like a client issue. We're experiencing the problem on machines with 512MB and 1GB Ram.. Nevertheless we have already ordered ram upgrades to bring all workstations up to 1GB.
We're running 10.0.1.199 on all machines. Windows XP Pro SP2, all security updates applied. CA Anti-virus, and Peachtree pervasive DB engine on the clients. These machines are very clean overall.
The total of all databases is about 800MB.
I'm concerned about the growing memory footprint of ACTSage.exe. It continues to grow with time. It's symptomatic of some process failing and not releasing memory therefore increasing the memory consumption. I suspect this has something to do with the performance issues. I'm wondering if the outlook link is contributing to this.. We have Office Pro 2003. Our users are't using the ACt/Outlook connectivity, except one who is experiencing the greatest growth of ACTSage.exe memory consumption. The ACT Outlook service is running on all machines, including the server which doesn't even have Office installed.
We've got a definate problem here and it's specific to ACT 10. ACT 9 performed much better. There aren't any other changes to the system except the upgrade to ACT 10.
It seems that the performance issues may be centered around activities scheduling and listing. Viewing the activities list, then adding activities from other users to the list increases the ACTSage.exe file by 100MB..(it's about 4000 activities overall). Subsequently removing those user's activities from the list does not reclaim that memory.. ACTSage.exe remains 100MB larger and does not decrease. It appears that the exe isn't releasing memory properly.
Entering a followup to an activity causes a wait of 8-10 seconds.
Then restart ACT!, wait for the problem, close ACT! (let actlog.xml update for a few seconds) then check the log. Of course a memory leak typically won't be logged ;-) but it may provide some insight as to what's happening.
Actlog.xml can be found at: C:\Documents and Settings\jason\Application Data\ACT\ACT for Windows 10.
Actsage.exe.config is at: c:\Program Files\ACT\ACT for Windows\
Regarding your new post... if you remove the activities and restart ACT! is the memory footprint back to "normal"? This would indeed point to a problem with activities in memory. Since it's not a known-issue I would think there might be a local fix, if only we could find it... ;-)
Another thing to test would be the fetchsize setting of the SmartList, also in actsage.exe.config (although I'm not sure if Activities use the SmartList).
<SmartList profile="static" fetchsize="50" cacheleasetime="900000" misspolicy="1" /> Experiment with the fetchsize setting. Decreasing the value from 50 might give you more paging, but faster initial load times.