Jack Killpatrick wrote:
>
> John Stewart wrote:
<<SNIP>>
> >
> > 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?
Yes, a Pentium 100 with 2 gb disk as a server is marginal.
>
> >, 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?
>
No argument. Only one had previous experience as a programmer and that
was with FoxPro and that was learned by reading the manual and using
it. Training didn't come until they had floundered around getting
nowhere. Yes, the learning curve was steep!
<<SNIP>>
>
> 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.
>
Some of the requirements were documents and images (digital pictures)
stored in the database in addition to text data elements.
> > 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).
>
The capabiity to modify the data content is necessary. The ability to
modify the data structure was the issue that certain individuals felt
they needed to maintain. That ability does not play well in a
multi-user database. It is not an easy task to convince someone that
they really do need to pay attention to the design phase. Random
changes to the structure do cause loss of data. No, everyone was not on
the same page. At times, I questioned whether they were in the same
book!
<<SNIP>>
>
> 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).
>
It is understood that the SQL route will be more complex. No solution
is without drawbacks. We need to interface with other databases (Oracle
and Sybase) that are outside our control. The SQL model provides a
cleaner interface that Access.
> > 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 software is a tool to accomplish a task. Matching the correct tool
(or tools) to the task is part of the solution. A complete
understanding of the use of the tools, their strengths and limitations
is another part. The tools and use of tools are useless if you don't
have a task that is within their capabilities. In this case, the
correct tools and the ability to apply the tools were not available for
the project. It didn't help matters that the project was ill-defined.
>
> > 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.
>
The VB seemed to add a layer of complexitiy at the web interface.
Hence, the JavaScript, Perl, C, WebObjects, and Cold Fusion appear to be
useful as the tools to move the data from the database to a visual
display on-screen. Again, the challenge is getting the correct tools
for the task.
>
> 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.
> ---------------------------------------------------------------------
--
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.
---------------------------------------------------------------------
