Re: Is Forms 4.0 stable?

From: David E. Scheim <des_at_helix.nih.gov>
Date: Mon, 28 Feb 1994 13:41:02 GMT
Message-ID: <des.29.2D71F46E_at_helix.nih.gov>


In article <94040.100631SCUNNANE_at_ESTEC.BITNET> SCUNNANE_at_ESTEC.BITNET writes:
>From: SCUNNANE_at_ESTEC.BITNET
>Subject: Re: Is Forms 4.0 stable?
>Date: 28 Feb 94 05:07:06 GMT
 

>Does anyone have a soft copy of the article on Forms 4.0 in PC Week (31/1/94)
>that they could post to this group ?
 

>Also, has someone put together a full? list of all currently known Forms 4.0
>bugs that is accessible via ftp ?

I'm not sure whether it's proper under copyright guidelines to post the whole article, but I am providing below excerpts of note I wrote summarizing some points of this article as well as the opening few paragraphs of the article. (As you may gather, I'm not a particular fan of Oracle, going back to an abortive trial of it about five years back, a contrasting successful experience with another database platform, and my monitoring of others experiences with these products). -- David Scheim

    In a front page story of its January 31 issue, PC Week reported that Oracle Forms 4.0, Oracle's pivotal client tool, was buggy, slow, cumbersome, and fundamentally limited in its design. This has prevented Price-Waterhouse from attempting to deploy any mission-critical applications using Oracle Forms 4.0, even though the product is now in its 12th set of versions (4.0.12.1.10). This tool is "the crux of Oracle's Cooperative Develoment Environment product family, which encompasses all of the company's development, query, and CASE tools," PC Week noted.

     That Oracle's key client tool still doesn't work in its 12th set of versions is a troubling reprise of that company's past fiascos with buggy products issued with continually proliferating version fixes not always interoperable with each other, requiring continual upgrades for proper technical support. If such a tool were to become the client foundation for any large distributed system, this would entail expensive and cumbersome installations and reinstallations at every client, a version control nightmare.

     Indeed, any client tool, even a reliable and stable one, with underlying software required to be installed at each client site would pose a major maintenance burden for each ICD. The net expense of such client software maintenance could far exceed that of the central database engine. Leading client tools such as PowerBuilder and JAM, in contrast, are distributed as small royalty-free executables. Such application distribution withoutan underlying software requirement presents a major advantage for a large distributed environment.

     In any case, if a company with a history of buggy products offers a client tool that is not usable for mission critical applications in its 12th version, is fundamentally flawed, and would entail an enormous maintenance burden for the clients, it is questionable whether that tool is usable in a production client-server system.

FORMS 4.0 PLIGHT HAMPERS ORACLE'S CLIENT/SERVER PLAN (PC Week, 1/31/94, pp 1,10.)

     Oracle Corp.'s push to provide its customers with a comprehensive set of client/server development tools is at risk because of problems with Oracle Forms 4.0, a Windows applicationdevelopment  package that began shipping last summer.

     Oracle Forms is the crux of Oracle's Cooperative Development Environment product family, which encompasses all of the company's development, query, and CASE tools.

     Forms 4.0 users are complaining that the software is slow, cumbersome, and limited in both windows functionality and database connectivity. . .

/*********************************************************************/
/*                      --- David E. Scheim ---                      */
/* BITNET: none                                                      */
/* INTERNET: des_at_helix.nih.gov           PHONE: 301 496-2194         */
/* CompuServe: 73750,3305                  FAX: 301 402-1065         */
/*                                                                   */
/* DISCLAIMER: These comments are offered to share knowledge based   */
/*   upon my personal views.  They do not represent the positions    */
/*   of my employer.                                                 */
/*********************************************************************/
Received on Mon Feb 28 1994 - 14:41:02 CET

Original text of this message