如果更改位于“Memo”类型的字段中，则保存更改的行时出错
我们在 sql 服务器上有一个带有链接 (odbc) 表的 Access-db。有时，特定行的一列会出现罕见的问题：无法在类型备注字段中进行更多更改。 此特定行的其他列中的更改将照常保存。 错误消息类似于：另一个应用程序已更改该行，因此更新已被取消。
可能是什么原因，可以采取什么措施来防止这种行为？
和平 Ice
更新：
mdb 绝对没有损坏。里面只有odbc-connections，我们以只读模式使用它。我认为问题一定出在jet-engine和odbc-driver各自的sql-server之间。
和平
冰
We have a Access-db with linked (odbc) tables on an sql-server. Some times there is a rare problem with one column of a particular row: no more changes in the field of type memo are possible.
Changes in other columns of this particular rows are saved as normal.
The error-msg goes something like: annother application has changed the row and therefor the update has been canceled.
what could be the reason, what can be done to prevent this behaviour?
Peace
Ice
Update:
The mdb is definitively not corrupt. There are only the odbc-connections inside, we use it in read-only mode. The issue must be between the jet-engine and the odbc-driver respective the sql-server, that is what i think.
Peace
Ice
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您的数据存储在 Jet/ACE 后端中，我想说您的备忘录指针可能已损坏。由于您的数据位于 SQL Server 中并通过 ODBC 访问，因此这不是答案。但是，由于其他人可能会遇到 Jet/ACE 后端问题而参与此讨论，因此以下内容可能会有所帮助：
在 Jet/ACE 表中，备注数据不会与其他字段内联存储。相反，数据存储在其他地方的单独数据页中，并且内联存储的所有内容都是指向第一个外部数据页的指针。该指针容易损坏，并且是导致数据丢失的常见原因。
Tony Toews 的一些链接（最佳来源）：
Jet/ACE 上的一般参考源腐败
腐败症状
在第二个中，搜索3197，这可能是您遇到的问题的错误号。那里有一个链接解释了如何排除故障。
修复该问题后，您应该考虑重组数据表，以最大限度地降低备注字段损坏的风险。
我知道您没有使用 Access，但对于 Access 表单，一种解决方案是避免绑定备注字段，而是在未绑定的文本框中编辑它们。在 Access 表单的 OnCurrent 事件中，您可以将备注数据从表单的字段集合复制到其未绑定的文本框中，然后在文本框的 AfterUpdate 事件中，将其保存回表单的基础记录集。
对于所有应用程序，无论是否访问，将备忘录放在单独的表中会将备忘录字段指针与其余数据分开。如果您有一个备忘录，它可以是一个 1:1 表，如果您有多个备忘录，您将有一个 1:N，并且备忘录表必须有一个字段来指示备忘录类型。使用该结构，不必删除并重新创建主记录来修复损坏的指针 - 您所要做的就是删除备忘录表中损坏的记录。
If your data were stored in a Jet/ACE back end, I'd say you likely have a corrupted memo pointer. Since your data is in SQL Server and accessed via ODBC, that can't be the answer. But since others might come to this discussion who are encountering the problem with a Jet/ACE back end, the below might be helpful:
In Jet/ACE tables, memo data is not stored inline with the the other fields. Instead, the data is stored in separate data pages elsewhere and all that is stored inline is a pointer to the first of the external data pages. That pointer is susceptible to corruption and is a frequent cause of lost data.
Some links from Tony Toews (the best source for this):
General Reference Source on Jet/ACE Corruption
Corruption Symptoms
In that second one, search for 3197, which is likely the error number of the problem you're encountering. There's a link there that explains how to troubleshoot it.
After you've fixed it, you should consider restructuring your data tables to minimize the risk of memo field corruption.
I know you are not using Access, but for Access forms, one solution is to avoid bound memo fields, and instead edit them in unbound textboxes. In the Access form's OnCurrent event, you'd copy the memo data from the form's fields collection into the unbound textbox for it, and in the textbox's AfterUpdate event, save it back to the form's underlying recordset.
for all applications, Access or not, putting the memos in a separate table segregates the memo field pointer from the rest of the data. If you have one memo, it can be a 1:1 table, and if you have multiple memos, you would have a 1:N and the memo table would have to have a field to indicate the memo type. With that structure, the main record does not have to be deleted and recreated to fix a corrupted pointer -- all you have to do is delete the corrupted record in the memo table.