今天策划同学报告程序里的触发器有bug，过去看了下日志，提示数据文档配置有问题。心想问题不大，修改下表格内容就可以了，当我看完数据表后，悲催的一天开始了。。。
我们项目模板数据使用的是json，但策划同学肯定更喜欢Excel，所以我们项目的配置文件生成流程是这样的：
其中在Excel转json这步，我们将Excel文件生成json，同时自动生成配置文件类。
当前的问题发生在Excel转json的过程中json数据丢失了，由于这个工程各个项目组都在用，我怀疑是策划同学在填表的时候有特殊符号，导致在转换的过程中出了问题。但仔细检查后并没有问题。那唯一的问题只能是Excel转json的工程有bug。查看相关代码没有看出什么嫌疑。去Google查询Excel数据丢失问题，也没得到什么好的答案。
通过分析输出字段我发现通过转换后的字段长度都是255，无论字符串里是否包含特殊字符，排除掉特殊字符这条线索。然后将255关键字加上之后，Google立马给出了答案：
当数据驱动从Excel读取数据的时候，会从HKEY_LOCAL_MACHINESOFTWAREMicrosoftJet4.0EnginesExcel这个地址读取变量TypeGuessRows来决定通过读取几行来判断数据类型，如果前8行没有超过255的字段，后面都按255长度来读。
解决方案岂不是显而易见，就是修改这个值，我们的数据表很大，所以我将TypeGuessRows修改为0，貌似世界清静了，但结果出乎意料，没有任何作用。查了非常多的文档，大家几乎都是用这种方式，包括微软官方文档。可是没有任何效果。
最终我让策划同学在我们的表类型说明行里填充超过255的字符，来当占用符，问题解决了。
通过这个问题，再次巩固了我对解决问题的几个认识：
1、用别人的库确实方便，但没有源代码但出了问题只能查看文档和google能告诉你怎么办了。
2、在遇到问题的时候，不选择优美但不确定的方案，而是采用实用的方案。
3、合理的实用搜索引擎，只有告诉Google正确的关键字，才能得到合适的答案。
参考资料
[1]http://support.microsoft.com/en-us/kb/839785
[2]http://www.dotnetthoughts.net/text-truncated-to-255-characters-when-reading-from-excel-using-oledb/