Difference in using SQL Standard Edition and Enterprise Edition for EPM

[Sumit]

Can someone please provide info or document on what would be the difference if we deploy EPM 2002 or 2003 on MS SQL Server 2000 Standard Edition Vs Enterprise Edition

I understand that its basically the difference of processors, memory, DB Size and so on but how does this affect EPM's functionality

We would use EPM for
1. Approx 20 avtive projects of avg 2 yr duratio
2. 80 users including 10 PMs with approx 10 concurrent users

Awaiting a prompt response

Regards
Sumit

 

[Microsoft News]

My advise would be to use EPM 2003. If you're only using SQL 2000 for EMP
then it doesn't make mutch diffrence using standard or enterprise SQL
Server. Especially not for the ammount of users you're talking about.

Though if you're using more applications and do some own development I would
advise you to take the enterprise edition.

Merijn

Can someone please provide info or document on what would be the

difference if we deploy EPM 2002 or 2003 on MS SQL Server 2000 Standard
Edition Vs Enterprise Edition.

I understand that its basically the difference of processors, memory, DB

Size and so on but how does this affect EPM's functionality.

 

[Sumit]

Dear Merijn

Thanks for your response

Currently we are using EPM 2002 with SQL Ent Edition (basically a pilot run)

Post pilot, we are planning to deploy SQL only for EPM, but is there any benchmark document which can specify the difference that might be there by using Std edition and Ent Edition

Also, could you elaborate as to why are you recommending to use EPM 2003? Ours is a functional organization where we are using EPM only for trakcing project's schedule. We have even not defined Skill or RBS, using it simply for schedule. Given the scenario would you still recommend 2003? If yes then why? Sorry for cross question but I need to be clear in my objective for using EPM 2003, right

Regards
Sumit.

 

[Merijn Boom]

Sumit,

I'm not sure about a bentch mark, you could look at the microsoft server
pages (http://www.microsoft.com/sql/techinfo/planning/SQLReskChooseEd.asp)
for detailed information about the diffrences between Standard and
Enterprise but you might have done it.

For our clients we mostly use the enterprise edition because we always try
to run mulitple databases on one server (read mostly need quite heavy
servers) and do some custom developing as well (one of our products only,
fully, runs with the enterpirse edition).

The reason why I would use 2003 is partly becasue STS are replaced with WSS
meaning that other problems you posted will be solved and that you're saver
for the future.

Regards,

Merijn

Dear Merijn,

Thanks for your response.

Currently we are using EPM 2002 with SQL Ent Edition (basically a pilot run).

Post pilot, we are planning to deploy SQL only for EPM, but is there any

benchmark document which can specify the difference that might be there by
using Std edition and Ent Edition?

Also, could you elaborate as to why are you recommending to use EPM 2003?

Ours is a functional organization where we are using EPM only for trakcing
project's schedule. We have even not defined Skill or RBS, using it simply
for schedule. Given the scenario would you still recommend 2003? If yes then
why? Sorry for cross question but I need to be clear in my objective for
using EPM 2003, right?

 

[Haitham Hijazi]

They both work fine with EPM, you do need the Ent version if you are
planning to expose the EPM server to the Internet. Exposing OALP data over
the Internet is only supported in the Ent version of SQL

Can someone please provide info or document on what would be the

difference if we deploy EPM 2002 or 2003 on MS SQL Server 2000 Standard
Edition Vs Enterprise Edition.

I understand that its basically the difference of processors, memory, DB

Size and so on but how does this affect EPM's functionality.

 

[Sumit]

Dear all

Thanks for the response. What I understand is that in case we need to make OLAP cube available online we need to go for EE else we can continue with Std Ed

Regards
Sumit.