.NET Windows Forms Application VS MS Access client Application

[Tony Toews]

"no touch" and
automatic installation of client application updates)

Once Access, likely runtime for all but your power users who will be
doing their own ad-hoc queries, reporting and exporting to Excel, is
installed, you can use the free Auto FE Updater so the clients can
pull down updates

I specifically created the Auto FE Updater utility so that I could
make changes to the FE MDE as often as I wanted and be quite confident
that the next time someone went to run the app that it would pull in
the latest version. For more info on the errors or the Auto FE
Updater utility see the free Auto FE Updater utility at
http://www.granite.ab.ca/access/autofe.htm at my website to keep the
FE on each PC up to date.

In a Terminal Server or Citrix environment the Auto FE Updater now
supports creating a directory named after the user on a server. Given
a choice put the FE on the Citrix server to reduce network traffic and
to avoid having to load objects over the network which can be somewhat
sluggish.

- Extensibility (ease of *quickly* adding substantial new functionality)

That's Access.

- Web access (eventually wants a Web UI in addition to Windows Forms UI)

But if the number of remote users is relatively small and controlled,
ie employees who are on the road or remote branches you may want to
consider Terminal Server/Citrix. In that scenario that cost would
likely be cheaper than a lot of work in getting the app to run on a
Web UI. This is in respect to an Access app. I have no idea how
quickly a Windows Form UI could be converted to work well on the web.

Now if the potential users are indeed general public using web
browsers then ignore my suggestion in the above paragraph. Although
even then such users may only require a small subset of the complete
apps functionality.

- Intuitive and attractive UI controls - including grids that can host
embedded controls (like a pop-up calendar or combo box).

Well, my users are pretty happy with the standard Access controls.
And using a pop calendar form rather than a control. Combo box?
With one exception the one in Access is quite good. The exception
being combo boxes on continuous forms where you want the source to be
different on each row.

- Multiple "security levels" (UI controls or entire forms are
enabled/disabled/hidden depending on user's security access level)

A little bit of home grown security combined with SQL Server security
would suffice here. Along with MDEs and blocking special keys or
whatever the setting is.

- Interfacing with external systems (as either a TCP client, as the consumer
of a Web service, and sending e-mail).

Sure.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Tony Toews]

7. Visual Studio .NET significantly increases developer productivity (vs MS
Access support for application development)
8. The .NET base classes significantly increase developer productivity by
pre-packing substantial functionality that would have to be coded from
scratch in MS Access.

One person I know quotes a .NET app as taking six times as long to
develop as the equivalent Access app. He is the technical person
for a largish consulting company in Sydney Australia.

DOWNSIDE OF a .MS Access Client Application:
1. Insert right here THE EXACT OPPOSITE of all of the benefits of a .NET
Windows Forms application, then:

Pretty sweeping statement

2. The client machine must have the correct version of MS Access installed
(i.e. they're stuck with a particular version, or all must upgrade
simultaneously).

No. If you distribute an A2000 MDE then A2000, A2002 and A2003 can
run the app. Furthermore you can do the development in A2003 and just
revert to A2000 when creating the MDE.

5. Date processing logic is less secure because users can, relatively
easily, view and modify the client-side code and/or queries.

Code no. Queries yes.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Jordan S.]

Thanks for the feedback Tony. Very helpful (throughout the thread today),
especially for clarifying some incorrect beliefs I held (like MS Access apps
being Access version-dependent).

Now, a couple of things:
RE: << One person I know quotes a .NET app as taking six times as long to
develop as the equivalent Access app. >>

That's easily the case when we're dealing with bound controls with little or
no programming logic (or at least relatively straight-forward programming
logic). But get into anything non trivial and there's just no way to
substantiate the cliaim that .NET takes longer to develop... reason being:
there's just no way that VBA can compete with the .NET base classes.

Now if were creating bound forms with bound controls, then yes - MS Access
dev time will be substantially lower than in .NET because one would have to
make the .NET form "data aware" while MS Access forms are data aware right
out of the box. My point: each product will "lose" the productivity game in
the other's neighborhood. MS Access shines when it comes to bound controls.
But put it up against an unbound scenario with complex busienss logic or
work flows and suddenly life with MS Access becomes very difficult... and
..NET dev time would easily be quicker than Access....

RE:
<< He is the technical person for a largish consulting company in Sydney
Australia >>
So am I (just not in Australia!), and you can see that I was incorrect about
some things!

-Jordan