John Stewart wrote:
> 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? Do you mean lack of $$'s to buy hw and sw?
>, inadequate
> documentation
MS products are very scant in the "printed material that comes with the
product" department, that's for sure. I think it is somewhat criminal. The
help files are usually rather good, though, and many programs that are going
to be used by developers come with substantial documented "demo" programs
that can be picked apart so you can see how they work.
> and training on the web interface (Interdev, MS IIS,
> Visual Basic and Access),
These are definitely products with a learning curve. You can get started
with them quickly, but to truly "know" them takes some time. To use them for
a project you must either budget for training (and receive good training),
budget for "learn time", or select a person who already has some
understanding of the products, or experience that would help them in
learning the new products. In other words, don't just pick someone who can
write letters in Word and expect them to do well with it, unless they have
the time, smarts and drive. Perhaps the people selected for your project
were poorly selected?
> an end-user that changed database spec
> requirements on a regular basis.
It is difficult to put any substantial product together in an environment
like that, unless of course YOU are the one creating the environment and you
have the time to make the changes to the underlaying database on the fly. It
is certainly wise to know what you are building before you start building
it.
> As I said previously, in theory, it is
> possible.
In fact it is possible.
> The software is not at the maturity stage to accomplish it
> quickly and easily without extensive training.
Well, really, what can you expect?
> The year spent was a
> good learning experience and they have grown to appreciate the value of
> a relational database model.
That's good.
> 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.
Sounds like they were seduced by marketing and didn't do their homework.
They also selected the wrong team for the project. The software should not
take the blame.
> No one had the depth of experience to pull it off
> and when they really got into the requirements, the costs outweighed
> the benefits.
>
> On the database side, Access was self limiting. It works great as a
> single user flat file record management database.
That might be correct, though I've never used it that way. I have been
developing Access databases on and off since version 1.0 (1993?). It is a
relational database system through and through, without a doubt,
definitively. That is what it, and all of it's interface tools, are built to
do.
In our experience, it
> could not handle the "relational" and multi-user tasks required.
I would be interested in knowing what those tasks were. ? As far as
multi-user tasks are concerned, regarding the web, Access is not a good
engine for handling zillions of concurrent queries. That is true. However,
if your solution was an Access db to be used in a local network, you should
have been able to have many users on the system at the same time.
> Users
> could not accept that they could not change the field size or add fields
> as they saw fit.
You will not get that capability with any rdbms that I know of, unless you
specifically allow the user the permission to make that kind of a change. In
general, it's best to only allow those kinds of changes to be made by an
administrator, since shortening a field can truncate records inadvertently.
It's best to plan ahead and foresee what length the data that will be
entered by the user will be, then make the field that length or longer
(we're talking text fields, here).
> Attempts to accomodate individual perceptions of
> solutions to the problem just compounded the programming issues.
The perceptions should have been consolidated in a blueprint of the
database, ahead of time. Once you have an agreed upon framework it is much
easier to expand on, since everyone is on the same page.
> We are looking at salvaging most of the work by replacing
> the Access db
> with either an M$ SQL server on the NT side
SQL server will be more complex to use than Access, be aware. It will handle
concurrent users much better, but the docs might be just as crappy (ie, no
book in the package).
> 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.
Yes. But it seems that initially you blamed the software. I'm not really
trying to stick up for MS and Access, but the facts seemed wrong.
> The tools available from M$ are not comprehensive
> enough to accomplish complex projects without significant programming
> background.
Depends on how you define complex projects. You can get quite far with
Access by just using the interface tools built into it, for projects where
the interface runs on your LAN. For designing a web interface you would not
use Access at all. Access would just be used to setup the tables and maybe
design queries. You would need to use html forms and a scripting language of
some kind to manipulate the data in the database via a browser interface.
Some Access developing, for LAN stuff, may require some custom coding in
Visual Basic for Applications, which would require finding someone who knew
how to do it, or spending time for learning. AS I said, though, you can get
quite far without using VB for Apps...and for web stuff you wouldn't even
need to touch VB for Apps, though you would need to know some kind of
scripting language that would run on your NT server and allow you to, um,
access the Access tables. Same thing with SQL server.
There are generic "data handling forms" that come with ASP and other web to
database solutions, but they are mostly very basic templates that will still
require that the user understands what knowledge is needed to customize the
solution.
> 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.
Yes, but we knew that, eh ;-)
> 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.
Yes. But beware that Cold Fusion will not build the interface per se. It
will not build what people see (form elements). It will act as the
middleware that communicates data back and forth between your forms and your
database. Re: WebObjects, I do not know what kind of a development
environment they have, but I've heard good things about the product. Any
one?
Thanks,
Jack
____________________________________________________________________
--------------------------------------------------------------------
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.
---------------------------------------------------------------------
