MS Access迁移的前端？

Question

背景

我为一个拥有数千个MS Access应用程序的大型组织工作。我没有写任何这些 - 事实上，大多数原作者早已离开公司 - 但有时候另一个Access应用程序落在我的桌面上寻求支持。我会 soooo 喜欢用不同的解决方案替换访问权限。

要求

我知道MS Access（Jet数据库）的数据库部分有几个不错的选择，例如SQLite，MySQL，VistaDB等。

我想知道的是：有什么东西可以取代MS Access的前端部分吗？

即。可用于构建表单，编写简单脚本和查询等的东西？

为什么？

@BracC问“为什么要替换访问？” - 确实是一个公平的问题 我想摆脱访问，因为：

• 它隐藏了逻辑，导致难以支持的应用程序。逻辑可以在许多不同的地方，没有一个提供或鼓励任何结构：
  • 宏
  • 模块
  • 查询
  • 形式
• 它本质上鼓励用户创建“小”应用程序，这些应用程序变得“不是那么少的应用程序”。然后用户离开，我必须支持一堆意大利面。我知道访问不是唯一的罪魁祸首，但它是我组织中的领导者，我希望完全摆脱它。

额外信用

我真正喜欢找到的东西是可以在MDB文件中读取并输出类似C＃的东西来复制功能。 （或任何语言 - 不挑剔）。

我希望这一切都清楚。如果没有，请发表评论，我会重新编写/添加详细信息。

更新

@GuinnessFan提出了一些我感兴趣的观点。我已经添加了我的评论来讨论这些观点。

自从我提出问题以来我们做了什么：

• 让用户向我们提供他们使用和需要的访问应用程序的明确列表。 （理解是列表中没有的任何MDB文件都可以删除 - 万岁！）。
• 分析了名单上的多边开发银行，得出以下结论：
  • 大多数“应用程序”由单个硬编码查询或单个链接表组成。
  • 许多是带有日期参数或类似信息的少量查询。
  • 很少（如果有的话）有任何真正复杂的逻辑。
• 我们现在正在完成该列表，将大多数应用程序转换为SSRS（SQL Server Reporting Services）程序包。
• 使用SSRS无法复制的任何内容都将成为手工制作的Web应用程序。但是，这些并不多。

我要非常感谢 每个人 谁给了我有用的答案。

Answer 1

几年前，我将一个应用程序的后端从MSacces切换到MSSQL。保持前端，因为它运作良好，我没有找到任何易于使用/修改的东西。

我从未见过MSAccess - ＆gt; C＃翻译。但是，您可能能够找到一个MSAccess到VB6转换器（它们的语法大致相似），从那里有VB6-> VB.Net转换器（甚至VB.Net - ＆gt; C＃转换器）

Answer 2

您可以查看Oracle's Application Express。它是免费的，它面向Access开发人员。

它还有一个迁移助手，您可以运行Access数据库，它会处理数据和表单，将所有内容迁移到Oracle数据库（这适用于免费数据库，Oracle XE，默认安装）和为Access数据库构建Web表单。

因此，最后您将在Web上拥有Access数据库，在Oracle中拥有您的数据以及用于扩展它们的一些不错的Web前端。

就Oracle而言，这个工具并不是坏事。您可以注册一个免费的实例来使用here。

Here's the document that explains how you migrate Access Databases.

Answer 3

那么，除了个人厌恶之外，为什么要更换Access前端？对于某些（简单）数据库来说可能很容易，但现实世界中的大多数Access应用程序都有很多复杂性。

升级后端的很多原因，当然（可伸缩性，性能，数据库损坏，用户锁定）。 Access甚至还有一个内置的“升级向导”工具，允许您从数据中拆分表单和逻辑，并将数据升级到MS SQL服务器。如果需要，可以使用此向导将后端升级到SQL Express，然后手动迁移到另一个数据库平台。

希望这不是太偏离主题，但有时您只需要使用Access：

1. 升级后端（正如我们已经讨论过的）

2. 始终确保前端已锁定（只读）

3. 如有必要，为不同的用户角色创建不同的前端（作为安全形式）。

4. 如果可能，出于性能原因，请在每个工作站上本地复制前端。您可能需要使用网络脚本来检查前端的新版本。

我没有任何直接经验，但我确实在http://www.microtools.us/

找到了一个名为“Access Whiz”的ASP.Net转换工具。

Answer 4

我们使用基于MS Access的内部应用程序作为MySQL数据库的前端。我们遇到lots of problems，最终在CodeGear Delphi 2007 for Win32重写了整个应用程序。这已经取得了巨大的成功，尽管迁移确实需要花费很多精力（培训/雇用几个Delphi程序员，购买一些第三方工具）。不过，我可以全心全意地推荐Delphi。和AFAIK一样，与MS Access后端的集成当然是可能的---我曾经写过一个Delphi应用程序就是这样做的，而且只需要花费几天的时间来获得一个功能完整的版本！

我意识到这是一个完整的编程解决方案，所以你肯定会放弃一些易于使用的MS Access来构建前端。然后，您可以在10分钟内将数据库应用程序放在Delphi中，而无需编写太多代码 - 不要开玩笑！自2009年发布以来，语言再次逐渐成为主流...

Answer 5

@BradC

我不推荐使用MicroTools。我曾经在一家公司工作过，我们遇到了同样的问题。除非MicroTools对他们的产品做出了重大改进，否则在我检查后它会吐出垃圾。

我们发现几乎任何升级路径都需要大量的编码更改。所有这些工具都适用于维护与原始应用程序类似的GUI。他们的代码没有对象结构，只有一堆实用函数被转储到每个页面上以模拟Access提供记录导航的方式。如果您拥有大量表单，那么提取解决方案并实施自己的解决方案需要花费一些工作和大量的查找和替换操作。

我们对MicroTools的性能非常失望，我们开始编写自己的转换器。我们提供的ASP.NET表单比编码一周后更好。

Answer 6

您将找不到附加了桌面界面设计工具的服务器级引擎。大型服务器引擎都希望您使用C ++，C＃，Java或PHP之类的东西来构建您的界面。

我也很想看到一个用于访问的升级工具，它会吐出一些基本的C＃表单并与等效的SQL Server数据库进行对话。对于微软而言，这似乎是一个巨大的赚钱机器，因为他们可以将其用作向客户推销完整SQL Server的一种方式。

IIRC，可能有一种方法可以告诉Access前端与SQL Server通信，或者将Access前端使用的表更改为真正的链接表到SQL Server，或类似的东西，但我从来没有必要自己使用这个功能。

Answer 7

我有一个不同的视角供你考虑。您的主要问题是它隐藏了逻辑，并且数据和应用程序分散在整个组织中。

不幸的是，我不知道RAD（快速应用程序开发）工具就像Access一样容易创建功能表单。

但是我建议您更多地关注将数据和逻辑集中在一起的可能性，并仍然允许Access作为前端。我支持名为Advantage Database Server的数据库产品，它支持RI（参照完整性）规则，存储过程，触发器等，这些规则，存储过程，触发器等都可以在中央服务器上进行管理，从而为您提供所有逻辑。然后，这些Access前端可以使用ODBC或OLEDB链接到数据后端。如果您切换到这样的解决方案，那么稍后您可以灵活地编写其他应用程序，例如.NET，PHP，JDBC等，这些应用程序在分析Access前端时会绑定到相同的数据中。

一个良好的开端是停止新的Access开发，除非他们使用这种数据后端。

Answer 8

在1000个Access文件中，有多少人被要求支持？我猜的是不到100个。为什么重建一个应用程序A）没有人使用B）它的工作方式很好吗？

您需要开始一项策略，即大型组织在强大，可扩展，可靠的yadda yadda yadda环境中开发自定义应用程序是一种可接受的做法。确定您认为关键或正在过时的Access应用程序，并且只需处理这些应用程序。

准备好应对快速和肮脏的小应用程序快速周转的期望。您必须向他们展示新应用的好处。

我认为您只需要成为常驻专家，并教会这些用户如何改进他们的应用程序或从一开始就获得您的输入以正确启动它们。转换所有这些文件的要求将是压倒性的。

Answer 9

Microtools提供Access Whiz，一组Access转换工具。它包括访问ASP .NET（VB / C＃）转换器，访问VB6转换器，访问WinForms（VB .NET / C＃）转换器和访问Crystal Reports转换器。可以在http://www.microtools.us找到更多信息和试用版。

Answer 10

您还可以查看Firebird

这是migrate（你需要德尔福）的方法

我也找到了这个MDB2FDB

Answer 11

  

有什么东西可以取代MS Access的前端部分吗？

也许Kexi？