提前道歉的长度; 我只是想确保所有的事实都包括在内，以便能够做出正确的诊断。
我对这个问题一无所知，希望有人遇到过这个问题，或者至less可以提供一些有关这个问题的见解。
在过去的几个星期里，我们的应用程序遇到了一个问题，看似随机的表格中的随机logging会自我复制。 似乎没有任何押韵或理由，我不相信这是一个编码问题。 有时logging会重复3次，有时会重复20次以上，其间的所有内容。
我在我的数据库的每个表上都有一个date时间字段，我习惯性地添加它们，有一件我觉得非常奇怪的事情是，每次发生重复时， 真实logging都会有一个正确的date时间戳，如2010-10 -28 16：28：26.903 （注意毫秒是准确的，你会期望） – 但重复的logging都有一个date时间戳2010-10-28 16:28:27。 000 。
这是我说这不是一个编码问题的原因之一。 我会期待的是，如果出现了一些糟糕的错误循环，那么就是在某个恶意代码块中随机插入一堆logging，插入的logging的date时间戳将相差几毫秒 – 但这不是这种情况。 所有重复logging的毫秒数将下降，并向上或向下舍入到最接近的秒数。
所有其他信息是绝对相同的PK /身份列的例外。
这发生在应用程序中的大约4个不同的表，据我所知，但它可能发生了更多…我还没有检查（数据库有很多表）。 我知道这不是发生在所有的桌子上。 似乎已经停止在问题首先发生的表格，现在“传播”到其他表格。
我拿了一个数据库的副本，用于预发布版本的分期/testing，并且在那个数据库中也有重复的数据。 该数据库与正在遇到此问题的实时数据库位于同一个框中。 但是，我们在我们的开发箱上有一个数据库，似乎根本没有这个问题。 我想如果这是一个编码问题，我们会在所有三个数据库中看到问题。
除此之外，它所影响的表格之一更多的是后端表格。 它只有两个logging，但其中一个重复了10次。 我们的系统中没有任何代码插入logging或更新logging，或以任何方式与此特定表进行交互。 没有为它写的存储过程，没有意见，没有触发器，绝对没有…而其中一个logging是重复的。 我可以看到一个影响其他表格的编码问题，但是鉴于这个特定的表格有重复，而没有代码与它交互 – 我发现这是非常奇特的。 我也应该提到，这里重复的logging是在几个月前手动插入的。
这些重复也不会在插入真实logging时发生。 我在第一次开始的时候做了一些testing – 认为这是一个编码问题，并试图追捕代码的stream氓部分。 我所有的testing结果都很好，我无法重现结果。 我testing了有问题的区域，检查了数据库，没有新插入的logging有重复。 我第二天早上好奇地检查了一下，没有插入重复的内容。 那天下午我检查了一下，果然，已经插入了24个重复的logging – 在事实发生近24小时后。
有没有人知道任何数据库过程，也许可能会导致这种情况发生？ 插入一条logging，在一段时间之后将logging多次抽出logging时，有什么东西卡在内存中？
我知道这不是你的磨坊问题，或者至less我不认为这是事实。 我第一次听说过这件事。 有任何想法吗？ 即使在黑暗中的一枪，在这一点上将不胜感激。
我知道一个“解决scheme”就是对受影响的表进行限制，使重复logging成为不可能; 但是我真的很想深入了解问题的底部，或者至less在我去之前做一些这样的事情的时候，至less有一些倾向（如果可能的话）。 我想知道如果我可能没有正确地设置一些东西，可以知道在未来避免这个问题。 如果有问题，我宁愿修好它，而不是掩盖它，让它回来，后来困扰我。 墨菲定律，你知道的。
多谢你们; 如果你需要更多的信息，我会很乐意提供。
编辑对不起，我应该提到我在生产数据库服务器上使用SQL Server 2005，在开发盒上的SQL Server 2008，他们都连接到一个ASP.net应用程序
对表格施加限制并不是一个“解决scheme”（从数字上来说）。 相反，这是正确的做法。 根据定义，应该将数据库模式devise为使RDBMS执行约束，以防止在数据库中表示无效数据。
您应该对表进行约束，以防止将“重复数据”作为数据库基本devise的一部分插入。 如果你使用自然主键，你会得到这个“免费”。 由于您使用的是人工主键（“身份”列），因此您需要构成自然主键的列上的唯一性约束。
几乎可以肯定，这是发生在你的代码中的某个地方。 多年来，SQL Server一直受到非常大量的用户的重视。 这种types的SQL Server引擎本身的错误很早就已经被整理出来了。
一旦你有了唯一性约束，当插入这些重复logging时，将会抛出错误，并且你将能够追溯到它们的源头。 如果您的代码没有与其中的“On Error Resume Next”types的构造类似，那么当有问题的代码无法对“重复”数据执行插入时，您应该开始获取错误（未处理的exception等）。
你描述的整个“四舍五入时间”的症状让我觉得你有一个“实用”function，通过截断时间（因为截断datetime值是相当平凡的），被埋在代码中的“帮助”的地方。
使SQL Server抛出违反违规的错误，你将能够追查有问题的代码。 即使修复了有问题的代码，也不要在数据库上留下限制，因为排除无效数据是数据库作业的一部分。
我知道这个问题是很久以前发布的，但问题依然存在。 我在我的表中获取重复行时遇到了同样的问题。 我正在使用SQL Server Express 2016的Asp.net VB.net。
由于某种原因，当我使用GridView.RowUpdatinglogging被重复，即使我同时debugging和检查数据库，似乎是我退出RowUpdating事件后，logging被重复。
我使用ExecuteNonQuery一次，并立即closures我的连接。 我在网上研究了很多答案，但没有任何工作。
但是，我发现GridView.RowUpdating不喜欢没有e.Cancel = true，所以我把它放在任何地方，并意识到我可以使用它来阻止RowUpdating事件运行两次（对于我的生活，我无法找出原因并不能看到它发生）。 所以在我退出之前，我把e.Cancel = true，解决了这个问题。
希望我的回答能帮助有类似问题的人。