[AccessD] Paean to the Access Development Team

As both a fan of Access and of VB, I would like to put in my two cents as to
why someone would develop in VB, .Net, ASP or Access.

To begin with, Access has the absolute advantage of being both a database
and an interface.  The other three can store data, and retrieve it, but it
requires a custom system to do so.  Obviously, unless you require a server
side DB, an Access DB is perfect for data storage in the other three
interfaces.

Access Front End:  It's not called Rapid Development for nothing.  Once you
have the data structure built (which should be the most important part of
any project), Access provides for very rapid development of forms and
reports to enter, modify and display data.  With VBA entrenched within
Access, it can do all sorts of dog and pony tricks, just like any other
programming language, with a few exceptions.  Drawbacks:  There are a few
things that are possible in VB that you can't do in VBA, or that don't work
as well in VBA (on the plus side, VBA has 'Eval' statement, which can come
in handy sometimes).  You must run it in an Access environment, so you must
either have a runtime installed or a version of office that has Access.

VB Front End: I'm going to skip .Net, since I still use VB 6.0.  I've played
with .Net, and it's nice, but not nice enough for me to move away from 6.0.
A VB front end has a few advantages over an Access Front end.  For example,
it is natively it's own application.  By that, I mean sometimes you want a
window that just sits on the desktop, not a window in a window.  Yes, you
can do this in Access, but it's automatically so in a VB environment.  MDI
windows.  Want to create a custom MDI window, and have application windows
within it?  VB is your app.  .exe's.  Yep, with a small 1.4 meg runtime,
which is probably installed on 98% of the windows based machines already, VB
will run like a charm.  When you need to have those 'special' capabilities.
Multi-threading, API Callbacks (which work in Access, but will throw a
wrench in development...because they crash Access if in use while debugging
code....in A2k and later (97 didn't have that problem)), Add-in controls
(since VB creates it's own installation, extra .dll's and .ocx's can be
installed with the application (yes, you can do this with Access developer
too, but I'm just stating that VB is natively 'installable'.)  Better
combo/list boxes.  In VB, you can add and remove items from a list
selectively, without having to build a callback routine.  Finally, in VB,
windows are windows in VB.  If you don't know what I mean, and you're
curious, enum the child windows of a VB form, and enum the child windows on
an Access form....why they built Access forms that way, who knows.  There
are other VB bonuses, but they aren't really directly involved in a Front
End tool.

ASP:  This, in my humble opinion, is the king of interfaces.  Fast,
lightweight, extremely easy to modify, even on a live system.  The only end
user requirement is a browser, which are free.  ASP is natively 'unbound',
and since the 'application' is running from a single server/machine, it
virtually has no limit to the number of users in the system (even with an
Access Backend).  Disadvantages?  With raw ASP, you're building from
scratch, no wizards to build a form for you, etc.  There are tools out there
to help, but out of the box, it is going to take longer.  However,
technically the box is free, since ASP is a scripting language, if you have
an IIS webserver, there is no application or compiler to buy.

(Of course, my preference is an Access backend, with a VB .dll 'framework'
used in an ASP front end... for most of my applications)

Drew

-----Original Message-----
From: artful at rogers.com [mailto:artful at rogers.com] 
Sent: Monday, January 29, 2007 2:42 PM
To: AccessD at databaseadvisors. com
Cc: dba-SQLServer
Subject: [AccessD] Paean to the Access Development Team

In the beginning were Relational Databases -- a valiant attempt by the late
and lamented Dr. Edgar (Ted) Codd. His set-based theories changed the
database world. I wish he had lived 20 more years, so he could address the
new issues. (He did try, late in life, to address the OODB issues, but
didn't survive long enough to complete his arguments.)

Yes, Dr. Codd rationalized the world of databases as viewed from set theory.
But the most important and radical of Dr. Codd's propositions was that
statement X ought to work in implementations Y and Z. 

Vendors and their marketing staff view the world differently. Thus they
foisted upon Dr. Codd's universal language the Language Extension. And the
Language Extensions proliferated, on grounds similar to brand-name crack or
heroin dealers in Manhattan. 

The new mantra: "Adhere to the standards, but toss in a few really addictive
commands that are way cool and extend the language in proprietary ways."

Dr. Codd's rules were thus undermined by the capitalist system, at every
possible step. "Offer tempting extensions that force or at least coerce
total buy-in." Make it difficult or impossible to port code-X from
implementation Y to implementation Z. To the extent that you buy in, you are
our captive market.

Any reasonable (i.e. non-marketing) person would agree that this approach
totally violates everything Dr. Codd's achievements stood for. As an IBM
Fellow, Dr. Codd was above and beyond the fray of market competition. He
thought only of the big picture. Smaller minds plundered his ideas and the
result is an array of variants upon commands that ought to have been
standard across all implementations.

The ISO SQL projects notwithstanding, virtually every vendor persists in
redefining or extending the language in proprietary ways.  I have a tiny
book published by O'Reilly and written by Jonathan Gennick, which is a
Prince Valiant attempt to sort all this out and provide a Rosetta Stone.
Thank you, Sir Jonathan! You have saved those cross-implementation readers
such as I hundreds or even thousands of hours of investigative time. To be
objective, there are one or two subjects you haven't covered, but you are
the Valiant of the SQL Wars!

I began in dBASE not SQL (and expect that many readers will immediately
slight me for my origins), but even back then the strategic path was the
same. Wayne Ratliff and Jeb Long invented a language based on JPL-DIS. It
was called Vulcan, but after one ad in Byte magazine they discovered that
Harris Computing owned the name. Enter Hal Pollock, a marketing genious. He
suggested the name dBASE II, on the grounds that no one would buy dBASE 1.0.
He also created the legendary "bilge pump" ad. dBASE II took over the CP/M
and then DOS world by storm. A couple of years later, a vastly superior
product called KnowledgeMan came along, but could not compete against
Pollock's brilliant marketing of dBASE II. 

Despite numerous interanl arguments, Ashton-Tate refused to release a
compiler, and committed seppukku. A couple of frustrated, not to mention
opportunity-sensitive, A-T employees, met in a restaurant called Nantucket,
and  to conceive and devise a compiler for dBASE. The result was Clipper,
from Nantucket Software.

I bought into Nantucket big-time (not in shares but in development hours). I
wrote two books about Clipper, and I like to pretend that I helped lead the
way for these folks into O-O programming, but in reality I borrowed lessons
learned from playing with SmallTalk and other O-O languages.

The point is, Brian and Rich and Barry realized that the way to capture the
market is to provide 98% compatibility with dBASE syntax, but also offer
totally addictive extensions, which delivered much more power but also
trapped the developer into Clipper. The Clipper code would not readily port
to FoxPro or dbCompiler and most certainly not into dBASE. So, to the extent
that one bought in to the extensions -- and I bought in, big time, because
they were so powerful -- one excluded porting the code to other variants of
dBASE.

Jump-cut to the SQL world. Oracle releases Java extensions. MS releases .NET
extensions. Sybase struggles to tread water (not a slight on their team --
they are underfunded and carry the albatross of PowerBuilder compatibility,
etc.) and Borland tries to find a way to fit. Later, Gupta and Clarion and a
dozen others. The market is a vicious place.

The world is not flat, and here is an interesting example. Although I know
nothing about MS internal development and even less about the development
hierarchy, what I can deduce from outside is that the MS-Access team is seen
as a wart, if not a threat, to the marketing of all the .NET stuff. This, in
my view, is most unfortunate. Admittedly, there are things that an Access
expert cannot implement, but that covers the 20% of the people who insist
upon a BMW or better. The "Chevrolet" set would be most pleased to learn
that an Access developer can deliver a functional application for
approximately 1/10 the cost of the equivalent app developed in .NET.

The C# and VB.NET developers don't like to acknowledge this, nor does
Microsoft. But facts are facts. If you need to deliver a shrink-wrapped
package that depends on nothing (a laughable concept in itself, but let's
let that pass), then C# or VB.NET are the languages of choice. But if you
need to deliver something quickly and easily changed in the light of revised
requirements, then I vote Access as the best available platform. There is no
problem in directly connecting it to the SQL Server database of choice.
Granted, an Access developer cannot deliver an executable. This distinction
matters, apparently, to those who would bill you 10 times as much for an
equivalent project.

I cannot understand why Microsoft continues (over the past decade at least)
to slight the achievements possible in Access. This particular newsgroup is
ALL about what can be done in Access. I can cite numerous developers here
who have bolstered my argument, but I will cite only a few and hope those
whose contributions I didn't cite will forgive me): 

Bartow, Brock, Connelly, Carbonell, Colby, Der, Enright, Fields, Foust,
Harkins, Kjos, Hindman, Lacey, Lawrence, Matte, Mattys, McLachlan, Reid,
Salakhetitov, Skolits, Smolin, Tapia, Tejpal, Williamson, Wutka.

I wish all the best to MS-Access development team, and I hope that one or
two or three of said team occasionally visits our group, to learn how much
we appreciate their efforts, and to know that we understand what challenges
they face. All the marketing $ focus on .NET (which is very cool - no slight
on that team intended) but the Access team delivers top-quality stuff in
spite of its underfunding. 

Hats off to the Access development team. Without you, many of us would be in
serious financial trouble. Thanks to you, we can make a living. You give us
the tools and we discover ingenious ways to use them.

My $.02. 
 
Arthur Fuller
Technical Writer, Data Modeler, SQL Sensei
Artful Databases Organization
www.artfulsoftware.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com