今天策划同学报告程序里的触发器有bug,过去看了下日志,提示数据文档配置有问题。心想问题不大,修改下表格内容就可以了,当我看完数据表后,悲催的一天开始了。。。
我们项目模板数据使用的是json,但策划同学肯定更喜欢Excel,所以我们项目的配置文件生成流程是这样的:
其中在Excel转json这步,我们将Excel文件生成json,同时自动生成配置文件类。
当前的问题发生在Excel转json的过程中json数据丢失了,由于这个工程各个项目组都在用,我怀疑是策划同学在填表的时候有特殊符号,导致在转换的过程中出了问题。但仔细检查后并没有问题。那唯一的问题只能是Excel转json的工程有bug。查看相关代码没有看出什么嫌疑。去Google查询Excel数据丢失问题,也没得到什么好的答案。
通过分析输出字段我发现通过转换后的字段长度都是255,无论字符串里是否包含特殊字符,排除掉特殊字符这条线索。然后将255关键字加上之后,Google立马给出了答案:
当数据驱动从Excel读取数据的时候,会从HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel这个地址读取变量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/
原文:http://blog.csdn.net/hackmind/article/details/44731865