基本问题是这样的：
订阅者使用事务复制成功地从发布者复制了一行。现在，我们如何跟踪最后一次成功复制该行的时间？
一位朋友提出了以下解决方案，他将其用于他的 SQL Server 2000：
1) 添加日期时间列。
2）更改复制存储过程以更新日期时间列（！）。
第 2 步引发了我内心的各种警钟，所以在我详细介绍他的解决方案之前，我想问在这种情况下是否有更好的 SQL Server 2005 解决方案。
【问题讨论】：
标签： sql-server sql-server-2005 replication
几周前我遇到了这个确切的问题，试图查找最近更改的记录。
创建一个新列并将数据类型设置为 TIMESTAMP。 SS2005 在行更新时自动更新此类型。唯一的问题是这个“时间戳”与日期或时间完全没有关系，它只是一个反映该行最后一次成功更新的数字（任何更新，不仅仅是通过复制）。如果这就是你所需要的，那么你应该没问题。
如果您需要最后一次复制更新，事情可能会变得有些棘手，您需要亲自动手处理触发器和存储过程。
http://www.sqlteam.com/article/timestamps-vs-datetime-data-types
希望对你有帮助~
【讨论】：
我会完全按照你朋友的建议去做。这样，只有对复制过程的调用才会更新时间戳。
这种方法的问题是你需要一个写锁，但我没有看到任何其他实用的方法。
否则您可以使用在获取行时触发的触发器（不要引用我的话，我很少使用触发器），但这似乎不正确（您可能以误报结束）
【讨论】：
如果您正在使用事务复制，为什么不记录主数据更新的时间并考虑在下一次复制作业时将其复制到其他数据库？
【讨论】：
@Philippe：这种方法的主要问题是由于网络连接不良，复制可能需要一段时间才能到达一些更远程的数据库。所以，主记录的更新时间不会反映记录在远程数据库中实际复制的时间。
无论如何，我已经测试了我朋友的方法，它可以很好地满足我们的要求。
如果有人也想这样做，这里有一个重要注意事项：在初始化订阅和未来的架构更改时要小心。
就我而言，我们决定initialize the snapshot manually 以便将添加的日期时间列保留在订阅者数据库中。另一种可能的方法可能是允许初始化，但修改现有存储过程以忽略复制添加的日期时间列。
【讨论】：