我们最近将我们的后端数据库从SQL Server 2000升级到SQL Server 2008.由于切换我们已经断断续续（读取：不可能一致地重现）和奇怪的问题，但它们似乎都以某种方式相关。
在一种情况下，我们的用户通过绑定表单向表中添加新记录。 保存记录后，会立即显示不同的（更旧的）记录。按 Shift + F9 强制重新查询该表单将带回新添加的记录（表单被过滤以仅显示单个记录）。
我们已经设法根据在不同表单上发生的日志记录来隔离问题的特定实例。在表单的BeforeUpdate事件中，时间戳正确填写在正在插入的记录上。在同一表单的AfterUpdate事件中，在包含第一个表的自动编号ID的另一个表中创建历史记录。 使用错误的自动编号ID创建了大约十分之一的历史记录。
有没有人目睹过这种行为或有任何解释？
编辑：其他想法：
@@IDENTITY从SQL Server中获取新添加的记录{SQL Server} ODBC驱动程序和{SQL Server Native Client 10.0} ODBC驱动程序连接到后端表时出现问题编辑： SQL事件探查器跟踪结果：
我运行了SQL Profiler并确认Access确实在后台使用SELECT @@IDENTITY来返回新插入的记录。我确认MS Access 2000,2002（XP）和2007前端正在发生这种情况。使用{SQL Server} ODBC驱动程序或{SQL Server Native Client 10.0} ODBC驱动程序链接表也会发生。
我应该强调Access正在幕后使用SELECT @@IDENTITY 。据我所知，没有办法强制Access使用SCOPE_IDENTITY。但是，太糟糕了，因为这似乎是最简单的修复。
答案 0 :(得分：3)
使用SCOPE_IDENTITY代替@@ IDENTITY。
由于@@ IDENTITY返回最后一个 当前生成的身份值 会话，如果有一些触发器 任何在当前操纵的表 会话，我们将获得意想不到的价值。 为了获得所需的价值， 请使用SCOPE_IDENTITY。这个 函数将返回插入的值 仅在当前范围内。
答案 1 :(得分：2)
有点环顾四周（主要是通过garik包含的“更多”链接），表明你遇到了这种行为 - 这是一个Access / SQL Server通信错误。 但是，this link描述了一种解决方法。
对于我来说，复制细节并非常复杂，非常在那里很好地解释了，但基本上你在开始触发时将@@ IDENTITY保存到变量，然后做一个假的#temp插入以将值伪装回到最后返回的内容。
答案 2 :(得分：2)