什么会导致零星的“-2147352567 数据已更改”错误？
What can cause a sporadic "-2147352567 The data has been changed" error?
我们的一个表单会偶尔生成此错误消息。该问题出现在我们的订单上，该订单绑定到链接的 SQL Server 2008 table。打印通知单（使用报告）后，订单状态将设置为 'Printed Order'。此时，我偶尔会看到“-2147352567 数据已更改”错误。我会说 95% 的时间，这不会发生，但让我们头疼的是另外 5%（以及无数支持电话）。
奇怪的是，关闭表单并尝试对订单执行相同的操作会导致相同的错误消息，但关闭数据库并再次尝试会正常。
就好像对表单绑定的 table/record 有一些未提交的更改，即使没有打开的表单、报告等也存在。
代码如下所示：
Select Case Me.txtCurrentStatus
Case NEW_ORDER, UNPRINTED_ORDER:
Me.txtCurrentStatus = PRINTED_ORDER
End Select
'Commit changes
If Me.Dirty = True Then Me.Dirty = False
@iDevelop 实际上促使我考虑向 table 添加时间戳，所以我只接受了部分功劳 ;)...
简而言之 - 在 Microsoft Access 中使用链接的 table 时，如果 table 不包含 timestamp 类型的列，Access 将比较table 中的每一列，以查看自检索记录以来数据是否已更改。 Access 无法可靠地检查多种数据类型（请参阅下面的文章）。只需添加类型为 timestamp 的列即可更改此行为，而 Access 只会检查 rowversion 是否已更改...这会进行此检查更可靠，也提高了性能。
奇怪的是，这根本不是真正的时间戳 - 它是一个行版本，但在 SQL Server 2008 中，我正在使用 行版本 不可用通过 GUI。
参见https://technet.microsoft.com/en-us/library/bb188204%28v=sql.90%29.aspx。
Probably the leading cause of updatability problems in Office Access–linked tables is that Office Access is unable to verify whether data on the server matches what was last retrieved by the dynaset being updated. If Office Access cannot perform this verification, it assumes that the server row has been modified or deleted by another user and it aborts the update.
There are several types of data that Office Access is unable to check reliably for matching values. These include large object types, such as text, ntext, image, and the varchar(max), nvarchar(max), and varbinary(max) types introduced in SQL Server 2005. In addition, floating-point numeric types, such as real and float, are subject to rounding issues that can make comparisons imprecise, resulting in cancelled updates when the values haven't really changed. Office Access also has trouble updating tables containing bit columns that do not have a default value and that contain null values.
A quick and easy way to remedy these problems is to add a timestamp column to the table on SQL Server. The data in a timestamp column is completely unrelated to the date or time. Instead, it is a binary value that is guaranteed to be unique across the database and to increase automatically every time a new value is assigned to any column in the table. The ANSI standard term for this type of column is rowversion. This term is supported in SQL Server.
Office Access automatically detects when a table contains this type of column and uses it in the WHERE clause of all UPDATE and DELETE statements affecting that table. This is more efficient than verifying that all the other columns still have the same values they had when the dynaset was last refreshed.
我们的一个表单会偶尔生成此错误消息。该问题出现在我们的订单上，该订单绑定到链接的 SQL Server 2008 table。打印通知单（使用报告）后，订单状态将设置为 'Printed Order'。此时，我偶尔会看到“-2147352567 数据已更改”错误。我会说 95% 的时间，这不会发生，但让我们头疼的是另外 5%（以及无数支持电话）。
奇怪的是，关闭表单并尝试对订单执行相同的操作会导致相同的错误消息，但关闭数据库并再次尝试会正常。
就好像对表单绑定的 table/record 有一些未提交的更改，即使没有打开的表单、报告等也存在。
代码如下所示：
Select Case Me.txtCurrentStatus
Case NEW_ORDER, UNPRINTED_ORDER:
Me.txtCurrentStatus = PRINTED_ORDER
End Select
'Commit changes
If Me.Dirty = True Then Me.Dirty = False
@iDevelop 实际上促使我考虑向 table 添加时间戳，所以我只接受了部分功劳 ;)...
简而言之 - 在 Microsoft Access 中使用链接的 table 时，如果 table 不包含 timestamp 类型的列，Access 将比较table 中的每一列，以查看自检索记录以来数据是否已更改。 Access 无法可靠地检查多种数据类型（请参阅下面的文章）。只需添加类型为 timestamp 的列即可更改此行为，而 Access 只会检查 rowversion 是否已更改...这会进行此检查更可靠，也提高了性能。
奇怪的是，这根本不是真正的时间戳 - 它是一个行版本，但在 SQL Server 2008 中，我正在使用 行版本 不可用通过 GUI。
参见https://technet.microsoft.com/en-us/library/bb188204%28v=sql.90%29.aspx。
Probably the leading cause of updatability problems in Office Access–linked tables is that Office Access is unable to verify whether data on the server matches what was last retrieved by the dynaset being updated. If Office Access cannot perform this verification, it assumes that the server row has been modified or deleted by another user and it aborts the update.
There are several types of data that Office Access is unable to check reliably for matching values. These include large object types, such as text, ntext, image, and the varchar(max), nvarchar(max), and varbinary(max) types introduced in SQL Server 2005. In addition, floating-point numeric types, such as real and float, are subject to rounding issues that can make comparisons imprecise, resulting in cancelled updates when the values haven't really changed. Office Access also has trouble updating tables containing bit columns that do not have a default value and that contain null values.
A quick and easy way to remedy these problems is to add a timestamp column to the table on SQL Server. The data in a timestamp column is completely unrelated to the date or time. Instead, it is a binary value that is guaranteed to be unique across the database and to increase automatically every time a new value is assigned to any column in the table. The ANSI standard term for this type of column is rowversion. This term is supported in SQL Server.
Office Access automatically detects when a table contains this type of column and uses it in the WHERE clause of all UPDATE and DELETE statements affecting that table. This is more efficient than verifying that all the other columns still have the same values they had when the dynaset was last refreshed.