为什么不考虑将表移到 SQL Server 之类的东西上,或者使用 MySQL,然后继续在用户桌面上使用 Access 前端?
在我看来,对于我们所谓的应用程序之间的区别存在一些广泛的混淆。应用程序具有我们所说的 UI(用户界面)。这意味着您拥有用户代码、表单等用户界面以及报告等内容。
应用程序的这一部分是使用 MS Access 等开发工具构建的。
在使用 MS、Access、Delphi、C++ 或 VB 构建应用程序时,您还必须选择数据库系统来存储这些数据。因此,如果您使用 C++、Delphi、VB 或在这种情况下为 MS Access 编写应用程序,您就可以自由选择合适的数据库系统与该开发工具一起使用。通常,开发具有 MS 访问权限的应用程序软件的人会选择使用名为 JET 的默认和基于文件共享的数据引擎(或现在的 ACE,因为有一个新版本支持 64 位并且还存储过程)。
换句话说,您可以继续使用此应用程序,但只需将表链接到 SQL 服务器,或者在本例中为运行在 Web 服务器上的 MySQL 实例。
所以我不确定为什么这里会出现如此混乱的情况,而且人们无法区分您选择使用的数据库系统?以及使用像 MS Access 这样的工具来构建和开发软件。
我的意思是接下来会发生什么?我们要称 VB 或 C++ 为数据库?人们在我们的行业中不掌握和理解数据库系统与软件开发系统之间的区别似乎非常愚蠢。
我不确定在哪里或为什么会在这里发生如此大的混乱,但我当然希望人们不会被某人付钱或做咨询或实际接受计费的工作时间,其中数据库和应用程序系统之间的基本理解和区别是不明白!我很想对我们 IT 行业可怕的事态和缺乏教育大发雷霆,但我会避免这样做。
无论如何,10 多年来,我一直在使用廉价的低成本网络托管并将 MS Access 应用程序部署到人们的桌面上。我只是将应用程序链接到在 Web 服务器上运行的数据库实例。我开始使用 MySQL 来做这件事,但在过去的很多年里,我一直在使用 SQL Server(而且我一直在使用 SQL Server,因为我更习惯它)。
因此,没有什么能阻止您将数据和表移动到在该 Linux 服务器上运行的某种类型的 SQL 服务器或 MySQL 的实例。因此,您可以“按原样”继续使用 Access 应用程序。通过这种方式,99% 的代码、表单和应用程序应该可以继续运行而无需修改。应用程序中可能有一些小片段和几行代码不起作用,但对于任何熟悉 Access 作为开发的应用程序开发人员来说,这不应该花费超过几个小时的时间工具。
这种设置的美妙之处在于,您构建的任何类型的 Web 界面现在都可以立即在用户桌面上的任何访问表单中看到。用户在 Access 表单和 Access VBA 代码中的任何更新都将立即出现在网站上,因为他们共享同一个数据库系统。
所以我认为最好的方法是首先掌握使用 Access 内置的应用程序与您选择使用 Access 的数据库系统之间的区别。
最后但同样重要的是,Access 现在确实具有 Web 发布功能,您可以根据以下视频了解我如何更改为在 Access 中运行此应用程序以 100% 浏览器:
http://www.youtube.com/watch?v=AU4mH0jPntI
但是,上述内容确实需要所谓的访问 Web 服务。事实上,它基于一组 Web 服务和添加到 Access 的新界面 - 因此,除非运行 Office 365 或 SharePoint,否则此设置在这种情况下不合适。