August 15, 2018 at 8:18 am
Hi Experts,
I had a argument with my manager today and please correct me if i am wrong.We have SQL Developer edition in DEV and Standard Edition in Production.On production(standard edition)he ran a query which converts a varchar to int and the query was successfull.
He ran the same query on DEV(Developer edition) and returned errors. I am not an expert but as far as i know the data types and conversions works the same whether it's express,developer,standard or enterprise edition.He ordered me to remove Developer edition on DEV and put standard because there is no consistency between the two according to his knowledge.I argued that editions differ only on features not what he is thinking.
Am i wrong and please advise.
Thanks
T
August 15, 2018 at 8:22 am
You are right, standard and developer editions would not behave differently to each other.
What errors were returned on Developer?
Thanks
August 15, 2018 at 8:30 am
You are correct. The biggest differences between Dev and Standard are that Dev edition includes all the features of Enterprise edition. As far as datatypes, converting between, etc, it's all the same.
I'd suggest start with the basics:
Are your Dev and Standard editions on the same service pack and cumulative update?
Verify that the query run was *exactly* the same on both.
Verify that the data the query is being run against is exactly the same.
I'd likely lean towards there being a difference in the data, possibly a non-numeric character in the data in Dev somewhere, it could be something as simple as a "tab" character on the end of the string (or the beginning.) It wouldn't be easily noticeable in a plain select Try it! Run this:select '1234'
and tell me if you can spot the tabs at the beginning and end of the line. Yet if you wrap it in a "convert(int,' 1234')" it *WILL* fail with a "Conversion failed..." message.
August 15, 2018 at 8:38 am
NorthernSoul - Wednesday, August 15, 2018 8:22 AMYou are right, standard and developer editions would not behave differently to each other.
What errors were returned on Developer?Thanks
Yup...sounds like it could be a PEBCAK issue as opposed to a SQL Server edition issue.
I'd love to know what the error was as well.
Sue
August 15, 2018 at 8:54 am
One more vote to a data problem. If you're on the correct version of SQL Server, you could do something like this to find the problem.
SELECT *
FROM MyTable
WHERE TRY_CAST( SomeStringColumn AS int) IS NULL;
August 15, 2018 at 10:23 am
Keep in mind that dev edition is free for non-production databases.
If you install standard you'll have to pay regular MS licence costs.
Other than that, of course SQL functions exactly the same between versions. Your issue is the underlying data, an improper query and as is often the case, the users.
August 15, 2018 at 11:14 am
Legion51 - Wednesday, August 15, 2018 10:23 AMKeep in mind that dev edition is free for non-production databases.
If you install standard you'll have to pay regular MS licence costs.Other than that, of course SQL functions exactly the same between versions. Your issue is the underlying data, an improper query and as is often the case, the users.
Not 100% accurate, there are a lot of "it depends" here.
The problem with using developer edition in dev, and standard in prod, is that there are features available in developer that are not available in standard. The risk is if a developer implements code using an enterprise level feature, and attempts to deploy it to production.
The nature of the development environment determines if there are licensing costs involved. I have received different answers from Microsoft regarding licensing for development environments. As an example, at a previous position, clients would access the development environment to "try out new stuff". This needed to be licensed.
In my current position, the dev environment matches the rest of the stack. Some of the apps have standard edition installed in dev. No licensing needed.
Licensing is complicated. Ask a professional!
But installing developer edition in the dev environment does not mean no license fees. Just like installing standard in development does not mean you must pay license fees.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
August 15, 2018 at 1:10 pm
If you have suitable licensing in place, I'd definitely recommend running the same edition in your development environment that you run in production. Even with 2016 SP1+ (where many of the language feature availability issues go away) it's still a little too easy to produce a solution that will only work on Enterprise edition and it's not a good idea to find that out on a go-live day.
December 29, 2018 at 8:04 am
Michael L John - Wednesday, August 15, 2018 11:14 AMLegion51 - Wednesday, August 15, 2018 10:23 AMKeep in mind that dev edition is free for non-production databases.
If you install standard you'll have to pay regular MS licence costs.Other than that, of course SQL functions exactly the same between versions. Your issue is the underlying data, an improper query and as is often the case, the users.
Not 100% accurate, there are a lot of "it depends" here.
The problem with using developer edition in dev, and standard in prod, is that there are features available in developer that are not available in standard. The risk is if a developer implements code using an enterprise level feature, and attempts to deploy it to production.
The nature of the development environment determines if there are licensing costs involved. I have received different answers from Microsoft regarding licensing for development environments. As an example, at a previous position, clients would access the development environment to "try out new stuff". This needed to be licensed.
In my current position, the dev environment matches the rest of the stack. Some of the apps have standard edition installed in dev. No licensing needed.
Licensing is complicated. Ask a professional!
But installing developer edition in the dev environment does not mean no license fees. Just like installing standard in development does not mean you must pay license fees.
I would be interested to know more about running Standard Edition in DEV - and not paying a license fee.
As it is, I have been having ongoing discussions about the use of Development Edition in place of Standard in DEV as my understanding
was the same as posted by Legion51 (based on previous discussions on here).
Thanks
Steve O.
December 29, 2018 at 10:53 am
SteveOC - Saturday, December 29, 2018 8:04 AMMichael L John - Wednesday, August 15, 2018 11:14 AMLegion51 - Wednesday, August 15, 2018 10:23 AMKeep in mind that dev edition is free for non-production databases.
If you install standard you'll have to pay regular MS licence costs.Other than that, of course SQL functions exactly the same between versions. Your issue is the underlying data, an improper query and as is often the case, the users.
Not 100% accurate, there are a lot of "it depends" here.
The problem with using developer edition in dev, and standard in prod, is that there are features available in developer that are not available in standard. The risk is if a developer implements code using an enterprise level feature, and attempts to deploy it to production.
The nature of the development environment determines if there are licensing costs involved. I have received different answers from Microsoft regarding licensing for development environments. As an example, at a previous position, clients would access the development environment to "try out new stuff". This needed to be licensed.
In my current position, the dev environment matches the rest of the stack. Some of the apps have standard edition installed in dev. No licensing needed.
Licensing is complicated. Ask a professional!
But installing developer edition in the dev environment does not mean no license fees. Just like installing standard in development does not mean you must pay license fees.I would be interested to know more about running Standard Edition in DEV - and not paying a license fee.
As it is, I have been having ongoing discussions about the use of Development Edition in place of Standard in DEV as my understanding
was the same as posted by Legion51 (based on previous discussions on here).
Thanks
Steve O.
It is possible to use standard ed in dev if it is licensed under MSDN - it does imply, amongst other things that every single individual accessing a MSDN SQL instance also has a MSDN license.
If using a MSDN license on a VM it has far reaching implications and as such is not advisable and only option really is using the developer edition - or paying for a standard ed instead.
Since SQL 2016 SP1 there is little need not to use developer edition in dev as all major coding aspects that could cause issues while moving to prod are gone.
December 29, 2018 at 3:00 pm
frederico_fonseca - Saturday, December 29, 2018 10:53 AMSteveOC - Saturday, December 29, 2018 8:04 AMMichael L John - Wednesday, August 15, 2018 11:14 AMLegion51 - Wednesday, August 15, 2018 10:23 AMKeep in mind that dev edition is free for non-production databases.
If you install standard you'll have to pay regular MS licence costs.Other than that, of course SQL functions exactly the same between versions. Your issue is the underlying data, an improper query and as is often the case, the users.
Not 100% accurate, there are a lot of "it depends" here.
The problem with using developer edition in dev, and standard in prod, is that there are features available in developer that are not available in standard. The risk is if a developer implements code using an enterprise level feature, and attempts to deploy it to production.
The nature of the development environment determines if there are licensing costs involved. I have received different answers from Microsoft regarding licensing for development environments. As an example, at a previous position, clients would access the development environment to "try out new stuff". This needed to be licensed.
In my current position, the dev environment matches the rest of the stack. Some of the apps have standard edition installed in dev. No licensing needed.
Licensing is complicated. Ask a professional!
But installing developer edition in the dev environment does not mean no license fees. Just like installing standard in development does not mean you must pay license fees.I would be interested to know more about running Standard Edition in DEV - and not paying a license fee.
As it is, I have been having ongoing discussions about the use of Development Edition in place of Standard in DEV as my understanding
was the same as posted by Legion51 (based on previous discussions on here).
Thanks
Steve O.It is possible to use standard ed in dev if it is licensed under MSDN - it does imply, amongst other things that every single individual accessing a MSDN SQL instance also has a MSDN license.
If using a MSDN license on a VM it has far reaching implications and as such is not advisable and only option really is using the developer edition - or paying for a standard ed instead.
Since SQL 2016 SP1 there is little need not to use developer edition in dev as all major coding aspects that could cause issues while moving to prod are gone.
When I started in my current position 4 years ago, the entire organization was running enterprise edition on every server, regardless of environment.
There was no reason for enterprise, the previous DBA thought that you had to have enterprise to do active-passive clustering.
We have a written email/memo from Microsoft that says we do not need to license any of our non-production environments. This was in direct conflict with the written set of licensing I had, again from Microsoft, at the position I had left.
The fundamental difference was that the end-users did UAT, QA, and just plain old digging around in the non-production environments. Every server had standard edition installed in all environments.
Our EA is under negotiation again, and we again MS has said we do not need to license the non-prod environments.
I have some dev/stg/qa servers running standard, and others running developer. The non-prod boxes running developer edition correspond with the production servers that are running enterprise edition.
All the developers, as well as the QA folks, are covered in the EA with MSDN.
Comparing the 2 companies, the primary difference was that end-users accessed the non-prod environments, and that all of the developers were not covered under the EA. They purchased separate MSDN subscriptions.
The short answer is to talk to Microsoft to get the answer that applies to your specific case.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply