Is there any good reason to continue writing VBA + Access Forms applications?

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 开发者_JAVA百科wrong? If so, what are the reasons to continue using this technology (besides avoiding the cost to port old apps to .NET)?

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:

1. 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).

2. 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).

3. 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.

4. 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).

5. 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:

Is there any reason to continue using this technology (besides avoiding the cost to move it over)?

Of course there are very good reasons to continue using Access:

1. the app is already developed.

2. the app works, or works well enough to get the job done.

3. the app needs only some new features, rather than a complete rewrite.

4. 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.

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.

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.

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