Re: Is Forms 4.0 stable?

> > Forms 4.0 is something much less than a backbone for solid
> > client-server computing.
>
> You include no reasons to support this claim, so I can only
> presume that you have used another product and have achieved
> better client/server performance and/or integration with the
> Oracle7 database. Or perhaps better default data interaction
> capability for which you didn't have to write code. STUFF DELETED....
> We offer all of the necessary
> elements for a well-performing client/server application and
> more. In other words, not only a backbone, but a full skeleton.

Steven,
I appreciate the fact that Oracle has decided that the internet is a useful forum for information exchange. Personally, I prefer it to sitting on the support lines anyway. Since , I assume from your post that you are truly interested in other opinions, I'll explain a little of what frustrates me with Oracle tools. While many tools will perform well with a 486-33 with 16 meg of ram(this has been discussed by others at length), the main gripe I have is programmer productivity. I will grant you that Reports 2.0 and Forms 4.0 are more productive than Reports 1.1 and Forms 3.0; however, compared to other development environments they still have a ways to go.

Productivity with a tool involves:
1. Consistency of development across (CDE) tools and 2. Ability to create a complete, easily maintained system within a given amount of time after learning the tools.

1. Each CDE tool requires a different approach to devlopment; therefore a greater learning curve for developing a complete system. Though tight integration is heralded as a plus for these products they are really not "tightly" integrated. Forms call reports through a host command, the PL/SQL version in the database is different from the one in the tools, and migration from old versions of the tools works, although many of are more complicated forms and reports did not work at all. On top of these integration issues, each product uses different naming conventions, layout editors, and procedures for using PL/SQL.
2. For example, to develop a report which involves processing data based on parameters accepted from the user takes forms and reports integration along with views and temporary tables in the database. ( CDE does not support local tables ). It also does not support returning rows from stored procedures, thus requiring many of these views and temporary tables to be used. Maintenance is also an issue as it is very difficult to go back an change a report once it has been developed because one must completely recreate the layout each time (or else play with the little grouping boxes for a very long time).

> > In case you haven't read the January 31, 1994 issue of PC
> > Week, the front cover states "Forms 4.0 plight hampers
> > Oracle's Client/Server plan." I agree whole heartedly with
> > the article and its discussion of the system requirements,
> > connectivity issues, and general cumbersome approach to
> > system design.
>
> STUFF DELETED...

Not to mention the fact that I have a run time fee for each Oracle product on each PC in the building accessing my programs; not a small sum of money when you consider that you may need Reports 2.0, Forms 4.0, Book, and Graphics for a complete solution.

> We've addressed all of the stability issues referred to in
> that article for the Forms 4.0.12 release which is already in
> shipping for Windows and Mac (Sun soon, too). We're working on
> nailing down the additional connectivity issues for 4.0.13.
> I hope you are still using the product by that time so that
> you'll be able to benefit from what we're doing.

I am also concerned about the versionitis of Oracle's CDE tools. It seems that you believe that it is as easy to update 1500 PC's with new versions of EACH of the CDE tools as it is to change the database version number on a single server.  IT'S NOT.

          STUFF DELETED...


>        How about explaining what you do and don't

>        like so that we have a fair chance at responding to specific

>        issues. It's hard to start a technical discussion with a

>        statement like "Y truly sucks".

On this statement I admit to succumbing to an emotional fever that overcame my usually technical demeanor. I appreciate Per Brondrum's note challenging this notion, and I replied to explain the difficulties in using the Oracle products vis a vis other products. An example I gave to Per is the simple problem of having a 0 show up on a cross tabular report when the x and y does not return a row. This never worked well in Reports 1.1, and still does not work well on Reports 2.0. The workaround for 1.1 does not work on 2.0, and the workaround for 2.0 will not print on an HP laserjet printer. Why should I need a workaround for this kind of standard report? For those of you who don't know Oracle suggests that one place a 0 on the report two grouping levels down with the element printing over the 0 having a non-transparent attribute. While this will print correctly to the screen, printing to an HP printer does not show the 0's.

• Rich Cannon -- AT&T GIS CSM&D Columbia *
• DUKE Alum -- Now an Oracle Hostage *

  ---