門號 1、2 還是 3？…從 SQL Server 2016 到 SQL Server 2019 的就地升級導致安全性更改、錯誤或升級失敗？

我做了什麼：

ServerA最近，我測試了在執行 SQL Server 2016 (SP 2 CU17) 標準版到 SQL Server 2019 標準版的開發伺服器上進行就地升級。（我知道這不是進行升級的首選方式，而只是在開發伺服器上進行測試，所以沒有傷害沒有犯規。）

在安裝嚮導期間，其中一個步驟掛了很長時間，所以我的同事點擊下一步按鈕跳過該步驟。我不太記得它是哪一步，但我相信它是產品更新或安裝設置文件步驟。我記得它接下來說它跳過了幾種不同類型的下載。其餘的安裝順利，成功完成。

我能夠啟動實例、登錄並訪問我們的數據庫。然後我將數據庫兼容級別提高到 150（SQL Server 2019 的兼容級別）。我執行了一些性能測試查詢，然後最終決定打開 Legacy Cardinality Estimator。到目前為止，一切似乎都在工作。

發生的事情是：

然後我注意到了一些有趣的東西ServerB，另一台已經在執行 SQL Server 2019 的開發伺服器，並且有一個連結伺服器設置指向ServerA. 一切都執行良好ServerB，除了引用連結伺服器上的視圖的任何查詢，該視圖在ServerA其中使用了模式綁定標量函式。我收到錯誤The EXECUTE permission was denied on the object 'MyFunction', database 'Database1OnServerA', schema 'dbo'。如果我返回ServerA並更改WITH SCHEMABINDING註釋掉的行的函式，則ServerB能夠從再次引用該函式的視圖中進行選擇。

附加資訊：

連結伺服器對像中使用的帳戶是 SQL Server Login on ServerA，只有db_datareader映射到它Database1的角色（當然ServerA除了Public數據庫角色）。它沒有設置額外的細化權限，它也只分配了Public伺服器角色。

有趣的是，我的問題的另一種解決方案是授予連結伺服器帳戶的權限EXECUTE或專門授予連結伺服器帳戶的權限。但是我不必在升級到 SQL Server 2019 之前授予權限，而且我的生產伺服器（在此測試升級之前非常類似地鏡像我的開發伺服器）目前也沒有為連結伺服器帳戶提供權限。Database1``ServerA``MyFunction``EXECUTE``ServerA``EXECUTE

1、2 或 3 號門：

1. 從 SQL Server 2016 到 SQL Server 2019 發生了一些我沒有意識到的與安全相關的變化，或者……
2. 這聽起來像是我遇到的錯誤還是…
3. 你認為我把就地升級搞砸了ServerA嗎？

關於為什麼在從 SQL Server 2016升級到 SQL Server 2019後，僅通過連結伺服器訪問的架構綁定函式的權限ServerB上出現權限錯誤的任何其他想法，簡單地說？EXECUTE``ServerA``ServerA

1、2 或 3 號門：

2，加上破折號3。

所有權鏈應防止對從視圖引用的標量 UDF 進行權限檢查，因此對視圖具有 SELECT 權限的使用者不應該還需要視圖所有者擁有的 UDF 的 EXECUTE 權限。

看起來這是 RTM 中存在並在某些 CU 中修復的眾多 TSQL 標量 UDF 內聯錯誤之一。它在 RTM 上為我重現並在升級到 CU14 後停止。

SQL Server 通常不支持累積更新（或 Service Pack*），因此安裝程序會安裝 RTM，然後在升級後進行修補。通常會為 GDR 更新建構更新的安裝程序，但在主要版本升級後沒有理由繼續使用 RTM+GDR。

當我設置時，它也停止在 RTM 上這樣做

ALTER DATABASE SCOPED CONFIGURATION SET TSQL_SCALAR_UDF_INLINING = OFF;

*SQL Server 2017 及更高版本沒有服務包，只有 CU。

引用自：https://dba.stackexchange.com/questions/306114