Yes.  I believe it started with vs. 17.  They are aware but it took me a month and a half and over $1000 looking elsewhere for solutions to get them to acknowlege the problem is with the software and find a solution for us.  I believe they'll write a knowledgebase article soon.  Does TN.exe still exist in Vs. 18?

On 18.2.2 we see the same behavior when using Desktop. I can remember this occurring with 17.1 also.

This is happening to us also (18.2.2).  Launching the full module from desktop works fine, and launching tasks from the full module works fine as well.  Launching Tasks from Desktop is very slow for most, but not all modules (for some reason CM and GL work fine)  AP, AR, BL, EQ, JC, and PR are slow.

I found this same slow activity when I upgraded to 17.  I finally found that once you select a module and the drop down list appears.  Click on the very top item.  It is underlined with a square box and an upward pointing arrow in box.  This will take you back to the "old" familiar screen.  It behaves and moves at the same speed before upgrade.

Hi dfingliss,

We are actively looking in to this to try to find a solution. If you (or anyone else on the thread) would be willing to post the specifications of the workstation and/or server, that would assist us in our testing. Please include:

Processor

RAM

Hard disk type

Also these questions:

Does it happen to all users on all workstations?

Does it happen when logged in to the server as the domain admin and Sage admin?

Are you using Sage Replicator, Paperless, MyAssistant, Timberscan, or any other 3rd party applications that access Sage data?

Are you using Record security or File security in Security Administration?

Thanks!

We have the same hardware and environment we had in Vs. 16.  We are not using Replicator, Paperless, My Assistant, Timberscan, and we even uninstalled the antivirus in a last ditch effort.  It happens at all workstations.  It happens when logged into the server as the domain admin and the Sage admin.  Favorites works the way it should.  Desktop apps do not work the way they should.  The Desktop calls back to the Server when we try Application-Task or Application-Setup under the Application tab.  It does not call back to the server from Favorites. Over 5 support sessions, you have tried turning the Actian cache engine on and off to test.  You have tried reinstalling Actian twice.  You have suspected our OS, our antivirus, and our processor speed.  There's nothing wrong with us.  The problem is Desktop.  Mark Smethers found a work around for us through a registry edit which will work only for small networks.  I suggest you talk to Mark who understands the problem.  We look forward to you fixing the Desktop. 

Occurs on our server running version  Sage 300 CRE 18.2.2.

To note, as an example, after loading AP > Tasks one time this does not occur on immediate subsequent attempts to replicate the delay. This said, if I go away form the menu for 15 minutes I experience the same delay. (Memory?)

Server Specs are above recommendations, feel free to reach out for details.
Occurs to all users including Domain/Sage admins.
Occurs on workstations along with the application server.
Occurs in data folders where record security on and in data folders where record security is off.
Numerous 3rd party apps are installed, but do not appear to be bogging down the server. Yet to configure replicator with 18.2.2 and deal with the performance hit that may cause. Server memory and CPU is not maxing out.

Thank you for confirming that you are working on a solution. I've been waiting on a follow up call from a Sage manager since the end of December (still waiting) regarding this issue and, as some others have commented, have had numerous calls with Sage some of which tried to pawn off the behavior on the environment. As part of the suggested troubleshooting from Sage I even installed 18.2 on a standalone machine (a graphics powerhouse we have in house) and the behavior was the same on a fresh install with Sage sample data.

Intel XEON E5-2680 2.4ghz (2 processors)

24GB

SSD

All users work with Sage either via remoteapp connection or open it directly on the server through RDP connection. Behavior occurs for all users, domain admins, and Sage admins.

We are not using Sage Replicator, Paperless, MyAssistant, Timberscan, or any 3rd party apps that access Sage data.

We do use record security to restrict user access by job.

Would you share the workaround?

Hello again everyone!

Here is the current solution we're testing. Let me know if you try it and what the results are. Please include load times prior to and after implementing the fix. The solution is implemented on the workstation so you can test with just one or two for now to see how it works for you.

On the workstation (logged in to the workstation using the Sage user's windows credentials):

1. Close all Sage applications
2. Open the Windows Registry editor (regedit)
3. Browse to HKEY_CURRENT_USER\Software\Timberline\Desktop
4. Right-click on Desktop and select New String Value
5. Enter "UpdateTaskInformationFileIntervalInMinutes" and press ENTER.
6. Right-click on Desktop again and select New String Value
7. Enter "UseTaskInformationFile" and press Enter.
8. Double click the new string values and enter "1" in the Value Data field for both of them.

This will create a file in the workstation that is accessed when you launch Sage Desktop. Note that it can take up to 5 minutes for the file to be created.

Thanks!

This is the fix we applied days ago.  Mark said it's only good for approximately 15 workstations or less and that a larger network would create havoc so I'm mentioning this, too.  It fixed the problem we were experiencing so that the load times are nearly instantaneous. 

However we are still having problems on two workstations that are a little different.  This is new:  One is Windows 10 and today, just starting Sage, before the log on, Sage was "not responding" (and it loaded fine yesterday). 

This is since Vs 17 install November 2018:.  Another, Windows 7, has problems where the "log in" box is greyed out and unavailable repeatedly.  In both instances, we found restarting the workstations remedied the problems. 

Jesse,

I am working in an environment with a large number of client machines, just wondering if there is something I need to be aware of based on this statement from Rhonda V: "This is the fix we applied days ago.  Mark said it's only good for approximately 15 workstations or less and that a larger network would create havoc so I'm mentioning this, too.  It fixed the problem we were experiencing so that the load times are nearly instantaneous."

Do you by chance have any details on what is being referenced? I would like to start applying this through our network.

Thanks.

I'm referencing the regedit that Jesse Gordon has given above.  Mark (Sage Senior Analyst) gave me the same registry edit to apply.  But Mark also said it would cause havoc if larger networks (more than approximately 15 workstations) applied this fix.  I was surprised that Jesse Gordon posted this because I thought doing so could be dangerous for some.  This is why I mentioned Mark's statement about larger nettworks because it might be important.