今天我在编写dp2图书馆集成系统参考手册的时候，写到upgradedt1000todp2程序，也就是从dt1000升级的程序，的章节的时候，涉及到升级程序中是否对册条码进行查重的一个选项，为手册增加了下面的一些注释内容：
这里有一个“对册条码进行查重”的事项，建议保持它为off状态。
如果“对册条码进行查重”为on状态，在复制书目库的操作中，升级程序将对册信息进行册条码查重，如果发现有包含重条码的册信息，升级程序将拒绝转入dp2系统内(大书目库下属的)实体库。然而这一策略并不完美：因为升级程序并不知道发生重复的册记录中，哪一条是可以丢弃的，还是都不能丢弃…。
dp2系统已经开发为能够适应dt1000系统常见的册条码重复情况，建议将“对册条码进行查重”设置为off，升级程序将转入全部册信息(包括那些重复了的册条码信息)到dp2系统中，等dp2系统投入运行后，再在工作中追渐发现和消灭重条码现象。
注：dt1000系统内的册条码(或者读者条码)会出现重复的问题，是一个历史遗留问题，原因是dt1000系统并不严格检查和警告条码重复的情况。dt1000系统经过长期运行后，这类问题可能会很严重，例如我们就曾经见到过某些图书馆居然有上万个发生重复的条码，其情况的严重程度令人触目惊心。并且dt1000系统在各个环节都会忽视这种条码重复的情况。例如，借还图书操作的时候，如果软件发现有重复的册条码多条记录，简单取第一个记录进行操作，并不报警。然而这样的“宽容”操作是完全不能被接受的，它会造成读者借阅信息的张冠李戴，或者“诬陷”读者 – 说读者借了他们根本没有借过的那册图书，以及其它连锁发生的后果。可怜许多dt1000系统的用户(系统管理员)对此并不知情，或者说被告知有这类问题后因为“眼不见心不烦”没有直观的感受引不起重视，可能因为不了解情况，还对dt1000系统的“稳定性”“可靠性”赞誉有加呢。这些都是让人感到悲哀的事实。
而dp2系统是完全不允许数据中出现重复册条码这一现象的，软件会进行严格的查重，拒绝用户输入的重复册条码。但是，由于dt1000系统已经存在重复册条码的严重问题，并且这一严重问题通常不可能在需要升级到dp2前的几天内就得到本质解决(那需要耗费很长的时间去架上逐一核对图书实物，修改数据，并且许多册因为在读者手上无法进行有效实物核对)，为了允许用户的数据升级到dp2系统并立即投入工作，dp2系统的开发者作了局部的妥协，允许升级程序将重复的册条码写入dp2系统的数据库，并在以后的日常工作中自动检查和报警，以便提供一种更加缓和的升级运行方式。这，绝对不表明dp2系统具有和dt1000系统一样的允许册条码重复的毛病，也绝对不表明dp2系统在运行中会不断产生新的重复册条码的故障。
关于上述的后者，即“dp2系统是否在运行中会不断产生新的重复册条码的故障？”这一话题，实在是很冤枉和滑稽，因为dp2系统在利用从dt1000升级上来的糟糕数据开展了日常业务后，dp2系统对册条码重复问题很敏感和负责，时常会弹出窗口认真报错，目的是要提醒操作者随时纠正这些从dt1000系统内带来的遗留问题，但是图书馆工作人员容易误以为这些问题是dp2系统带来的“新问题”，理由很简单 – 为什么原来用dt1000的时候不报错，而升级到dp2以后却开始报错了 – 胡乱归结为dp2系统的问题。这真是一种可悲的误会。为了避免做好事反倒被诬陷，数字平台的工程师在给dt1000系统用户进行升级后，会立即启动一个查错的程序，打印出所有dt1000系统内的数据问题，并和用户单位系统管理员一起当面启动dt1000系统抽样验证这个列表的客观性，然后请用户单位在这个打印清单上签字盖章，确认这是dt1000系统的遗留问题而不是dp2系统带来的问题。
还有另外一种办法，就是干脆将上述“对册条码进行查重”的checkbox设置为on状态进行升级，这样做可以完全避免任何重复的册条码进入dp2系统的数据库，但是这是以牺牲数据的完整性为代价的，在升级完成后，在用户单位的日常运行中，工作人员将不得不逐渐去增补那些因为重复条码而没有被转入新系统的数据。不过，这两种办法到底哪种更好，是可以由用户自行选择的。