.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\System32 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]

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

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]

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]

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]

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]

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\System32 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.

 

[Will]

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]

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

 

[Jordan S.]

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]

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.

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

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/ProductOverview.aspx?Product=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]

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.

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

SP

 

[Guest]

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)

 

[TC]

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.

BENEFITS OF a .NET Windows Forms Application:

1. Client can be MDI (whereas Access only SDI)

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

2. Much richer UI with .NET (vs MS Access UI controls)

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.

5. 3rd party UI controls for .NET are more ... capable, and rich than 3rd party COM controls.

As above: Why? Who says?

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.

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.

7. Visual Studio .NET significantly increases developer productivity (vs MS
Access support for application development)

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

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.

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?

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.

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

 

[TC]

Further to the "developer versus toolset" thing, tell me what level of
"increased productivity" you would expect from the following developer:

http://www.thedailywtf.com/forums/63312/ShowPost.aspx

Hmm ... negative? fractional?

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

 

[Jordan S.]

Thanks for jumping back in, TC:

I think you identified a place where I may misunderstand MS Access... so if
you'd be kind enough to please elaborate. Regarding MS Access having a [file
server architecture]: In response to my apparent misunderstanding you wrote
<< Fine - but Access has no preference between the two [file server vs
client server], so the comparison is nothing to do with Access as such >>.
Can you elaborate on how MS Access can take on a true client relationship in
a client/server relstionship with say an MS SQL Server database? I'd
appreciate it.

Clarifying that one fact (above) may cause my final analysis to take a
completely different direction. It has huge implications for performance of
MS Access client applications. I'd hate to inaccurately misrepresent what's
possible and what's not.

Separately, I *completely* AGREE with you that anyone can write bad code in
*any* language or platform.

RE:
<< You may well be right - but I'm just saying, you can not argue by
assertion>>
Correct again!
So here's some objective data, the sort of which you inquire (although it
doesn't directly compare MS Access with .NET, it certainly provides support
for the general assertion that .NET offers increased developer productivity
vs other techologies).
http://www.gotdotnet.com/team/compare/petshop.aspx
http://www.promoteware.com/Module/Article/ArticleView.aspx?id=10

Additionally, subjective analysis cannot be completely discounted (just like
"objective" analyses can never really be truly objective). Nobody's going to
be able to take the time to conduct highly controlled lab experiments and
subsequently replicate them in order to verify results in some big effort
to obtain "objective, quantifiable" measures of some claims. Sometimes we go
on simple, straight-forward, deductive reasoning. So it's not really fair or
reasonable to say that someone must come up with "objective" data to back up
all assertions, and if they don't, then their assertions are automatically
presumed false.

So, here's an example of how one could arrive at a conclusion that .NET
increases developer productivity (by using simple deductive reasoning)
without going to a lab and conducting experiments:
If, in VBA I want an array that is sorted, I have to do the sorting myself
in code that I write. I have to chose a sorting algorithm, then implement
it - which means testing and debugging. That all takes time. On the other
hand, the .NET base classes include a class called ArrayList which can sort
itself. So I have to write one line of code to tell the ArrayList to sort
itself. So, "common sense" (yes - I know it's rather uncommon!) tells us
that it takes less time to write one line of code vs. writing many lines of
code; therefore increased developer productivity. So the claim (that .NET
base classes increase developer productivity) is more than a "warm and
fuzzy" statement. It IS a warm and fuzzy statement, but it's also a TRUE
warm and fuzzy statement

NEXT:
RE:
<< Re"Much richer UI with .NET (vs MS Access UI controls)"...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.>>

Here are a bunch of specific types of controls that .NET has that Access
doesn't (and this is from just one 3rd party control provider):
http://www.infragistics.com/products/NetAdvantage/WinForms/Default.aspx
Be sure to take a close look at the controls. You can say that MS Access has
*similar* controls; but what ships with MS Access isn't even *close* to what
is provided by these particular controls (both qualitatively and
quantitavely). For instance check out the "Card View" of a grid. Truly
useful - that view. Nothing like it in MS Access (although MS Access does
have a grid - it's just provides absolute minimal functionality in
comparison). But you don't have to take my word for it - just take a few
minutes at the link above to explore it all.

Let's keep this thread and debate "spirited" at most (nothing
approaching a flame - anyone - please!).

Cheers!

 

[TC]

Thanks for jumping back in, TC:

No probs. I'll just address your first point, and get back to the
others tomorrow. It's now 5 AM here, and I haven't eaten dinner yet!

I think you identified a place where I may misunderstand MS Access... so if
you'd be kind enough to please elaborate. Regarding MS Access having a [file
server architecture]: In response to my apparent misunderstanding you wrote
<< Fine - but Access has no preference between the two [file server vs
client server], so the comparison is nothing to do with Access as such >>.
Can you elaborate on how MS Access can take on a true client relationship in
a client/server relstionship with say an MS SQL Server database? I'd
appreciate it.

Here's the gen: Access is not a database engine. It has no inherent
database capabilities. It is entirely unable to create or manage
database tables or indexes, parse & execute SQL statements, control the
access of multiple users, and all the other "database engine" tasks
that are required of it. It simply does not do those tasks.

Instead, Access is just a front-end interactive development environment
(IDE), which lets the user create, manage, store & execute forms &
reports. It *seems* to let the user create & manage tables & indexes,
parse & execute SQL statements, and so on - but it *defers* those tasks
to an external database engine. Without an external database engine,
Access can not do those tasks.

By default, Access comes together with MS Jet, which is a *file server*
database engine. So, when an Access form or report executes an SQL
statement, for example, Access (on the client PC) will:
- parse the statement;
- pull in some index data blocks from the back-end database file on the
server;
- use that index data to work out what further data blocks it requires;
- pull in those further data blocks from the server,
- munge it all together (eg. to action JOINs or UNIONs), then
- extract the actual data columns & rows required by the SQL statement.

But an Access front end can just as easily use a *client server*
database engine such as SQL*Server or Oracle. In that case, the Access
form or report can execute an SQL statement in "pass through" mode; in
which case, Access (on the client PC) will:
- pass that statement to the client/server back-end database;
then the *client/server back-end database* will:
- parse the statement,
- work out how to execute it,
- execute it,
- collect the actual data columns & rows required by the SQL statement,
then
- send that data (and *only* that data) back to the Access front-end.

So as you can see, Access does not say: "I am a file srver database
program". It says: "I am a front-end interactive development
environment. Connect me to whatever back-end database engine you want".

I'm not saying that the same code would work, unchanged, with equal
efficiency, against a file/server back end (eg. MS Jet) *and* a
client/server back end (eg. SQL *Server). You'd need to know the
back-end type, up front, to write the most efficient code. I'm just
saying that Access, *itself*, is agnostic as to the ature (file server
or client/server) of the back-end database engine.

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

 

[Tony Toews]

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.

How is .Net going to make this kind of restructuring easier?

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]

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 had one system with 450 forms and 350 reports. But I needed them
all. There were 160 tables in the app.

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