基本问题是这样的：
订阅者已使用事务复制成功地从发布者复制了一行。现在，我们如何跟踪上次成功复制该行的时间？

一位朋友提出了以下解决方案，该解决方案用于他的SQL Server 2000：
1)添加日期时间列。
2)更改复制存储过程以更新datetime列(！)。

步骤2引起了我内心的种种警钟，因此我想问一问在这种情况下是否有针对SQL Server 2005的更好的解决方案，甚至我还不详细介绍他的解决方案。

解决方案

我会按照你朋友的建议去做。这样，只有对复制过程的调用才能更新时间戳。

这种方法的问题是我们需要写锁定，但是我看不到任何其他实用方法。

否则，我们可以使用在获取行时触发的触发器(不要在此引用我，我很少使用触发器)，但这似乎不正确(我们可能会以误报结束)

如果我们正在使用事务复制，为什么不只记录主数据更新的时间并认为它已在下一个复制作业中复制到其他数据库？

@Philippe：这种方法的主要问题是由于网络连接不良，复制可能需要一段时间才能到达一些更远程的数据库。因此，主记录的更新时间不会反映实际在远程数据库中复制的记录的时间。

无论如何，我已经测试了我朋友的方法，并且可以很好地满足我们的要求。

如果有人也想这样做，请注意以下重要事项：在初始化订阅和将来的模式更改时要小心。

就我而言，我们决定手动初始化快照，以将添加的datetime列保留在Subscriber数据库中。另一种可能的方法是允许初始化，但是修改现有的存储过程以忽略复制添加的datetime列。

几周前，我遇到了这个确切的问题，试图查找最近更改的记录。

创建一个新列并将数据类型设置为TIMESTAMP。当更新行时，SS2005会自动更新此类型。唯一的问题是，此"时间戳"与日期或者时间完全无关，它只是一个数字，反映了该行的最后一次成功更新(任何更新，而不仅仅是通过复制)。如果这是我们所需要的，那么我们应该会没事的。

如果我们需要最后一次复制更新，则可能会有些棘手，并且需要动手使用触发器和存储的proc。

http://www.sqlteam.com/article/timestamps-vs-datetime-data-types

希望有帮助〜