Up
ASP Information
Customers form
Static HTML
HTX and IDC
Access ASP
| | So you want to put your (Access)
database and images on the web?
Pseudomyth:
It's
easy to put a database on the web
Well, yes and no. If you know
Access and the nature of the beast, if you know
about HTML and the nature of that beast, if you know about Microsoft
web servers
and the nature of those beasts and you are realistic about service
capacities,
multi-user issues etc.., then it IS simple.
This is a strange question, but
take a minute and ask, what does your Access
knowledge contribute to putting it on the web?
Some people reckon:
"Oh, it's fairly easy to make tables, forms,
reports, queries. Simple ones take a few clicks and 30 seconds at most"
Well,
if that
is your understanding, then you are in for a bit
of skilling up.
The Web is in essence, web pages
consisting of HTML
and other bits. There are static webpages and there dynamically
generated webpages created on the fly by the webserver when you
interact with the website using your Web Browser. Once you
understand what HTML is, then there are several ways to publish to
HTML so that anyone with a web browser on another machine can access
your
information.
But.., you say, "I could use Microsoft
FrontPage or Macromedia
DreamWeaver
and just type stuff like I do in Microsoft Word". And if I
could just make an Access database, some Access Forms and Reports, then
isn't
that it? I have Access, I'm sure that
there are menus
that say - Publish to the Web or something like that"
Sorry
to disappoint you, it isn't.
In a nutshell, when you visit a
website with a client web browser, the web browser exchanges data with
the web server and the web server throws data at your web browser. Your
web browser then renders it and displays an integrated page.
This is nowhere like what
Microsoft Access works and nowhere
like what Microsoft Word works.
Static Web Pages
This
is the simplest but least
satisfying solution. You periodically make a .htm
file which you hand over to the Webmaster and he/she puts it on any web
server.
Server
Side Generated Dynamic Web Pages This
is inflexible, deprecated technology. Requires you to use
Microsoft's webserver IIS, See:
This
is a really good way and the Active Server Pages
technology can then be further programmed. ASP is also older,
deprecated technology. There is one BIG catch!
Access'97 will generate files that require the ActiveX
Layout Control. That means that your website visitors
need to use Microsoft Internet Explorer on a Microsoft Windows PC). Not
another web browser. Also requires you to use Microsoft's webserver,
IIS.
DAP are new, version 1.0 technology in Access 2000.
They rely heavily on the visitor having using Microsoft Internet
Explorer and
Office/Access on their machine. The DAP uses embedded ActiveX Controls which
need to authenticate to IIS and connect directly to .mdb file
or SQL Server. DAPs are deprecated in Access 2007.
- You
could use
MacroMedia ColdFusion
- You can use php
- You can use CGI (Common
Gateway Interface) or ISAPI on IIS.
You
can write your CGI programs in
perl, Visual Basic (VB6), Delphi, C or C++ etc..
- You can use packaged
solutions
- Ability
to work with
your database on any machine which has a web browser and is connected
to the web.
- No
need to buy more copies of Access for each client machine.
- No need to hassle through
installing Access or Access runtime on each client machine.
- Ability to use Access 97 data on
a Apple Mac, Unix/Linux, MS-DOS or Windows 3.1 client.
- An nice alternative to using
Access native security. Also, the user has no way of deleting your .mdb
file or taking it off site.
Now,
you're asking the right
question. Some of the answers are:
- If
you use an Access
database, you can do a composite Web and LAN application. Admin tasks
are in the familiar Access environment (forms, etc...) which take those
30 secs (another pseudomyth, but let's believe this one for the time
being) to whip up, while "the rest of the mob" stuff is via the web.
This is a major time saver.
- The database is portable. You can take a copy of
the database offline on another PC and play with the data.
- You don't need too much
dependence of other people like webmasters, Unix/Linux geeks, Oracle
dbAs to help you with a web server, a database on a machine that you
will never be allowed to go near.
- Microsoft Visual Tools like Access '97 or Visual
Interdev can start you off by producing the initial SQL and screens for
the web. (Unless your end users are using Internet Explorer, these
Microsoft tools will not complete the job because they all too often
rely on ActiveX components that Netscape, Macs, Unix end users cannot
work with)
- You
can practise, practise, practise on your little old personal Win'95 PC,
once you configure it for Personal Web Server, TCP/IP communications
before putting this stuff on the Big Web Server.
- If you are an advanced user,
through your work, you would have understood parameters, queries and
some SQL, nulls vs zeroes vs empty strings.
There
are some constraints:
- It
is NOT a 7 day x
24 hour database. From time to time, you need to block off access,
compact it and then open shop again. For light duty use, where you can
allocate at least one hour to do some tasks, this works out fine.
- It is not a 700 hits per minute
database. I've worked Access with 80 web users/sec or 40 concurrent
users on it. After you have delivered the web page, your machine is
idle. If you are going to have 700 people hitting the database at any
one time, give up - go to a big gun on another machine - web server on
one machine, SQL Server or Oracle on another machine.
- It is not a 1Gb database. Once
the database becomes big, of course performance slows down and queries
take longer to complete.
- Watch out for ASP queries that do not make sense,
retrieve nonsense x infinity etc... For example, I declared a forward
only recordset and attempted to move first. The whole server went to
100% utilisation and refused to talk to anything.
- While you worked with Access SQL
in Access, when you connect Access to the Microsoft Web Server, you are
using an ODBC connection and therefore you are using ANSI SQL. Nothing
to be alarmed about, but, for example, you need to know that the
wildcard characters in the query are different.
- Your Access forms, reports are
generally not available as they are on the Web. You can save these as
HTML+ActiveX objects for use on the Web but the standard forms and
reports are NOT what the web client sees.
I
almost forgot about writing this
but this is a very significant section.
- You
data is now
exposed to the other members of the web. Yes, you can implement
password security, even go through things like HTTPS (web services with
Secure Sockets authentication) but your data is now, NOT
IN A LOCKED ROOM.
- You could have a user which is not the intended
user. For example, you train someone, he/she goes back to the othe end
of the earth, he/she doesn't think it's a job worth doing, and he/she
gets his/her assistant to key in.
- If your programming / data quality is not good,
every man and his dog can see it. It is NOT AN INTERNAL
USE DATABASE ANYMORE. People that you may not
explicitly have in mind may start relying on it for their political or
operational life and when goes through an unscheduled downtime (read:
belly up), they will scream blue murder at your boss.
- Training or support for the
guy/gal in Timbuktu is not that easy as walking down the corridor.
Other
Websites and Information
Re-edited September 2007 |
