Access verses VB.net

  • Thread starter Thread starter Woody Splawn
  • Start date Start date
W

Woody Splawn

It is real important to choose the right tool for a given problem and it is
not clear to me just what the advantage of VS.net is over Access, for
example, when writing a non-web applicaiton. I see the strengths of VB.net
when it comes to the web but what about non-web applications. VB.net is
complicated, but that's ok and I feel that this is not a reason by itself to
choose Access over VB.net. What other argurments in VB.net's favor are
there for writing non-web applications?

Anyone.
 
* "Woody Splawn said:
It is real important to choose the right tool for a given problem and it is
not clear to me just what the advantage of VS.net is over Access, for
example, when writing a non-web applicaiton. I see the strengths of VB.net
when it comes to the web but what about non-web applications. VB.net is
complicated, but that's ok and I feel that this is not a reason by itself to
choose Access over VB.net. What other argurments in VB.net's favor are
there for writing non-web applications?
Click to expand...

.... you don't necessarily need an Access license, depending on the dbms
you are using...
 
Woody, to be honest the argument should be the other way around. The only
thing Access has in its favor is that it's 'easier'. That is easier to do a
lot of common tasks. It's certainly not easier to write a multithreaded
windows service with Access for instance. Let me highlight a few
1) You can use VB.NET to write all sorts of apps, web, compact framework and
desktop. When I first started with .NET at my last company, I had a manager
that had heard .NET was only for Web stuff. He was a complete idiot but he
ran around for a month trying to stop the move to .NET b/c we mainly wrote
desktop apps. The rumor started somewhere but it's defintiely not true. You
can use VB.NET classes in web services, web applications(which are much
different from web services), destkop app and PDA apps. The code can be
reused everywhere. You can also mix VB.NET and C# in the same solution so
you don't have to limit yourself to hiring people with only one of the
skills
2) Access isn't a real database. I know that sounds harsh but it isn't.
This is a client/server/n-tier world. Access thrives in a single user
environment. Doing point in time restores is impossible for any practical
perspective. Access has very limited security. It doesn't support real
stored procedures. It doesn't have a programmatic langugage syntax like
T-SQL or PL/SQL and its implementation of SQL is ghastly. MSDE edition of
Sql Server is free, has the same storage restrictions as access, allows you
to easily upsize, provides better security, better performance, real backup
and recovery etc etc etc.
3) VB.NET is a real object oriented language. All of the crap associated
with Weak Typing goes away (well, as long as you use Option Strict which
should be a Law IMHO).
4) ADO.NET walks all over DAO. You can use data from all different data
sources and send data all over the place. ADO.NET is so much more powerful
it's hard to even know where to start, then again the same holds with VB.NET
5) VB.NET (actually the .NET Framework's) security model is lightyears ahead
of access, even if you don't use MSDE (which will further cause a rift
between the two). You can implement security declaratively and do so at the
code level...it's so superior again it's hard to know where to start
6) The IDE and intellisense will make you 1000000 times more productive
7) The Base classes in .NET are far more developed than VBA
8) You can easily implement zero touch deployment with .NET and you don't
need everyone to have access installed on their computers
9) You won't get laughed at by all the other programmers
10) Your users won't be p/o'd all the time b/c you have to take down the DB
so you can repair and compact it.

This is but a smidgen of the reasons. Actually, it's easier to go the other
direction. Other than the fact that it's easier to build point and click
apps with Access (and even that is diminished) there's no reason. Access
isn't a language and as far as a database, it's horrible. VBA is fine, but
it's outdated. Wouldn't you rather use a modern programming language with
tons of support and examples, tons of books and an IDE that really helps
you? With MSDE in the winds, the demand for access is going to dwindle and
employment wise, you'll probably make 4-6 times what you will as an access
programmer if you take the time to get good at it. YOu also can do so many
things that can't be done with access, it'll be a lot more fun. MUCH MORE.

HTH,

Bill

--

W.G. Ryan, eMVP

http://forums.devbuzz.com/
http://www.knowdotnet.com/williamryan.html
http://www.msmvps.com/WilliamRyan/
http://www.devbuzz.com/content/zinc_personal_media_center_pg1.asp
 
Bill,

I appreciate your detailed reply. 10 years ago I had to decide between
going from Paradox for Windows to a RAD tool or Access. For good or ill I
chose a RAD tool - PowerBuilder. I could have gone Delphi or VB 4.0 but
Borland's future at that point was in question and VB 4.0 was not considered
a serious tool. Subsequently VB developed into a nice tool but I never got
on the VB 6 band wagon. When VB.net came along, however, I took the plunge.
Because PowerBuilder is a true OOP tool the switch was less onerous for me
than for some others but it was still a big change. I have been using it
now for some 20 months and am beginning to feel comfortable. I use it
primarily for non-windows applications.

But something happened recently to cause me to wonder if I had made the
right choices after all. I am not talking about me as a developer so much
as I am the client or potential clients. I am about to embark on a campaign
of rounding up more business for local area network (non web) applications
and either way, the only real solution out there is Microsoft. The question
is whether it is in Access or VS.net. I have traditionally said that when
you get up over a certain amount of records you need to switch from a PC
database solution to something bigger. But I understand that Access can be
used as a front-end for SQL Server or even Oracle for that matter. If I
take my clients to a tool as, what's the word, "complicated" as VB.net I
want to be sure I am doing what is best for them as well as me.

If I were giving myself a reason for doing non-web apps with VS as opposed
to Access it would probably be that VS.net appears to be the center piece of
Microsoft Technology. As such, nothing else is more main stream and as such
the client is or would be, I believe, on the most solid ground; especially
where maintainability is concerned. I believe this is good logic though I
can tell you first hand that much of what I have read to get up on VS.net
for non-web was way more complicated than it needs to be. People like me
can be taught how to write solid non-web applications using only a portion
of all there is to know in VB.net and in simpler terms. I hope that VS 2005
will make the non-web experience even simpler. I don't like having to use
Infragistics or Crystal Reports. I would much prefer that MS offer a true
end-to-end solution though it looks like VS 2005 will come closer. I think
VS 2005 will offer a better non-web solution for report writing with
Reporting Services and I hope we will be able to do simple things in a grid
like being able to access a lookup table in a cell in a grid that is based
on some values from a table in the database. This is so basic in everthing
but this incarnation of VS.net.


Anyway, I will bring this to a close. Just thought it would be worth asking
myself again, if no one else, if I am headed in the right direction. How
good a solution is VS.net for non-web?

Woody
 
take my clients to a tool as, what's the word, "complicated" as VB.net I
want to be sure I am doing what is best for them as well as me.
Click to expand...

I'm curious about this statement. Your clients (End Users?) shouldn't care
about the tool you use to create the app as long as it works. It seems to
me that the choice comes down to what is easier for you the developer to
use and maintain.

Just a thought,

Cheers
 
Hi Chris
I'm curious about this statement. Your clients (End Users?) shouldn't care
about the tool you use to create the app as long as it works. It seems to
me that the choice comes down to what is easier for you the developer to
use and maintain.
Click to expand...

I don't think of the end-user as the client. If the client is the end-user
then you are right. If the end-user is the business owner then I think I
have a point. I have discovred that for the business owner getting an
applicaiton written is only a part, and sometimes the smaller part, of the
solution. The real rub comes in trying to maintain it. If the developer
goes away or worse yet, if the software company that the application is
written in looses market share, its a real problem for the business owner.
He finds himself in the position of having climbed up the wrong latter.
This may be one of the most compelling reasons for using VB.net because I
see it as a solid tool for the future. But then, I don't see Access going
away either.





Chris Dunaway said:
take my clients to a tool as, what's the word, "complicated" as VB.net I
want to be sure I am doing what is best for them as well as me.
Click to expand...

I'm curious about this statement. Your clients (End Users?) shouldn't care
about the tool you use to create the app as long as it works. It seems to
me that the choice comes down to what is easier for you the developer to
use and maintain.

Just a thought,

Cheers


--
Chris

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.
Click to expand...
 
Hi Woody,

I think that with this you hit some good points, although there are much
more which Bill already stated.

To add something on your message, the change that an Access program is made
as spaghetti is much higher in my opinion than with a VB.net program. (This
is surely not always, I said the change)

Cor
 
Back
Top