升级后的一周，由于客户的销售人员相对较少，所以用的也少。第二周开始，销售助理在整理销售的拜访报表后发现了很多以前的异常情况。
例如： 有些拜访没有company；有些拜访记录关联的company不是销售本人的company，权限上应该看不到不是他的company。
由于客户的集团对网络的要求比较高，所以不能对外开发远程或者ftp等，我们只能到现场调试，我在sql.log中发现了很多solo同步时，出现ID重复没有插入到comm表或者cmli表的数据。 问题一下子就找到了。表象就是修复数据，但修复根源却麻烦得多。加班了几个夜晚才大概明白其中的问题，可能我比较笨，而且solo的应用在国内好像是没有，DPP能找到的文章也有限。
客户使用SageCRM也有一段历史，可能是他们以前的代理商对他们的数据做了特殊处理，例如初始化或者数据导入等，把ID弄乱了。系统的自增ID才到20W多一点。实际的数据也才13万不到。但是有很多数据的ID已经是90多万了。明显有问题的。SageCRM自增ID的相关内容可以参考我的文章了解一下《Sage CRM 自增ID的方案和遇到的问题》。
那根本的问题就是现在solo产生的ID已经存在crm了。后来我也发了文章到DPP，有为国外同行的建议和我的想法一致，就是把crm的自增ID的基数提高，我本机测试过，只要把服务器的ID提高了，solo的自增ID基数也会提高，这样solo的数据产生的ID就不会跟现有的数据重复了。我叫同事帮忙在后台运行了我写好的sql。ID确实也涨上去了。但是却没有效果，我也怀疑自己的思路。
后来我自己到现场后，查了数据库，发现ID并没有提高，我的同事一向细心，一定是少了什么。我自己再次update，这次直接增加到2千万，想起来要刷新元数据，做完这些之后，观察了几周，这种数据越来越少，很多solo同步一次后，ID就自动变高了，下次再同步也不会出问题了，但也有一些很顽固的，就叫客户安排他们的销售到总部重装solo。solo重装很痛苦，主要是因为客户没有限制每个销售导入到solo的数据，有多少就导多少，初始化数据的时间比较长。到这周基本只剩一下一个两个顾问有问题了。
比较郁闷的还在后面，漏洞堵住了，修复数据才头大。 我先把cmli插入到系统，这类数据本身的comm不会变，自动会关联上主表；再把comm插入到系统，然后把comm和他之前的cmli做一个关联。问题还是有。后面发现自己太不细心了，原来comp也有这种情况。两个表还好，现在有三个表了，修复起来就不能100%完整了。只能尽量，然后把还有错误的数据导出来给他们的销售核对，重新填写到系统。由于太后面才发现的comp，可能后面还会有comp重复的出现，这个问题还没跟客户反馈呢。囧！
不过到现在为止，我也还没弄明白solo产生的ID是怎样避免和crm服务器上产生的ID重复的，问题解决了就没有心态去研究这些东西。