Access 中的数据单元“#Deleted” - ODBC、MySQL 和 BIGINT 唯一 ID

Posted 2023-05-07

【中文标题】Access 中的数据单元“#Deleted” - ODBC、MySQL 和 BIGINT 唯一 ID

【英文标题】：Data cells "#Deleted" in Access - ODBC, MySQL and BIGINT unique ID

【发布时间】：2014-10-13 14:04:06

【问题描述】：

我对通过 ODBC 连接到 mysql 服务器（不是 Microsoft SQL Server）的 MS Access 2007 表有问题。

如果 MySQL 表中的唯一标识符是 BIGINT - 所有单元格内容显示如下：“#Deleted”。

我找到了这篇文章：

"#Deleted" errors with linked ODBC tables (at support.microsoft.com)

它说：

您可以使用以下一些策略来避免这种情况 行为：

避免输入除唯一索引外完全相同的记录。

避免触发唯一索引和另一个字段更新的更新。

不要将 Float 字段用作唯一索引或作为唯一索引的一部分，因为这种数据类型存在固有的舍入问题。

使用 SQL 传递查询执行所有更新和插入，以便您准确了解发送到 ODBC 数据源的内容。

使用 SQL 传递查询检索记录。 SQL 传递查询不可更新，因此不会导致 “#Delete”错误。

避免在构成链接的 ODBC 表的唯一索引的任何字段中存储 Null 值。

但我没有任何“要避免”的事情。我的问题出在 BIGINT 中。为了确定是否是这样，我创建了 2 个表，一个带有 INT id，一个带有 BIGINT。就是这样。

我无法在生产数据库中将 BIGINT 更改为 INT。

有什么办法可以解决这个问题吗？

我正在使用：Access 2007，mysql-connector-odbc-3.51.30-winx64，MySQL 服务器 5.1.73。

【问题讨论】：

在 MySQL 连接器/ODBC 数据源配置对话框的“元数据”选项卡上，有一个“将 BIGINT 列视为 INT 列”设置。这有什么区别吗？

使用更新的 v5.1 版本的 MySQL Connector/ODBC 可能会更好。 v3.51 已经很老了。 FWIW，我刚刚使用 MySQL ODBC 5.1 Driver v5.01.13.00 进行了测试，我能够使用 Access 中的链接表轻松地操作具有 BIGINT 主键的 MySQL 表。

【参考方案1】：

您可以尝试将表单基于 Access 查询，并在查询中使用 CInt() 将 BIGINT 转换为 INT。这发生在表单处理之前。根据您的情况，您可能需要在查询中转换为字符串 (CStr())，然后手动处理验证用户是否使用 IsNumeric 输入了数字。这个想法是诱使表单不尝试解释数据类型，这似乎是您的问题。

【参考方案2】：

Access 2016 现在支持 BigInt：https://blogs.office.com/2017/03/06/new-in-access-2016-large-number-bigint-support/

【讨论】：

我尝试使用最新的 MS Access (Office 365)。还是有这个问题。

如果您对此进行测试，您会发现 ODBC 的功能与 Access 的功能之间存在冲突。 :-( 所以，不，MS 声称它支持 bigint，但没有正确实现。

【参考方案3】：

现在是 2019 年，使用来自 Oracle (v 8.0.17) 和 Access 365 (v 16.0.11904) 的最新 ODBC 驱动程序，问题仍然存在。

当勾选 ODBC“将 BIGINT 列视为 INT 列”并在 Access 选项中启用 Bigint 支持时，带有 Bigint #id 列（主键）的链接表显示为已删除。 Ruby 默认创建这些，所以我们不愿意摆弄它。

如果我们禁用以上两个选项，Access 会认为#id 列 bigint 是一个字符串并显示数据。但是字段类型不再是 bigint 或 int 了。

这很可悲，因为这个问题现在已经有将近 10 年的历史了。

【讨论】：

我猜想，在 2000 年的 Office 2003 中确实是完整的、经过打磨的，并且是无事可做的好产品。因此，他们解雇了在 Office 工作的整个团队，并聘请了一些孩子来制作丝带并删除他们不理解的东西（例如 Access 中的数据透视表）。太糟糕了。值得庆幸的是，Office 2003 仍在 Windows 7 中运行。

我同意你的看法，Kamil，MS Office 已经稳步倒退。它太复杂了，菜单被混淆了，通常它用果冻代替了精确度。但是，Access 仍然提供了我们能够找到的最好的 GUI SQL 编辑器，并且我们已经测试了很多！

【参考方案4】：

MySQL 驱动程序具有将BIGINT 值转换为INT 的选项。这会为您解决问题吗？

【讨论】：

这并不能解决问题，但即使这样做，当处理大于 int 支持的数字时，它也会再次产生问题。因此，它可能是对小型数据集的修复，但确实需要妥善解决。