Sage 100

MAS 200 Install v44 - 30 Users - Run as a service or as application?

We've had better luck as an application. Running as a service, you run into the 100+ processes and lockups. (Unless you change the heap stack.)

My vote would be application with over 15 users.

Application unless you bill hourly

Amazing that with as many installs in the field that the default settings are expanded to run more efficiently.

@JeffSchwenk - I'm the majority contributor of the KB for the heap size settings. It isn't automatically adjusted for you because doing so can potentially have negative undesired affects on the whole operating system. Back in the day of NT4 Server and early Server 2003, setting the Services heap size too high could stop Task Scheduler and some other built-in Windows apps and services from running. That's why you have to set the initial value and then ""tune"" it. And the initial value you set (2nd or 3rd setting) depends on whether you run as an App or Service. I suppose the Sage 100 Advanced (hah) installer could ask you about how to set it.. Going back to your question, for 30-users I definitely vote for running it as a desktop app, based on experience from many cases. Also based on technical reasons related to the MAS and ProvideX software architecture.

@AlnoorCassim - One final question - Does the following have any impact? Or do we just put the desktop application in the startup folder? The moral of the story is in Version 4.x MAS 200, for the App Server service (or App Server desktop application) use a Domain account that is part of the Local Administrators group to ensure your best chances of success (and this login cannot be a service account only).

No the moral does not have any impact on that.

What are people doing with the Crystal ODBC Server side driver? Setting it up to run on the server. Not messing with it unless reports run extremely slow? Should this be configured as a service or run as an application also?

For the ProvideX IO service (CS ODBC service) in terms of configuration: * It has to be setup to run on the MAS server * Okay to run as a service. Initially start is as an app to work out the setup kinks you will certainly run into, then change it to service. * Okay to use LocalSystem account on the service. About the why - various reasons: * To run extremely slow reports as you mentioned * To run regular non-slow forms/reports from remote sites running over VPN or any kind of slower connection * To run it in the main office (not remotely) but turn it on only for users that run the slow reports. In 1 case, it was for the user that ran a lot of BIE views (it uses ODBC too). In another just for the FRx users (created a silent connect System DSN using CS ODBC) and pointed FRx to that. All the discussion in the past of using Access PTQs and other forms of optimization are still applicable.