從 SQL Server 2008 R2 遷移到 SQL Server 2019 時遇到問題。我的代碼
DECLARE @str NVARCHAR(50) = 'all',
@int TINYINT = 1
DECLARE @tmp TABLE (val nvarchar(MAX))
INSERT INTO @tmp VALUES('123')
INSERT INTO @tmp VALUES('all')
SELECT val
FROM @tmp
WHERE @str = 'ALL' OR @int = val
使用 SQL Server 2008 R2 時，沒問題。輸出如下
val
123
all
但是，當我遷移到 SQL Server 2019 時，出現如下錯誤。此外，它只是在 2019 年不尋常地發生。
訊息 245 級別 16 狀態 1 第 8 行 將 nvarchar 值“all”轉換為資料型別 int 時轉換失敗。
如您所見，第二個條件OR @int = val出乎意料地發生了。
我想知道它是否由于與OR運算子順序或vs在下一個 SQL Server 2008 R2 版本中的順序相關的任何重大更改而失敗。case sensitive ALLall
更新
對不起，我的重現代碼讓你們感到困惑。這是我的原始代碼
uj5u.com熱心網友回復：
你應該做這三件事中的兩件事：
(
要么使用
DECLARE @int nvarchar(max) = 1或者
利用
WHERE val = CONVERT(nvarchar(max), @int)
)
和
- 改為使用
STRING_SPLIT. 即使在本機解決方案存在之前，該回圈函式也是用于拆分字串的效率最低的方法之一。見https://sqlblog.org/split
這個db<>fiddle fiddle 演示。
而這一個節目，為什么WHERE @str = 'ALL' OR (@str <> 'ALL' AND @int = val)不是一個解決辦法。您選擇的這些模式僅在@stris always 時才有效'all'，因為它們在遇到其他任何情況時都會中斷。那么為什么有OR呢？
您一直堅持 SQL Server 應該服從從左到右的評估，但我們一直告訴您事實并非如此。
這是Microsoft 的 Bart Duncan 的一篇文章，他曾在 SQL Server 上作業，在發表更多評論或進一步編輯您的問題之前，您絕對應該閱讀全文。不過，關鍵點是：
您不能依賴運算式求值順序，
WHERE <expr1> OR <expr2>
因為優化器可能會選擇在第一個謂詞之前評估第二個謂詞的計劃。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/399929.html
標籤：sql-server sql-server-2008-r2 sql-server-2019