我有一个Microsoft Access业务关键数据库，最初是在90年代创建的，此时已扩展并升级到Access 2007。我们一直在使用这个数据库作为自定义编写的ERP系统的前端。我们很久以前已将大部分数据移到SQL服务器上，但我们仍然使用MS Access作为前端。随着项目的发展，我们有了一名全职开发人员，我们已经开始出现稳定性问题，以及极其频繁的未知原因导致的崩溃。
例如：如果我更改1个特定字段中的数据，则在10个左右的时间内，某个表单会崩溃。当时没有代码触发，数据位于本地临时表中，该表通常在大多数情况下通常只有5行。如果我更改表中的数据没有任何问题，但如果我在表单上更改它将很难崩溃并将我转储到桌面。我可以提供其他无法解释的崩溃的例子
我正在寻找关于这一点的建议 - 访问前端具有运行我们公司的所有业务逻辑，因此我不能放弃它。理想情况下，我们会用其他语言重写整个前端。问题在于，作为一家小公司，我们没有足够的资源来重新编写整个系统的任何类似时间框架的东西，并且没有现金流来支付其他人来做这件事。我理想的解决方案是将某种类型的转换从访问前端转换到另一个端点 - 无论是网络还是本地窗口 - 但我在这里和谷歌上的搜索看起来像是一个非首发。
基本上我所看到的每条大道似乎都是一个死胡同：
我们找不到崩溃的来源来稳定我们现有的系统，
我们无法在现有系统中停止生产，只要重新编写它就可以了，
我们无法支付其他人来编写新系统，
自动转换工具似乎浪费钱
我有其他选择或哪些选项看起来最好？
答案 0 :(得分：1)
我们有一个带有Access前端和SQL Server后端的企业级程序。我想知道将程序拆分成不同的诊断部分是否有帮助。例如，如果您有订单输入和库存管理，则每个功能可以有一个前端。 （是的，我可以听到背景中的嚎叫，但如果只是为了诊断的目的，也许会有所帮助......）
您还可以将Access数据库对象导出到文本文件，然后将它们导入到一个全新的数据库中，以便在某些情况下消除奇怪的错误。
答案 1 :(得分：0)
好吧，我想我会在这里重新解释基本问题。如果您有两名计算机科学毕业生，那么他们应该很久以前就已经预料到他们达到了Access的极限。我没有看到这与在餐馆过度工作的烤箱有任何不同，现在有太多顾客或送货卡车无法向顾客提供货物。
由于没有资金可以重写，因此您的员工未能按月支付资金来应对这种情况，现在您选择这种延迟行动以应对这一日益严重的问题困难的情况。
你所拥有的计算科学人员很久以前就应该看到这面墙，并限制你的到来。根据我的经验，对于大多数CS人来说他们认为Access相当有限，因此甚至更多的警钟应该在这里振铃，这意味着你有更少的借口存在于这种不幸的困境中。
因此，假设您拥有的计算科学人员很好地维护了这个应用程序（我慷慨地接受了这种情况），那么合乎逻辑的结论是该应用程序已经达到或超过了Access的限制。如前所述，这些限制应该早就预料到了。
正如你所指出的那样，现在资金不存在重写，那么没有这些资金就没有多少选择。
然而，你的情况可能不是那么糟糕，因为我们现在知道你有经验丰富的开发人员。鉴于这种情况，那么我的建议是考虑从应用程序中逐个分解模块或小的可管理部件和功能，并让训练有素且经验丰富的开发人员构建Web界面，或者甚至使用.net之类的东西。你希望保持100％的桌面。因此，这个机会的“窗口”是考虑改变架构的绝佳机会。
由于数据限制是SQL服务器和非访问，因此两个应用程序（现有访问前端）和新部件可以很好地轻松操作相同的数据。执行此操作时，您将分解并从Access应用程序中删除现有部件。这将建议您在Access应用程序中尽快恢复可加入的稳定性。此时，您可以继续，或停止节省资金。
如上所述，没有资金重写，那么唯一的选择就是找到一些方法来每月释放一些有限的资源来解决这个问题。
在一天结束时，这个问题的解决方案是更多的资源，但是如果没有这样的资源，那么这里几乎没有技术选择和选项。根据迄今为止提供的信息，您已明确表示此处没有资源。但是，此问题的解决方案需要资源分配和规划。
换句话说，在没有分配资源的情况下对此问题进行技术修复可能不适合您。
我真诚地道歉，因为我无法在这里为您提供技术解决方案，但这看起来是一个解决方案，需要将资源分配给问题，并且此处不存在简单的快捷方式或技巧或魔术银弹。