Last Post on the Topic: MS Access vs. Something Else

[Jordan S.]

So I'm trying to help a client determine if they should rewrite an existing
problemmatic system using an MS Access client (the database is already SQL
Server) or use something else. The decision has become a big political
football, so I'm trying to get down to some "as objective as possible"
heuristics or "rules of thumb" I have come up with over the past few days
that can be used to help make the decision. The decision will not be mine,
but I can substantially influence it. I'd hate to be totally wrong about
anything I claim.

Please note that I am not at all "Anti-Access" (I did over 5 years of non
trivial Access programming - so I understand that it is far more capable
than it often gets credit for being), and this post is not intended in any
way to cast MS Access in any negative light. I believe that MS Access has
strengths and weaknesses. Consequently, it frequently IS THE BEST solution
for some problems, while it is not the best solution for every problem (just
like every other technology we've ever had).

So I would appreciate your honest non flaming feedback on my list of
heuristics below.

FAVOR THE USE OF MS ACCESS *client* APPLICATIONS WHEN.
1. the use of bound controls will suffice (e.g., minimal or no processing
between the UI and the database is required).

2. realtime communication or integration with external systems is not
required.

3. relatively straight-forward user interfaces will suffice - with no
specialized 3rd party COM controls required, and with minimal or no MDI
requirements.

4. while lengthy or complex business logic may be present, the purpose of
the application is largely to maintain data in a database; insert, update,
delete, read data, and generate reports.

FAVOR THE USE OF SOMETHING OTHER THAN MS ACCESS as a *client* WHEN..
1. the use of bound controls would be difficult or impossible (e.g., when
any logical or physical middle tier components are *required*).

2. communication, interoperability, or integration with external systems is
required.

3. non trivial user interfaces are required, necessitating the use of
specialized 3rd party controls, and/or with full MDI capabilities required.

4. complicated business logic, data processing rules, or workflow
orchestration is required.

5. non trivial user services are required (perhaps involving the caching of
complex data structures designed to improve overall system performance).

6. the purpose of the application far exceeds simple data maintenance and
retrieval tasks.

7. users of the application will be geographically dispursed (i.e., not all
on the same LAN... some on a slow WAN link).

8. multiple application types are required to interface with the database
and/or middle tiers (e.g., Windows Forms application, Web Forms application,
Smart Client Application, Web Services, etc).

9. Substantial extensions to core system functionalities are foreseeable -
AND such extensions would not be satisfactorily met in an MS Access client
application (even if the short-term needs could be met entirely with an MS
Access client).


Please note that we're interested in Access *client applications* - NOT
Access as a database (so no contention or scalability issues addressed).

Thanks for your thoughtful feedback.

-Jordan

 

[david epsom dot com dot au]

SQL Server linked table transactions are broken in Jet 4/
Access 2K+. All the transactions have to be moved up to
the server, invalidating most of what I have to say here.

So this message is a valadiction for Access 97...



I started to answer in-line, then realised I was still on a
different wavelength, and it would be easier to explain that
first.

Access is a beautiful environment for complex business logic
and complex middle tier processing. Written in Access. Located
on the Client computer.

Access is a powerful, flexible and efficient distributed
processing environment for complex business logic and middle
tier processing. Which is written in Access, and copied (file
copy) to the client computers.

Sometimes, people don't want a powerful, flexible, and efficient
distributed processing environment with file-copy installation
for complex business logic and middle tier processing. Sometimes,
people are making stratigic decisions about the skills they want
to have in house, or the skills they have in house, or distributed
vs centralised support, or code piracy protection, or the
marketability of the product, or any of a hundred other business
or technical criteria.

So then I realised that when you were talking about the
unsuitability of Access for complex multi-tier applications, you
had already decided that your middle tier would not be in Access,
and would be centralised to a few servers.

Ok. I can live with that.

Secondly, all of our best user interfaces were written in C, C++,
and Pascal (and designed by a graphic artist). Ultimately, the RAD
Access interface is limiting.

Thirdly, we don't use Access for our Web interface :~)

Now, read on:

So I'm trying to help a client determine if they should rewrite an
existing problemmatic system using an MS Access client (the database is
already SQL Server) or use something else. The decision has become a big
political football, so I'm trying to get down to some "as objective as
possible" heuristics or "rules of thumb" I have come up with over the past
few days that can be used to help make the decision. The decision will not
be mine, but I can substantially influence it. I'd hate to be totally
wrong about anything I claim.

Please note that I am not at all "Anti-Access" (I did over 5 years of non
trivial Access programming - so I understand that it is far more capable
than it often gets credit for being), and this post is not intended in any
way to cast MS Access in any negative light. I believe that MS Access has
strengths and weaknesses. Consequently, it frequently IS THE BEST solution
for some problems, while it is not the best solution for every problem
(just like every other technology we've ever had).

So I would appreciate your honest non flaming feedback on my list of
heuristics below.

FAVOR THE USE OF MS ACCESS *client* APPLICATIONS WHEN.
1. the use of bound controls will suffice (e.g., minimal or no processing
between the UI and the database is required).

We do quite a lot of processing between the UI and the database.
Those forms are bound to local tables, which are not bound to the
database. All of the processing takes place between the temp table
and the destination tables. It's not an issue.

2. realtime communication or integration with external systems is not
required.

All the realtime communication I've done has been with a Winsock DLL.
As it happens, there has never been an Access application at either
end, but the VB coding was exactly the same as I do in Access.

The integration with external systems I've done has been with com objects
and DLL's. The com objects and DLL's were agnostic wrt my calling program.
I've done that in C++ (VS6) Borland C, VB, VBS, Access. I can't say it
was any different in Access than in any other environment, except for
driving the hardware com port, which did feel different over the years
and in different environments.

3. relatively straight-forward user interfaces will suffice - with no
specialized 3rd party COM controls required, and with minimal or no MDI
requirements.

I've never had any problem inserting COM controls into Access, but if you
aren't using the native Access controls, it certainly weakens the argument
for Access.

4. while lengthy or complex business logic may be present, the purpose of
the application is largely to maintain data in a database; insert, update,
delete, read data, and generate reports.

The reason our main application is in Access is that, when it was started,
Access was the best place for including all your complex business logic
in one place. It still works for us (although we have since abstracted most
of the technical stuff into a seperate layer).

I am reminded of the story of a large business application originally
written
in Pascal, ported to C. A company spokesman explaned that when it was
written,
all the graduates knew Pascal. The platform was changed because all the new
graduates didn't know Pascal. Access is still a good environment for complex
business logic, but if you want to write your complex business logic in C#
instead of VB and SQL, there is nothing for you here.

FAVOR THE USE OF SOMETHING OTHER THAN MS ACCESS as a *client* WHEN..
1. the use of bound controls would be difficult or impossible (e.g., when
any logical or physical middle tier components are *required*).

I would have no problems using a local table and a middle tier. In fact,
that is how I've done it: I needed to buffer the network communication,
and using a table was a RAD way to achieve that end.

Having a local table, I wouldn't have any problem binding it to an
Access form: that is our normal Access approach anyway.

But I do have something different to say:

1a) The use of bound controls would be difficult or impossible, because,
rich as they are, sometimes you want something smoother for your UI.

2. communication, interoperability, or integration with external systems
is required.

That just seems to come out of left field. I can't think why that would
lead me to favour any of the platforms I've used.

3. non trivial user interfaces are required, necessitating the use of
specialized 3rd party controls, and/or with full MDI capabilities
required.

I can get to 80% faster this way... if you want the extra 20% it's gonna
cost you 80% more, but sometimes that's a price you have to pay.

4. complicated business logic, data processing rules, or workflow
orchestration is required.

It's the complex data processing rules Access really shines at. It's
so simple, so cheap, so easy to install, modify, upgrade.

5. non trivial user services are required (perhaps involving the caching
of complex data structures designed to improve overall system
performance).

I do all that, but I'm working in Access anyway.

6. the purpose of the application far exceeds simple data maintenance and
retrieval tasks.

None of the applications I work on are simple data and report applications.
I see applications like that sometimes when I add email, replication,
General
Ledger interfaces, process integration or whatever to other peoples
applications, but our own application runs 7 data streams out of each
transaction, plus audit records. I've got simple option pricing using
Monte-Carlo simulation,

7. users of the application will be geographically dispursed (i.e., not
all on the same LAN... some on a slow WAN link).

Again, I don't have a problem funnelling data through a socket interface.
I didn't find C or Pascal more or less productive than VB, and I don't
expect to find c# particularly different: it's still a socket interface
no matter which library you load.

8. multiple application types are required to interface with the database
and/or middle tiers (e.g., Windows Forms application, Web Forms
application, Smart Client Application, Web Services, etc).

We don't use Access for our Web interface :~)

9. Substantial extensions to core system functionalities are foreseeable -
AND such extensions would not be satisfactorily met in an MS Access client
application (even if the short-term needs could be met entirely with an MS
Access client).

If you define it as a need that can't be met in an Access client, then an
Access client is not suitable by definition, but it's a circular argument.

 

[Brendan Reynolds]

FAVOR THE USE OF MS ACCESS *client* APPLICATIONS WHEN.
1. the use of bound controls will suffice (e.g., minimal or no processing
between the UI and the database is required).

I agree on 'use of bound controls' but I'm not sure that I would agree that
use of bound controls necessarily means 'minimal or no processing between
the UI and the database'. You can use bound controls yet still have
non-trivial processing in, for example, BeforeUpdate event procedures. In
recent versions of Access, you can even bind forms to disconnected
recordsets - though I've never yet encountered a need to do so.

2. realtime communication or integration with external systems is not
required.

What sort of communication or integration are we discussing here, with what
sort of external systems? Are you aware, for example, that you can call web
services from Access 2002 or 2003?

3. relatively straight-forward user interfaces will suffice - with no
specialized 3rd party COM controls required, and with minimal or no MDI
requirements.

As I've said elsewhere, I have never found the range of controls available
in Access to be a significant limiting factor. Sure, if you want to do, say,
drag-and-drop from one control to another, Access is limited in that
respect. But how many data-centric applications really *need* that kind of
UI?

Not sure what you mean by 'minimal or no MDI requirements'?

4. while lengthy or complex business logic may be present, the purpose of
the application is largely to maintain data in a database; insert, update,
delete, read data, and generate reports.

Absolutely, that's what Access is for.

FAVOR THE USE OF SOMETHING OTHER THAN MS ACCESS as a *client* WHEN..
1. the use of bound controls would be difficult or impossible (e.g., when
any logical or physical middle tier components are *required*).

As we've discussed in another thread, you can bind Access forms to
recordsets (DAO or ADO) but that's as far as you can go. If your app really
needs the kind of flexibility that .NET offers, with its ability to bind to
custom objects or typed or untyped datasets, then Access would not be a
viable option for that application.

2. communication, interoperability, or integration with external systems
is required.

Again, what kind of communication, interoperability or integration, with
what kind of external systems?

3. non trivial user interfaces are required, necessitating the use of
specialized 3rd party controls, and/or with full MDI capabilities
required.

I agree that there is better third-party support for COM and .NET, but
disagree that only trivial user interfaces can be created without third
party controls.

Again, what exactly is meant by 'full MDI capabilities'?

4. complicated business logic, data processing rules, or workflow
orchestration is required.

Complicated business logic and data processing rules can be implemented
using Access. I can't comment on workflow orchestration, as I do not have
enough experience in that area to have an opinion.

5. non trivial user services are required (perhaps involving the caching
of complex data structures designed to improve overall system
performance).

Not really sure what you have in mind here. In Access you can easily do
things like storing static or relatively static data in local lookup tables.
But 'non trivial user services' could mean many different things.

6. the purpose of the application far exceeds simple data maintenance and
retrieval tasks.

Again, 'simple' is a very relative and subjective term. An Access app can
perform complex data maintenance and retrieval tasks, it is not at all
limited to only 'simple' tasks. At least, not according to my definition of
'simple'.

7. users of the application will be geographically dispursed (i.e., not
all on the same LAN... some on a slow WAN link).

Generally, yes, though as others have suggested elsewhere Terminal Services
or Citrix can be used.

8. multiple application types are required to interface with the database
and/or middle tiers (e.g., Windows Forms application, Web Forms
application, Smart Client Application, Web Services, etc).

Yes. You can certainly have an Access app and an ASP.NET app or web service
interfacing with the same database, but they can not share code and/or
components to the same extent that a .NET Windows Forms and an ASP.NET app
could, so you would likely find yourself duplicating work in .NET and VBA.

9. Substantial extensions to core system functionalities are foreseeable -
AND such extensions would not be satisfactorily met in an MS Access client
application (even if the short-term needs could be met entirely with an MS
Access client).

Agreed - though we might have different ideas about what requirements can or
can not be satisfactorily met using Access.

 

[Larry Daugherty]

Excellent David!

Yep. "Question" #9 of the Anti-Access side was slipped in there as a
show-stopper. Someone is averse to the consideration of an Access
solution and posited a negative conclusion as though it were a
question.

Jordan, you won't get absolutely unbiased questions here because those
of us lurking here favor Access in some way(s). Many of us are
professional developers.

You might find it enlightening to post your questionnaire into
newsgroups of all of the other platforms you're considering. Replace
"Access" with "Delphi", "VB", "C++" etc. Throw out Q#9 in part 2 and
don't include it in the other newsgroups.

Irrespective of the chosen platform, the expertise of the developer(s)
will have a lot to do with cost and success.

HTH

 

[Jordan S.]

Thanks for the discussion Brendan (and david)...

It appears to me (after several related threads on this topic) that our
decision will...
1. NOT be about what is [possible] with MS Access - but rather [what it
would take] to accomplish certain things, and associated development time
(and "complexity" of the final product).
and
2. be substantially influenced by our definition of terms and phrases - like
"need" "requirement" "complex" and "can be done in Access"

At the end of the day I understand that MS Access clients can be extended
beyond the "built-in capabilities" by calling the Win32 API, that local
tables can serve as "temp tables" and be bound to in order to leverage the
binding capabilities of .NET while doing some local "middle tier" processing
that can be non trivial. I've done all of that. What I'm looking at is
development time. Binding to a base table or query is where Access really
gets its RAD reputation. When you get away from that (by binding to local
temp tables that get populated in code - perhaps involving passthrough
queries) you're creating a more complicated system (mimicking a disconnected
recordset, really). So the question becomes - is Access best suited for this
job, or is there something better? - something designed specifically to deal
with disconnected datasets... and there is (ADO.NET - it's awesome!). Of
course just because something perceived as "better" may exist doesn't mean
we automatically adopt it without careful consideration of the tradeoffs
(which is what these threads are all about - the *tradeoffs*, if we can nail
any down).

Now, to follow up on some specifics from your post...

RE:
<< what exactly is meant by 'full MDI capabilities'? >>
In particular I'm thinking about having dockable forms, panels and toolbars
and tabbed MDI forms (as is available in VS.NET - and feature available to
developers in a 3rd party .NET component suite).

RE:
<< But how many data-centric applications really *need* that kind of UI? >>
The answer boils down to one's definition of *need*.

My grandfather thinks that e-mail commuication is the most ridiculous form
of communication known to mankind - really. He honestly doesn't understand
why one would fire up a computer, connect to the Internet, then type a
message... when one could "more easily" pick up the phone, say what's on his
mind, then hang up... all faster than the time it takes for the computer to
boot up. My grandfather doesn't *need* email - and neither do you or I...
er, um... hummm, maybe I should think about that

I agree that the range of controls available in Access is not necessarily
limiting... if the objective is to create an "attractive" user interface.
But one of my primary objectives as a developer is to create user interfaces
that are as *transparent* to the user as possible (aka "intuitive"). This is
different than creating an "attractive" user interface. Some of the 3rd
party controls (e.g., tabbed mdi forms... just as one example - there are
others), and the ability to dock/undock panels, forms, and toolbars goes a
long way toward creating intuitive or transparent user interfaces. Yes - a
good job can still be done without those controls, but the user experience
could be quite different if the developer is using only the controls
available in MS Access.

So at the end of the day we (me and my client) are getting hung up on
definitions of terms like "intuitive" and "need." That's why I'm looking to
get objective factual data about [what it would take] to do certain things
in MS Access. Like, for example, the use of 3rd party controls. If one is
"needed" that is not included with MS Access, then the COM control would
have to be installed AND registered on the client machine. That's an
important fact that cannot be disputed and does not hinge on anyone's
definitions. Knowing those facts, we can then decide if we want to go around
installing additional software (the ocx) and updating the Registry on all
client PCs, then accepting the fact that we're no longer just deploying and
supporting one single MDB file (and opening up ourselves to "DLL hell"). Do
we want to live with that? Maybe so, maybe not - but at least I've
identified it as fact (FWIW and by way of comparison, 3rd party .NET
components do not need to be registered... simply copied to the application
folder).

RE:
<< If your app really needs the kind of flexibility that .NET offers, with
its ability to bind to custom objects or typed or untyped datasets, then
Access would not be a viable option for that application.>>

Agreed, but at the end of the day we're back to the definition of "need".

Thanks for your input. I guess my "final report" will be far less conclusive
than I was hoping to achieve. Perhaps the final decision will be made based
on "what we want to live with" than what is technically possible or not with
MS Access.

-Jordan

 

[Jordan S.]

Sorry to disappoint, Larry, but #9 was not "slipped in" in some malicious
fashion like you purport.
I agree in retrospect that it was circular reasoning... but what I
attempting (and apparently failed) to capture succinctly was this:
"If everything we need *today* can be done in MS Access, that doesn't
necessarily mean we should do it in MS Access BECAUSE *tomorrow* we may need
to have something that is not easily done in MS Access. SO IF we know,
today, for sure that we'll soon need something that isn't easily
accomplished in MS Access - then we might want to NOT go with MS Access and
create a solution that we know will "soon" need to be replaced." That's what
#9 was really about, believe it or not.

Finally, I find your labeling of me as "Anti-Access" completely unhelpful.
You sound as if you have an "us vs. them" attitude. If you have followed my
recent threads related to this topic you will see that I have a lot of
experience creating non trivial MS Access applications. I also have
extensive experience in other technologies. So I'm neither "pro access" nor
"anti access." What I am is "Anti-the-wrong-solution-for-the-problem". So if
..NET is the wrong solution for the problem, then *in that case* I'd be
"Anti-.NET". And if MS Access is the wrong solution for the problem, then
*in that case* I'd be "Anti-Access." So what this and related threads are
*really* all about is trying to have a reasonable discussion about what I
perceive as limitations of MS Access. I have specifically asked the group to
point out where I am wrong about my beliefs or assumptions. That's not
"Anti-Access."

RE:
<< Many of us are professional developers >>
Then act like it and stop assuming that people malevolent and labeling them
as "Anti Access" just because they may pose questions about some possible
limitations of Access. I'm sure you'd agree that MS Access has *some*
limitations - yes? Can we talk about those without getting upset and
labeling each other?

RE:
<< You might find it enlightening to post your questionnaire into newsgroups
of all of the other platforms you're considering>>
Why would I do that when I want MS Access people to tell me what they think
about MS Access' possible limitations? You folks are the most knowledgeable
about the strengths and weaknesses of the product. In the past I have posted
simultaneously to MS Access + other groups and it quickly becomes an "us vs.
them" debate that I was trying to avoid.

Finally, and please think about this: If I were "Anti-Access" as you
apparently believe, I would NOT be posting ANY questions in this group. I
wouldn't even be asking the questions; instead I'd be talking with my client
about moving forward with an alternative platform or technology.

-Jordan

 

[Brendan Reynolds]

I agree in retrospect that it was circular reasoning... but what I
attempting (and apparently failed) to capture succinctly was this:
"If everything we need *today* can be done in MS Access, that doesn't
necessarily mean we should do it in MS Access BECAUSE *tomorrow* we may
need to have something that is not easily done in MS Access. SO IF we
know, today, for sure that we'll soon need something that isn't easily
accomplished in MS Access - then we might want to NOT go with MS Access
and create a solution that we know will "soon" need to be replaced."

<snip>
It comes down to definition of terms again. If everything that we need today
can be done in Access, but we estimate a 90% probability that we'll need
something in 12 months time that can't be done in Access, then we probably
shouldn't use Access. But if everything that we need today can be done in
Access, but we estimate a 60% probability that we may need something in five
years time that can't be done in Access, then the case for using Access
becomes much stronger.

You said something in another post about each tool losing its advantage in
the other's neighbourhood. This is very true. The problem, then, becomes not
one of deciding which tool is best, but in which neighbourhood we find
ourselves.

 

[Jordan S.]

Thanks again Brendan for the helpful and reasonable dialogue,

RE:
<< The problem, then, becomes not one of deciding which tool is best, but in
which neighbourhood we find ourselves.>>

Brilliant! I couldn't agree more.

While I don't know what specific tradeoffs the client will consider most
important, I am fairly certain that many non technical considerations (i.e.,
the neighbourhood and the economics of all technologies under consideration)
will significantly influence the final decision. I need to speak to those,
thus my recent inquiries into both [what Access can do] and more importantly
[what it would take] to get access to do things that it really wasn't
designed to do. I have spent years "pushing the envelope" of what Access can
do - so I know for example that we can always go to the Win32 API and do
sockets programming, work with unbound forms, etc. I also understand the
*economics* of "pushing the envelope" - it can be VERY expensive in terms of
time and money and can ultimately result in an unstable system. So in the
end it's really not about "can access do xyx" but "what are the economics
involved in getting Access to do xyz." I'm clear on much of that... this
recent round of questioning was because I have been out of the Access
neighbourhood since 1998/9 and wanted to know how far it's come since
then... didn't want to assume that I still know what's going on. So thanks
to everyone who addressed my specific questions with reasonable or
thoughtful responses.

-Jordan

 

[Larry Daugherty]

Jordan,

Apparently I struck a nerve, unintentionally but there it is. As I
just ran across your post to me in the thread I went back and re-read
mine. It comes across as harsh and judgemental. For that I
apologize.

However, you might cool off, re-read things and realize that most of
the damage you've suffered is self inflicted.

You neither disappoint nor elate me. You really aren't a big thing in
my world. I don't know you from Adam's off ox. And, regarding a
comment of yours, no, I don't follow your posts except in this thread.
There are many of the MVPs and other long time contributors of that
stature that I do often read but the only one I go out of the way to
read is John Vinson. Years ago it was Dev Ashish.

My observation was that Question #9 of the Anti-Access side was a show
stopper. Concede the point of that one question as submitted and the
consideration of Access as a platform is dead. As Brendan got at it
later in the thread things seemed to resolve alright.

Note that the Anti-Access side didn't refer to you or to any person.
You had two parts in your questionnaire which I perceived to be
Pro-Access side (the first part) and Anti-Access side (the 2nd part).
There was not the slightest hint that I labeled you as Anti-Access. I
surmise that your emotions were aroused as you read my post and that
you concatenated things in your mind that were not and are not
related.

You are wrong again as to the "us vs. them" comment. The gist of my
suggestion that you submit similar questionnaires into newsgroups for
other platforms was that we are all biased in favor of our own tools
and solutions. Much as we try to be open and unbiased it's truly
impossible. To see responses viz other platforms you might be better
able to gauge the level of bias in all of the responses. It was
intended as a helpful suggestion, just a thought to consider. You're
welcome.

You bet your boots that Access has some severe limitations and flaws.
Some of what I perceive to be flaws were deliberately designed into
the product. The Lookup field is a case in point. I have the itchy
feeling that the '07 product may have a few more doozies. I have all
of the versions up to date but Access 97 is still my favorite. I API
solutions instead of OCX.

as to your quote and comment reproduced below

<< Many of us are professional developers >>
Then act like it and stop assuming that people malevolent and

labeling them

You can stick it where the sun don't shine! By daring to instruct me
on my behavior you have crossed the line of reasonable discourse here.
Again, I haven't labeled you or anyone as anything. If you quietly
and calmly re-read my post you will see for yourself. Your emotions
got in the way of your reason.

Now, you've flamed me and I've flamed you. Lets leave it at that. We
don't need to be friends but we can be courteous. That's my intent.

I've just scanned down to the end of the thread to date. I commend
you on your effort to provide your client the best information for
getting at a good solution. Good luck with your project.

--
-Larry-
--

Sorry to disappoint, Larry, but #9 was not "slipped in" in some malicious
fashion like you purport.
I agree in retrospect that it was circular reasoning... but what I
attempting (and apparently failed) to capture succinctly was this:
"If everything we need *today* can be done in MS Access, that doesn't
necessarily mean we should do it in MS Access BECAUSE *tomorrow* we may need
to have something that is not easily done in MS Access. SO IF we know,
today, for sure that we'll soon need something that isn't easily
accomplished in MS Access - then we might want to NOT go with MS Access and
create a solution that we know will "soon" need to be replaced." That's what
#9 was really about, believe it or not.

Finally, I find your labeling of me as "Anti-Access" completely unhelpful.
You sound as if you have an "us vs. them" attitude. If you have followed my
recent threads related to this topic you will see that I have a lot of
experience creating non trivial MS Access applications. I also have
extensive experience in other technologies. So I'm neither "pro access" nor
"anti access." What I am is

"Anti-the-wrong-solution-for-the-problem". So if