randall@informix.com (Randall Rhea) (12/07/90)
In article <1990Dec4.215711.2508@oracle.com> kbittner@oracle.UUCP (Kurt Bittner) writes: > >The version is *highly* relevant, since >SQL*Forms v3 is FAR superior to SQL*Forms v2. Enough flames on this one.... >Also, there is a need to contrast rapid application development from production >application development. In many cases, applications can be prototyped very >rapidly, up to the point where the application development environment hits the >wall (dictating switching from ABF to Ingres/4GL). SQL*Forms provides a >consistent environment for prototyping through production application develop- >ment. I don't know much about Ingres, so I can't compare it to anything else. However, I do know Oracle's SQL*Forms Version 3 quite well. I completely disagree with Kurt's opinions about it. SQL*Forms is a great prototyping tool. You can build screens and windows that look good rather quickly. However, when one attempts to move from a prototype to a real application, SQL*Forms completely falls apart. (unless the application is very simple) After a year of attempting to build an order entry application with SQL*Forms at my previous job, I gave up and came to work for Informix. I gave up even though I had help from Oracle Corporation consultants. Some of the things I noticed about SQL*Forms were ... : 1. Bugs. Beaucoup d'bugs. Mucho bugs. Later versions were better than earlier ones, but I still could not trust the stability of the product. Maybe the product has become more stable in the past few months; I don't know. 2. The product was fundamentally mis-designed from a developer's standpoint. It looked like something a grad student would create for a research project, not something a real developer would use. I believe this product started out as something called "INP" about 10 years ago, and gradually had feature after feature added on until it became the mess it is now. Oracle would have been better off re-designing a new product, instead of simply filling enhancement requests from users of SQL*Forms Version 2. 3. When an application became somewhat complex, it was very difficult to figure out which trigger to use in particular circumstances, how triggers related to each other, and when certain triggers were going to fire. In a regular programming language, you just look at the code, and you know what will happen next. Not so with SQL*Forms ... this makes development frustrating. 4. SQL*Menu Version 5 was a disaster. How we could have been sold a product that was so buggy is beyond me. The interface to SQL*Forms Version 3 was sparsely documented, and didn't really work anyway. The program often bombed out with a stack dump. Oracle Corporation denied that there was even a bug until we found another one of their clients with the same problem. 5. SQL*Forms required huge system resources, especially memory. We had huge VAX/VMS machines, but the applications slowed to a crawl when more than a handful of users were running SQL*Forms. Oracle's only answer to this problem was some mysterious "version 7", which wasn't even available in beta. We had a hard time with the idea of trying version 7 when version 6 still had problems. >Having choices is always more difficult. On the other hand, having a set of >tools, where each tool is well suited to the task at hand is IMHO better than >having a general purpose tool (ala swiss army knife) that does many things but >only a few well. The only Oracle tool that's suitable for anything is SQL*Plus, which is a very good version of SQL. Other than that, their tools were really unusable to us, especially the report writers. (SQL*ReportWriter was just as buggy as SQL*Forms) You will notice that many successful Oracle installations have most of their development done in C. There's a reason for this .... >In general, the net is a great forum for sharing experiences and ideas. Many >times however, opinions are stated as facts, without explaining how you >reached that conclusion. Hopefully, I've stated how I reached my conclusions. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Randall Rhea Informix Software, Inc. Senior Programmer/Analyst, MIS uunet!pyramid!infmx!randall
lugnut@sequent.UUCP (Don Bolton) (12/08/90)
In article <1990Dec7.023519.9020@informix.com> randall@informix.com (Randall Rhea) writes: >In article <1990Dec4.215711.2508@oracle.com> kbittner@oracle.UUCP (Kurt Bittner) writes: >> >>The version is *highly* relevant, since >>SQL*Forms v3 is FAR superior to SQL*Forms v2. Enough flames on this one.... >>Also, there is a need to contrast rapid application development from production >>application development. In many cases, applications can be prototyped very >>rapidly, up to the point where the application development environment hits the >I don't know much about Ingres, so I can't compare it to anything else. >However, I do know Oracle's SQL*Forms Version 3 quite well. I completely >disagree with Kurt's opinions about it. SQL*Forms is a great prototyping >tool. You can build screens and windows that look good rather >quickly. However, when one attempts to move from a prototype to a real >application, SQL*Forms completely falls apart. (unless the application >is very simple) After a year of attempting to build an order entry application >with SQL*Forms at my previous job, I gave up and came to work for Informix. >I gave up even though I had help from Oracle Corporation consultants. > >Some of the things I noticed about SQL*Forms were ... : > >1. Bugs. Beaucoup d'bugs. Mucho bugs. Later versions were better than >earlier ones, but I still could not trust the stability of the product. Maybe >the product has become more stable in the past few months; I don't know. > I'd have to agree on this one, in many cases workarounds are possible but that gets you back into trigger complexities that bite you later on. >2. The product was fundamentally mis-designed from a developer's standpoint. >It looked like something a grad student would create for a research project, >not something a real developer would use. I believe this product started >out as something called "INP" about 10 years ago, and gradually had >feature after feature added on until it became the mess it is now. >Oracle would have been better off re-designing a new product, instead of >simply filling enhancement requests from users of SQL*Forms Version 2. > Not ever having been a grad student, I can't vouch for the assesment as stated. BUT, It is something a non-programmer (with some G2) can pick up and build some relatively sophisticated screens with. The troubles begin with getting "mondo" complex, then its a b*tch to track things unless you build in special failure messages for prototype and testing, then rescript them when production is in the cards. (more work) editing the inp files directly helps some too *sometimes*. >3. When an application became somewhat complex, it was very difficult >to figure out which trigger to use in particular circumstances, how >triggers related to each other, and when certain triggers were going to >fire. In a regular programming language, you just look at the code, and >you know what will happen next. Not so with SQL*Forms ... this makes >development frustrating. > >4. SQL*Menu Version 5 was a disaster. How we could have been sold a product >that was so buggy is beyond me. The interface to SQL*Forms Version 3 >was sparsely documented, and didn't really work anyway. The program often >bombed out with a stack dump. Oracle Corporation denied that there was >even a bug until we found another one of their clients with the >same problem. > >5. SQL*Forms required huge system resources, especially memory. We had >huge VAX/VMS machines, but the applications slowed to a crawl when more >than a handful of users were running SQL*Forms. Oracle's only answer to Never really noticed this given our hardware here :-) >this problem was some mysterious "version 7", which wasn't even available >in beta. We had a hard time with the idea of trying version 7 when version >6 still had problems. > THe infamous vaporware cataloug. :-) >>Having choices is always more difficult. On the other hand, having a set of >>tools, where each tool is well suited to the task at hand is IMHO better than >>having a general purpose tool (ala swiss army knife) that does many things but >>only a few well. > >The only Oracle tool that's suitable for anything is SQL*Plus, which is >a very good version of SQL. Other than that, their tools were really AMEN, its super. Informix isql is a bit, shall we say neandrethal by comparisson. >unusable to us, especially the report writers. (SQL*ReportWriter was just >as buggy as SQL*Forms) You will notice that many successful Oracle >installations have most of their development done in C. There's a reason >for this .... > Report writer? you *used* that? I tried it, has merit for some simple things but ended up using rpt, now theres a reporting tool :-( BUT it works, goto goto goto goto goto goto goto. <KLUNK> sorry, flashbacks :-) Oracle has fancy screens, a SUPER sql command language, and no easy integration between their screens and report output. It takes a rocket science team to get a screen to drive reports and handle input to the RDBMS. Typicaly you'll end up having 2 screens (one for each) This is my pet peeve about Oracle, I can live with the other things but report output is what the damn databases are all about and Oracle does not make this a trivial task. Informix 4gl really gets my vote on this functionality. (but the screens are ahem, crude) I'd prototype in Informix any day because of this ability. It halves your build time to be able to use the same screens for any function its also easier for the users, Oracle's keys-from hell approach is nice for a thermodynamic engineer, but sally-secretary???? >>In general, the net is a great forum for sharing experiences and ideas. Many >>times however, opinions are stated as facts, without explaining how you >>reached that conclusion. > >Hopefully, I've stated how I reached my conclusions. I've reached mine by working with both systems. And in watching project developement times. BOTH products have their strengths and weakness. But I'd have to say, Oracle has overcomplicated the process through over- simplification (or in an attempt to) but it sure looks pretty.