General - GDR, SP, CU

What's the difference in a GDR, a Cumulative Update, CTP, RC, and a Service Pack?

CTP:
Microsoft changed the terminology for SQL Server pre-releases.
They are now referred to as CTPs (Community Technology Previews).

RC:
As the product enters it's final stages before release, the feature set is complete and the product is undergoing final testing, it's called an RC (Release Candidate).

GA:
After a product has undergone significant testing and it's determined that no more changes will be made to the product before release, it's sometimes said that the product has gone golden. It's also called a GA (General Availability) release.

RTM:
Once the bits been turned over to a company to mass produce the media (CDs, DVDs, etc), it's RTM'd (Released To Manufacturing).

GDR:
Over time, Hot Fixes are created by the dev team to address specific product issues affecting certain customers. Sometimes the issue is so wide spread, a GDR (General Distribution Release) is issued so that all customers will receive the updates.


CU:
CU (Cumulative Update) is created that contains all of the applicable hot fixes.

SP:
Once a large enough collection of changes have been gathered, an SP (Service Pack) will be issued.

Latest:

An Incremental Servicing Model is available from the SQL Server team to deliver hotfixes for reported problems:

https://support.microsoft.com/en-us/help/935897/an-incremental-servicing-model-is-available-from-the-sql-server-team-t

Going ahead we need to apply only CU to SQL Server to bring the system into servicing support cycle.

More On:  https://blogs.msdn.microsoft.com/sqlreleaseservices/announcing-the-modern-servicing-model-for-sql-server/

https://blogs.msdn.microsoft.com/sqlreleaseservices/announcing-updates-to-the-sql-server-incremental-servicing-model-ism/

EXECUTE permission was denied on the object 'sp_enable_sql_debug'

The SQL code was failing for one DB User with DBO permissions on the databases it was accessing. 

Problem: There was one stored procedure under database DB1 at some point it used to call other stored procedures from DB2. This caused failure when tried to analyse the issue using DEBUG method.

SOLUTION: Its fixed for us by doing following changes at code and DB level.

Code Level:

11)      Impersonate method

·         With execute as [login]

·         Execute as login=[login name]

22)      Fully qualified database object names

Administration Side:

11)     Grant user granted public role on master to read objects.

22)      Granting View Server State at instance level.