针对我们做的一套winform产品，数据库用的Access，上午青岛客户过来了，说怎么保存成功数据后无法查看报表。我们说不可能啊，其他家用户都没有出现过这种问题。然后帮他检查了一下数据，发现里面的日期格式都错了，而在我们系统里运行的时候就没有问题。早在上一阶段的培训的时候，由于参加培训的客户比较多，有四五十家，每个客户带的笔记本软硬件都有差异，就曾经出现过很多类似的问题。
比如有家客户在安装我们打包好的软件时，出现乱码问题，安装好后，同样是系统出现乱码。这家客户以前装过Microsoft AppLocale。而AppLocal在简体中文系统里使用过后，会令某些简体中文的MSI形式的安装程序乱码。刚好，我们打包的程序就是MSI形式的。这个时候有三种解决方法：1.卸载AppLocale即可解决;2.删除AppLocale安装目录下的一个临时文件:/WINDOWS/AppPatch/AppLoc.tmp（此文件有4字节）；3.AppLocale刚安装好的时候, 是没有AppLoc.tmp这个文件的. 自己在AppLocale的安装目录内, 弄一个0字节AppLoc.tmp文件, 并把它设为只读属性, 以后就不会造成乱码了!还有的客户用的是Visita，win7的系统，程序运行的很好，但是在将他的数据库拷出来放置其他的机器中，总是找不到数据，跟刚安装好程序时的数据量是一样的，这类问题应该和Visita，win7的安全性有关，因为安装的时候可能是一个虚拟目录；再有就是有些系统是64位的，要单独生成用于64位的系统的x86程序；还有一些日期格式本来是yyyy-mm-dd格式的，保存的时候偏偏就成了yyyy/mm/dd了等等问题。这些问题都说明了C/S模式的软件的局限性和缺点，也反应出winform程序的一些不足之处。
而今天上午这个客户出现的问题，经过检查后，发现是电脑里短日期格式设置的有问题。通常情况下，我们电脑控制面板，区域与语言选项中设置的短日期格式为yyyy-M-d，日期分割符为-，而这位客户里面设置的短日期格式为yyyy-MM-dd。这样我们程序里调用了一个日期转换字符串函数ToShortDateString()，所以前面两种情况同样是一月的数据得出的结果就会一个是2010-1-10，一个是2010-01-10，从而出现了问题。本来Microsoft offices办公系列软件中就都会受到本地机器上的日期格式的限制这个规则就是Access 总是使用在 Windows 区域设置中指定的日期分隔符、时间分隔符、财务符号和其他字符，除非您用自定义显示格式替代它们。有人可能说用Format函数可以解决，但是项目中总还是或多或少的有其他的跟本地PC的设置相关连的。而由于考虑到公司的成本或其他一些综合性问题，我们不可能组织大量人员再对本地化的问题进行全面解决。所以，这就要求我们在给客户部署的时候统一他们所有的PC机，以及PC机上一些本地格式的设置，因为不可能在程序执行的时候，用程序去进行本地PC的设置，虽然有相应的代码。
当然，我们也要尽量开发出自己的统一性的代码，解决这方面的问题，提高代码的重用性，以免以后不再发生类似的问题。