Hum, this is not such a easy question.
The real downfall of access is its ties to the office suite.
Of course, in many cases, this can be consider its strength also.
I would say that if the company as a general rule has CONTROL of the
install, and set-up of the pc, then ms-access is a good choice. By CONTROL,
that means your IT department has very good, and very reliable windows
install (probably they image the pc's). That also means that users don't
mess much with the pc, and they are all standardized. With a controlled
environment, I would lean towards the ms-access way.
If you don't have much control over the pc environment, then VB has a better
package and deployment ability. With a lot of users, you need to work hard
to make sure no install problems occur.
once ms-access is PROPERLY INSTALLED and running, then in fact you can have
LESS problems then a deployment VB applications. (less dll hell, but of
course in ms-access you will thus avoid activeX controls...while in VB you
tend to have more freedom in this regards).
The other important factor is skill of the developer team. If the team is a
good group and is has completed several VB projects together, then the time
saved by ms-access my NOT be realized/ That team will need several months of
time to really start figuring out ms-access, and how to do things. Probably
more important is how NOT to do things the same way they are done in VB
The other factor is how many developers on the team. If you go beyond two
developers, then VB tends to be again somewhat better. (you create com
objects, and PARTS of the applications tend to use more class objects). Your
developer team will likely be more orientated towards a modular approach,
and also that of using objects during the development process.
If you just have one developer on the team, and that developer has strong
coding skills and knows ms-access well...then ms-access wins hands down.
I have a SMALL application in in-access, that has 25,000 lines of source
code, and has 160 forms. The whole thing as mde is less then 6 megs in size.
In fact, I can still zip the whole application on to a single floppy. It is
small, and complete self contained in that mde file.
There is no doubt in my mind that 160 forms would have taken at least 3
times as long to create (or, I would only have had built 60 forms) in VB.
The productivity of ms-access allowed me to crate FAR MORE FEATURE rich
applications. You get more application for you money spent, but ONLY IF the
developer team know how to take advantage of ms-access. VB people out of the
box don't know how to get high productivity out of ms-access.
Of course, a lot of ms-access developers don't have a lot of coding
experience with "team" development either.
I mean, for example during a interview process for access developers, I
often ask:
What did the last class object you wrote in ms-access do?
The above is not a make, or break question, but it does give me an idea of
what kind development and coding the developer has done in the past.
There is often a common myth that ms-access is easy, or in fact easier then
VB. I would say the opposite is true, as the forms model in ms-access is FAR
MORE complex then the simple VB forms.
Another good interview question of mine is:
Explain the difference between the on-open event and on-load event in
ms-access. Why use one event other the other? Most VB developers don't know
this answer. In fact, a lot of ms-access developers don't either!!
So, at the end of the day, if your developer team is good with one set of
tools, then that is going to be big factor.
I would tend to go with what the team knows best. It also depends on how
large the budget is. If there is few months of burn time in the project, and
you have one ms-access Guru on the team that can guide design decisions for
the inexperienced team, then ms-access would still be my choice.
