最近需要维护一个差不多十多年前开发的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\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语言选项不正确，会导致查询结果编码不正确的问题。
