VB .Net FE vs. Access 2003 FE

[Sharkbyte]

I have begun exploring expanding my skills into VB .Net. And while I fully
intend to learn this language, I am not yet even well-versed in some of VB's
functionality. So I was hoping to get some input from those of you who have
experience, with both VB and Access, in a distributed db environment.

1) Which front-end 'language' do you prefer? Why? In my limited
experience, while VB is more robust, it seems to perform slower than my
Access front-ends.

2) In a VB front-end environment, do you still need the Access engine to
support an Access back-end? I would assume yes, but then all of the
processing is being defined by VB...

3) Please add any personal observations. All information is greatly
appreciated.

Thanks, in advance, everyone...

Sharkbyte

 

[Arvin Meyer [MVP]]

What makes you think the VB is more robust? I prefer Access as a database
front-end in almost every case, even over a WAN if I can use a Terminal
Server. Why? Because Access has about 40% more data aware properties,
methods, and events. That makes it at least 3 times faster to develop with
than VB, and as much as 6 or 7 times faster than VB.NET or a web interface.
That allows you to give the client more value for his money, and allows you
to spend more time on the business process and data design, thus making it a
better product.

For the data-side back-end, I use either Access or SQL-Server depending upon
my requirements of size, number of users, and security.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads
http://www.datastrat.com
http://www.mvps.org/access

 

[Brendan Reynolds]

I'm not sure that it is practical to develop a distributed application in
Access. Using Access as the front-end to a server-based database, you can
develop a two-tier, client-server app. But as I understand it, a two-tier
client-server app is not generally considered to be a distributed app.

To attempt to answer some of your specific questions, though ...

1) My preferred language is neither VB.NET nor VBA, but C#. But the move to
..NET is much more than a change of language. There's a vast new object
model, new data access technology, and new reporting technologies to learn.

2) You need the JET database engine, not Access. Much of the documentation
uses the words 'JET' and 'Access' synonymously, but a .NET app can
manipulate data in an MDB file quite happily on a system on which Access is
not installed.

3) Personal observations. Well. ASP.NET rocks for web apps. If you're
developing a web app, then I'd have no hesitation in recommending ASP.NET.
This begs the question, though, of whether you have a good reason to develop
the app as a web app in the first place.

Another reason to consider a .NET app is that in some markets it just isn't
possible to sell an Access app. The myth of 'Access is a toy' is quite
widespread and hard to overcome. But unless you have specific requirements
that are difficult or impossible to fulfil using Access, or you're up
against serious customer resistance to using Access, then Access should be
your first choice for a typical data-centric desktop application.