在SQL Server日常的函數(shù)、存儲過程和SQL語句中，經(jīng)常會用到不同數(shù)據(jù)類型的轉換。在SQL Server有兩種數(shù)據(jù)轉換類型：一種是顯性數(shù)據(jù)轉換；另一種是隱性數(shù)據(jù)轉換。下面分別對這兩種數(shù)據(jù)類型轉換進行簡要的說明：
1 顯式轉換
顯示轉換是將某種數(shù)據(jù)類型的表達式顯式轉換為另一種數(shù)據(jù)類型。常用的是CAST 和 CONVERT 函數(shù)。
CAST： CAST ( expression AS data_type )
CONVERT： CONVERT (data_type[(length)], expression [, style])
參數(shù) expression 是任何有效的 Microsoft SQL Server表達式。data_type 目標系統(tǒng)所提供的數(shù)據(jù)類型，不能使用用戶定義的數(shù)據(jù)類型。
2 隱性轉換
隱性轉換對于用戶是不可見的，由SQL Server 引擎自動處理。 隱性轉換自動將數(shù)據(jù)從一種數(shù)據(jù)類型轉換成另一種數(shù)據(jù)類型。例如，如果一個 smallint 變量和一個 int 變量相比較，這個 smallint 變量在比較前即被隱性轉換成 int 變量。 當從一個 SQL Server 對象的數(shù)據(jù)類型向另一個轉換時，一些隱性和顯式數(shù)據(jù)類型轉換是不支持的。例如，nchar 數(shù)值根本就不能被轉換成 image 數(shù)值。nchar 只能顯式地轉換成 binary，隱性地轉換到 binary 是不支持的。nchar 可以顯式地或者隱性地轉換成 nvarchar。
3 隱性轉換的風險
隱性轉換有的時候非常方便，可以簡化SQL 腳本，但是這里面也孕育著潛在的風險，可能會出現(xiàn)在腳本一開始運行的時候都是正常的，但卻某一個時間點之后，程序莫名出現(xiàn)錯誤。下面舉一個現(xiàn)實項目中的例子來說明。在SQL Server 2008中有一個表，需要從兩個不同的數(shù)據(jù)表中拉取數(shù)據(jù)，由于這兩個數(shù)據(jù)表屬于不同的系統(tǒng)，其主鍵類型是不同的，一個是int類型，一個是GUID，一開始想著這兩個都可以轉換成字符類型進行存儲。所以就在表中建立一個nvarchar(50)的混合ID列作為主鍵。如下圖所示：
一開始拉取的數(shù)據(jù)并未有GUID的值，都是INT類型轉換過來的數(shù)據(jù)，所以SQL腳本運行的正常，但是突然某一次運行時，出現(xiàn)了“在將 nvarchar 值 '4C185367-F004-41FE-8A0A-DB4E819B1FF2' 轉換成數(shù)據(jù)類型 int 時失敗。”的錯誤。如下圖所示：
定位到腳本，執(zhí)行的SQL如下：
select * from dbo.Demo where 混合ID=305
其中主鍵中的數(shù)據(jù)有GUID轉換的字符型，也有INT轉換的字符串，示例數(shù)據(jù)如下：
但是如果執(zhí)行下面的SQL，則都是正常執(zhí)行：
|
1
2
3
4
5
6
7
8
9
|
select * from dbo.Demo where 混合ID=305 and 名稱='INT'select * from dbo.Demo where 混合ID=305 and 序號='2'select * from dbo.Demo where 混合ID=305 and 序號=2select * from dbo.Demo where 混合ID='305' and 名稱='INT'select * from dbo.Demo where 混合ID='305' |
結果如下：
出現(xiàn)上述錯誤的結果應該是這樣的：
select * from dbo.Demo where 混合ID=305在執(zhí)行時，SQL Server會將nvarchar類型的隱性轉換成int類型，如果數(shù)據(jù)中沒有GUID類型的字符，則轉換正常，如果有，當進行GUID字符到INT的隱性轉換時，則轉換失敗。
以上就是本文的全部內(nèi)容，希望對大家進行SQL Server數(shù)據(jù)類型轉換有所幫助。
