Access forms or VB.NET?

[bernadou]

Our office is considering some options for a new internal application. We've
discussed several options, but, I thought I'd get some outside perspective.

Generally speaking, if we are working with SQL Svr backends, would it be
better to develop the client apps in Access (we have a MS site license for
Office) or VB.NET? Are there major advantages one way or the other?

The only one I could come up with so far was the ease of development in
Access forms, but, VB.NET is supposed to be getting better and better. I'd
be the one doing the work and I have done plenty of stuff in Access forms,
and some recent projects in ASP.NET (VB) 2.0.

Thanks for your input!

Bernadou

 

[Mark Burns]

bernadou,

my $0.02...go with VB.net Winforms or Webforms over Access forms.
Experience has taught me that I'd prefer to be in control of everything
happening in my app. Why keep Access in the loop if you're hitting a
SqlServer Back-End anyway?

Of course, it can be done either way. So, if you have any reason to stick
with Access, do so, but if it's a new app and you don't have to, why suffer
the overhead / slings&arrows of Access (not that VB.Net/ASP.Net is
perfect...)?

 

[Brendan Reynolds]

Ease - and speed - of development is no small thing - developer time is
expensive. I haven't had an opportunity to investigate VS.NET 2005 in any
detail yet - I'm in the midst of an ASP.NET 1.1 project and don't feel like
trying to switch horses in mid-stream - but my impression so far is, yes, it
is a significant improvement over VS.NET 2003, but it doesn't come close to
Access for ease - and speed - of development for the type of app to which
Access is suited.

Of course, if you are developing a type of app for which Access is not
suited, such as a web app or a distributed app, that's a different story.

You used the term 'generally speaking', but I would say that is just what we
should not be doing. To give a meaningful answer to this question, we have
to talk specifically, not generally. What, specifically, do you hope to gain
from using .NET? Without knowing what those hopes are, it isn't possible to
say whether they are realistic or not.

 

[bernadou]

Ok, fair enough. I guess I'm just trying to see if someone out there can
say...
"Don't use VB.NET because it is way too...."
Or
"Use VB.NET, it will provide X long term advantage..."

You get the idea.

I think we'll be fine either way. I also think I'm leaning towards VB.NET
as my personal experience has always been that if I don't just jump in and
push myself to learn, I'll just keep using what I know well. Access/VBA has
so far never failed to be able to do what I need, but, I'm just thinking that
VB.NET is the future so I might as well get some strong experience now.

Does someone dissagree???

B

 

[Brendan Reynolds]

There's another significant factor that we haven't talked about. How big is
this project? If it's a smallish project that can be completed by one person
in days or weeks, then I'd be inclined to say: "Yes, you're right, there's
no substitute for real-world, hand's-on experience if you want to learn a
new language. Go for it." If it's a large-scale project that's going to
involve multiple developers and/or months of development time, I might be
more inclined to advise caution!

 

[bernadou]

"Smallish" internal app used by about 5 employees, one lonley developer...

 

[Brendan Reynolds]

Well, assuming that there aren't any special requirements that would be
impossible or difficult to do in Access, it is likely to take considerably
longer to develop this app in .NET than it would in Access. In recompense
for the extra time and effort you will get hands on experience of a new
skill that will be good for your future career prospects. But what will your
organisation get? Think about it from your manager's point of view. If
he/she asks you what the organisation is going to get for the extra
development cost, do you have an answer? "A more experienced developer with
a wider range of skills" may or may not be an acceptable answer. I don't
know. Only you can answer that.