Enable SQL Developer Edition to target specific SQL version
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.
Upvotes: 186<=-=Oct 7 2009 7:03AM=-=>
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).<=-=Oct 23 2009 6:13AM=-=>
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.<=-=Jan 28 2010 3:29AM=-=>
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?<=-=Jun 23 2011 2:43PM=-=>
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.
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.
Or, as someone suggested in another version of this request, provide us with a Developer Enterprise Edition, Developer Standard Edition, etc.<=-=May 20 2014 1:11PM=-=>
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.<=-=Nov 25 2014 4:05AM=-=>
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
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.<=-=Apr 11 2017 8:13AM=-=>
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.