问这个问题并回答here已经10年了，我想看看当前的想法是什么。
我们有一个第三方应用程序，至少已经支持了这么长时间。这是一个Access运行时应用程序，它连接到SQL Server，并包含高度机密数据。
几年前，我们将数据库移至在Server Core上运行的SQL Server。最近，我们被要求运行六年来的数据库架构的第一次升级。供应商提供的升级软件包似乎是使用VB6构建的，不会在服务器上运行。它还不支持远程运行更新。我们有几种方法可以完成它，但它为我提供了一个机会，可以最终从我认为不是企业产品的地方继续前进。
有人问我为什么为什么，这个产品太糟糕了，据我估计，它已经过时了。我的直接内部回应是，这不是一个真正的应用程序，而是Access。我们为此付出了很多钱，而且我认为现在有更好，更强大的解决方案也更便宜，这一事实使情况更加复杂（我认为应该物）。
那表示我承认我对此特定应用程序的看法存在偏见。回顾那个旧帖子，有几件事脱颖而出。
我认为以这种方式构建的内部开发应用程序与为解决方案付费的应用程序之间存在很大差异。支持使用Access编写的内部开发的应用程序可能仍然会有一些好处。我认为当您付钱给某人时，最佳答案中指出的肯定不会成立。缺点恰恰是我们遇到的问题。
在Access中未完成报告。现在大多数情况是使用外部工具完成的。大多数用户希望查看基于Web的报告。
一些回答提到了 Professional Access开发人员，或者这类应用程序是 21世纪的COBOL 。我认为这是一个恰当的描述。我不确定专业的Access开发人员是否仍然存在。我们应该尝试维持多长时间？我们认为供应商将能够维持多长时间？
我认为Access的主要错误是将其视为业余爱好者开发应用程序的工具。它可以这样工作，但是请记住，业余开发将为您提供业余应用程序，而专业开发将为您提供专业结果
也许这尤其是我的问题的症结所在。我不相信我们的应用程序是“专业”的。如果我很慷慨的话，会感觉半专业。 VB6更新器是一个线索，多年来，还有其他一些组件引起了我的关注。
在我看来，企业中的大多数（如果不是全部）访问应用程序都具有这些相同的问题，这是否公平。归根结底，问题是它是否可以满足使用它的部门的需求。
Access在2019年适合企业的哪些位置？