[AccessD] MDB on the web

Continued with >>>in-line reply

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence
Sent: Thursday, February 14, 2008 5:24 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] MDB on the web

Hi Drew:
<snip>

Is there any reason why only MDBs have been used, other than "If it
ain't
broke don't fix it"?
>>>#7. Interface:  While I have a lot of web interfaces, there are times
where I might need to whip up a report, query, or even a form (I use
code behind forms quite frequently to do data manipulations....not that
I do data manipulation frequently, but if I have to manipulation, I may
use a query, but most of the time I need some capabilities that only VBA
has).  Since I use .mdb's, to create a one time or infrequent report,
all I have to do is open the .mdb off of the intranet/internet server
and make the report.  No other steps required.

Would you have any other suggestions or recommendations? 

>>>Yes, first of all, I have listed many of the reasons why I use .mdbs,
but NONE of them should be taken as a 'don't use a server side db'
argument.  As a member of our IT department, I don't have to deal with
the stigma of 'Access is a toy'.  Believe you me, with the number of
things I have done with Access based systems, no one at my company would
challenge me on the capabilities of Access.  There are absolute
circumstances where Access won't cut it though.  I have an upcoming
system which I'll detail for the heck of it in a minute, which is going
to REQUIRE a SQL Server.  It's just that until recently, I haven't had a
project that required more then Access could provide.

Many IT departments challenge the reliability of an Access .mdb.  Well,
go visit our website.  http://www.marlow.com .  The navigation bar you
see on EVERY page is built with a combination of two databases.  One's
an .mdb, the other is a .dat file created by FrontPage (it's where it
stores it's navigation data).  But every single time you go to any page
on our website, our IIS server is reading that dat file, and also
querying an .mdb to create that menu bar.  (it queries the product
database, to build the product links on the menu bar).  It's fast, and
our web server is running on a PIII 800 mhz machine, with 384 megs of
RAM, so it's not a screaming machine, but it runs fine.  Now that's
'reading' a database.  That same site records its IIS logs in an Access
.mdb.  Which means, for every hit on our site, the IIS server is dumping
several records into an .mdb PER HIT. (Because every image displayed on
a website is a single entry in the web log).  We've had that site online
going on 5 years....not a single .mdb on that server has ever corrupted.

As for the system I am building that will require a SQL Server.  It's a
Data Acquisition system.  We have lot's of test machines (computers
using engineering cards, or serial interfaces, to record test data on
the stuff we build).  All of these machines record data in various ways,
most of them into .mdbs that the system developers created.  These
databases are not designed very well, in 99% of the cases, the database
has one huge flat table that holds whatever data they are recording.  A
few years ago, I was asked to build a database to record data for a
specific machine.  I went one step more there.  I build an .mdb that is
designed to allow the 'system developer' to create his own 'tables' (I
think I called them programs) where he can see this 'program' what
fields he will need, including the type of field (date, integer, double,
text, etc), limits on the field (min max) and 'warning levels' (min
max), etc.  The system doesn't create a new table, it is just designed
that these 'programs' are stored within it's structure, and then the
data is stored in separate tables (based on the data type).  It's as
normalized as I could get it.  Up until this point, I have completed,
and it's running on that particular test machine (and has been for I
think 2 years).  It has a web interface....and that's part of the beauty
of this system.  Currently, our engineers hit these other test machines
and to get the data from their .mdb's, they are opening those .mdb's
across a network connection.  With the system I created, the 'web
interface' is run on the local test machine.  So data from that test
machine is actually queried BY the test machine. (VERY fast way to view
that data).  What I have to 'finish' now with this system, is that I am
going to create a SQL Server database that will be a central hub where
all data, from all test machines is dumped into it.  It will simply be
too much data to keep an in .mdb.  Then I will build a web interface
that will allow our engineers and anyone else that needs access to this
data, to view all of the data.  If they are reviewing data that is a day
old or older, they would be seeing the data from the SQL Server, if they
want to see the live data, they would actually be redirected to those
machine's IIS servers.  I know this has very little to do with what
you're doing, but I don't have many venues where I get to chat up about
systems I build (at least not with having the listener understand what
I'm talking about!).

Drew

The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited.