Skip to content

breaking-changes-to-database-engine-features-in-sql-server-2017.md

Latest commit

 

History

History
47 lines (34 loc) · 3.93 KB

breaking-changes-to-database-engine-features-in-sql-server-2017.md

File metadata and controls

47 lines (34 loc) · 3.93 KB
title Database Engine: Breaking changes
titleSuffix SQL Server 2017
description Learn about changes that might break applications, scripts, or functionalities that are based on earlier versions of SQL Server.
author MikeRayMSFT
ms.author mikeray
ms.reviewer randolphwest
ms.date 07/25/2022
ms.prod sql
ms.prod_service high-availability
ms.technology release-landing
ms.topic conceptual
ms.custom seo-lt-2019
helpviewer_keywords
breaking changes 2017 [SQL Server]
monikerRange >=sql-server-2017||>=sql-server-linux-2017

Breaking changes to Database Engine features in [!INCLUDEsssql17-md]

[!INCLUDESQL Server 2017]

This article describes breaking changes in the [!INCLUDEsssql17-md] [!INCLUDEssDE]. These changes might break applications, scripts, or functionalities that are based on earlier versions of [!INCLUDEssNoVersion]. You might encounter these issues when you upgrade.

Breaking changes in [!INCLUDEsssql17-md] [!INCLUDEssDE]

  • CLR uses Code Access Security (CAS) in the .NET Framework, which is no longer supported as a security boundary. Beginning with [!INCLUDEsssql17-md][!INCLUDEssDE], an sp_configure option called clr strict security is introduced to enhance the security of CLR assemblies. clr strict security is enabled by default, and treats SAFE and EXTERNAL_ACCESS CLR assemblies as if they were marked UNSAFE. The clr strict security option can be disabled for backward compatibility, but this isn't recommended. When clr strict security is disabled, a CLR assembly created with PERMISSION_SET = SAFE may be able to access external system resources, call unmanaged code, and acquire sysadmin privileges. After enabling strict security, any assemblies that aren't signed will fail to load. Also, if a database has SAFE or EXTERNAL_ACCESS assemblies, RESTORE or ATTACH DATABASE statements can complete, but the assemblies may fail to load.

    To load the assemblies, you must either alter or drop and recreate each assembly so that it's signed with a certificate or asymmetric key that has a corresponding login with the UNSAFE ASSEMBLY permission on the server. For more information, see CLR strict security.

  • The MD2, MD4, MD5, SHA, and SHA1 algorithms are deprecated in [!INCLUDEsssql15-md]. Up to [!INCLUDEsssql15-md], a self-signed certificate is created using SHA1. Starting with [!INCLUDEssSQL17], a self-signed certificate is created using SHA2_256.

Previous versions

Archived documentation for old versions of SQL Server

[!INCLUDEArchived documentation for old versions of SQL Server]

See also