Enable SQL Developer Edition to target specific SQL version - by Des Norton

Status : 


Sign in
to vote
ID 496380 Comments
Status Active Workarounds
Type Suggestion Repros 0
Opened 10/7/2009 5:56:51 AM
Duplicates 507277 Access Restriction Public


When developing using SQL Developer Edition (SSRE, SSIS, SSAS, SSRS), it is possible to use enterprise features (eg: Partitioning).  However, if the solution needs to be deployed to a customer with SQL Standard Edition, developers usually find out after the fact that the particular feature used is not supported by the destination Edition.
Sign in to post a comment.
Posted by Pedro Bonilla on 4/11/2017 at 8:13 AM
Having the same version of SQL Server in all environments is a MUST for doing the correct lifecycle.
If I have Standard in Prod, but then Developer (all Enterprise features), then that does not work. In Dev edition should be configurable the wished edition behavior.
Posted by Michael J. Swart on 6/14/2016 at 7:11 AM
We ran into a problem based on the different NOEXPAND behavior seen in Standard vs. Dev editions. Because we didn't catch it in Dev, the defect forced us to hotfix and re-release a version of our own software. So I know how much pain we felt that could have been avoided had we been able to develop in a "standard edition mode". I imagine that many clients continue to feel this pain as well.
Posted by Ian Bruyninckx on 11/25/2014 at 4:05 AM
I'd like to see build and deployment options for SQL versions (2012, 2014, ...) and for the editions on those database versions (SE, EE, ...)
That way, we can have one codebase and still target all combinations of the above
Posted by Bruno Martinez on 5/20/2014 at 1:11 PM
A subtle problem with using the Developer Edition but deploying to Standard Edition is that the former will automatically use indexed view but the latter needs noexpand hints. No target platform in SSDT will catch this.
Posted by Sscottt on 5/3/2013 at 6:30 AM
Or, as someone suggested in another version of this request, provide us with a Developer Enterprise Edition, Developer Standard Edition, etc.
Posted by Microsoft on 7/12/2011 at 2:34 PM
While you can target SQL platforms in SSDT projects, we don't currently have a feature to target a given SKU. This is feature is on our radar and in our future plans. Thanks for letting us know that this is an important scenario.

Janet Yeilding
Posted by Microsoft on 6/23/2011 at 2:43 PM
Apologies for the delayed response!

SQL Server Developer Tools allows you to change the target platform of a project to different versions of SQL via the Project Properties. SSDT will then provide platform-specific validation while you edit your script. Depending on the target platform specified, SSDT will catch any error caused by illegal syntax for that specific SQL platform.

Thanks for your feedback and interest in the product.

Janet Yeilding
Posted by Stan Segers on 1/28/2010 at 3:29 AM
Is it legal to acquire a Developer Edition license for a development system, but install a Standard or Workgroup Edition for non-production usage only, in order to prevent usage of higher Edition features?
Posted by Phil Brammer on 10/23/2009 at 6:13 AM
I think this is important, yes, but I'm unsure how well such a feature could be implemented in disconnected tools such as SSIS. Given that the dev teams work almost independently, I'm not sure how the SSIS team could know and keep track of which SQL Server features belong to which edition. Nevermind the ability for users to use custom SQL in something like an Execute SQL Task that SSIS surely couldn't validate at design time.
Posted by AaronBertrand on 10/7/2009 at 7:03 AM
I think it could be even deeper down, because not everybody develops using BIDS or Visual Studio or the UI. If I run an Enterprise-only statement in a query window, I should be able to see an attention event, or something similar to the deprecation warning, when using features that don't run on the target you've specified. When I know I am targeting standard or lower, I can simply check for that event. Much simpler than reviewing all of the features and code against some checklist. This could be set at the database level and/or server level, so that you can be working on multiple dev databases at the same time, potentially with one targeting express and one targeting standard... then an event would be raised if, for example, you used CREATE PARTITION SCHEME. But you'd also want to catch server-level things (e.g. BACKUP DATABASE ... WITH COMPRESSION).