Re: Developer/2000 strengths, was Re: Power Objects - Is there a mar

Dennis Moore <dbmoore_at_netcom.com> writes:  

>Developer/2000 keeps getting smaller and faster. For tiny applications like
>'hello, world', because of the built-in functionality in Developer/2000,
>most tools will use less memory than Developer/2000. However, as the
>application grows beyond a simple single table to a complex system, the
>value to your program size of Developer/2000's built-in functionality
>becomes apparent and other products start using a lot more memory and
>running a lot slower. And the productivity, portability, multilingual
>support, and much more that are present in Developer/2000 just don't
>exist at all in tools like Visual Basic.
   

I have been using Developer/2000 for 12 months now (originally as CDE 2, and for about a month as Oracle Forms version 4.0).  

My colleagues and I have implemented one application system, and three subsystems of another application. In the process, we have become increasingly frustrated with the difficulty of producing quality applications using the Developer/2000 tools.  

Our complaints fall into two groups:  

• Complaints about the frequency of General Protection Faults and other failures when developing applications with the toolset
• Complaints about the cumbersome and awkward nature of the toolset even when it works, as well as the inconsistency of user interface behavior between different tools (and even within individual tools)

General Protection (and other) Faults:  

  We heard from some earlier Usenet postings that the former name, CDE,   referred not to "Cooperative Development Environment", but instead   to "Core Dumps Everywhere". Although Forms 4.5.6 reduces the frequency   of GPF's quite a bit over Forms 4.5.5, they still occur much too   often.  

  We find ourselves wasting precious development time doing excessive   File|Save operations followed by file system copy operations to   create fallback versions of our work, simply as insurance against   those unanticipated GPF's during a design session.  

  Every so often, a GPF does permanent damage to an .FMB file we are   working on. We must create a new empty .FMB and salvage what we can   from the damaged .FMB by copying via the Object Navigator. The exact   sequence of copying is critical, and things like Master/Detail   Relationships cannot be copied, but must be recreated in the new .FMB.  

  We find ourselves restarting Forms Designer or Reports Designer quite   often due to GPF's, or due to interrupted PL/SQL operations in Reports   Designer's test mode (which don't fully rollback the execution state).   This constant restarting only serves to constantly remind us of the   inconsistent Connect behavior of the two tools.  

  When we double-click an .RDF file to open Reports Designer, it always   complains it cannot compile PL/SQL triggers that refer to the   database, but never gives us a chance to try connecting first. We   must then do a File|Connect manually, then File|Compile, lest the test   mode complain that not all PL/SQL modules have been compiled!  

  The designer tools cannot always be relied on to maintain internal   consistency of their module files. For example, in order to modify   a Data Model Editor SQL query in a specific matrix report, I had to   first delete the Links across queries, modify the SQL query's WHERE   clause, then recreate the links. If I didn't follow this tedious   sequence, the tool corrupted the .RDF file, yielding complaints about   a null pointer being used as a handle.  

  The list goes on.    

Awkwardness  

  At times, we find we must have the following tools running   simultaneously:  

    Forms Designer
    Forms Runtime
    Reports Designer
    Reports Server
    SQL*Plus  

  The total Allocated Memory, as reported by Windows 95's System   Monitor, goes over 40 megabytes for this scenario!  

  Even this might be acceptable if the tools had better "locality of   reference" in their memory accesses. Instead, the tools page fault   CONSTANTLY, apparently touching only little pieces of many separate   memory pages as they execute internal loops.  

  Based on the page faulting behavior, and the inconsistent user   interface behavior, we conclude that the tools were written by   separate teams of programmers with little integration and code sharing   between teams. This contributes to the excessive size of these tools.  

  The tools are also quite sluggish in displaying certain editor windows   or property dialogs. We are running 70 MHz and 90 Mhz Pentiums, so   our CPU's are not to blame here.  

  When trying to perform quality assurance on our own code, we are   frustrated by the lack of a decent way to simply list the PL/SQL   source code from a Form or Report.  

  The global PL/SQL search and replace function ridiculously requires us   to acknowledge a message box with the Enter key for EACH routine in a   Form module ("No text found, continue search?"). This does not   promote frequent searching or replacing!    

If this toolset cost a few hundred dollars, one MIGHT be willing to overlook these problems. But this product set costs FOUR THOUSAND DOLLARS! (We had a laugh a few months ago when a trade magazine report published the price as $39.95. We figure he talked on the phone with someone that read $3,995 verbally as "thirty-nine ninety-five"; the reporter, more in tune with PC software realities, never considered to interpret this in the thousands of dollars, so made the next rational choice in interpretation. Shades of Turbo Pascal ...)    

Some of us also work with Visual Basic and Microsoft Access. These products sell in the $100 to $400 range, depending on prior ownership of earlier versions or competitive products.  

These Microsoft Products have very responsive and productive design environments. As I stated in an earlier posting, Microsoft Access lets me design forms and reports, query my database, and do test runs in a single tool with a memory footprint smaller than just Oracle Forms. Page faulting is minimal with Access and Visual Basic.    

Which brings us to Power Objects. Today's credo is "lean and mean". Of the Oracle desktop products, only Power Objects seems to follow this credo.  

To me, a tool does not become an "Enterprise Tool" by being expensive, so the Purchasing department thinks we are spending "Quality Money". No, a tool becomes valuable to the enterprise by being both flexible and efficent enough to become ubiquitous throughout the company. Microsoft Access meets these criteria, especially when supplemented by Visual Basic applications.  

When its initial bugs are fixed, Power Objects can also meet these criteria.    

Having converted Oracle Forms into a Graphical User Interface environment is commendable, since it shows ongoing support for previous customers. These developers can move their existing Forms applications into the modern GUI world with little redesign.  

However, for "green field" applications, the Developer/2000 toolset carries too much excess baggage from its character cell past. It is a battleship convoy in an age of missile destroyers and Harrier jump jets.  

The best long-term direction for Oracle's desktop strategy would be to stabilize Developer/2000 to support long-term Forms customers, and to make Power Objects the strategic enterprise application toolset.  

• Rick

--
 
(Rick Rutt is a system architect living and working in Midland, Michigan.)