我最初尝试重新创建您的问题失败。我在我的32位测试VM上使用了以下代码：

• 访问2010
• SQLite 3.8.2软件包
• SQLite ODBC驱动程序0.996

我创建并填充了测试表[tbl1]，并记录为here。我创建了一个Access链接表，并在出现提示时选择了两列（[one]和[two]）作为主键。当我在“数据表视图”中打开链接表时，我可以添加、编辑和删除记录，而不会发生意外。
我可以看到我的设置和您的设置之间的唯一区别（除了我使用的是32位而您使用的是64位这一事实之外）是，在ODBC DSN设置中，我将Sync.Mode设置保留为默认值NORMAL，而您的设置似乎设置为OFF。
尝试将您的Sync.Mode设置为NORMAL，看看是否会有不同。

编辑回复：注解

这种情况下的解决方案如下：
一种可能的解决方法是创建一个新的SQLite表，该表包含所有相同的列以及一个新的INTEGER PRIMARY KEY列，Access将“看到”该列作为AutoNumber。您可以在（当前的）前四列上创建一个唯一索引，以确保它们保持唯一性，但Access将使用新的“标识”（ROWID）列来标识CRUD操作的行。

我也遇到过这个问题。我有一个表的主键在VARCHAR（30）（TEXT）字段上。
添加INTEGER PRIMARY KEY列根本没有帮助。经过大量测试后，我发现问题出在表中的DATETIME字段上。我删除了DATETIME字段，并能够在MS-Access数据表视图中更新记录值。
现在，我在SQLite中需要的任何DATETIME字段，我都声明为VARCHAR（19），这样它们就可以通过ODBC以文本的形式进入Access。虽然不完美，但它可以工作。（当然，SQLite没有真正的DATETIME字段类型，所以TEXT就可以了，可以转换为OK）
我确认这是一个数字转换问题。如果DATETIME字段为空，我可以通过Access的数据表视图添加时间01 - 01 - 2014 12：01：02，如果我在SQLite中查看该值，则秒数已四舍五入：

sqlite> SELECT three from TEST where FLoc='1020';
2014-01-01 12:01:00.000

SYNCMODE也应该是NORMAL而不是OFF。

• • 更新：**如果您有任何具有定义长度的文本字段（例如foo VARCHAR（10）），并且字段内容包含的字符数多于字段定义（SQLite允许），则MS-Access在尝试更新该行上的 * 任何 * 字段时也会呕吐。

我搜索了所有类似的帖子，因为我在通过ODBC链接到Access的SQLite中遇到了类似的问题。我有三个表，其中两个允许编辑，但第三个不允许。第三个表有一个DATETIME字段，当我将原始SQLite数据库中的数据类型更改为TEXT字段并重新链接到Access时，我可以编辑该表。所以对我来说，这被确认为DATETIME字段的问题。

在遇到这个问题后，没有找到满意的答案，并且浪费了大量时间尝试其他解决方案，我最终发现其他人提到的关于DATETIME字段的内容是准确的，但是存在另一种解决方案，可以让您保持正确的数据类型。SQLite ODBC驱动程序可以通过在列中查找浮点值，将儒略日值转换为ODBC SQL_TIMESTAMP / SQL_TYPE_TIMESTAMP类型，如果您在驱动程序中启用了该选项，则可以使用该选项。以这种方式存储日期可以使ODBC时间戳值具有足够的精度，以避免写入冲突错误，同时还可以使Access将该列视为日期/时间字段。
甚至在日期字符串中存储亚秒精度也不起作用，这可能是驱动程序中的一个错误，因为生成的TIMESTAMP_STRUCT包含相同的值，但小数秒必须在其他位置丢失。