最近需要維護一個差不多十多年前開發的ASP.Net程序，遇到了各種奇奇怪怪的問題，把其中比較難查明的問題記錄如下：
同樣的SQL查詢在不同服務器上查詢結果不同。在QA環境下，結果完全正常，而在本地，部分字段值為DBNull。
這是一個很詭異的問題，當時唯一發現的規律是，出現DBNull值的字段為Clob類型。ASP.Net連接數據庫的方式為OleDb，鏈接字符串中“Provider=OraOLEDB.Oracle.1”。
首先換為OracleClient，查詢結果正常，問題似乎出在OleDb上。網上也有關於Clob類型的一些資料，但是為什麼QA服務器上又沒問題呢。
帶著這個問題，我做了一個能通過.Net裡不同Client執行Sql查詢的小工具，放到QA服務器上運行，結果確實是正常的。
QA服務器的環境為32位，Oracle客戶端主版本為10，我自己的電腦環境為32位，Oracle客戶端主版本為11。
接著我在幾個服務器上嘗試，結果都正常。我開始懷疑自己電腦上的Oracle客戶端安裝不正常，於是卸載重裝，結果依舊。
對照注冊表
HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\KEY_OraClient11g_home1\OLEDBHKEY_LOCAL_MACHINE\SOFTWARE\Oracle\ODP.NET\2.112.1.0
發現鍵值完全一致。這時我開始懷疑是32位與64位的差異。因為之前測試過的服務器都是64位的，只有QA環境是32位，而QA環境又是10版本的客戶端。
最後找到了一台32位環境的服務器，客戶端版本為11，問題重現。
因此推測，OleDb查詢Clob字段的問題是在32位系統上運行32位客戶端造成的，64位系統上的64位客戶端似乎都不存在這個問題。至於64位系統上的32位客戶端是否存在這個問題，因為時間關系就不親自驗證了。而該問題似乎與服務器無關，因為在32位和64位服務器上都會重現這個問題。
因此，這個問題可以重新描述：使用32位系統下的32位Oracle Provider for OLE DB查詢含有Clob字段類型的數據時可能得到假空值的結果。
解決方式有兩種，使用OracleClient類訪問數據庫或者使用Provider=msdaora;的方式訪問數據庫，這其實是一樣的方法，都是使用Microsoft OLE DB Provider for Oracle；
另一種解決方式就是將服務器升級為64位環境，並盡可能安裝64位客戶端。目前來看應該是Oracle Provider for OLE DB在處理字符編碼時的Bug。
[2016/5/5問題一補充：因為系統環境不同，這個問題可能不一定會重現，目前已知會影響重現的因素是注冊表 HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\KEY_OraClient11g_home1下NLS_LANG的值。當系統區域和語言選項中，格式選擇為中國，則該值默認為SIMPLIFIED CHINESE_CHINA.XXXX，這種情況下查詢結果正常。若系統區域和語言選項中，格式為美國，則NLS_LANG的值默認為AMERICAN_AMERICA.WE8MSWIN1252，這種情況才會出現這個問題。目前沒有發現這個問題跟服務器端的NLS_LANG值有關。]
有西班牙語特殊字符的查詢結果在不同服務器上查詢結果顯示不同，本地執行有亂碼，QA服務器正常。
這個問題也糾結了挺久，在各種嘗試無果後想到了一個控制面板的配置項：在"Region and Language"配置項的管理員選項卡中有一個"Language for non-Unicode programs"選項。之前為了運行某些沒有使用Unicode編碼的國產軟件時將這個配置項改為了中文，我的系統本來是英文版的。於是將這個選項改回英文，問題解決。
因此，這個問題可以重新描述：使用Oracle Provider for OLE DB查詢含有非Unicode編碼字段內容時，若系統的非Unicode語言選項不正確，會導致查詢結果編碼不正確的問題。
