VB.NET中Dapper+Kimtoo.Bindingprovider操作Access数据库删除行报错

云原生阿岚

2026-8-16

解决方案

1. 检查Access连接字符串配置

确保使用符合Access格式的连接字符串，避免沿用MySQL的配置：

// .mdb格式（旧版Access）
string connString = @"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\YourDB.mdb;";
// .accdb格式（Office 2007+）
string connString = @"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\YourDB.accdb;Persist Security Info=False;";

初始化Kimtoo.DbContext时必须传入上述正确的Access连接字符串。

2. 修正删除操作的SQL语法

Access与MySQL的SQL语法存在差异，需调整参数占位符和语句格式：

Access使用@作为参数前缀，而非MySQL的?
确保删除语句的WHERE条件绑定正确的主键字段，示例：

// Dapper执行Access删除的正确写法
string sql = "DELETE FROM YourTable WHERE Id = @Id";
connection.Execute(sql, new { Id = deletedRowPrimaryKey });

若依赖Kimtoo.Bindingprovider自动生成SQL，需确认其是否适配Access语法，必要时手动覆盖删除逻辑。

3. 验证Kimtoo.DbContext对Access的适配性

确认Kimtoo.DbContext官方是否明确支持Access数据库，部分ORM工具对小众数据源的适配存在局限
绕过Kimtoo.DbContext，直接用Dapper执行删除操作，排查问题根源：

using (var conn = new OleDbConnection(connString))
{
    conn.Open();
    int affectedRows = conn.Execute("DELETE FROM YourTable WHERE Id = @Id", new { Id = targetId });
    // 若affectedRows为1，说明Dapper本身可正常操作Access，问题出在Kimtoo.DbContext的适配层
}

4. 获取详细异常信息

原异常仅提示来自Kimtoo.DbContext.dll，需捕获完整异常栈定位具体原因：

try
{
    // 你的删除同步逻辑代码
}
catch (Exception ex)
{
    string fullError = ex.ToString(); // 包含InnerException和调用栈
    // 查看fullError可获取具体错误，比如SQL语法错误、数据库只读、主键缺失等
}