在搞基于DB2的嵌入式C语言项目时，出现了一件非常奇怪的事情，拿出来与大家分享。
当时为了保持测试数据的完整性及开发人员的数据的一致性，更是为了减少DBServer的压力，故而为每两人做一个DB实例噩梦由此开始。
每当担当者A编译好程序，开始运行的之后，使用同一DB实例的担当者B也开始编译运行，此时担当者A就会报出“SQL0818N A timestamp conflict occurred.”之类的错误。于是，A开始重新预编译，运行，ok，开始测试，而此时的B就会报出刚才A报出的错误。
当时，由于刚刚接触DB2，对其嵌入式开发还不太熟悉其原理，我自己还以为是DB2处了问题或者客户端出了问题，于是，卸载Quest Central,重新安装DB2。一直没有解决问题。
后来，通过查找资料，总结，终于找出其缘由。下图是创建包的过程。
由于只使用了段条目来标识应用程序中的上下文，修改过的源文件和包被紧紧地链接在一起，并且必须保证它们总是指向相同的上下文。这是通过在修改过的源文件中嵌入一个一致性标志（token），也叫“时间戳（timestamp）”，并且在 DB2 UDB 内将相同的值存储在包信息中来实现的。来自应用程序的每一条请求都带有这种一致性标志，传入的值要与编目表中的值相比较。如果这两个值不相同，并且装入模块的时间戳与一致性标志不相同，那么将发生一个“timestamp”错误（SQLCODE -818）。
原因就是如上所述，希望对你有用。
时间： 2024-08-30 06:30:59