July 2, 2013 at 10:23 am
Is it possible to restrict SQL Developer edition to only allow features in Standard edition? Our production environment is Standard Edition, and we are considering using Dev Edition in our dev environment due to the licensing, but we want to make sure whatever breaks in prod due to editions restrictions will break in dev.
July 2, 2013 at 10:30 am
no, but the features differences all really have to do with a lot of advanced things, that would never come up in basic development; they come up more along the lines support, like max memory/processor, high availability features, auditing features, and maintenance and support.
take a peek here, and see if any of the Standard items columns are things you think you'd be using during development.
http://msdn.microsoft.com/en-us/library/cc645993.aspx
Lowell
July 2, 2013 at 10:47 am
Lowell (7/2/2013)
no, but the features differences all really have to do with a lot of advanced things, that would never come up in basic development; they come up more along the lines support, like max memory/processor, high availability features, auditing features, and maintenance and support.take a peek here, and see if any of the Standard items columns are things you think you'd be using during development.
I work with a lot of developers that like to test the limits of things. It wouldn't surprise me if someone tried to use something like data compression
July 2, 2013 at 12:30 pm
Lowell (7/2/2013)
no, but the features differences all really have to do with a lot of advanced things, that would never come up in basic development; they come up more along the lines support, like max memory/processor, high availability features, auditing features, and maintenance and support.take a peek here, and see if any of the Standard items columns are things you think you'd be using during development.
Not all of the things that come along with Enterprise/Developer edition are things a developer needs to "develop" (star join optimizations for example). Others they may not know are not available in std ed. (partitioned tables). Some are administrative yet important (online index rebuild, TDE). Others no one uses anyway (MDS, DQS). 😎
I too think it would be nice to have a Dev edition that doesn't expose non-EE-only features, but we don't have that. So it is up to the OP to school the team on what isn't usable in production.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
July 2, 2013 at 1:06 pm
Gabriel P (7/2/2013)
I work with a lot of developers that like to test the limits of things. It wouldn't surprise me if someone tried to use something like data compression
Then set policy not to use the features, if they do they need to understand there are no circumstances that an upgrade to enterprise will be allowed. So when stuff breaks in testing it will be their problem to fix it. In other words more work for them and the likelihood of pushing project deadlines. That usually help police people..
CEWII
July 3, 2013 at 4:36 am
July 3, 2013 at 1:12 pm
Make sure that QA system is standard edition. Make sure that the development test system on which development integrates the various parts is standard edition.
Machines that developers develop on can be development edition: tell the developers they are not permitted to use EE features; after a few builds fail as soon as they get into integration and/or thrown out by QA they will obey the rule.
Tom
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply