简介一份面向C#入门者与中小型Web项目开发者的示例资料围绕在ASP.NET Web Forms环境下查询Access数据库展开涉及OleDbConnection建立连接、OleDbCommand执行SQL语句、OleDbDataReader逐行读取结果以及GridView绑定展示、参数化查询防注入与连接资源释放等要点。压缩包共62个文件、约973KB以9个cs源码、4个sln解决方案、4个resx资源文件、3个csproj项目文件为主体另含asax、asmx、wsdl等Web服务配置文件与Northwind.mdb示例数据库客户端与WebService两端工程结构完整。目前已有245人学习下载。读者可对照源码梳理ADO.NET访问Access的完整调用链理解Web页面取数的实现方式也可作为课程设计或小型管理系统的起步骨架。1. 从一份 .mdb 说起Web 查询 Access 到底难在哪某公司内部有一份用了很多年的 Access 台账.mdb 文件躺在共享盘里同事要查一条记录得先找一台装了 Office 的电脑打开文件、翻表、按 CtrlF。需求很朴素做一个内网页面输入关键词就能查。真动手做「如何以 Web 方式查询 Access 数据库」这件事用 C# 写页面只是最轻松的一环真正耗费时间的是 OleDb 驱动的位数对不上、Access SQL 方言和标准 T-SQL 的差异以及 Access 那套文件级锁。这个项目适合手上有几份 .mdb/.accdb 想把它们变成内网查询站的人也适合已经写好查询但部署到服务器就报「未注册提供程序」的人。2. 环境与工程骨架.NET OleDb 连接层怎么搭要把 Access 包成 HTTP 服务工程骨架不需要多复杂三层足够一个只负责产连接的数据访问层一个封装方言差异的查询服务一个薄的 API/页面层。这套结构后面换数据库时能省下大量返工所以一开始就别把 OleDb 的代码摊到 Controller 里。2.1 驱动选择与位数对齐Access 文件有两代格式驱动也有两套。.mdb是 Jet 4.0 时代的东西Microsoft.Jet.OLEDB.4.0能开但它只有 32 位版本在 64 位进程里根本加载不了.accdb必须用Microsoft.ACE.OLEDB.12.0或 16.0ACE 引擎同时提供 32 位和 64 位两种安装包。我的习惯是统一装 ACE.mdb也走 ACE 打开少维护一套分支。麻烦点在于同一台机器上 32 位和 64 位的 ACE 不能随便共存先装的会占住注册表项后装的安装程序可能直接拒绝。所以第一件事是确定宿主的位数——IIS 应用池是不是开了「启用 32 位应用程序」dotnet run用的是 x64 还是 x86。位数定了再去装对应版本的 Access Database Engine 运行时顺序反了就要卸载重装这是纯浪费时间。.NET 这边需要System.Data.OleDb这个 NuGet 包它只支持 Windows。工程文件写成下面这样把目标框架锁到 windows 变体能避免一堆 CA1416 平台兼容警告Project SdkMicrosoft.NET.Sdk.Web PropertyGroup !-- OleDb 只在 Windows 上有实现TFM 直接锁死 -- TargetFrameworknet8.0-windows/TargetFramework Nullableenable/Nullable ImplicitUsingsenable/ImplicitUsings /PropertyGroup ItemGroup !-- 8.x 起官方单独发包不再内置在共享框架里 -- PackageReference IncludeSystem.Data.OleDb Version8.0.0 / /ItemGroup /Projectnet8.0-windows不是随便写的System.Data.OleDb包里带的是 win-x64 / win-x86 的原生资产把 TFM 写成跨平台的net8.0也能编过但发布到 Linux 容器里运行时会直接抛PlatformNotSupportedException。这一点在本地开发机上完全看不出来等到上容器才炸。2.2 连接字符串与工厂类连接字符串别用字符串拼接用OleDbConnectionStringBuilder组装键名写错会在 Open 的时候才报错builder 至少能让配置读起来清楚一点。配置放appsettings.json{ AccessDb: { Provider: Microsoft.ACE.OLEDB.12.0, DataSource: D:\\AccessData\\ledger.accdb, Password: , ReadOnly: true, Pooling: false } }ReadOnly和Pooling这两个开关是这个项目的核心参数。只读模式下连接不会在数据目录里生成.ldb锁文件也就不会因为目录没写权限而失败关池化是为了避免文件被替换后页面还在读旧连接。工厂类负责把这些配置翻译成连接串public sealed class AccessConnectionFactory { private readonly string _connectionString; public AccessConnectionFactory(IConfiguration cfg) { var s cfg.GetSection(AccessDb); var builder new OleDbConnectionStringBuilder { Provider s[Provider] ?? Microsoft.ACE.OLEDB.12.0, DataSource s[DataSource] ?? throw new InvalidOperationException(未配置数据源路径) }; // 数据库设了密码时必须走这个键名写成 Password 是无效的 var pwd s[Password]; if (!string.IsNullOrEmpty(pwd)) { builder[Jet OLEDB:Database Password] pwd; } // Read 模式打开不创建 .ldb也不锁写 if (s.GetValue(ReadOnly, true)) { builder[Mode] Read; } // -4 表示关闭 OLE DB 服务组件的池化文件被替换后立刻生效 if (!s.GetValue(Pooling, false)) { builder[OleDbServices] -4; } _connectionString builder.ConnectionString; } public OleDbConnection Create() new(_connectionString); }逻辑上就三件事把 provider 和数据源塞进 builder密码用Jet OLEDB:Database Password这个专用键普通的PasswordAccess 引擎不认OleDbServices-4是个位标志数值上等于「关池化 关事务自动登记」副作用是每次 Open 都真去开文件QPS 会掉一些但对一个内网查询站来说完全够用换来的是改完数据文件刷新页面就能看到。配置里的DataSource建议写绝对路径。用相对路径时基准是当前工作目录dotnet run和 IIS 托管下的工作目录不一样本地跑得好好的一发布就找不到文件这类问题排查起来最费劲。2.3 工程分层与目录结构目录按职责切不按技术名词堆AccessWebQuery/ ├─ Program.cs # 注册服务、映射最小 API ├─ appsettings.json # 连接配置 ├─ Data/ │ ├─ AccessConnectionFactory.cs # 只负责产连接 │ ├─ AccessSchemaReader.cs # 读表/字段/主键元数据 │ └─ AccessQueryRepository.cs # 拼 SQL、执行、读结果 ├─ Services/ │ ├─ QueryService.cs # 白名单校验 分页编排 │ └─ CsvExporter.cs # 结果导出 ├─ Models/ │ ├─ QueryRequest.cs │ └─ PagedResult.cs └─ wwwroot/ └─ index.html # 一个静态页fetch 调接口AccessSchemaReader和AccessQueryRepository分开是刻意的前者只读元数据后者只跑数据查询表结构缓存挂在前者身上不会跟查询逻辑纠缠。QueryService是关键的一层所有来自前端的表名、字段名、排序方向都在这里过一遍白名单过完才允许进 Repository。前端用静态页加fetch不引框架一个内网查询站没必要为几十行交互背一个打包链。Program.cs 里注册成单例即可工厂类本身无状态连接是每次用完就释放的builder.Services.AddSingletonAccessConnectionFactory(); builder.Services.AddSingletonAccessSchemaReader(); builder.Services.AddScopedAccessQueryRepository(); builder.Services.AddMemoryCache();3. 元数据与查询构造先把表结构读出来再拼 SQLAccess 没有information_schema也没有sys.tables表结构得靠 OleDb 的 schema 接口拿。这一步做完前端才能给出「选表 → 选字段 → 填条件」的下拉框后端也才有白名单可以校验。3.1 用 GetOleDbSchemaTable 摸清表与字段OleDbConnection.GetOleDbSchemaTable是这套东西的入口传入不同的 Guid 拿不同的元数据集合。取表用OleDbSchemaGuid.Tables四个限制参数依次是 catalog、owner、table、table type只想拿用户表就把类型填TABLEpublic IReadOnlyListstring ListTables() { using var conn _factory.Create(); conn.Open(); // 第 4 个限制位填 TABLE过滤掉 VIEW / SYSTEM TABLE var dt conn.GetOleDbSchemaTable( OleDbSchemaGuid.Tables, new object?[] { null, null, null, TABLE }); return dt!.Rows.CastDataRow() // Access 的系统表以 MSys 开头界面上不该出现 .Select(r r[TABLE_NAME].ToString()!) .Where(n !n.StartsWith(MSys, StringComparison.OrdinalIgnoreCase)) .OrderBy(n n) .ToList(); }字段信息用OleDbSchemaGuid.Columns第三个限制位填表名返回的 DataTable 里有COLUMN_NAME、DATA_TYPEOLE DB 类型枚举值、IS_NULLABLE、ORDINAL_POSITION。主键单独查OleDbSchemaGuid.Primary_Keys它的COLUMN_NAME就是主键列。分页要靠主键所以这三份数据要一起返回给前端。元数据不需要每次请求都读Access 打开文件本身有开销我一般挂IMemoryCache缓存十分钟同时记一个文件的LastWriteTimeUtc时间戳变了就主动失效。表结构改完不用重启站点这个体验对维护的人很友好。DATA_TYPE返回的是 OLE DB 的整型枚举比如 130 是字符串、7 是日期不是 SQL 类型名。要展示成人能看懂的类型得自己维护一张映射表别指望它给出nvarchar(50)这种带长度的描述——Access 的短文本在元数据里根本拿不到长度。3.2 标识符白名单与动态 SQL 的边界表名、字段名、排序方向这三样没法参数化只能拼进 SQL所以必须过白名单。最省事的写法是正则但我更倾向「跟 schema 结果精确比对」——正则永远有漏网的写法而 schema 里存在什么是确定的public QueryPlan BuildPlan(QueryRequest req, AccessSchema schema) { // 1. 表名必须是 schema 里真实存在的大小写不敏感 var table schema.Tables.FirstOrDefault(t string.Equals(t.Name, req.Table, StringComparison.OrdinalIgnoreCase)) ?? throw new ArgumentException($未知的表{req.Table}); // 2. 字段逐个校验任何一个不在表里就整单拒绝 var columns req.Columns.Count 0 ? table.Columns.Select(c c.Name).ToList() : req.Columns.Select(c table.Columns.FirstOrDefault(x string.Equals(x.Name, c, StringComparison.OrdinalIgnoreCase))?.Name ?? throw new ArgumentException($未知的字段{c})).ToList(); // 3. 排序方向只允许两个枚举值不接受前端传自由文本 var direction req.Descending ? DESC : ASC; // 4. 标识符统一用 [] 包裹处理空格和中文列名 var columnList string.Join(, , columns.Select(c $[{c}])); var sql $SELECT {columnList} FROM [{table.Name}]; return new QueryPlan(sql, table, direction); }这段代码的重点在第 2 步的?? throw如果前端传了Drop Table之类的表名它连FirstOrDefault都过不了直接抛参数异常后面的 SQL 拼装根本执行不到。把校验放在拼 SQL 之前而不是执行时再判断是这套逻辑唯一正确的顺序。第 4 步的方括号不能省。Access 的列名允许空格、中文、甚至和关键字重名[订单 明细]、[Date]、[Value]这些不加方括号会直接语法错误。如果你从 Excel 或者旧系统导入过数据字段名前带空格也是很常见的事。3.3 Access SQL 方言速查写完白名单接下来一定会撞上方言下表是我这一个项目里遇到过的差异可以直接当备忘场景标准 T-SQLAccess / Jet SQL取前 N 行SELECT TOP 10 *同左但TOP后面不能跟参数占位符分页OFFSET ... FETCH没有 OFFSET要TOP套子查询字符串拼接或CONCAT且空值当空串处理条件表达式CASE WHEN只有IIF(cond, a, b)空值处理COALESCENZ(expr, 0)日期字面量2024-01-01#2024-01-01#参数化时传 DateTime 即可LIKE 通配符%_默认是*?布尔值1/0或TRUETrue/False字面量有效NZ和IIF这两个函数名在标准 SQL 里不存在但写 Access 查询时很顺手尤其是老表允许空值、你又不想在前端处理 null 的时候。LIKE那行的坑要单独说ACE/Jet 默认走 ANSI-89 的通配符%会被当成普通字符所以LIKE %关键词%查出来永远是空结果。要么改用*关键词*要么去 Access 里打开「SQL Server 兼容语法ANSI 92」选项二选一不能混着来。我在同一个项目里两种都见过——老库是 ANSI-89新建的 .accdb 开的是 ANSI-92代码里只能通过配置项容忍这种不一致。4. 查询执行链路参数化、分页与结果导出SQL 拼好之后就到执行层。Access 的执行层有两个特性必须提前设计进去OleDb 的参数是按位置绑定的以及 Access 不支持 OFFSET 分页。这两点决定了 Repository 的接口长什么样。4.1 参数化查询与 OleDb 的位置绑定OleDb 用的是?占位符OleDbParameter的ParameterName会被忽略。也就是说下面的 SQL 里两个参数谁先谁后完全由Parameters.Add的调用顺序决定跟你命名的kw、start没有关系public ListDictionarystring, object? Search(string table, string column, string keyword, DateTime from) { using var conn _factory.Create(); conn.Open(); // Access 的 LIKE 通配符默认是 * 而不是 %这里按 ANSI-89 写 var sql $SELECT TOP 200 * FROM [{table}] $WHERE [{column}] LIKE ? AND [CreatedAt] ? ORDER BY [CreatedAt] DESC; using var cmd new OleDbCommand(sql, conn); // 顺序必须与 SQL 中 ? 出现的顺序严格一致名字只是给人看的 cmd.Parameters.AddWithValue(kw, $*{keyword}*); cmd.Parameters.AddWithValue(from, from); using var reader cmd.ExecuteReader(); var rows new ListDictionarystring, object?(); while (reader.Read()) { var row new Dictionarystring, object?(StringComparer.OrdinalIgnoreCase); for (var i 0; i reader.FieldCount; i) { row[reader.GetName(i)] reader.IsDBNull(i) ? null : reader.GetValue(i); } rows.Add(row); } return rows; }参数说明kw传入的是带通配符的完整模式串通配符拼接要在 C# 侧完成不能写成LIKE * ? *Access 不支持这种表达式。from直接传DateTime对象OleDb 会按列类型转换不要自己ToString(yyyy-MM-dd)再拼进#...#那样在不同区域设置下会翻车。代码里两个AddWithValue的顺序就是唯一的绑定依据。曾经有人为了「可读性」写成from在前、kw在后SQL 里?的顺序又没改结果查询不出错也不报异常只是永远返回空集——参数错位不会抛异常它只会静默给你错误的结果。这是 OleDb 最典型的一类问题。reader.GetValue返回的是objectAccess 的日期列会以DateTime出来货币列以decimal备注列Memo以string。序列化成 JSON 前不需要额外处理System.Text.Json能直接吃这些类型。4.2 分页的写法与代价Access 没有OFFSET分页只能靠TOP加子查询。最通用的一种是「用主键排除前 N 条」public PagedResultDictionarystring, object? QueryPage(QueryPlan plan, int page, int size) { var offset (page - 1) * size; // 外层再套一层 TOP内层先把前 offset 条的主键排除掉 var sql offset 0 ? $SELECT TOP {size} * FROM [{plan.Table}] ORDER BY [{plan.Key}] {plan.Direction} : $SELECT TOP {size} * FROM [{plan.Table}] $WHERE [{plan.Key}] NOT IN ( $ SELECT TOP {offset} [{plan.Key}] FROM [{plan.Table}] ORDER BY [{plan.Key}] {plan.Direction} $) ORDER BY [{plan.Key}] {plan.Direction}; var total CountAll(plan); var rows Execute(sql); return new PagedResultDictionarystring, object?(rows, total, page, size); }size和offset是整数来自服务端计算不是前端直接透传的字符串所以拼进 SQL 是安全的。plan.Key是主键列名前面已经过 schema 校验。NOT IN这套写法在第 1 页时退化成一句普通TOP性能最好页码越深内层子查询扫的行越多到几千页之后明显变慢。对 Access 这种文件数据库我一般直接限制最大页码比如只允许翻到第 200 页前端提示「请缩小查询范围」。比优化 SQL 更有效的是把筛选条件用起来——让用户在翻页前先选时间范围物理行数降下来分页怎么写都快。还有一个替代方案是先把符合条件的全部主键读进内存再用Skip/Take切片。数据量小于几万行时这么干反而更快因为省掉了内层子查询的重复扫描。缺点是内存占用不可控所以我把它做成配置项默认关闭。4.3 结果序列化与 CSV 导出内网查询站的刚需往往不是页面好看而是「把结果导出来发给人」。CSV 导出要处理三件事中文编码、逗号转义、以及null和空字符串的区分。public static byte[] ToCsv(IReadOnlyListstring headers, IEnumerableDictionarystring, object? rows) { var sb new StringBuilder(); sb.AppendLine(string.Join(,, headers.Select(Escape))); foreach (var row in rows) { sb.AppendLine(string.Join(,, headers.Select(h Escape(row.TryGetValue(h, out var v) ? v?.ToString() : null)))); } // 带 BOM 的 UTF-8Excel 直接双击打开不乱码 return Encoding.UTF8.GetPreamble().Concat(Encoding.UTF8.GetBytes(sb.ToString())).ToArray(); } private static string Escape(string? value) { if (string.IsNullOrEmpty(value)) return ; // 含逗号、引号、换行时整体加引号内部引号翻倍 var needQuote value.Contains(,) || value.Contains() || value.Contains(\n) || value.Contains(\r); return needQuote ? $\{value.Replace(\, \\)}\ : value; }Escape里的四个判断缺一不可。只判断逗号的话字段里带换行的备注列会把整行拆散导出来的文件行数对不上但打开看又「好像没错」这种问题最难被发现。BOM 那行是血泪经验不带 BOM 的 UTF-8 CSV 在 Excel 里默认按本地代码页解析中文全是乱码收到文件的人第一反应是「你导的数据有问题」。导出走流式响应别先拼成一个大byte[]再返回。Access 备注字段单条能到几 MB几千行攒下来内存直接起飞。app.MapGet(/api/export, async (string table, string? keyword, HttpResponse resp) { resp.ContentType text/csv; charsetutf-8; resp.Headers.ContentDisposition $attachment; filename\{table}-{DateTime.Now:yyyyMMddHHmm}.csv\; await using var stream resp.Body; await CsvStreamer.WriteAsync(stream, table, keyword); });5. 避坑与排查五个真实翻车现场这个项目上线过程中踩的坑八成不在代码逻辑里而在驱动、权限和文件特性上。下面五条按「现象 → 原因 → 解决」记下来遇到同类问题可以直接对照。5.1 驱动与部署三条现场记录现象一本地dotnet run一切正常发布到 IIS 后所有查询报「未在本地计算机上注册 Microsoft.ACE.OLEDB.12.0 提供程序」。原因是位数不匹配。开发机装的是 64 位 ACEdotnet run默认 x64 进程能加载IIS 那个应用池如果开了「启用 32 位应用程序」w3wp 变成 32 位进程就找不到 64 位的 provider反过来也一样。解决方式是先确认应用池位数再装对应位数的 Access Database Engine 运行时。改完要回收应用池光重启站点不够。如果同一台机器上还要跑别的必须用另一种位数的站点就得接受两个应用池位数不同或者把 Access 访问拆到独立的小服务里。现象二浏览器直接访问/data/ledger.accdb整个数据库被下载走了。原因是文件放在wwwroot下面。静态文件中间件不管文件类型只要路径能对上就发。解决方式是把数据文件挪到站点根目录之外比如D:\AccessData\配置文件里写绝对路径。如果因为历史原因必须留在站点内就在UseStaticFiles之前加一段路径拦截同时把.mdb、.accdb、.ldb三个扩展名写进拒绝列表。这件事没有折中方案权限系统做得再好文件被直接下走就全白搭。现象三改了 .accdb 文件里的数据页面刷新还是旧值重启站点才更新。原因是连接池。OleDb 默认会缓存物理连接一段时间连接字符串不变就复用而复用的连接持有的是旧的文件句柄。解决方式是连接字符串里加OleDbServices-4关掉池化或者在连接串末尾拼一个数据文件最后修改时间的哈希文件一变连接串就变池自然失效。前一种简单粗暴后一种性能更好看站点访问量选。5.2 查询与并发两条现场记录现象四关键词搜索框输入任何内容都返回空列表但数据库里明明有匹配的记录。原因是 LIKE 通配符。ACE/Jet 默认用 ANSI-89 语法%是普通字符LIKE %张%等价于查找包含「%张%」这五个字符的字符串当然查不到。解决办法是把模式串改成*张*或者去数据库选项里打开 ANSI-92 兼容模式。要注意这个设置是跟着 .accdb 文件走的同一个站点连两个库可能一个要*一个要%只能做成配置项别硬编码。现象五多个同事同时查询偶尔有人报「操作必须使用一个可更新的查询」或者「无法锁定文件」目录里还残留.ldb。原因是 Access 是文件级锁写操作会独占读操作之间本来可以并行但如果连接是以读写模式打开的多个连接抢锁就会冲突。解决办法是查询站一律用ModeRead打开彻底不参与写锁真需要写入的场景单独做一个队列串行化处理。另外数据目录必须给应用池身份写权限因为即使是只读打开Access 也可能在目录里创建临时文件目录只读会导致连接失败报的却是看起来毫不相关的错误。提示排查 Access 连接问题时先单独写一个控制台程序用同样的连接串跑一次conn.Open()。能开就是 Web 层的问题权限、位数、池化开不了就是驱动或路径的问题。这一步能把排查范围砍掉一半。6. 二次开发把 Access 关进笼子里这套代码要长期维护关键不是把功能做全而是把 Access 的可变部分收敛到少数几个文件里将来换库或者加权限时不用翻遍整个工程。6.1 抽一层查询接口隔离方言第一步是定义IAccessQueryService把「按条件查一页」和「读表结构」两个方法暴露出去Controller 只依赖接口。Repository 里所有跟 Access 有关的写法——方括号、TOP、*通配符、NZ——全部封在实现类里面。将来数据量涨到 Access 撑不住换 SQLite 或 SQL Server 只需要新写一个实现上层一行不改。改造顺序建议这样先把AccessQueryRepository里的 SQL 拼装抽成ISqlDialect把Top、LikePattern、Pagination三个方法做成接口再让 Access 实现类和 SQLite 实现类分别实现它最后加一组冒烟 SQL覆盖「首页查询、深分页、带空值列、中文列名、日期范围」五个场景换实现后跑一遍全绿才算完。这套动作大概半天但能省掉后面无数次的「这里为什么写死了方括号」。6.2 缓存与失效别让文件时间戳骗了你查询站的读多写少特性很适合加缓存但失效条件要选对。用文件LastWriteTimeUtc做 key 是常见做法问题是网络共享盘上的时间戳精度可能只到秒同一秒内改两次就失效不了。我的做法是时间戳加文件长度做联合 keypublic string BuildCacheKey(string dataSource) { var fi new FileInfo(dataSource); // 秒级时间戳 字节长度单靠时间戳在共享盘上会漏失效 return ${fi.LastWriteTimeUtc.Ticks}:{fi.Length}; }缓存只放元数据和小结果集单条结果超过 200 行就不进缓存直接查。这样内存占用可控也不会出现「数据改了十分钟页面还是旧的」这种投诉。改造点投入收益抽ISqlDialect接口半天换库零改动元数据缓存 时间戳失效1 小时每次请求少开一次文件只读连接模式10 分钟消除大部分锁冲突CSV 流式导出2 小时大结果集不爆内存我在这类项目上养成的一个习惯是任何一次「查不到数据」的报障先不看业务代码直接拿连接串跑三条验证 SQL——SELECT COUNT(*)、带通配符的LIKE、带日期参数的过滤。三条都正常才去怀疑上层。因为 Access 的失败方式太沉默了参数错位不报错、通配符写错不报错、连接池拿旧数据也不报错它只会给你一个空列表。从那以后我每次改完查询层都强制走一遍这三条冒烟 SQL 再提测比事后对着日志猜快得多。希望帮到你。本文还有配套的精品资源点击获取
