Access 数据库引擎的优缺点。 SQLite 之后的生活

Question

不久前我问了一个问题，关于哪个本地数据库适合我的情况。 我需要从 .NET 代码和 VB6 访问数据库。 压倒性的反响是 SQLite。 然而，我决定放弃 SQLite，因为它唯一的 OLE DB 提供商对我的软件的每个部署副本收取版税。 它还需要在每台 PC 上运行激活程序。

在评估其他选项（SQL Server Compact 版本 - 几乎无法运行的 OLE DB 提供程序、Firebird - 不想为另一个驱动程序付费等...）之后，我得出的结论是，唯一可行的选择是使用 .由 Microsoft Access（或 Jet 引擎）创建的 MDB 文件。

我从90年代后期就没有使用过它了，所以我有以下问题想请教有使用过它的人。

1. 他们是否解决了数据库时不时损坏的问题？
2. 是通过 ADO.NET OLEDB Provider 从 C# 完成对 MDB 的访问，还是有一个本机解决方案（我似乎找不到它）。
3. 有没有可行的替代方案来替代 Access 中真正蹩脚的 SQL 编辑器？

谢谢。

Answer 1

我不会“返回”Access，而是坚持使用 SQLite 并使用 System.Data.SQLite 提供程序在 .NET 代码中进行 SQLite 数据访问。

然后，我只需创建一个简单的 COM 互操作 .NET 类，供 VB6 使用，该类包装了任何所需的 SQLite 数据访问功能。 最后，只需像 VB6 项目中的标准 COM 对象一样引用和使用它即可。

我对 Access 的了解可能有点过时，并且因糟糕的经历而产生偏差，但在合理范围内，我会在诉诸 Access 路线之前尝试大多数其他选择。

Answer 2

您是否考虑过SQL Server 2008 Express Edition（而不是SQL Server CE）？

1) 就我个人而言，我发现大多数情况下 Access DB 损坏是由于代码自身未清理，或者涉及到有故障的网卡。

2)

string connectionString = @“Provider = Microsoft.Jet.OLEDB.4.0; " + 
                          @"Data Source = C:\data\northwind.mdb; " +
                          @"User Id = guest; Password = abc123”


using (OleDbConnection oleDbConnection = New OleDbConnection())
{
    oleDbConnection.ConnectionString = connectionString;

    oleDbConnection.Open();

    ...
}

3) SQL Server 2008 Express 版

Answer 3

MDB 损坏主要是由于数据库打开时客户端计算机、文件服务器和网络中发生的故障造成的。 如果将 MDB 放在文件共享上，这始终是一种风险，如果放在本地硬盘驱动器上并由一个用户使用，则问题要少得多。

我不希望 SQLite 有任何不同，甚至更糟。

定期运行 JetComp.exe（Microsoft 下载）将修复许多问题并压缩索引表等。 无论您使用什么，备份都很重要。

您根本不需要 MS Access 即可使用 Jet MDB。 有一些第三方工具可用于设计数据库模式和执行交互式查询，包括命令行和 GUI。

Answer 4

由于 MDB 格式或多或少已被弃用，因此您 90 年代末的知识相当最新。 查看此 MSDN 页面

Answer 5

您还可以尝试SQL Anywhere，它可以在各种操作系统上运行并且占用空间较小。 对我有用:)

Answer 6

AngryHacker问：

Q1。 他们是否解决了数据库时不时损坏的问题？

呃，什么？

在正确维护的环境中正确部署的正确设计的应用程序中从来不存在任何损坏问题。 我已经三四年没有见过损坏的 MDB，而且我有几十个应用程序在许多不同类型的操作环境中被许多客户全职使用。

我认为大多数遭受损坏的人是那些尝试在许多用户（无论是拆分还是未拆分）之间共享 MDB 文件的人。 由于您没有考虑使用 Access，所以这并不是一个真正的问题。

Q2。 是通过 ADO.NET OLEDB Provider 从 C# 完成对 MDB 的访问，还是有一个本机解决方案（我似乎找不到它）。

本机解决方案是 DAO，但那是 COM，因此您可能不想使用它。 对于 C#，我认为 OLEDB 是您最好的选择，但这不是我的专业领域，因此请持保留态度。 我相信 Michael Kaplan 报道过 Jet ADO/OLEDB 提供程序是线程安全的，而 DAO 则不是。 但这并不意味着他推荐 ADO/OLEDB 而不是 DAO，但他的评论也是来自 Access 上下文，而不是 C#。

Q3。 有没有可行的替代方案来替代 Access 中真正蹩脚的 SQL 编辑器？

当您实际上没有使用 Access 时，为什么要使用它？ 您可以使用任何您喜欢的 SQL 编辑器，只要您测试您编写的 SQL 与 Jet 的 SQL 方言兼容即可。

就我而言，我不明白 Access 的 SQL 编辑器有什么问题（除了无法设置字体大小），但是，我使用 QBE 编写了很多 SQL，甚至从来不看SQL 视图。

Answer 7

回答你关于 Access 中真正蹩脚的 SQL 编辑器的问题 - 我完全同意。 字体很糟糕，MSAccess 总是错误地重新格式化查询，有时会添加破坏 SQL 的元字符，最后但最糟糕的是，如果它无法解析 SQL，它不会让您访问它！

我的解决方案是使用外部代码。 我使用 DAO 实例化 MSAccess，然后可以使用 QueryDefs 集合直接编辑查询。 它可以让您执行大多数操作 - 创建、重命名、编辑等。但是，有一些操作您无法通过这种方式执行 - 例如，您无权访问查询元数据（描述、隐藏等）。

外部代码也很棒，因为您可以构建一套测试用例，指定预期返回值等。