Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Great Plains - app server and db server

Status
Not open for further replies.

beleyrs

IS-IT--Management
Nov 22, 2004
28
0
0
US
Hi,
We are looking to move our great plains application to a new group in our company for support. they use a model of application server talks to database server. clients connect to the application server and the database stays hidden.

Can this model work for Great Plains? Is anyone using this type of model? Our curren model has GP running on teh same server where the SQL Server database resides.

Thanks for any insight!

RB
 
We use this model. We host Great Plains on some Windows 2003 Terminal Servers, and use ODBC to connect Great Plains to a separate MS SQL 2000 Server.
 
Thanks MLandin.

If you don't mind me asking, do you have a large user base? About how many users do you have connecting?
 
We have 100 users worldwide, with a max of 45 concurrent users (although we are about to add a handful more). I don't know if you would call that "large" or not. We are only running Financials, Collection Management, and a third-party service management add-on.

Certainly, I would think a shared app / db server would only work in very small environments.
 
We are using almost the same model as MLandin but are using citrix with about 500 users and 75 concurrent licenses. We are using 3 citrix machines for our app server. We are possibly looking to use SMS to push out the app to all of the users desktop.
 
We are running Citrix on our 2 Terminal Servers also.

Why are you thinking about doing desktop access instead of the thin-client model?

One of the reasons we went thin is because we have users on the other side of the Atlantic, but the databases are here in the States. Supporting Citrix traffic over the WAN is a lot less painful than actually supporting the full application over a LAN.
 
If you have 500 users, I wouldn't even think about deploying Great Plains to everyone. We have 30 users with only 10 concurrent, everyone is in the same building, and the app is installed on everyone's desktop. Automating the deployment is a hassle every time we do an upgrade - 6.0 to 7.0 was especially problematic. Packaging and deploying the 7.5 upgrade was much easier but still took quite a bit of testing.
 
We are using Citrix on 2 servers and have 23 concurrent users. We're experiencing performance issues within Great Plains. Smartlist reports are hanging up other users in the app. Any suggestions?
 
We have 200+ users, 50 concurrent licenses and had used full capacity. We're adding 10-20 licenses more this year. We've changed our environment a few times to test which one works for us and finally found our current the best. HQ with 60 users and 35 GP concurrent users are all in a Terminal Server while the remote locations all go to our network through Citrix Nfuse. We have a separate SQL Server running Windows Server 2003 on HP DL380 Raid 5. Our only issue right now is printing which we're testing tricerat's simplified printing.

Smartlist is processing-intensive. Try to open Performance in Administrative Tools then Aad %Processor Time, you'll see your a spike when you run Smartlist. I always advise users to run Smartlist when its really necessary.
 
We have 200+ users, 50 concurrent licenses and had used full capacity. We're adding 10-20 licenses more this year. We've changed our environment a few times to test which one works for us and finally found our current the best. HQ with 60 users and 35 GP concurrent users are all in a Terminal Server while the remote locations all go to our network through Citrix Nfuse. We have a separate SQL Server running Windows Server 2003 on HP DL380 Raid 5. Our only issue right now is printing which we're testing tricerat's simplified printing.

Smartlist is processing-intensive. Try to open Performance in Administrative Tools then add %Processor Time, you'll see your a spike when you run Smartlist. I always advise users to run Smartlist when its really necessary. If you're using a single-processor server try to add another processor.
 
Simplify Printing is good. It's light-years better than standard Citrix / TS printing. No more drivers to install on servers, etc. They also have a blacklisting feature that's handy, to prevent known "bad" printers from being created. We've used it since Day 1 of Great Plains and have never regretted it!
 
We use uniprint ( for our printing on citrix. We have 6 citrix servers and have found 99% of our printing issue disappear. GP in newer version converted most of its reports to graphical, so printing these from remote locations took forever (some of the print jobs were over 10mb and higher in size). Uniprint converts all print jobs to a compressed pdf and prints to the local printer, using the local printer's driver. It also has a nice preview screen where you can save or email anything you print (anything).

Smartlist takes forever to open in our environment. So does logging into a company. I have no problem with these on my local installation on xp. Even with no users connected to a dual P4 1.4Ghz citrix server with over 1Gb of RAM, it still hangs in Smartlist and logging in.

GP is not designed to run in a citrix/terminal server. I have spent hours with technical support trying to fix a performance issue with project accounting and found out that much of GP's processing happens in local temp directories on the local hard drive instead of sending sql queries to the server as it should. A client should not have to be a power house to run an application whose backend is sql. The server should be the power house as that is where the processing should occur.
 
We used to have issues logging into Citrix and GP which took forever in the morning because 60% of the users login at the same time. We played a lot of scenarios with user profiles and found roaming profile was causing the delays. This would be on a case-to-case basis so it might not work for others.

I found that using Anyview objects was better than using the standard objects in Smartlist. I recreated all the objects and since then had been using them instead. I did some benchmarking with the same objects and tables(example, Sales Transactions) and saw tremendous improvement on our servers.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top