显示为 #DELETED 的行

Posted 2023-05-06

【中文标题】显示为 #DELETED 的行

【英文标题】：Rows showing as #DELETED

【发布时间】：2012-03-12 00:37:07

【问题描述】：

在使用 Access 时，我在一台计算机上显示为 #DELETED 的表中有数据行，但它们在 SQL 数据库和其他使用 Access 的计算机上都很好。它似乎只有最新的 200 行。 Access 2007 版本和 ODBC MSJet 驱动程序在每台计算机上看起来都是相同且最新的。一个建议是将任何 PK 或 FK 更改为 int，但它们已经是。

对此有什么解决办法吗？

【参考方案1】：

当表的主键值超出 MS Access 支持的范围时会发生这种情况，通常如果您在 SQL Server 中使用“BigInt”类型，如果您只是想读取数据，那么只需创建一个“snap- shot”查询表，所有行都会正确显示，因为“snap-shot”不需要读取所有索引。

如果您需要随时更新这些行中的数据，那么我建议您改用 ADO 记录集。

【讨论】：

如果这是一个访问问题，它会如何只影响一个用户而不是同时影响所有人？

很难调用，设置可能存在细微差别，也许是服务包或补丁级别，32 位与 64 位，没有单独看到这两个实例恐怕是个谜。

我问的原因是，我在我正在进行的一个项目中偶尔看到过这种情况，但它不会同时影响多个用户，而且通常会自行消失。显然我宁愿完全避免它，但如果它是被广泛报道的“bigint”问题，我应该认为它应该更普遍一些。

此回复中要注意的主要是“bigint”是 Access 无法处理的内容，您应该转换为其他内容。

请注意，更高版本的 Access 2016 do 支持 BigInt 字段。当然，这个答案在编写时是完全有效的。

【参考方案2】：

有一个选项可以在较新版本的 Access 上支持 BigInt 数据类型。

File > Options > Current Database > Data Type Support Options

应用该选项，然后刷新您的表格。

【讨论】：

对于任何对此选项感兴趣的人 -- 当您勾选复选框时，您将收到一条警告，指出该文件将无法再在 Access 2013 或更早版本的 Access 中打开。此外，我发现这仅在我使用链接表管理器重新链接我的 ODBC 表之后才对我有用。

是的，确认迈克的评论。很好的解决方法，无需在 SQL Server 中创建另一个视图。但是您必须在 Linked Table Mgr 中重新链接 SQL 视图才能工作。

【参考方案3】：

考虑使用 numeric (18,0) 而不是 bigint 作为 SQL 中的主键数据类型。如果在 SQL Server 端将其设置为数字数据类型，MS Access 可以解析有效的大整数 PK。我在带有 Access 2010 的 SQL 2008R2 上遇到了同样的问题，在使用 bigint PK 时，所有行都显示为“#DELETED”。

【讨论】：

感谢您的信息，我会尽快试用。但是你有没有看到这个：***.com/questions/6838374/…？不确定十进制与数字是否有很大差异。

【参考方案4】：

多年来，我一直将 Access 前端连接到 SQL Server 2000、2008 R2 和 2014，没有出现任何问题。硬盘出现故障后，我在 Windows 7（64 位）计算机上重新安装了 SQL Server 2014 Developer，当移动到新记录或单击功能区上的“保存”时，突然间，我的 Access 2010 表单在每个字段中都出现了可怕的#Deleted。

这很奇怪，因为在另一台计算机上安装相同的 Windows 7（64 位）没有问题。嗯，几乎一模一样。在新硬盘上安装 SQL Server 2014 后，我发现只安装了 Native Client 11.0 驱动程序，因此我在 Access VBA 代码中修改了 ODBC 连接字符串以使用 DRIVER=SQL Server Native Client 11.0。使用 Access 表单时，我立即开始在插入记录的每个字段中获取 #Deleted。

调查显示正确处理插入记录的“好”计算机与 #Deleted 的“坏”计算机之间的区别在于是否存在 Native Client 10.0 驱动程序。我从 Microsoft 下载了 10.0 驱动程序，安装它并检查我的代码以确保所有 ODBC 连接字符串都使用 DRIVER=SQL Server Native Client 10.0。

现在一切正常，不再出现#Deleted 问题。

【参考方案5】：

如果在 SQL 使用 ROW_NUMBER() 函数的字段上设置主键，则可以将其强制转换为 int。默认情况下，ROW_NUMBER() 是 int64 (bigInt)。

【参考方案6】：

只是想添加对我有用的解决方案。

我将一些视图链接到 MS Access 并且它们工作正常。一段时间后，我更改了之前为 Integer 的列之一的类型，并创建了 VARCHAR。由于此列是我的表的主键（我在 MS Access 中添加视图时也选择了它作为主键），因此在更改后它开始显示“#DELETED”。为了解决这个问题，我只是用“ALTER VIEW”语句重新执行了相同的视图，并使用了sp_refreshview'VIEW_NAME'。

这样做之后，它开始为我工作。 希望这对面临同样问题的人有所帮助。

【参考方案7】：

我遇到了同样的#DELETED 问题，这是因为主键数据类型是 bigint 。当我查询由第三方应用程序创建的表时，我无法修改数据类型，所以我在表上创建了一个视图并使用 CAST 将数据类型转换为 int（之后检查表中保存的值不会导致溢出）。

【参考方案8】：

将 Access 指向 SQL 2017 数据库（以前指向 SQL 2008R2 数据库）时，可能会发生这种奇怪的行为。当我们使用更新的 ODBC 驱动程序（SQL Native Client 11）创建新的 DSN 时，行为恢复正常。

【讨论】：

我们的数据库运行良好，然后开始无故返回#deleted，重新创建现有的 DSN 解决了​​这个问题。感谢您的提示。

【参考方案9】：

我遇到了一个奇怪的情况，查询将数据返回为#Deleted，但我会再次运行（刷新查询中的结果）并且数据会正确......有时。然后我将查询结果写入一个表以查看是否有帮助，并且数据实际上已写入，但包含其他表 (int(11)) 的外键的行将返回零作为值。设置了访问中的 BigInt 配置（并且在 odbc 驱动程序中设置了将 bigint 绑定为字符串的检查 - 以前安装的习惯）。

经过大量阅读和困惑，我决定卸载我的 ODBC 5.03.13 驱动程序并尝试使用旧版本。我碰巧安装了一个下载的 5.03.04 msi，并且我的数据库按预期工作。奇怪的解决方案，我不知道为什么它现在可以工作，但这花了我一天的工作！想我会分享它，希望这个解决方案可以帮助某人，以防关于这个主题的所有其他建议都用尽了（就像我所做的那样）。

【参考方案10】：

如果您从 SQL 上的视图链接表，那么由于 ROW_NUMBER() 是 bigint，MS Access 将显示#Deleted，但如果您刷新一行，它会显示该值。为了克服这个问题，你可以使用 cast。例如

CAST((Row_number() OVER(ORDER BY AllColumns.AnyColumnNameSuchAsDateColumn DESC)) AS INT) AS 'id', AllColumns.* FROM (SELECT AnyColumnNameSuchAsDateColumn, ...etc FROM YourTableName WHERE YourCondition) AS AllColumns