有什么充分的理由继续编写 VBA +访问表单应用程序？
最近，我被要求更新旧的 Access Forms 应用程序。由于具有 .NET 背景，我发现这种变化令人恐惧，并且感到有些不舒服。我原以为这些都是遗留技术，很快就会变得不合时宜……
我错了吗？如果是这样，继续使用该技术的原因是什么（除了避免将旧应用程序移植到 .NET 的成本之外）？
I was recently asked to update an old Access Forms application. Coming from a .NET background, I found the change frightening, and became somewhat uncomfortable. I had assumed these were legacy technologies, fast becoming anachronisms...
Am I wrong? If so, what are the reasons to continue using this technology (besides avoiding the cost to port old apps to .NET)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不会回答问题的潜台词（即 Access 应用程序无论如何都很糟糕），而是提供有关 Access 未来的一些信息：
Access 是 Microsoft 的旗舰产品。它在微软的产品线中没有替代品，因此在可预见的未来，微软仍会以某种形式继续推广和开发它（只要有微软的Office套件，就会有Access）。
对于 Access 提供的功能，除了 MS 之外几乎没有竞争。唯一可比的产品是 FileMaker Pro。人们可能会说 OpenOffice 套件中的 Base 组件是竞争产品，但它仅涵盖 FM 和 Access 提供的功能的子集（这并不是说它可能不足以满足任何数量的场景）。
Access（以及整个 Office 套件）仍然使用 VBA 作为其编程语言，而 Microsoft 的其余部分已从 VB 转向基于 .NET 的语言。其他 Office 产品现在可以使用 .NET 组件（尽管与使用 VBA 的方式不同），但 Access 的情况并非如此。我预计在接下来的几个 Access 版本中（不是 A2010），会以某种方式引入 .NET 支持。但了解 MS 的历史，VBA 将继续受到多个版本的支持。
Access 应用程序历来在 Web 部署方面存在巨大弱点，而 FileMaker 多年前就提供了这一点。 A2010 通过 Sharepoint 集成纠正了这一重大问题，该集成允许使用新的 Web 对象创建 Access 应用程序，这些对象可以在 Access 客户端和 Web 浏览器（任何符合标准的 Web 浏览器）中相同地运行 - 不再需要 Web 组件和限制IE）。
Jet 数据库引擎基本上在 Jet 4（1999 年发布）发布时被 MS 宣布死亡，尽管 MS 将 Jet 4 作为 Windows 操作系统的一个组件（现在仍然如此）。随着 Access 2007 的发布以及新版本的 Jet 数据库引擎（称为 ACE）的加入，Jet 获得了新生，该引擎由 Access 开发团队拥有（Jet 4 仍然由 Windows 开发团队拥有，并按原样冻结） ，无需额外开发）。 ACE 中引入的许多新功能都是由 Microsoft 将 Access 与 Sharepoint 集成的目标驱动的，但在 A2010 中，一些新功能（例如表级数据宏，它启用了相当于触发器的功能）即使没有使用 Sharepoint（其他的，比如多值字段，则不是）。有了 64 位版本的 Office，现在就有了 64 位版本的 ACE，因此 Jet/ACE 现在可以在 64 位应用程序中使用，而无需仅编译为 32 位应用程序。
现在，最后一个问题：
@ChrisDiRulli 问道：
当然，有充分的理由继续使用 Access：
应用程序已经开发。
应用程序可以工作，或者工作得足够好，可以完成工作。
应用程序只需要一些新功能，而不是完全重写。
该应用程序由一组不存在部署问题的用户使用（他们都具有完全访问权限或正在使用运行时）。
在我看来，Access 有着美好的未来。自从 Office 95/97 发布以来，我对 Access 就不再那么热衷了，Office 95/97 将 VBA 引入了 Office 套件，并支持创建构建在 Office 套件之上的“元应用程序”。
现在，在任何特定情况下，对于旧版 Access 应用程序，问题可能是没有人知道如何修复现有应用程序，或者现有应用程序是一堆意大利面条代码和宏（如果它使用宏，则更糟糕，因为它是几乎不可能说出它们如何相互关联），或者模式很糟糕，或者，或者，或者......
如果问题是没有人有能力（或兴趣）来拯救应用程序，你应该考虑雇用一个承包商是一位经验丰富的 Access 开发人员。找到这些人并不那么容易，但这样的人有很多。您可以通过他们在 Access Usenet 组中的公开帖子甚至其中一些人在 SO 上的公开帖子来判断谁是有能力的人。
如果您不想这样做，您可能会花费更多的钱，要么四处寻找如何修复 Access 应用程序，要么发现在 Access 之外复制相同功能的成本有多高。在后一种情况下，许多组织选择将应用程序替换为仅提供一小部分相同功能的应用程序。这是疏远最终用户并促使他们放弃保留并且将来不再向 IT 部门寻求帮助的好方法，因此这可能不是一个好主意。
但首先要做的事情是：
放弃对 Access 的敌意。这是非理性的，并且 99.99% 的可能性是完全基于无知。
Instead of answering the subtext of the question (which is that Access apps are terrible no matter what), I'll give some information about the future of Access:
Access is a flagship product for Microsoft. There is no substitute for it in Microsoft's product line so it's going to continue to be promoted and developed by Microsoft in some form for the foreseeable future (as long as there's an Office suite from MS, there will be Access).
There is almost no competition outside MS for the functionality that Access provides. The only comparable product anywhere is FileMaker Pro. One could possibly say that the Base component in the OpenOffice suite is competition, but it covers only a subset of the features offered by FM and Access (which is not to say that it might not be sufficient for any number of scenarios).
Access (and the entire Office suite) is still using VBA as its programming language and the rest of Microsoft has moved on from VB to the .NET-based languages. The other Office products can now use .NET components (though not in the same way that they use VBA), but this is not the case for Access. I would expect that sometime in the next couple of versions of Access (not in A2010), .NET support will be introduced in some way. But knowing MS's history, VBA will continue to be supported for several versions.
Access applications have historically had a huge weakness in regard to web deployment, something that FileMaker offered years ago. A2010 rectifies that big time through Sharepoint integration that allows the creation of an Access app using the new web objects that can run identically in the Access client and in a web browser (any standards-compliant web browser -- no more web components and restriction to IE).
The Jet database engine was basically declared dead by MS around the release of Jet 4 (which came in 1999), even though MS made Jet 4 a component of the Windows operating system (and it still is). Jet got new life with the release of Access 2007, and the inclusion of a new version of the Jet database engine called ACE, and owned by the Access development team (Jet 4 continues to be owned by the Windows development team and is frozen as is, with no additional development). Much of the new functionality introduced in the ACE has been driven by Microsoft's goal of integrating Access with Sharepoint, but with A2010, some of the new features (like table-level data macros, which enable the equivalent of triggers) are very useful even without using Sharepoint (others, like multi-value fields, are not). With the 64-bit version of Office, there's now a 64-bit version of ACE, so Jet/ACE can now be used in 64-bit applications without needing to compile as 32-bit only.
Now, the last question:
@ChrisDiRulli asked:
Of course there are very good reasons to continue using Access:
the app is already developed.
the app works, or works well enough to get the job done.
the app needs only some new features, rather than a complete rewrite.
the app is used by a group of users for whom there are no deployment issues (they all have full Access or are using the runtime).
There's a great future for Access, seems to me. I haven't been this enthused about Access since the release of Office 95/97, which introduced VBA to the Office suite and enabled the creation of "meta-applications" built on top of the Office suite.
Now in any particular situation, with a legacy Access app, the issue may be that nobody knows how to fix the existing app, or that the existing app is a holy mess of spaghetti code and macros (much worse if it uses macros, as it's nearly impossible to tell how they interrelate), or the schema is bad, or, or, or....
If the issue is that nobody has the chops (or the interest) to rescue the app, you should consider hiring a contractor who is an experienced Access developer. Finding those people is not so simple, but there are lots of them out there. You can tell who the competent ones are by their public postings in the Access Usenet groups and even some of them here on SO.
If you don't want to do that, you'll likely spend a lot more money either flailing around trying to figure out how to fix the Access app or alternatively, discovering how expensive it is to replicate the same functionality outside of Access. In the latter case, many organizations opt for replacing the app with one that offers only a fraction of the same functionality. That's a great way to alienate end users and nudge them in the direction of going off the reservation and not asking IT for help in the future, so it's probably not a good idea.
But first things first:
Lose the hostility to Access. It's irrational and 99.99% likely that it's based entirely on ignorance.
仍然有大量用 COBOL 编写的软件，而且它们比 Access 更古老。
在某些领域，Access 应用程序可能就足够了，而且是最便宜的选择。如果它能完成工作（你的工作部分是让你的雇主知道它是否真的完成了工作）并且如果这是他们想要的，那就去做吧。
如果您发现 .NET 项目会更好或 Access 会达不到要求的充分理由，请公开讨论它们，并尝试做出最符合检查者最大利益的决定。
There is still a ton of software written in COBOL, and that's much older than Access.
There are some areas where an Access application is probably sufficient and the least expensive option. If it gets the job done (your job is partially to let your employer know if it really gets the job done) and if it's what they want, go for it.
If you see good reasons that a .NET project would be better or that Access will fall short, discuss them openly and try to reach a decision that's in the best interest of the person cutting the check.
我们保留它是因为它有效。当企业的需求增长如此之大以至于 Access 应用程序无法再完成工作时（这对企业来说是一件好事，或者是您的 Access 开发人员可能缺乏这方面知识的不幸迹象。），您可以构建一些可以或雇用有能力的人。
你对所有开发人员都会经历的感到沮丧。我从来没有在一天开始时这样想：“&^%&，我必须构建一个新的应用程序！我什么时候才能回到 3 年前的 .NET 代码并修复那......”重构有它的一席之地。
现在，我希望在 Access 中看到许多 .NET 功能，并期待 2010 版本。
We keep it because it works. When a business's needs grow so much that the Access App can no longer get the job done (A very good thing for the business or an unfortunate sign that your Access developer may be lacking knowledge in this area.), you build something that can or hire someone who can.
You were frustrated which all developers go through. I never start my day thinking, "&^%&, I have to build a new application! When am I ever going to get to go back to that 3 yr old .NET code and fix that ..." Refactoring has its place.
Now, there are many .NET features I'd like to see available in Access and look forward to the 2010 version.
使用正确的工具完成正确的工作。许多 IT 人员都推迟了访问，因为必须维护一些刚刚从 Excel 中出来的人创建的可怕的数据库。然而，访问有很多好处。例如，我即将开展一个项目，要求在短时间内向大约 10 个用户快速推出。对于这项工作，我将 SQL Server 和 Visual Studio 的副本放在架子上并使用访问权限。如果访问适合这项工作，那么为什么要在 .net 中重写它，以便它可以在 .net 中。对我来说，使用的编程工具是达到目的的手段，而不是功能
Use the right tools for the right job. Many people in IT are put off access from having to maintain some god awful db made by someone just stepping out of excel. However access has many things going for it. For example I have a project coming up that calls for rapid roll out to about 10 users with a short turn around time. For this job I'm leaving the SQL server and the copy of visual studio on the shelf and using access. If access fits the job then why rewrite it in .net just so it can be in .net. For me the programming tool used is a means to an end not a feature