473,699 Members | 2,421 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

.NET Windows Forms Application VS MS Access client Application

SQL Server will be used as the back-end database to a non trivial client
application.

In question is the choice of client application:

I need to be able to speak intelligently about when one client (MS Access vs
..NET Windows Forms) would be preferred over the other. While I have some
good arguments on both sides, I would appreciate your points of view on the
topic.

For the sake of this discussion, please assume a *non trivial* client
application with, say 120 forms, secure data processing, hundreds of
reports, and a clear need for a rich UI experience (MDI, a variety of rich
UI controls, non trivial printing requirements, etc).

I would appreciate help in compiling arguments both for and against each
technology (MS Access and .NET Windows Forms) as a client application.

So far I have this (in no particular order):

BENEFITS OF a .NET Windows Forms Application:
1. Client can be MDI (whereas Access only SDI)
2. Much richer UI with .NET (vs MS Access UI controls)
3. Easier deployment (with ClickOnce, XCopy, and similar .NET technologies
or methods). The client already has the CLR installed as part of their
standard desktop image - so I need to put nothing more than "XCopy" the
application files onto the local machine.
4. .NET requires a smaller footprint on the client with respect to the use
of 3rd party UI controls. MS Access is a COM-based technology and therefore
requires that 3rd party controls be COM controls. These require installation
to Windows\System3 2 and associated updates to the Registry (whereas .NET 3rd
party controls require only XCopy deployment to the application folder)
5. 3rd party UI controls for .NET are more prevalent, capable, and rich than
3rd party COM controls. Plus support for COM controls (i.e. number of 3rd
party companies making and supporting them) is expected to only decrease,
not increase, during the coming years - with the exact opposite trend
expected for 3rd party .NET controls.
6. .NET Windows Forms applications can take full advantage of OOP constructs
and patterns - thereby enabling the developers to create applications that
are easier to maintain, more easily extensible, and better architected than
the "equivalent " functionality provided in an MS Access application.
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.
9. Runtime performance of a .NET application would likely be faster than MS
Access because MS Access (really Jet) necessarily entails a file server
architecture, while ADO.NET necessarily entails a distributed (and
disconnected) architecture.
10. ADO.NET takes care of connection pooling automatically and provides a
huge amount of built-in functionality that substantially increases developer
productivity and increases programmer control over database communications
and updates (as compared to JET and DAO).

DOWNSIDE OF a .NET Windows Forms Application:
1. Increased expertise required for .NET development - vs. MS Access (at
least that's the perception of the client)
2. Requires the target version of the CLR to be installed on the client
machines (leading possibly to multiple versions of the .NET Framework
installed simultaneously. Not that I have a problem with it, but their
desktop support folks might).

BENEFITS OF a .MS Access Client Application:
1. Less expertise required on the part of the developers (at least that's
the perception of the client).
2. Out of the box it includes many useful UI controls and a first-class
report writer.

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:
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) .
3. Passthrough queries would be required in order to get the query
processing to happen on the server. Passthrough queries ential some
additional complexity than non passthrough queries.
4. Without the use of passthrough queries, SQL Server's locking mechanisms
can behave unexpectedly (e.g., locks can unexpectedly be placed on tables
rather than pages or rows) - thereby resulting in slower performance.
5. Date processing logic is less secure because users can, relatively
easily, view and modify the client-side code and/or queries.

Any additions to these lists are greatly appreciated!

Jordan
Apr 12 '06 #1
22 6267
That's amusing. I won't attempt to correct your opinions,
but note that you haven't addressed reporting yet. I've
used Crystal, Access, and Report Services, and my opinion
is that you really need to accommodate the skill set of your
developers.

(david)

"Jordan S." <A@B.COM> wrote in message
news:%2******** *******@TK2MSFT NGP04.phx.gbl.. .
SQL Server will be used as the back-end database to a non trivial client
application.

In question is the choice of client application:

I need to be able to speak intelligently about when one client (MS Access
vs .NET Windows Forms) would be preferred over the other. While I have
some good arguments on both sides, I would appreciate your points of view
on the topic.

For the sake of this discussion, please assume a *non trivial* client
application with, say 120 forms, secure data processing, hundreds of
reports, and a clear need for a rich UI experience (MDI, a variety of rich
UI controls, non trivial printing requirements, etc).

I would appreciate help in compiling arguments both for and against each
technology (MS Access and .NET Windows Forms) as a client application.

So far I have this (in no particular order):

BENEFITS OF a .NET Windows Forms Application:
1. Client can be MDI (whereas Access only SDI)
2. Much richer UI with .NET (vs MS Access UI controls)
3. Easier deployment (with ClickOnce, XCopy, and similar .NET technologies
or methods). The client already has the CLR installed as part of their
standard desktop image - so I need to put nothing more than "XCopy" the
application files onto the local machine.
4. .NET requires a smaller footprint on the client with respect to the use
of 3rd party UI controls. MS Access is a COM-based technology and
therefore requires that 3rd party controls be COM controls. These require
installation to Windows\System3 2 and associated updates to the Registry
(whereas .NET 3rd party controls require only XCopy deployment to the
application folder)
5. 3rd party UI controls for .NET are more prevalent, capable, and rich
than 3rd party COM controls. Plus support for COM controls (i.e. number of
3rd party companies making and supporting them) is expected to only
decrease, not increase, during the coming years - with the exact opposite
trend expected for 3rd party .NET controls.
6. .NET Windows Forms applications can take full advantage of OOP
constructs and patterns - thereby enabling the developers to create
applications that are easier to maintain, more easily extensible, and
better architected than the "equivalent " functionality provided in an MS
Access application.
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.
9. Runtime performance of a .NET application would likely be faster than
MS Access because MS Access (really Jet) necessarily entails a file server
architecture, while ADO.NET necessarily entails a distributed (and
disconnected) architecture.
10. ADO.NET takes care of connection pooling automatically and provides a
huge amount of built-in functionality that substantially increases
developer productivity and increases programmer control over database
communications and updates (as compared to JET and DAO).

DOWNSIDE OF a .NET Windows Forms Application:
1. Increased expertise required for .NET development - vs. MS Access (at
least that's the perception of the client)
2. Requires the target version of the CLR to be installed on the client
machines (leading possibly to multiple versions of the .NET Framework
installed simultaneously. Not that I have a problem with it, but their
desktop support folks might).

BENEFITS OF a .MS Access Client Application:
1. Less expertise required on the part of the developers (at least that's
the perception of the client).
2. Out of the box it includes many useful UI controls and a first-class
report writer.

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:
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) .
3. Passthrough queries would be required in order to get the query
processing to happen on the server. Passthrough queries ential some
additional complexity than non passthrough queries.
4. Without the use of passthrough queries, SQL Server's locking mechanisms
can behave unexpectedly (e.g., locks can unexpectedly be placed on tables
rather than pages or rows) - thereby resulting in slower performance.
5. Date processing logic is less secure because users can, relatively
easily, view and modify the client-side code and/or queries.

Any additions to these lists are greatly appreciated!

Jordan

Apr 13 '06 #2
Thanks for your perspective. Skill set of the developers is very important
as you mentioned, and a shorter learning curve on Access may be relevant to
the final decision.

Please feel free to add to the lists - *all* sides must be represented.


Apr 13 '06 #3
TC
Why do you say that Access is only SDI? You can open multiple forms,
each one individually resizable & repositionable within the Access
application window. Sounds like MDI, to me!

One of the primary advantages of Access, IMO, is its data-bound
controls. You don't need any code at all, to bind a control to a field
in the data source of a form or report.

As for the rest, IMHO you are asking too much from a newsgroup staffed
by volunteers. It would be a non-trivial consulting task to provide the
detailed comparative report that you want. And you'd really want it to
be done by someone who was expert in both technologies (winforms and
Access). Otherwise, it's too easy for the winforms person to slag
Access (through lack of knowledge of the product), and vice versa.

HTH,
TC (MVP Access)
http://tc2.atspace.com

Apr 13 '06 #4
It just frightens me that anyone would even consider using MS Access as
anything other than a torture device. Your point #6 for .NET benefits
is very important, and could easily be split out into about 20.

When the application needs to change to do some extra functionality
like access a web service, or perform complex operations on your data
then you would start crying if you were using access. An application
with 120 forms is probably going to have some seriously complex
requirement changes coming out that you won't find out about until mid
way through developing it (usually when the client actually sees a
screen working then says "oh, but if it's a saturday and it's raining
we don't do it like that"). You'll need the ability to put in some
serious design patterns that permit you to change this without having
to re-structure everything.

Apr 13 '06 #5
TC
Nonsense. A well designed & written systems can generally be enhanced
without much trouble. A badly designed & written system can't. The
workman has much more effect on this, than the tool. You could easily
have a well designed & written Access system, that was easy to enhance,
and a badly designed & written .NET system, that was a nightmare to
enhance.

TC (MVP Access)
http://tc2.atspace.com

Apr 13 '06 #6

"Jordan S." <A@B.COM> wrote in message
news:%2******** *******@TK2MSFT NGP04.phx.gbl.. .
2. Much richer UI with .NET (vs MS Access UI controls)
While it is true that there is a wider range of controls available in .NET,
Access provides all the controls that a typical data-centric application
really needs.
4. .NET requires a smaller footprint on the client with respect to the use
of 3rd party UI controls. MS Access is a COM-based technology and
therefore requires that 3rd party controls be COM controls. These require
installation to Windows\System3 2 and associated updates to the Registry
(whereas .NET 3rd party controls require only XCopy deployment to the
application folder)
See my answer to point 2 above. The availability or otherwise of third-party
controls isn't an issue when you don't need any third-party controls.
5. 3rd party UI controls for .NET are more prevalent, capable, and rich
than 3rd party COM controls. Plus support for COM controls (i.e. number of
3rd party companies making and supporting them) is expected to only
decrease, not increase, during the coming years - with the exact opposite
trend expected for 3rd party .NET controls.
See answers to 2 and 4 above.
7. Visual Studio .NET significantly increases developer productivity (vs
MS Access support for application development)
This has not been my experience.
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.
This has not been my experience.
9. Runtime performance of a .NET application would likely be faster than
MS Access because MS Access (really Jet) necessarily entails a file server
architecture, while ADO.NET necessarily entails a distributed (and
disconnected) architecture.
I can't say for sure whether a .NET app is likely to be faster, but I can
say from experience that a well-designed Access app can perform more than
satisfactorily on a LAN.
10. ADO.NET takes care of connection pooling automatically and provides a
huge amount of built-in functionality that substantially increases
developer productivity and increases programmer control over database
communications and updates (as compared to JET and DAO).
See answers to 7 and 8 above regarding developer productivity.
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) .
Not necesarily. Access 2002 and 2003 use the same file format by default as
Access 2000. You can run the same MDB under the last three versions of
Access, provided you are careful not to use any new features that were not
supported in Access 2000.
Any additions to these lists are greatly appreciated!


You haven't mentioned what you're going to use for reporting in .NET. SQL
Server Reporting Services is cool in many respects, but I miss the tight
integration of the Access report designer and engine, and SQL Server
Reporting Services requires additional installation and configuration on the
server.

Generally speaking, my experience so far is that ASP.NET has been a great
leap forward for Web-based applications, but I remain to be convinced about
the benefits of using Windows Forms for typical data-centric desktop
applications.

--
Brendan Reynolds
Access MVP
Apr 13 '06 #7
Fair point that the developer skill is the key factor.

But do you really see Access as a scalable solution for a 120 form
application? I do admit that I've only had a few frustrating encounters
with access forms applications, however it seemed to me that while
their databound controls are their strength for a simple application,
they lack the expressiveness available to .NET controls. I can see the
advantage of access forms if it's managing the database as well, but
when you need to have very particular formatting of your controls, and
tie in to a large variety of events .NET is definitely easier / more
obvious in how to do this.

Secondly, while I do accept that a .NET application can be written
badly, if written well then it will provide a more scalable and
maintainable architecture. I don't believe that Access was designed to
develop complicated middle tier logic, and while it may be possible to
do it in Access, .NET was built with this in mind.

I do agree we shouldn't start bashing other technologies though, so
please ignore my "torture device" comment posted previously

Apr 13 '06 #8
TC

Will wrote:
Fair point that the developer skill is the key factor.
But do you really see Access as a scalable solution for a 120 form application?
Access can easily handle 120 forms. There'd be squintillions of working
Access databases around the world with that number. However, you're
certainly right, that the number can not grow arbitrarily. So, winforms
might be more scalable here - I don't know.

But it does raise the question, how many is enough? What are all these
forms *for*, in systems that have hundreds & hundreds & hundreds of
forms? Every time I hear of one, I think: "Geez, surely it would be
possible to have a smaller # of forms & let them customize themselves
at runtime".

I do admit that I've only had a few frustrating encounters
with access forms applications, however it seemed to me that while
their databound controls are their strength for a simple application,
they lack the expressiveness available to .NET controls. I can see the
advantage of access forms if it's managing the database as well, but
when you need to have very particular formatting of your controls, and
tie in to a large variety of events .NET is definitely easier / more
obvious in how to do this.
It's hard to comment without specifics. You may be right - I don't know
enough about winforms to have an opinion. Certainly the Access event
model has a few deficiencies.

Secondly, while I do accept that a .NET application can be written
badly, if written well then it will provide a more scalable and
maintainable architecture. I don't believe that Access was designed to
develop complicated middle tier logic, and while it may be possible to
do it in Access, .NET was built with this in mind.
You may well be right. I don't know enough about .NET & winforms to
have an opinion yet.

I do agree we shouldn't start bashing other technologies though, so
please ignore my "torture device" comment posted previously


No probs, thanks for that acknowledgement . I was girding my loins, to
enter the fray!

Cheers,
TC (MVP Access)
http://tc2.atspace.com

Apr 13 '06 #9
Thanks for your perspective TC.

A couple of thoughts:
RE:
<< It would be a non-trivial consulting task to provide the detailed
comparative report that you want.>>
Exactly! That's my job and that's why I provided the initial lists in the OP
(to get the ball rolling). I hope I provided at least the "big hits" and
that that good folks here in the NG can just scan and say "oh, you missed x,
y, or z".

RE:
<< And you'd really want it to be done by someone who was expert in both
technologies (winforms and Access). >>
That's me to some extent also. FWIW I have 5 years of full-time and non
trivial MS Access programming experience (Access 2.0 through 97), 4 years in
VB, and 3 in .NET. So I can lay claim to some awareness of the strengths of
MS Access, plus some other technologies.

RE:
<< Otherwise, it's too easy for the winforms person to slag Access.... and
vice versa >>
I'm not here to bash MS Access nor start any flame war. I'm just recognizing
a situation where it may not be the *best* tool for the job. Rather than
just saying "geeze we shouldn't use Access for non trivial UI programming" I
want to be able to state specifically why. And if I'm wrong in my
assumptions or beliefs then I also want to know specifically why.

Finally, towards avoiding a flame war, I'd like to encourage respondents to
avoid arguing against any points anyone here makes. All are taken as either
[completely valid] or [perceived as valid] and thus are greatly appreciated.

Thanks again!
Apr 13 '06 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
3289
by: Chris Dunaway | last post by:
A quick scan of the group did not immediately reveal an answer to my questions so here goes. First let me describe my app and then I'll ask the questions. I am writing a Windows Forms App (not Web Forms) that serves as a thin client to some web services. In other words, the Windows Forms app will be installed on the client machines and that app will call web services that are deployed on my server.
3
2717
by: Nick | last post by:
I am working a new application...well actually a series of applications for my company. They want internal users to be able to go to a site and everything regarding security is transparent, however we will have brokers and customers that also need to connect and will require a username and password. In this case we were going to store their credentials in a SQL database. Internal users will have the ability to access the same resources...
5
1996
by: Rajat Tandon | last post by:
Hello Everybody, Please guide me so that I can fulfill this challenging assisnment ... I have been asked to "Restructure a Windows application" from scratch in 2 months. The existing application which is working but it is very heavy as no proper application architecture and layering has been followed for this. It was really hard to maintain (as I was maintaing it till now) . First let me tell u a bit about my application ...
5
2690
by: pberna | last post by:
Dear all, I built a Web Form application to start and stop a Windows Service remotely. I successful tested the application on Windows 2000 server + IIS. I must include the ASPNET user to the Administration group (on server side) to have the necessary authorization to start a Windows Service (I don't understand why "Power User" rights are not enough to do the same thing) Although I'm able to start a service using windows 2000 server...
5
1812
by: david | last post by:
I have developed my web service with a domain name of my computer name and wwwroot directory. I also developed a client of windows form application. It works locally (i.e. in the same machine). When I copy my client application to another machine and start it, I got an error about initialized problem. Note that I can browser my web service .asmx file from the second machine. The sample client source code:
4
3527
by: James | last post by:
I have a VB windows forms application that accesses a Microsoft Access database that has been secured using user-level security. The application is being deployed using No-Touch deployment. The objective in utilizing this new deployment method is to reduce the maintenance overhead as well as making it easier for my users to setup and run the application initially. I have VS 2002, Windows XP, Access XP(2000 format). He is my problem....
2
2282
by: Frankie | last post by:
Using SQL Server 2005 and .NET 2.0; I'm creating a Windows Forms application that will need to display photos of people, along with a bunch of information about each person. In a Web application, there is a generally accepted "best practice" of storing only a string (the path to the .jpg file name), with the actual file stored in an NTFS folder (and not in the database). What's the standard practice for Windows Forms applications? Is...
4
4018
by: Pini | last post by:
Hi all, I have a massive windows application that refernces a lot of assemblies and doing a lot of DAL anf IO operations. I want to expose this application to the interner so that a user can access it using a web browser. How can i do it? Do i have to use smart client? Can i do it using activex controls?
3
4292
by: shobhitguptait | last post by:
How to Run C#.NET Windows App on N/W with centralized DB using SQL SERVER 2000 Hello All...i m really grate full to c such a website where developers try to help people like us who face problems in s/w develepment...I am shobhit Gupta...23 years of age prusuing B.Tech in I.T. Engg. Final Year from Kurukshetra University, Kurukshetra. Recently, i have been working on a project which is to be implemented in a hospital for real life use...Its a...
0
8621
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
9041
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
8928
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
8890
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
7757
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
6538
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5877
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
2
2355
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
2013
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.