glen@proexam.UUCP (Glen Brydon) (07/13/89)
I have been trying to build applications in Ingres 4GL for several years now. Recently we have been trying to find someone who can help in this process, but have found relatively few individuals who have any significant experience in using this system (perhaps Ingres, but not the 4GL). I have long since become frustrated with the system for the following reason - there is no forms based method of building the framework for an application without requiring me to generate tons of OSL (4GL) code which ends up being traditional 3GL code. RTI does provide a tool that is forms based and intellegent called: Query by Forms (QBF), but while providing a fairly nice minimal application it does not allow me to extend that tool to do the things I might want. QBF is designed to browse and modify tables and simple joins, but I want to hook into the mechanism with my own constraints or code fragments. No such facility exists. Alternatively I would settle for a library of well structured tools which I can use to get the same functionality as QBF, but which I can insert into my own application - no dice. Without this nonexistent library my applications tend quickly toward being too big (for 4GL) and very difficult to maintain as I need to change even simple features of the form. One candidate recently told me that he would be quite happy to help me develop applications for my firm if I would only dump INGRES in favor of Oracle. While we have currently invested a fair amount of time, effort and $$$ into our current direction, I do not feel wedded to INGRES. I am now registered to attend a sales presentation seminar for Oracle directed toward Government installations using UNIX. This man who wants me to dump INGRES has spent some amount of time evaluating and developing in Ingres, Oracle as well and Informix. He says that Informix is simply a joke, and that while Ingres is a pretty good database, it falls far short of Oracle in this area of allowing the developer to quickly build applications in such a way that the complexity is controlled and maintenance does not become a nightmare. His final comment was that Sybase, while being often selected for its top-notch transaction performance is not quite as good as Oracle. Sybase and Oracle consider each other to be competetors and neither consider Ingres to be one. As I browse through the advertisments for application development products and databases with such support it looks as though everyone has it on the competition. A recent UNIX review magazine issue listed the following products: Informix - 3 times faster than any other 4GL? Oracle - largest database company (so what?) speed WITH power Ingres - CASE tools (not just yet!) Empress - compares itself to Oracle, Informix, Ingres and Sybase Interbase - BLOBS and capturing "business rules"? PROGRESS - compared to Oracle and informix by DATAPRO satisfaction rating Unify ACCELL - application generator works with any RDBMS! JYACC JAM - same as ACCELL? So we have the integrated database systems with application development systems and the application generators which work on any database. Without the opportunity to use more than one system and approach it would seem very difficult to know for sure who has the best approach. Now for the point to all of this - would people with comments, advice and warning please share it with the rest of us? Anyone who feels that they understand the basic approach to so called application development tools could possibly describe to us what makes their approach unique, etc. Does your system do more than simply give you a forms/menu environment and database access? Thanks for your knowledge/advice/comments. Glen Brydon
jkrueger@daitc.daitc.mil (Jonathan Krueger) (07/13/89)
In article <378@proexam.UUCP>, glen@proexam (Glen Brydon) writes: >QBF is designed to browse and modify tables and simple joins, but I want to >hook into the mechanism with my own constraints or code fragments Could you state what you're trying to do? A real example, stated succinctly as the problem to be solved, would go a long way toward identifying the right tools for the job. -- Jon --
emuleomo@yes.rutgers.edu (Emuleomo) (07/14/89)
In reference to your article about Ingres and OSL
1)
Yes, I am also using Ingres to develop a significantly large application
but I quickly found out that OSL is good ONLY for menu creation and not much
more.
The approach I have taken is to write most of my stuff in ESQL/C using millions
of EXEC SQL's and EXEC FRS's.
2) I have significant experience with ORACLE and INFORMIX but I am new to
INGRES. My experience is that, in the UNIX environment,
**INFORMIX** beats both of them hands down.
Besides, Informix has the only complete 4GL in all the products mentioned
above.
3) Personally, I am VERY disappointed with INGRES.
a) It CANNOT do ROW level locking!!
b) It DOES NOT have a modify structure command.
c) It offers only token support for ESQL/C (in favor of EQUEL/C)
d) VIFRED (it's screen painter) is a ROYAL PAIN etc etc...
(Somebody at RTI should take a look at SPERFORM from informix!)
4) As far as ORACLE is concerned, there is nothing of significance that It
does that Informix cannot do better! Besides Informix Turbo is probably
the fastest thing around. Also only Informix offers FETCH PREVIOUS
(like skip -1 in dbase). Try that in Oracle.
5) Lastly, for quick prototyping, Informix offers the
"Informix Rapid Development system." which is portable from UNIX to DOS to XENIX
B/4 you make a decision take a GOOOD look at INFORMIX.
--Emuleomo O.O. (emuleomo@yes.rutgers.edu)
--
** Research is what I'm doing when I dont know what I'm doing! **kws@stl.stc.co.uk (Ken Sleeman) (07/14/89)
In article <378@proexam.UUCP> glen@proexam.UUCP (Glen Brydon) writes: >I have been trying to build applications in Ingres 4GL for several years now. >Recently we have been trying to find someone who can help in this process, but >have found relatively few individuals who have any significant experience in >using this system (perhaps Ingres, but not the 4GL). I have long since become >frustrated with the system for the following reason - there is no forms based >method of building the framework for an application without requiring me to >generate tons of OSL (4GL) code which ends up being traditional 3GL code. > >Glen Brydon Here in sunny old England we are on the verge of completing an Ingres Application, having used OSL. Yes we have "tons" of OSL code but it would be heavier in C. QBF is "quite nice" for what it does but is limited. To use QBF style frames with the functionality we require we have written our own "qbf" frames in OSL. This took a long time (4 person weeks) but we can now use this code in any application and bend it to suit the application. At the last UK Ingres User Group meeting in London I enquired about RTI providing a "library of tools" (actually I asked for the C code for the QBF frames) but RTI were worried about maintenance, etc. But in a group of almost 200 people only 7 felt that such a library was important. Without support the request was quickly forgotten. I suspect that the majority of people will feel the need when they rach the limitations of QBF frames. My impression (from talking to a small number of developers) is that they write their own QBF style frames. Why is your BIG application difficult to maintain? Why do you continually need to change your forms? Even if your forms undergo lots of changes it is a fairly straightforward matter to print form details via VIFRED, but yes, you will need to change your OSL code also - moral: get it right fairly soon!! Easier said then done, I grant you, if the real world keeps changing. We looked at Oracle, Ingres, Sybase, etc. before deciding on Ingres. We felt that there was very little difference between Ingres and Oracle, as far as application development is concerned, but I do not claim to be an expert (or even correct). Conclusion(?) - we have enjoyed developing our application using the Ingres ADE. Yes QBF (at least) has limitations which are very annoying, but perhaps we expected too much to start with. Now that we are familiar with some of yhe vaguaries of Ingres we know what to expect and how to deal with them. Regards Ken Sleeman ( kws@stl.stc.co.uk +44-279-29531 Ext 2278 )
robf@squid.rtech.com (Robert Fair) (07/14/89)
>1) >Yes, I am also using Ingres to develop a significantly large application >but I quickly found out that OSL is good ONLY for menu creation and not much >more. What do you find missing ? OSL/4GL has: - All of SQL - Practically all the FRS/screen handling constructs from ESQL - Very high level constructs for screen handling, master/detail queries etc - Easy interfaces to other INGRES systems, plus the O/S - Pure 4GL procedures and frames, plus 3GL interface - plus 3GL-style flow control [IF/THEN/ELSEIF/ENDIF WHILE/DO/ENDWHILE] if you want it. INGRES release 6 added more features, including: - More FRS constructs - Precompiled queries [REPEAT queries] - SELECT loops - Run database procedures from 4GL [6.2 onwards] - Library management [6.2 onwards] - Specify default Frame or Procedure to run [6.2 onwards] - others Also ABF itself got a nice facelift in 6.2, with lots of nice pop-up windows and state-of-the-art zippiness - its actually quite pretty now. >3) Personally, I am VERY disappointed with INGRES. > a) It CANNOT do ROW level locking!! In most cases row level locking is not a big win - see the recent press comparing INGRES & Oracle, what happens is that the locking overhead increases so much with row locking that it cancels out the benefits of higher concurrancy, it turns out most often page locking is the best compromise [for those who don't know INGRES uses page or table level locking, as appropriate] > b) It DOES NOT have a modify structure command. INGRES has very dynamic ability to change the structure of tables, using the MODIFY command. If you want to add/delete whole columns from the database schema [SQL's ALTER TABLE] it can be done with about 3 regular SQL statements. > c) It offers only token support for ESQL/C (in favor of EQUEL/C) This is just plain crazy, INGRES offers full support for Embedded SQL for multiple environments, including C, ADA, Pascal, Fortran, COBOL... The release 5 ESQL was powerful enough for some VERY complex applications to use it, while the native server SQL in release 6 added more features including: - Dynamic SQL, including DESCRIBE/PREPARE/EXECUTE/EXECUTE IMMEDIATE. - Database procedures, including execution control facilities. - Cursors native to the server, including special READONLY cursors for maximum performance. - SELECT loops Note that most of these features are SQL *only* - about the only feature you can access from QUEL is a variant of cursors, and of course the original RETRIEVE loop still exists. > d) VIFRED (it's screen painter) is a ROYAL PAIN etc etc... > (Somebody at RTI should take a look at SPERFORM from informix!) Please explain what "ROYAL PAIN etc etc..." means - vifred certainly has more power and flexibility than SPERFORM [and yes, I have used both] New features are constantly being added - for example in release 6 vifred gives you: - Popup forms and windows - Box & line drawing - Sideways scrolling fields - Templates for date/money/numeric values - Invisible fields - Dynamic type changing of fields - others >5) Lastly, for quick prototyping, Informix offers the >"Informix Rapid Development system." which is portable from UNIX to DOS to XENIX The only nice thing about the RDS is the 4GL interpreter, which INGRES has in 6.2 [although you can still compile to object code for performance if you want]. Also, last time I looked the RDS was an expensive add-on to Informix - the INGRES 4GL interpreter is a standard part of ABF. Robert Fair Technical Support Relational Technology, Inc Disclaimer: These opinions are mine alone, and do not represent my employer, RTI, in any way.
bg0l+@andrew.cmu.edu (Bruce E. Golightly) (07/18/89)
I have to comment on this. We do LOTS of development work using Ingres. The applications we develop fall largely into two categories; batch oriented systems are written using embedded SQL, and interactive systems are written using ABF. The amount of time devoted to the development process is not excessive, especially for the ABF based work. The only times we have experienced the kinds of things described is when we had problems getting the design frozen. Trying to write applications when the design is still a moving target gets REALLY frustrating. For those systems/applications where the design has stabalized, we have seen significant gains in productivity by using OSL and VIFRED. I will admit that there are occassions when it is necessary to drop into embedded C within an ABF application. As a rule, this is rare. I have only had to do this when I needed to perform some more complex operaitons than OSL would readily permit. Bruce
dmc@sei.cmu.edu (Dawn Cappelli) (07/19/89)
I've been using INGRES 4GL for a few years, currently at the SEI, and prior to that at Westinghouse. I've developed some fairly sophisticated applications, some of which consisted of over 100 frames. I'd hate to have to develop those same applications with a 3GL. It's true that you can write a lot of code using INGRES 4GL - you can end up with some pretty large 4GL programs. However, I have also used 4GL's with which you can't generate a lot of code. They're quite easy to learn & to use, but you also are highly constrained as to what you can do with them, which severely limits application functionality. Also, one should take advantage of the ability to call procedures in INGRES 4GL to minimize the amount of code generated. I think the background of the programmers has a lot to do with the success of using ABF in an organization. INGRES 4GL is NOT easy for people with no programming background. However, someone with a programming background is very likely to prefer INGRES 4GL over some of the other packages which are easier to use, yet not as flexible and high level as they may need. A 4GL, after all, should be a "higher level" language! I've successfully used INGRES for prototyping applications. I think that prototypes are greatly misused, however. People tend to develop rapid prototypes with little or no up-front design, in which case the prototype should be thrown away after it has served its purpose, and then the final system built. If an organization develops a rapid prototype with no up-front design, then tries to build the final system upon it, then it's the software process which should be blamed, not the tool. With sufficient up-front design, INGRES 4GL is a very good application development and maintenance tool. -- Dawn Cappelli dmc@sei.cmu.edu sei!dmc (412) 268-6170 This is only my opinion, and doesn't necessarily reflect the opinion of the SEI.
Bron@cup.portal.com (George Bron Faison) (07/21/89)
>seen significant gains in productivity by using OSL and VIFRED. >I will admit that there are occassions when it is necessary to drop into >embedded C within an ABF application. As a rule, this is rare. I have only >had to do this when I needed to perform some more complex operaitons than >OSL would readily permit. >Bruce Sounds like you've got the right approach to me! As for moving target development, Amen! ----------------------------------------------------------------------------- George "Bron" Faison Email: Bron@cup.portal.com USMAIL: Modern Office Systems Technology, Inc. "Be Still!" 6455 Penrith Drive Mechanicsville, VA 23111 Oracle & UNIX Phone: (804) 730-1467 (voice) -----------------------------------------------------------------------------
emuleomo@yes.rutgers.edu (Emuleomo) (07/21/89)
In article <3190@rtech.rtech.com> Robert Fair writes, >What do you find missing ? >OSL/4GL has: >- All of SQL >- Practically all the FRS/screen handling constructs from ESQL >- Very high level constructs for screen handling, master/detail queries etc >- Easy interfaces to other INGRES systems, plus the O/S >- Pure 4GL procedures and frames, plus 3GL interface >- plus 3GL-style flow control [IF/THEN/ELSEIF/ENDIF WHILE/DO/ENDWHILE] if >you want it. What I find missing is this.. 1) You cannot use an SQL CURSOR in an ESQL/C proc called from an ABF frame. Any attempt to do this results in an "Access violation in running image" error. This was an error that also plagued the entire CS541 graduate class in rutgers in the fall of '88. This problem disappears if you convert that proc into a STANDALONE program. IT IS THIS PROBLEM THAT FORCES YOU TO USE OSL FOR MENU CREATION ONLY. 2) When I do master/detail queries and there is no next row, Ingres prints "no next row" as the message. I have no choice of printing the message I want. 3) Also I cannot do a "previous" operation to see the previous row! This can be very irritating, especially if you are converting a popular application from lowly dBASE on a PC to multi-user Ingres on a UNIX box. 4) "Resume menu" does not work in OSL but works fine in ESQL/C. 5) Since OSL code is converted to EQUEL, why can't we embedd EQUEL statements in OSL? That would have been REALLY NEAT!. >INGRES release 6 added more features, including: >- More FRS constructs >- Precompiled queries [REPEAT queries] >- SELECT loops >- Run database procedures from 4GL [6.2 onwards] >- Library management [6.2 onwards] >- Specify default Frame or Procedure to run [6.2 onwards] >- others I saw a DEMO of Ingres 6.0. I must say it looks good. However, I have not yet used it. >In most cases row level locking is not a big win - see the recent >press comparing INGRES & Oracle, what happens is that the locking overhead >increases so much with row locking that it cancels out the benefits >of higher concurrancy, it turns out most often page locking is the >best compromise [for those who don't know INGRES uses page or table level >locking, as appropriate] I STRONGLY FEEL that row level locking is ESSENTIAL in a highly concurrent application. If a DBMS does'nt have it, how do you ensure that only ONE user is currently updating a given record in a table without locking the whole table?? or the whole page??. We want to lock that record and that record alone! Why can't there be stmts like, LOCK CURRENT OF <cursor> and UNLOCK CURRENT OF <cursor>?? >INGRES has very dynamic ability to change the structure of tables, using >the MODIFY command. If you want to add/delete whole columns from the >database schema [SQL's ALTER TABLE] it can be done with about 3 regular >SQL statements. Suppose you want to change a c10 fld to c20 or to c8 ?? What do you do? Almost all other DBMS's that I have used (dBASE!, XDB, Informix etc..) will allow you to do this using menus, AND THEN REBUILD the new table for you automatically. Actually, I was SHOCKED when I discovered it was not included in Ingres. It seems like a strange OMISSION since the code can be written in a few hours by RTI programmers! >Please explain what "ROYAL PAIN etc etc..." means - vifred certainly >has more power and flexibility than SPERFORM [and yes, I have used both] >New features are constantly being added - for example in release 6 >vifred gives you: Oh yes. In version 5, VIFRED is a ROYAL PAIN. It is VERY POWERFUL, but it is STILL a ROYAL PAIN!! I am used to using screen painters that can do the following. a) Copy/move text from one part of the screen to another. b) Do BLOCK operations like BLOCK delete, copy and move. VIFRED uses an OBJECT oriented philosophy where every thing created is treated like an object. That's OK. But why can't you perform vi-like operations on these objects, like those mentioned above.?? I do not like to retype lines DIFFER ONLY by a few characters!! Besides, I like SPERFORM because it allows me to create my screens using my favourite UNIX text editor, VI. - Popup forms and windows - Box & line drawing - Sideways scrolling fields - Templates for date/money/numeric values - Invisible fields - Dynamic type changing of fields - others >5) Lastly, for quick prototyping, Informix offers the >"Informix Rapid Development system." which is portable from UNIX to DOS to XENIX The only nice thing about the RDS is the 4GL interpreter, which INGRES has in 6.2 [although you can still compile to object code for performance if you want]. Also, last time I looked the RDS was an expensive add-on to Informix - the INGRES 4GL interpreter is a standard part of ABF. Robert Fair Technical Support Relational Technology, Inc Disclaimer: These opinions are mine alone, and do not represent my employer, RTI, in any way. -- ** Research is what I'm doing when I dont know what I'm doing! **
robf@squid.rtech.com (Robert Fair) (07/25/89)
>From rtech!mtxinu!ucbvax!tut.cis.ohio-state.edu!rutgers!aramis.rutgers.edu!paul.rutgers.edu!yes.rutgers.edu!emuleomo Mon Jul 24 10:52:03 PDT 1989 > >In article <3190@rtech.rtech.com> Robert Fair writes, > >>What do you find missing ? >>OSL/4GL has: >>- All of SQL >>- Practically all the FRS/screen handling constructs from ESQL >>- Very high level constructs for screen handling, master/detail queries etc >>- Easy interfaces to other INGRES systems, plus the O/S >>- Pure 4GL procedures and frames, plus 3GL interface >>- plus 3GL-style flow control [IF/THEN/ELSEIF/ENDIF WHILE/DO/ENDWHILE] if > >you want it. > >What I find missing is this.. >1) You cannot use an SQL CURSOR in an ESQL/C proc called from an ABF frame. > Any attempt to do this results in an "Access violation in running image" > error. This was an error that also plagued the entire CS541 graduate class > in rutgers in the fall of '88. We have many users who successfully use ESQL/C cursors called from an ABF frame. There was a problem with dynamic linking in some early ports of 5.0 which failed with the Go option. The easy workaround was to Image the application, and regardless the problem was fixed way back. What version of INGRES are you on ?? >2) When I do master/detail queries and there is no next row, Ingres prints > "no next row" as the message. I have no choice of printing the message > I want. The whole point of a 4GL is that it is supposed to provide default error handling in cases like this. Why is the message so horrible ? >3) Also I cannot do a "previous" operation to see the previous row! This can > be very irritating, especially if you are converting a popular application > from lowly dBASE on a PC to multi-user Ingres on a UNIX box. This is not a problem specific to OSL - see all the recent mail recently about using tablefields etc as workarounds. >4) "Resume menu" does not work in OSL but works fine in ESQL/C. RESUME MENU works fine in current INGRES 5 and 6. People often get confused about when you can use this (for example you can't in a MENUITEM statement, since you are already on the menu it doen't make sense to resume to it) >5) Since OSL code is converted to EQUEL, why can't we embedd EQUEL statements > in OSL? That would have been REALLY NEAT!. OSL is no longer converted to EQUEL, it either gets interpreted for "Go" or is directly compiled to "C" for "Image". >I saw a DEMO of Ingres 6.0. I must say it looks good. However, I have not yet >used it. >>In most cases row level locking is not a big win - see the recent >>press comparing INGRES & Oracle, what happens is that the locking overhead >>increases so much with row locking that it cancels out the benefits >>of higher concurrancy, it turns out most often page locking is the >>best compromise [for those who don't know INGRES uses page or table level >>locking, as appropriate] > >I STRONGLY FEEL that row level locking is ESSENTIAL in a highly concurrent >application. If a DBMS does'nt have it, how do you ensure that only ONE >user is currently updating a given record in a table without locking the whole >table?? or the whole page??. We want to lock that record and that record alone! You may "STRONGLY FEEL" this but empirically this is much less important than other factors like disk throughput, caching etc. Page locking still gives you plenty fine granularity for most highly concurrent applications. >>INGRES has very dynamic ability to change the structure of tables, using >>the MODIFY command. If you want to add/delete whole columns from the >>database schema [SQL's ALTER TABLE] it can be done with about 3 regular >>SQL statements. > >Suppose you want to change a c10 fld to c20 or to c8 ?? What do you do? No problem, just use the regular built-in type conversion operators. There is an INGRES technical note describing all how to do this, as well as a section in the DBA Guide about it. >It seems like a strange OMISSION since the code can be written in >a few hours by RTI programmers! Thats the whole point - its really simple to create your own customized one, so other things which provided significant new functionality (like database procedures, popup windows etc) had higher priority. On your other complaints: If you have a problem or want to suggest an enhancement, call up RTI Tech Support through your contact - all enhancment suggestions are recorded (they're called SIRs in RTI-ese) and populer ones often get implemented. For example, most of the recent changes in ABF were prompted by user requests, from invisible fields through library support. Robert Fair Technical Support Relational Technology, Inc Disclaimer: These opinions are mine alone, and do not represent my employer, RTI, in any way.
caefletch@uqvax.decnet.uq.oz (07/25/89)
In article <378@proexam.UUCP>, glen@proexam.UUCP (Glen Brydon) writes: > I have been trying to build applications in Ingres 4GL for several years now. > Recently we have been trying to find someone who can help in this process, but > have found relatively few individuals who have any significant experience in > using this system (perhaps Ingres, but not the 4GL). I have long since become > frustrated with the system for the following reason - there is no forms based > method of building the framework for an application without requiring me to > generate tons of OSL (4GL) code which ends up being traditional 3GL code. > > RTI does provide a tool that is forms based and intellegent called: > Query by Forms (QBF), but while providing a fairly nice minimal application > it does not allow me to extend that tool to do the things I might want. > QBF is designed to browse and modify tables and simple joins, but I want to > hook into the mechanism with my own constraints or code fragments. No such > facility exists. Alternatively I would settle for a library of well structured > tools which I can use to get the same functionality as QBF, but which I can > insert into my own application - no dice. Without this nonexistent library > my applications tend quickly toward being too big (for 4GL) and very difficult > to maintain as I need to change even simple features of the form. > > One candidate recently told me that he would be quite happy to help me develop > applications for my firm if I would only dump INGRES in favor of Oracle. While > we have currently invested a fair amount of time, effort and $$$ into our > current direction, I do not feel wedded to INGRES. I am now registered to > attend a sales presentation seminar for Oracle directed toward Government > installations using UNIX. This man who wants me to dump INGRES has spent > some amount of time evaluating and developing in Ingres, Oracle as well and > Informix. He says that Informix is simply a joke, and that while Ingres is > a pretty good database, it falls far short of Oracle in this area of allowing > the developer to quickly build applications in such a way that the complexity > is controlled and maintenance does not become a nightmare. His final comment > was that Sybase, while being often selected for its top-notch transaction > performance is not quite as good as Oracle. Sybase and Oracle consider > each other to be competetors and neither consider Ingres to be one. > > As I browse through the advertisments for application development products > and databases with such support it looks as though everyone has it on the > competition. A recent UNIX review magazine issue listed the following > products: > Informix - 3 times faster than any other 4GL? > Oracle - largest database company (so what?) speed WITH power > Ingres - CASE tools (not just yet!) > Empress - compares itself to Oracle, Informix, Ingres and Sybase > Interbase - BLOBS and capturing "business rules"? > PROGRESS - compared to Oracle and informix by DATAPRO satisfaction rating > Unify ACCELL - application generator works with any RDBMS! > JYACC JAM - same as ACCELL? > > So we have the integrated database systems with application development > systems and the application generators which work on any database. Without > the opportunity to use more than one system and approach it would seem very > difficult to know for sure who has the best approach. > > Now for the point to all of this - would people with comments, advice > and warning please share it with the rest of us? Anyone who feels that they > understand the basic approach to so called application development tools > could possibly describe to us what makes their approach unique, etc. > Does your system do more than simply give you a forms/menu environment and > database access? Thanks for your knowledge/advice/comments. > > Glen Brydon