AOSAdmin said:

Issue: when opening any of the Invoices, Sales, etc.. dialog windows (you know, those that typically have a light green or blue background color), you literally see how the window is painted and it takes 3-5 seconds to display all the buttons and fields.

In tests that I have done, when this is *very* slow, it can be due to:

 -  the delay between the client program requesting data, and the database delivering it (Invoice data is in dozens of tables, as are user preferences, etc).  It looks a lot like slow painting, but it can be slow data retrieval.

The database server cache should be larger than the 'company file' ('Memory buffer size (in MB) in the Connection Manager should be larger than the size showing in Help | About.  Data reads from RAM are faster than the best SSD.

There should be at least a 1 Gbit connection between the client (or terminal server) and the data server, if there's a cable between them.

 - The location of temp files  (i.e. are they on a local disk to the Sage 50 client software?  redirected folder?  Roaming profile?)

Lists are stored in Temp files, and they are accessed frequently on the Invoice screens.

 - Anti-Malware software that carefully scans database data that couldn't possibly contain a virus.

 - automatic defragmentation should be off for the database volume.  There's not much benefit to scanning a database.

 - Any software that synchronizes, backs up, monitors, or otherwise performs a lot of actions on the disk is suspect.  VSS should be disabled, since MySQL is not VSS-aware.

Is it really a lot slower on the terminal server, than from a workstation?  

Let's see:

1) All systems are running on the same server: users remote in to a server where Remote Desktop Services is installed, Sage and its database are there as well. I don't have multiple volumes on this server, everything is on the C drive. But again, on the other server with a similar setup and SSD disks, I do have different volumes and I have the same slowness

2) I don't have any antivirus system running on the server for now

After your suggestion, I'm increasing the memory buffer in the Conn Manag to 2048MB ... not sure if I have to restart the service though. 

The slowness we experience goes from 3-5 seconds every time a user opens one of those dialog windows (Invoices, Receipts, etc..). Even after you have the window loaded, if you click on the Maximize button, it takes time to "repaint" the window... and at the point, I would assume that the data had been already loaded. So there's something going on here. I mean, it's not suuuuper slow but we have other applications running on this server (Outlook, Excel, etc.) and none of them have this lag. 

Thanks

AOSAdmin said:

After your suggestion, I'm increasing the memory buffer in the Conn Manag to 2048MB ... not sure if I have to restart the service though. 

Yes.  the MySQL daemon needs to shut down completely.

AOSAdmin said:

The slowness we experience goes from 3-5 seconds every time a user opens one of those dialog windows (Invoices, Receipts, etc..). Even after you have the window loaded, if you click on the Maximize button, it takes time to "repaint" the window... and at the point, I would assume that the data had been already loaded

I get that same effect on this workstation, but I would say it's about twice that fast (M82 ThinkCentre with I5 proc.  Sage 50 stores monitor sizes and window positions for each (Sage 50) user, so it might be writing the 'restored' size to the database each time it's 'Maximized'.   Restoring the window seems instant, so that may get pulled from 'cache'.

I would assume that the data had been loaded too, but that might not be the case.  It's easy to measure data access on with a workstation by just graphing network activity.  On Terminal Server and / or in a VM it might be more of a challenge.

To work around the issue of screen load time, (when we were still using Pentium-IV workstations) we learned to use control-z to clear an invoice form and start a new invoice, rather than closing the one just looked up, and opening a new one each time.   We had a consultant look at it, but he went down a rabbit hole on video resolution, colour depth, and directX.  (Sage 50 doesn't use DirectX, and low resolution with less colour depth was slower as well as unreadable, so that didn't work at all)

AOSAdmin said:

So there's something going on here. I mean, it's not suuuuper slow but we have other applications running on this server (Outlook, Excel, etc.) and none of them have this lag.

Sage 50 is kind of special, sometimes.  It's a complicated application, and perhaps has some legacy code or frameworks that use older, slower API calls than a newly minted Microsoft application would have.

AOSAdmin said:

But again, on the other server with a similar setup and SSD disks, I do have different volumes and I have the same slowness

I like to take a 'divide and conquer' approach to narrow down problems like this - like an optometrist's "Which is clearer - A (click) or B?"   Slice off the chunks you don't need to look at.

Even if you only have access to Terminal Server to test with, and can't easily isolate a "client" vs "server" vs "terminal server" issue:

 - You could test 'disk access' by attaching a fast (USB 3.0) external drive.   (but I really doubt that the SSD is a bottleneck.)

 - You could test the company data and the user settings by opening the sample file that comes with Sage 50 (if it was installed).  If the screens in the sample file load noticeably faster, you would have eliminated the client software (i.e. loading a resource from a DLL) and the installation, as well as Terminal Server, as trouble points. 

If there is a large difference between the client's company file and the sample file, I would look at user settings, list sizes, temp files, etc.

Testing the company data on another system could give more feel as to how long certain things will take.   A minimum 'test harness' could be backing up to a network or USB, and installing / restoring on a laptop. 

I hope that helps, please post back!

For the benefit of anyone reading this, I'm not a Sage employee, and all responsibility for following any suggestion belongs entirely to the reader.  (as does the credit for anything that works!)

Hi Randy,

I tried all these stuff without luck. Even tried with Sage 2015.3 and the latest 2016.2, on 4 computers running Windows 2008 R2, Windows 7, Windows 8.1 and Windows 10, same thing. I've contacted Sage support and they are telling me, essentially, that they don't know what is going on.

Here's a video showing what's going on:

aoshield-my.sharepoint.com/.../guestaccess.aspx

The same goes if I tried opening an invoice, a receipt, etc. The issue is worse if the dialog window is opened in Maximize mode.

Let me know if there's anything else I could try. Sage support has been useless so far...

S.

AOSAdmin said:

Even tried with Sage 2015.3 and the latest 2016.2, on 4 computers running Windows 2008 R2, Windows 7, Windows 8.1 and Windows 10, same thing.

Even though you're testing from a Terminal Server to several different end clients, you're still testing the exact same thing.  Using roughly the same data, using two nearly identical software packages with the same test rig won't show where the problem is.

If the Terminal Server system is that slow, opening the sample file, the problem is in the system setup, and not the data or where it's stored.

If opening that company data from a decent laptop is slow, but opening the sample file is not slow, then there is a problem with the data. 

In my experience, the end user complaint of "It doesn't work and I tried all that Stuff" and the I.T / I.S. response of "It works fine on my machine" are equally unhelpful in getting to the root of the problem. 

If it helps to know, our system is faster than what I see in that video, using RDP over an internet connection that goes through two separate ISPs. 

One last time:

Have you tried opening the sample data, or not?  If installed, the filename of the sample company is 'universl.sai'.

What is the size of the file 'ibdata1' in the company data folder, or what is the data size showing in File | Properties?

Does it behave any differently when local vs terminal window.  

In the video, I would say that was taking 10 seconds or so to display.

Just did some testing from home, connecting via RDP to a Windows workstation that accesses data from a LAN server:

Opened the sample data - the window opens and displays in about 1 second.  This is a small file, loading from local disk.  Clicked the left and right arrows, no noticeable delay.

Opened a few invoices in a 'real' file by drill-down from the aged Payables report - again, about 1, definitely under two seconds.   This is an important test, since this file is more than 30 times larger than the sample data, and loads over a LAN from a server.

Tried going full screen (1920x1200) and noticed it was substantially slower.

Then tried clicking the arrows to scroll through the invoices for a customer - no noticeable delay in displaying the data, perhaps 1 second.  The resources for the form are not loaded from the DLL each time.

AOSAdmin, did you ever find a solution to this issue? I've scoured the internet for a solution and your post here was the best to articulate the issue. There are plenty of companies that have this issue but due to an inability to accurately communicate the issue on Sage forums in how Sage 50 'paints' the program on the screen, the response from others hasn't targeted the real issue. It's literally a 10 second wait as various windows, like quotes, stalls before it finishes putting itself on the screen. We see the outline of the window with white boxes but no text.
 
We had the issue with Sage 50 2016 and it seems the problem has carried into 2017.1.

Same as you we have a Windows 2012 R2 Remote Desktop Services (RDS aka Terminal Services) server hosting the data for our remote users on a high end server.

We even went so far as to stick a 10gbps (that's ten gig, not your standard gigabit) NIC in the server to communicate to a 10gbps workstation NIC and the issue is still grossly apparent via RDS. It seems the speed of the network has no effect on the quality of the experience.

We found that adjusting the report colors to 8-bit base colors slightly improves the experience but even that doesn't fix the heart of the issue - it seems Sage stalls in bringing up the invoice or quote windows, before it finishes drawing the screen.

Tried the following to no avail:
- Compatibility Mode for Windows 7 and also XP
- Reduced color mode to 8-bit
- Disable display scaling
- Upgraded to 10gbps network uplink

I have a feeling this is an inherent issue with Sage 50 on Windows RDS servers but if anyone googles this and later finds a solution, I'd love to hear it.

niagarasys said:

It's literally a 10 second wait as various windows, like quotes, stalls before it finishes putting itself on the screen.

Sage 50 seems to throw the screen up with the defaults, then redraw it in pieces as the bits and pieces are collected from the company database.

Could you please check whether there is / isn't a noticeable difference between the company's and the sample 'Universal Construction' data? 

niagarasys said:

If you have it at, say, reduced size of 1/4 of the screen it will come up fairly quick.

Makes sense, the more pixels the program has to paint / draw, the longer it takes to send each pixel.  Maybe the reason I've never seen this problem, is that I use windows 'restored' rather than 'maximized'.  

Because...  Windows... plural.  Otherwise it would have been called 'Slow DOS with Pretty Colours'.

Randy Wester

niagarasys said:

Telling users they need to run at 640 x 480 isn't going to fly.

I just did a quick copy/paste of my invoice screen into PAINT, it's at 1415 x 631 pixels, so about a third of the total dual monitor width x about half the height.  Works great remotely with one physical monitor at 1920x1280.  Unfortunately I didn't set it up so I can't tell you how it compares to another system.

niagarasys said:

many companies are going with a native for data + hyper-v for Sage 50 user sessions

Sage 50 was designed and built (and hopefully optimized) as a client/server program, but a quick Google search turned up resellers hosting it as SAAS.  They must have gotten it to work reasonably well without resorting to the Dark Arts and RAM drives.

I hear good things about 'seamless' RDS.  Does it work / act any differently?  

(I heard those good things from the same salesman that told us we couldn't have more than 5000 items in a SharePoint Online list because it was like a bus teetering on the edge of a cliff, and that Sage 50 didn't work with downloaded Office 365, we had to buy a dozen 'open license'  copies at $900 each and install from CD.  So really not sure if there's any difference in user experience)

niagarasys said:

Sure, you can work with a copy of the screen just fine;

What I meant, was that I used copy / paste in paint to measure the number of pixels, not that painting a bitmap is the same as refreshing a combobox, or that I could remotely copy / paste it quickly.

niagarasys said:

probably via gdiplus.dll.

There's a list of the DLLs used under Help | About | Support Info.  I would download the sysinternals suite and use DEPENDS, PROCEXP, and PROCMON to find out.

niagarasys said:

The issue isn't what's appearing on screen but rather how Sage50Accounting.exe is rendering the Revenue Journal on screen

Yes, I get that.  It's a mildly irritating 2-3 second wait on an I5 running client-server on a 1 GB network.  But there's no delay at all when running the sample data from the local hard drive. 

 If you can't make it better, sometimes knowing what makes it worse can help, so I continue with what you were doing - changing colour depth, throttling system resources, etc.    (and also slowing the network connection, restricting RAM, running from a copy of the data on a cheap memory stick, trying it with the antimalware temporarily disabled, that sort of thing.)  

Once I had enough data to narrow it right down, I would open a support case with Sage.  Just because they don't officially support that configuration doesn't mean they have no idea.  The SAAS providers probably aren't using a secret '-NoFunkyScreenRefresh' switch.

TheITCompany said:

Was there any further development on this issue?

As far as I know, there's never been any development at all, in the sense of someone at Sage looking into the issue. 

I've responded to a post on a terminal server issue where Sage 50 2017.2 on a Terminal Server would max one CPU and grind to a halt after file conversion.   The cause was Sage 50 looking for certain Crystal Reports registry keys at about a million queries per minute.  The hack fix is to add a bogus registry key to make the Sage 50 software stop looking.  A good fix might start with a nerf bat at the desk of the programmer.  Again, as I've said in other posts, I don't work for Sage and I don't have clients, but I do like solving interesting and difficult puzzles. 

TheITCompany said:

Having my users use small windows alleviates some of the issue

Not sure what you mean by 'small windows'.   If you mean 'restored' versus 'maximized', yes, the invoice screens seem to run faster if they're not Maximized, even when their size is adjusted to cover the whole screen.  I can't tell you why that is without a lot of testing and hacking.  And maybe not even then.

The invoice screens also don't make you wait to load them if they don't have to - the executable code that displays them stays in RAM, so closing the invoice screen to open another invoice is slower than using control-z to clear the window for the next entry, or than opening an Invoice or Order from a pick list, report, or search. 

As I said in another post, some people use one window at a time, with one program maximized over it, and while it does work, it can be inefficient on multiple levels.

TheITCompany said:

but this seems like a core Sage programming issue when it comes to video display...

Rather than access the data needed for an invoice screen into a temporary file or array, and THEN display it all at once, Sage 50 appears to paint the screen, then tell each component to refresh itself, which appears to cause a lot of screen updates.  There's almost certainly a better way, but Sage almost certainly won't rebuild it.

To reiterate some items from previous posts:

 - Use 'restored' windows, not maximized.  Drag the corners to the size you need.   Train your users, they may have learned 'computers' using a single web browser with obvious multiple tabs and do not 'grok' Windows' multiple screens and taskbar.

 - Work out how to keep the window open and change the data, rather than closing it.   The screen components in any software are loaded out of the executable file on disk, configured, and assembled before they can be displayed. 

 - Use whatever diagnostic tools you have to find limiting factors - i.e. is it the disk or RAM on the data server, the terminal server, do the terminal, application client, and data server 'share' disk, RAM and CPU and just fight over it in a virtual cage match with the Windows OS as the referee?  

 - Test with the Sage 50 Sample file and with your company data. 

 - Don't be like our previous I.T. guy and waste time messing with Terminal Server colour settings, video drivers, total window size, etc.

I hope that helps, to re-iterate I don't work for Sage so I have the opposite of a reason to make excuses. 

We have the same problem  on Remote Desk top.  At work we work from a server and my computer is about 2 seconds faster to open an invoice than a different employee.  Did anyone come up with a good solution to this?