Jack Killpatrick wrote:
>
> John Stewart wrote:
> > Jack Killpatrick wrote:
> > >
> > > John Stewart wrote:
> > > > We have three individuals that have spent their full time
> > > > the past year
> > > > trying to integrate and Access database into a web-based solution with
> > > > no success.
> > >
> > > How'd they keep their jobs?
> >
> > Their job was to make it work or show that it wouldn't work.
> > Conceptually, it should work. In actuallity, the NT OS and associated
> > software are not mature enough to accomplish. They are now looking into
> > a similar solution based around MSSQL server.
>
> Do you know where their solution failed?
>
Their problems were numerous and ranged from inadequate hardware and
software to setup and maintain an NT server on-line, inadequate
documentation and training on the web interface (Interdev, MS IIS,
Visual Basic and Access), an end-user that changed database spec
requirements on a regular basis. As I said previously, in theory, it is
possible. The software is not at the maturity stage to accomplish it
quickly and easily without extensive training. The year spent was a
good learning experience and they have grown to appreciate the value of
a relational database model.
One of the prime issues facing M$ solutions is inadequate documentation
(or the need to buy "kit" enhancements that should be part of the
distribution package). In all fairness, only one of the three had
previous programming experience. The other two (and their management
group) attended a M$ traveling road show and thought they could do the
same thing in-house. No one had the depth of experience to pull it off
and when they really got into the requirements, the costs outweighted
the benefits.
On the database side, Access was self limiting. It works great as a
single user flat file record management database. In our experience, it
could not handle the "relational" and multi-user tasks required. Users
could not accept that they could not change the field size or add fields
as they saw fit. Attempts to accomodate individual perceptions of
solutions to the problem just compounded the programming issues.
We are looking at salvaging most of the work by replacing the Access db
with either an M$ SQL server on the NT side or with Oracle or Sybase
server on the Unix side. WebObjects appears to be a very good package
for accomplishing the web interface. Lack of expertise in C with either
the WebObjects or InterDev route.
In short, the project was doomed from lack of experience in C and
database design. The tools available from M$ are not comprehensive
enough to accomplish complex projects without significant programming
background. The overall cost for an M$ solution are tremendous in terms
of the software licenses and number of dedicated systems necessary to
support an NT-based network. Management interference,
"Not-Invented-Here", and reliance on M$ provided tools added to the
problems.
Hopefully, some of the netowrking issues will be corrected with the
pending release of NT 5.0. The database issues can be solved with
Oracle, Sybase or MS-SQL. WebObjects or CodlFusion will address the
interface issues along with additional training in C, JavaScript, and
database design.
John Stewart
SUPSHIP San Diego
Information Systems Security Mgr
--------------------------------
____________________________________________________________________
--------------------------------------------------------------------
Join The Web Consultants Association : Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------
