1

我有一个 Microsoft Access 业务关键数据库，它最初是在 90 年代创建的，此时已扩大并升级到 Access 2007。我们一直在使用这个数据库作为自定义编写的 ERP 系统的前端。很久以前，我们已经将大部分数据转移到 SQL 服务器，但我们仍然使用 MS Access 作为前端。随着项目的发展，我们有一个全职的开发人员，我们已经开始遇到稳定性问题和未知原因的极其频繁的崩溃。

例如：10 次左右，如果我更改 1 个特定字段中的数据，某个表单会崩溃。当时没有代码触发，数据在一个本地临时表中，大部分时间通常只有 5 行。如果我更改表中的数据没有任何问题，但如果我在表单上更改它，Access 将硬崩溃并将我转储到桌面。我还可以提供其他无法解释的崩溃示例

我正在寻找关于此时去哪里的建议——访问前端具有运行我们公司的所有业务逻辑，所以我不能放弃它。理想情况下，我们会用其他语言重写整个前端。问题是，作为一家小公司，我们没有足够的资源在一个好的时间框架内重新编写整个系统，也没有现金流来支付其他人的费用。我理想的解决方案是从访问前端到另一个端点的某种转换——无论是网络还是本地窗口——但我在这里和谷歌上的搜索看起来像是一个非首发。

所以基本上我看到的每条途径似乎都是死胡同：

  • 我们找不到崩溃的根源来稳定我们当前的系统，

  • 只要重新编写它，我们就不能停止我们当前系统的生产，

  • 我们付不起钱请别人写一个新系统，

  • 自动转换工具似乎在浪费钱

是否有其他选择，或者我认为哪个选项看起来最好？

4

2 回答 2

1

我们有一个带有 Access 前端和 SQL Server 后端的企业级程序。我想知道将程序分成不同的部分进行诊断是否无济于事。例如，如果您有订单输入和库存管理，您可以为每个功能设置一个前端。 （是的，我可以听到背景中的嚎叫声，但如果只是为了诊断，可能会有所帮助......）
您还可以将 Access 数据库对象导出到文本文件，然后将它们导入到新的数据库中以获取在某些情况下摆脱奇怪的错误。

于 2013-02-04T21:24:39.230 回答
0

好吧，我想我会在这里重新表述基本问题。如果您有两名计算机科学专业的毕业生，那么他们早就应该预料到他们已经达到了 Access 的极限。我认为这与现在有太多顾客的餐馆里的过度劳累的烤箱或没有能力向顾客运送货物的送货卡车有什么不同。

由于不存在可重写的资金，因此您的员工未能按月拨出资金来处理这种情况，而现在由于延迟采取行动来处理这个日益严重的问题，您的选择使您陷入困境.

您的计算机科学人员早就应该看到这堵墙并限制您的到来。根据我的经验，大多数 CS 人员是否认为访问权限相当有限，因此这里应该敲响更多的警钟，这意味着你陷入这种不幸困境的借口更少。

因此，假设您拥有的计算科学人员很好地维护了这个应用程序（我欣然接受这种情况），那么合乎逻辑的结论是这个应用程序已经达到或超过了 Access 的限制。如前所述，这种限制早就应该预料到了。

正如您很好地指出的那样，现在不存在用于重写的资金，那么没有这样的资金就几乎没有选择。

但是，您的情况可能还不错，因为我们现在知道您的员工中有经验丰富的开发人员。鉴于这种情况，我的建议是考虑从应用程序中拆分出模块或小的可管理部分和功能，并让训练有素且经验丰富的开发人员构建 Web 界面，或者甚至使用 .net 之类的东西，如果你希望保持 100% 的桌面。所以这个机会“窗口”是考虑改变架构的好机会）

由于数据限制是 SQL server 而不是 Access，因此应用程序（现有的访问前端）和新部件都可以很好地轻松地对相同的数据进行操作。执行此操作时，您可以从 Access 应用程序中拆分并删除现有部分。这将建议您最终在 Access 应用程序中恢复到可接受的稳定性。此时，您可以继续，也可以停止以节省资金。

如前所述，如果没有资金重写，那么唯一的选择就是想办法每月释放一些有限的资源来解决这个问题。

归根结底，这个问题的解决方案是更多的资源，但是如果没有这些资源，那么这里就很少有技术选择和选择。根据迄今为止提供的信息，您已经明确表示您在这里没有资源。然而，这里解决这个问题需要资源分配和规划。

换句话说，在没有分配资源的情况下对这个问题进行技术修复对您来说不太可能是一个可用的选项。

对于无法在这里为您提供技术解决方案，我深表歉意，但这看起来是一个需要为问题分配资源的解决方案，并且这里不存在简单的捷径或技巧或灵丹妙药。

于 2013-02-05T04:21:24.117 回答