.NET Windows Forms Application VS MS Access client Application

[Jordan S.]

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

[david epsom dot com dot au]

Re: .NET Windows Forms Application VS MS Access client Application

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:%23iVVsYoX GHA.196@TK2MSFT NGP04.phx.gbl.. .[color=blue]
> 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
>[/color]

[Jordan S.]

Re: .NET Windows Forms Application VS MS Access client Application

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.

[TC]

Re: .NET Windows Forms Application VS MS Access client Application

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

[Will]

Re: .NET Windows Forms Application VS MS Access client Application

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.

[TC]

Re: .NET Windows Forms Application VS MS Access client Application

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

[Brendan Reynolds]

Re: .NET Windows Forms Application VS MS Access client Application


"Jordan S." <A@B.COM> wrote in message
news:%23iVVsYoX GHA.196@TK2MSFT NGP04.phx.gbl.. .
[color=blue]
> 2. Much richer UI with .NET (vs MS Access UI controls)[/color]

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.
[color=blue]
> 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)[/color]

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.
[color=blue]
> 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.[/color]

See answers to 2 and 4 above.
[color=blue]
> 7. Visual Studio .NET significantly increases developer productivity (vs
> MS Access support for application development)[/color]

This has not been my experience.
[color=blue]
> 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.[/color]

This has not been my experience.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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).[/color]

See answers to 7 and 8 above regarding developer productivity.
[color=blue]
> 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) .[/color]

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.
[color=blue]
> Any additions to these lists are greatly appreciated![/color]

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

[Will]

Re: .NET Windows Forms Application VS MS Access client Application

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

[TC]

Re: .NET Windows Forms Application VS MS Access client Application


Will wrote:
[color=blue]
> Fair point that the developer skill is the key factor.[/color]

[color=blue]
> But do you really see Access as a scalable solution for a 120 form application?[/color]

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".

[color=blue]
> 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.[/color]

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.

[color=blue]
> 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.[/color]

You may well be right. I don't know enough about .NET & winforms to
have an opinion yet.

[color=blue]
> I do agree we shouldn't start bashing other technologies though, so
> please ignore my "torture device" comment posted previously[/color]

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

Cheers,
TC (MVP Access)

http://tc2.atspace.com

[Jordan S.]

Re: .NET Windows Forms Application VS MS Access client Application

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!

[SP]

Re: .NET Windows Forms Application VS MS Access client Application

"Jordan S." <A@B.COM> wrote in message
news:%23iVVsYoX GHA.196@TK2MSFT NGP04.phx.gbl.. .[color=blue]
> 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.[/color]

Without knowing the requirements I have the following comments.

You mentioned Jet a few times although you said the backend was to be SQL
Server. I would find out how or if Jet is even involved in a MS Access
application connecting to a SQL backend.

I have done some MS Access applications in the past. Primarily these were
data entry applications with reporting requirements. The editable controls
on the data entry screens had a 1 to 1 relationship with a table. The client
in these cases was looking for a way of getting information in so they could
get information out.

The requirements may not lend themselves to a purely data-centric
application but to an application based on an object model. How much
business logic is involved? Are there computational requirements involved as
the data is entered? What is the client's most sophisticated requirement?

SP

[Jordan S.]

Re: .NET Windows Forms Application VS MS Access client Application

Thanks for jumping in SP.

RE:
<< What is the client's most sophisticated requirement?>>

They are, in no particular order:

- Fast performance on a busy LAN/WAN (*very* important to the client)

- Maintainability (ease of modifying existing features; and "no touch" and
automatic installation of client application updates)

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

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

- MDI (with floating/dockable toolbars and windows, etc)

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

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

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

- Non trivial printing requirements; beyond simple reports.

Since it's been mentioned a couple of times in the thread, yes - MS Access
has a great report writer - built right in. For a .NET Windows Forms
application I'd tend to go with ActiveReports from DataDynamics
(http://www.datadynamics.com/Products...roduct=ARNET2).
It lets one bind a report to a variety of in-memory structures (lists,
arrays, etc) in addition to ADO.NET DataSets and DataTables; it's also
programmable with the hosting .NET language (e.g., C# or VB.NET), so no need
to learn some proprietary scripting language as is the case with Crystal.


-Jordan S.

[SP]

Re: .NET Windows Forms Application VS MS Access client Application


"Jordan S." <A@B.COM> wrote in message
news:u1a8lgxXGH A.1348@TK2MSFTN GP05.phx.gbl...[color=blue]
> Thanks for jumping in SP.
>
> RE:
> << What is the client's most sophisticated requirement?>>
>
> They are, in no particular order:
>
> - Fast performance on a busy LAN/WAN (*very* important to the client)
>
> - Maintainability (ease of modifying existing features; and "no touch" and
> automatic installation of client application updates)
>
> - Extensibility (ease of *quickly* adding substantial new functionality)
>
> - Web access (eventually wants a Web UI in addition to Windows Forms UI)
>
> - MDI (with floating/dockable toolbars and windows, etc)
>
> - Intuitive and attractive UI controls - including grids that can host
> embedded controls (like a pop-up calendar or combo box).
>
> - Multiple "security levels" (UI controls or entire forms are
> enabled/disabled/hidden depending on user's security access level)
>
> - Interfacing with external systems (as either a TCP client, as the
> consumer of a Web service, and sending e-mail).
>
> - Non trivial printing requirements; beyond simple reports.[/color]

Based on these requirement I would definitely be looking at .Net and not
Access. It seems way beyond a "data entry" application.

SP

[Guest]

Re: .NET Windows Forms Application VS MS Access client Application

> But do you really see Access as a scalable solution for a 120 form

Yes, we have way more than 120 forms in our application. I admit that when
we built our own template form and control objects, they were less robust,
harder to maintain, and had fewer features than the form and control objects
provided by Access, but perhaps most development shops really are better
than MS at creating form and control object templates.

The 'middle tier' argument is less often argued. In our case, we do have a
'middle tier', but it is a client-side middle tier, which limits
scalability, and only accessible from Access, which limits our options. I
can think of few situations in which I would decide, ex nova, to create a
middle tier in Access.

(david)

"Will" <william_pegg@y ahoo.co.uk> wrote in message
news:1144921394 .370175.319320@ z34g2000cwc.goo glegroups.com.. .[color=blue]
> 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
>[/color]

[TC]

Re: .NET Windows Forms Application VS MS Access client Application

Hi Jordan

One more pass from me. Note that I am *not* saying that in my opinion,
Access would be suitable for your client's application. I'm just
responding to some of the points in your original post.

[color=blue]
> BENEFITS OF a .NET Windows Forms Application:[/color]
[color=blue]
> 1. Client can be MDI (whereas Access only SDI)[/color]

Access is MDI by default. See my earlier post in this thread.

[color=blue]
> 2. Much richer UI with .NET (vs MS Access UI controls)[/color]

But - like what? You mentioned calendars. But calendars are easy to
program as a "drop in" Access popup form; and the next version of
Access might have some surprises here! So IMHO, you'd need to support
the allegation of "richer UI" by naming some specific types of controls
that .NET has, and Access doesn't.

[color=blue]
> 5. 3rd party UI controls for .NET are more ... capable, and rich than 3rd party COM controls.[/color]

As above: Why? Who says?

[color=blue]
> 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.[/color]

Truly, the developer is 90% of the equation & the toolset is 10% - if
that. If you don't believe me, just read the regular abominations on
http://www.thedailywtf.com - most of which are written in modern
toolsets like .NET! Some of the modern examples are completely
unmaintainable. A modern platform will not enforce maintainabilty *or*
enhancability. You're off-course if you're hoping that. Skilled
developers will produce maitainable & enhanceable systems, even on a
suboptimal platform. Unskilled developers will produce pea soup - even
on the very best platform. Management, of course, asume that the
"latest & greatest" toolset will solve their software development
problems. But that is just a hopeful assumption, in the absense of hard
statistics & studies.

[color=blue]
> 7. Visual Studio .NET significantly increases developer productivity (vs MS
> Access support for application development)[/color]

Who says? For what kinds of developers? Where is the evidence? You may
well be right - but I'm just saying, you can not argue by assertion.
You have to have some evidence. It sounds to me like: "It's newer -
thus better!"

[color=blue]
> 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.[/color]

Again - Like what? Who says? It's a "warm & fuzzy" statement that
proponents of .NET will undoubtedly agree with. But how do you know it
is true? How do you plan to *measure* your developer's productivity?
How will you *know* how productive (or not productive) they are? Is the
client *already* measuring dveloper productivity? If not, how will they
*know* if it increases - or decreases?

[color=blue]
> 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.[/color]

You're proposing a speed advantage for client server over file server.
Fine - but Access has no preference between the two, so the comparison
is nothing to do with Access as such.


Finally, I should stress again that I am *not* saying that in my
opinion, Access would be suitable for your client's application. I'm
just responding to some of the points in your original post. I feel, in
summary, that some of them are long on assertion, and short on actual
evidence!

Cheers,
TC (MVP Access)

http://tc2.atspace.com