Xref: utzoo comp.databases:3032 comp.software-eng:1783 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!aramis.rutgers.edu!paul.rutgers.edu!yes.rutgers.edu!emuleomo From: emuleomo@yes.rutgers.edu (Emuleomo) Newsgroups: comp.databases,comp.software-eng Subject: Re: 4GL and Application Prototyping in Databases Keywords: 4GL DBMS prototype maintainability OSL QBF INGRES Message-ID: Date: 21 Jul 89 14:32:41 GMT References: <378@proexam.UUCP> <3190@rtech.rtech.com> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 115 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 and UNLOCK CURRENT OF ?? >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! **