近日進行SQL Server資料庫轉移，由公司自有的雲環境搬遷到Azure混合雲中，沒想到一直以來都在繁體中文環境工作導致踩了個大雷。由於某些緣故，某資料庫在評估後，決定使用SQL script方式進行移轉，沒想到該資料庫內有許多資料表的欄位使用VARCHAR型態、而非NVARCHAR型態來儲存中文資料，這導致許多中文資料不管是SSMS或是在實際上線的Web應用程式中都成了問號（？），原訂停機1天完成資料移轉，只得持續延長。

由於舊資料庫可以正常儲存中文，程式也都可以正常顯示中文，從過往使用MySQL的經驗來判斷，非常有可能是語系／文字編碼的問題造成的。

在SSMS裡，確認了一下SQL Server的collation，果不其然，可能因為Azure建立的Windows和SQL Server預設是SQL_Latin1_General_CP1_CI_AS，很可惜安裝完就無法輕易更改，除非進行SQL Server rebuild，考量到已經有別的資料庫已經移轉進來正在使用，暫時作罷。接著再進一步確認此次轉移的資料庫實體的collation，也是SQL_Latin1_General_CP1_CI_AS，運氣很好，這是可以調整的，然而調整成Chinese_Taiwan_Stroke_CI_AS後並沒有解決問題，這只會影響之後CREATE TABLE新建資料表時的預設collation。在Google上一番胡亂查找，發現已經建立的資料表，就得一一手動ALTER TABLE ALTER COLUMN進行欄位collation的修改（真是晴天霹靂）。

透過sys.databases、sys.columns的資料，我們可以檢查特定欄位的collation：

SELECT name, collation_name FROM sys.columns WHERE name = N'<insert character data type column name>';

一陣操作之後，發現CHAR、NCHAR、VARCHAR、NVARCHAR、TEXT、NTEXT等文字欄位高達300個以上，要逐一確認是否應該該轉換為Chinese_Taiwan_Stroke_CI_AS實在太痛苦，便決定要將整個轉移程序重做一遍，唯一不同之處，就是在CREATE指令補上COLLATION，指定為Chinese_Taiwan_Stroke_CI_AS（其實先前已經在SSMS調整過COLLATION，所以不指定好像也行，但指定一下總是安心點）。

就在要執行前，又發現SSMS產生指令碼進階設定中，有一項「指令碼定序」，預設為false，於是改為true後，重新產生一批SQL script，這下COLLATION都幫我加好了！唉呀，真是相見恨晚～不過總算是順利解決這次危機。