請問如何比較 UNIQUEIDENTIFIER 型態的欄位值

Question

請問一下, 我有個 TABLE 內的一個欄位(PID) , 是使用 UNIQUEIDENTIFIER 型態 , 再用newid() 產生 DEFAULT 值

當成產品驗證碼

之後希望能在 WHERE 內找出是否合於該驗證碼

WHERE 是使用相等比較

當我用正確的值比較時, 如 WHERE PID = '正確值' 時 , 運作正常

(如 :  SELECT * FROM PRODUCT WHERE PID= '正確值' )

但當我用一個錯誤的值 , WHERE PID = '錯誤值' 時 , 會出現 "從字元字串轉換到 uniqueidentifier 時失敗"

請問我要如何解決 ?  ( 希望能傳回 0 列資料 )

謝謝

Answer 1

比較 GUID 及 uniqueidentifier 值

SqlGuid 結構

---

在現實生活中，你和誰在一起的確很重要，甚至能改變你的成長軌跡，決定你的人生成敗。 和什麼樣的人在一起，就會有什麼樣的人生。 和勤奮的人在一起，你不會懶惰； 和積極的人在一起，你不會消沈； 與智者同行，你會不同凡響； 與高人為伍，你能登上巔峰。

Answer 2

您好，

因為SQL會試圖將它轉成 uniqueidentifier ，所以就掛了。

請問您的sql是2012嗎?

請使用 TRY_CONVERT

create table #t1
(
c1 int,
c2 uniqueidentifier
);

insert into #t1 values(1, cast('CF097A41-A81D-4F23-80A0-A6902B6CE641' as uniqueidentifier));
select * from #t1
where c2 =  TRY_CONVERT(UNIQUEIDENTIFIER, 'xxx ')

---

亂馬客blog: http://www.dotblogs.com.tw/rainmaker/

Answer 3

您可以先檢查內容值是否為UUID, 才進行查詢, 像這樣:

How to check if a string is a uniqueidentifier?

Answer 4

檢查參數是呼叫者的責任。

---

強力監督SQL Injection問題!!

• 小朱的技術隨手寫：http://www.dotblogs.com.tw/regionbbs/
• 雲端學堂Facebook: http://www.facebook.com/studyazure

Answer 5

感謝各位回覆, 因為處理其他問題都沒進來看, 不好意思

我sql是2012沒錯

因為我是將產生的 guid 存成一個 Varchar的欄位

所以不知 Bill 所提供的方式是否可行 ?
 
還是必須先以Varchar的欄位的值先建立一個Guid物件

Guid g = new Guid("Varchar的欄位的值") , 再將其與 uniqueidentifier 欄位的值比較

但這樣做, 我似乎無法直接在 SQL 的 WHERE 中使用 ?

亂馬客所提使用 TRY_CONVERT, 看起來是防止型態轉換的錯誤, 錯誤時傳回 NULL ,

請問我是用傳回是 NULL 來判斷兩個值不相等嗎 ?  謝謝

tihs 所提將 "Varchar的欄位的值" Cast 成 uniqueidentifier , 

看起來跟 Bill的做法類似, 但應該可以直接放入SQL 的 WHERE 中使用

我目前轉個想法,是將 uniqueidentifier CAST 成 Varchar , 再與 "Varchar的欄位的值" 比較,

看起來可行, 但是還有個問題, 就是 CAST 成 Varchar 中英文都轉成大寫, 跟我當初存入 Varchar的欄位的值英文有小寫不同

雖然只需要都轉大寫就可以比較, 但不知會不會有甚麼沒想到的後果 ?

Answer 6

大小寫應該沒差, 因為他就是轉成 HEX String (GUID 原來的型態應該是 byte[])

---

在現實生活中，你和誰在一起的確很重要，甚至能改變你的成長軌跡，決定你的人生成敗。 和什麼樣的人在一起，就會有什麼樣的人生。 和勤奮的人在一起，你不會懶惰； 和積極的人在一起，你不會消沈； 與智者同行，你會不同凡響； 與高人為伍，你能登上巔峰。

Answer 7

我比較傾向檢查參數是呼叫者的責任，當你把檢查參數的任務交給SQL去處理時，無形加重了SQL的負擔，並且可能影響到SQL查詢效能

依你目前的想法，除了GUID，可能日後連int,decimal等，可能都想直接丟給SQL去處理

---

微軟免費線上課程

HTML5 & JavaScript程式開發實戰(MyBook)

開發ASP.NET您要瞭解的基楚

http://www.dotblogs.com.tw/ian (MyBlog)

Answer 8

大小寫應該沒差, 因為他就是轉成 HEX String (GUID 原來的型態應該是 byte[])

---

在現實生活中，你和誰在一起的確很重要，甚至能改變你的成長軌跡，決定你的人生成敗。 和什麼樣的人在一起，就會有什麼樣的人生。 和勤奮的人在一起，你不會懶惰； 和積極的人在一起，你不會消沈； 與智者同行，你會不同凡響； 與高人為伍，你能登上巔峰。

感謝您提供的資訊

Answer 9

我比較傾向檢查參數是呼叫者的責任，當你把檢查參數的任務交給SQL去處理時，無形加重了SQL的負擔，並且可能影響到SQL查詢效能

依你目前的想法，除了GUID，可能日後連int,decimal等，可能都想直接丟給SQL去處理

---

微軟免費線上課程

HTML5 & JavaScript程式開發實戰(MyBook)

開發ASP.NET您要瞭解的基楚

http://www.dotblogs.com.tw/ian (MyBlog)

感謝您提供的建議及提醒

但因是希望不要在程式中讓人家看到 DB 的欄位, 所以不能先讀出來再於程式處理, 不知如果不在 SQL 中做, 還有沒有其他方式 ?

謝謝

Answer 10

"不要在程式中讓人家看到 DB 的欄位"，所以你的需求是希望開發人員不要去接觸db嗎？
那你應該做分層設計，有關資料庫的處理，就寫成服務給開發人員去用，例如ORM這類的開發方式

---

微軟免費線上課程

HTML5 & JavaScript程式開發實戰(MyBook)

開發ASP.NET您要瞭解的基楚

http://www.dotblogs.com.tw/ian (MyBlog)

Answer 11

"不要在程式中讓人家看到 DB 的欄位"，所以你的需求是希望開發人員不要去接觸db嗎？
那你應該做分層設計，有關資料庫的處理，就寫成服務給開發人員去用，例如ORM這類的開發方式

---

微軟免費線上課程

HTML5 & JavaScript程式開發實戰(MyBook)

開發ASP.NET您要瞭解的基楚

http://www.dotblogs.com.tw/ian (MyBlog)

非常感謝您提供觀念上的知識

Answer 12

要隱藏欄位可以用檢視表 (view)，只允許外部程式接觸檢視表而不是表格 (table)，寫入部份可用預存程序 (stored procedure)，這樣就可以有效防止外部程式直接看到 table 的結構。

ORM 也是個方法，但我認為不是最佳的作法。

---

強力監督SQL Injection問題!!

• 小朱的技術隨手寫：http://www.dotblogs.com.tw/regionbbs/
• 雲端學堂Facebook: http://www.facebook.com/studyazure

Answer 13

您好，

您最初的欄位型態是 uniqueidentifier ，後來將它改成 varchar ? 

如果是 varchar 的話，就直接用字串的比較就可以了。

大小寫則是要看您DB的設定值是否有區分大小寫，

您可以試一下以下的SQL，

create table #t1
(
c1 int,
c2 UNIQUEIDENTIFIER, 
c3 VARCHAR(40)
);

insert into #t1 values(1, cast('CF097A41-A81D-4F23-80A0-A6902B6CE641' as uniqueidentifier), 'CF097A41-A81D-4F23-80A0-A6902B6CE641');
-- 查詢比較
-- 非 GUID 
SELECT * from #t1
where c2 =  TRY_CONVERT(UNIQUEIDENTIFIER, 'xxx ');

select * from #t1
where c3 =  'xxx';

-- GUID
select * from #t1
where c2 =  TRY_CONVERT(UNIQUEIDENTIFIER, 'cf097a41-a81d-4f23-80a0-a6902b6ce641');

select * from #t1
where c3 =  'cf097a41-a81d-4f23-80a0-a6902b6ce641';

-- 區分大小寫(因為我DB的設定是不分大小寫)，所以設定比較採區分大小寫的方式
select * from #t1
where c3 =  'cf097a41-a81d-4f23-80a0-a6902b6ce641' COLLATE Latin1_General_CS_AS ;

---

亂馬客blog: http://www.dotblogs.com.tw/rainmaker/