SQL Server GUID有時有效並且有時不是

我遇到GUID問題，我已經縮小到LIKE運算符看起來像一個問題。SQL Server GUID有時有效並且有時不是

當以下是我的服務器

DECLARE @Problem NVARCHAR(1000) = N'58C21BC6-081B-4E57-BFE1-5B11AAC662F1'; 

DECLARE @GuidPattern NVARCHAR(1000) = 
    REPLICATE('[0-9A-Fa-f]', 8) 
    + '-' 
    + REPLICATE('[0-9A-Fa-f]', 4) 
    + '-' 
    + REPLICATE('[0-9A-Fa-f]', 4) 
    + '-' 
    + REPLICATE('[0-9A-Fa-f]', 4) 
    + '-' 
    + REPLICATE('[0-9A-Fa-f]', 12); 

SELECT 
    CASE 
     WHEN @Problem LIKE @GuidPattern THEN 1 
     ELSE 0 
    END AS [FollowsPattern];

答案是0，但是當我在我的本地機器上運行完全相同的代碼答案是1上運行。

它看起來很明顯，該字符串實際上是一個有效的GUID，所以在這兩種情況下的答案應該是1。所有其他的方法，我知道，以確認GUID是有效的也是成功的，在本地和服務器上：

SELECT 
    CASE 
     WHEN CAST(@Problem AS UNIQUEIDENTIFIER) = @Problem THEN 1 
     ELSE 0 
    END AS [IsGuid1]; -- 1 

SELECT 
    CASE 
     WHEN CONVERT(UNIQUEIDENTIFIER, @Problem) = @Problem THEN 1 
     ELSE 0 
    END AS [IsGuid2]; -- 1 

SELECT 
    CASE 
     WHEN TRY_CONVERT(UNIQUEIDENTIFIER, @Problem) IS NOT NULL THEN 1 
     ELSE 0 
    END AS [IsGuid3]; -- 1

服務器版本是

Microsoft SQL Server 2016 (RTM) - 13.0.1601.5 (X64) 
    Apr 29 2016 23:23:58 
    Copyright (c) Microsoft Corporation 
    Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2012 R2 Standard 6.3 <X64> (Build 9600:) (Hypervisor)

和我的本地安裝的版本是

Microsoft SQL Server 2014 - 12.0.2000.8 (X64) 
    Feb 20 2014 20:04:26 
    Copyright (c) Microsoft Corporation 
    Express Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)

默認排序規則是不一樣的（SQL_Latin1_General_CP1_CI_AS本地和Danish_Norwegian_CI_AS在服務器上），但我不認爲這應該很重要，因爲我正在處理機智h Unicode仍然如此。 ~~在另一臺機器上添加額外的COLLATE子句與其他的排序規則沒有區別。~~更新：不正確，整理是問題的根源。我只在變量聲明中測試了不同的排序規則，而不是比較本身。

來源

2017-03-08 soapygopher

證明它的簡化版本：HTTP：//計算器。com/a/9577359/3270427 – McNets

GUID由我無法控制的集成提供，用於跨多個表關聯行。一切都表明集成確實使用了'NEWID'的等價物，但我在這裏使用了一個字符串常量，因爲我能夠追蹤導致問題的一個特定GUID實例（絕大多數我們沒有收到）。但是，這並不能解釋問題。 – soapygopher

rextester.com返回1 – McNets

我想問題是COLLATION。

看一看：http://rextester.com/IRQEFU33639

如果使用默認排序：

SELECT 
    CASE 
     WHEN @Problem LIKE @GuidPattern THEN 1 
     ELSE 0 
    END AS [FollowsPattern];

結果= 1

相反，如果你的力量Danish_Norwegian_CI_AS歸類：

SELECT 
    CASE 
     WHEN @Problem collate Danish_Norwegian_CI_AS LIKE @GuidPattern THEN 1 
     ELSE 0 
    END AS [FollowsPattern];

它返回0.

我建議強制排序到SQL_Latin1_General_CP1_CI_AS或其他排序方式運作良好。

SELECT 
    CASE 
     WHEN @Problem COLLATE SQL_Latin1_General_CP1_CI_AS LIKE @GuidPattern THEN 1 
     ELSE 0 
    END AS [FollowsPattern];

只是爲了方便使用INLINE User Defined Function。

來源

2017-03-08 15:40:30 McNets

我檢查了這一點，它似乎是真實的，排序是這個原因。我必須承認，我沒有想到這... – Shnugo

我想它與正則表達式有關，也許挪威語言需要改變它。 – McNets

演示在另一個問題http://stackoverflow.com/questions/1171510/sql-like-operator-and-aa – gbn

力的標準排序

SELECT 
    CASE 
     WHEN @Problem COLLATE Latin1_General_CI_AS LIKE @GuidPattern COLLATE Latin1_General_CI_AS THEN 1 
     ELSE 0 
    END AS [FollowsPattern];

的原因是如何「A」進行Danish_Norwegian_CI_AS整理匹配。

更多見SQL 'Like' operator and 'aa'在那裏我有Danish_Norwegian_CI_AS

來源

2017-03-08 15:46:43 gbn

是的，這可能是最好的解決方案。我最初在SSIS工作中的GUIDs字符串列中查找GUID時遇到了這個問題 - 與我在問題中描述的情況有所不同 - 所以我必須以某種方式將其適應於真正的問題。 – soapygopher

SQL Server GUID有時有效並且有時不是

回答

相關問題