Path: utzoo!attcan!uunet!husc6!bloom-beacon!gatech!mandrill!hal!ncoast!allbery From: allbery@ncoast.UUCP (Brandon S. Allbery) Newsgroups: comp.databases Subject: Re: ORACLE on the cheap... questions Message-ID: <11944@ncoast.UUCP> Date: 23 Jul 88 04:00:09 GMT References: <5165@dasys1.UUCP> <8208@ncoast.UUCP> <178@turbo.oracle.UUCP> Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery) Followup-To: comp.databases Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 107 We seem to have some misunderstandings and some time lags here. . . . As quoted from <178@turbo.oracle.UUCP> by rbradbur@oracle.UUCP (Robert Bradbury): +--------------- | In article <8208@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon S. Allbery) writes: | > Oracle has rollback, rollforward, and transaction logs. The version I used | > (5.1) wasn't too hot on the speed front (watch, however, for Turbo Oracle) | | I *hate* statements like "wasn't too hot on the speed front". Exactly | *what* are you doing that gives you that impression? We beat Informix +--------------- Informix 3.3 (which is a good deal faster than that miserable SQL product that Roger Sippl is now trying to cram down our throats!) and Unify were my benchmarks. Admitted, neither does the full set of rollback/rollforward and transaction logs -- but Unify does two of them with little speed penalty. I could see rollback implemented on top of the existing facility with little trouble, and in fact the functions are provided to do this oneself "manually" by opening the transaction log. +--------------- | SQL*Report is a very old program and is being replaced with a new report | writer which is as good as anything currently on the market. SQL*Forms +--------------- And, at about the time I was writing my original message, it came out for SunOS. Now for 6.0 and SQL*ReportWriter for Altos -- I told them I'd evaluate it for them when it came out. +--------------- | Oracle terminal definitions.) Can I ask how many menuing systems based | on termcap you have running under VM, MVS and DOS? :-) +--------------- I was thinking more of the graphics. Accell IDS and Informix-4GL both keep the graphics in the terminal definitions (termcap in both cases); I saw nothing to prevent your keeping character graphics in the Oracle terminal descriptions -- but you force me to use separate screens for separate terminal types instead. When I have to support a client which has a random mixture of Altos III's, Altos V's, and Wyse 50's, that is totally unacceptable. +--------------- | > The SQL supports quite a few more functions than (say) Informix or Unify, | > but not as many as Progress. Nor can new functions be linked into SQL. | | Well, you in fact can add functions to SQL if you know what tables to modify | and can relink the kernel. We have customers who are running with special +--------------- Then you need a more compact version of the link kit, perhaps. I know of at least one client that would benefit from having transcendental functions in SQL... as it turns out, I'm working in C linked into RM/COBOL instead (ugh!). +--------------- | to serve is not just the UNIX marketplace. SQL*FORMS will work with | multiple terminal types if you provide the terminal description. +--------------- But I have to declare three different screens to use on terminals with three different character graphics sequences!!! PLEASE add character graphics to the terminal description and use generic characters in the screens! It's not all that difficult -- Accell does it all the time. Oh, yeah -- while I have you by the ear [ ;-) ] ... The 386- and PC-flavored market you've expanded into isn't a big one for designing one's own front-ends, so SQL*Forms really needs to be overhauled to make it more generally functional. Problems I've had with it include: * Using the "select/sort" option in the block definition can get one into big trouble if one adds a constraint on a field (say, to perform upshifting on a query) -- I set up something along the lines of (working from memory, the Oracle manuals are 30 miles from here and it's midnight...): [prompt is "WHERE:"] MYTABLE.MYFIELD = UPCASE(':SOMEFIELD') This worked UNLESS there was a single quote in the field, at which point the SQL interface threw a fit and scared the sh*t out of the data entry operator. Why is the :FIELD expression a text substitution instead of a binding? * Certain useful operations aren't possible, due to the separation of user-initiated operations and database updates. (KEY-NXTREC != NXTREC) This resulted in gobs of hooks on KEY-* and *still* didn't execute my hook everywhere it was needed. (I don't remember what the exact problem was; I can try to restore the backup onto my personal system and reproduce it. I *do* remember that I couldn't get the following to work: in English, "after query go to next block, query 'detail' records, and return". In fact, there were a few examples in the SQL*Forms manual that, typed into a form exactly as printed, produced errors.) Sometimes I wish I could take all the good parts of all the DBMSes I've worked with and roll them up together into a single good DBMS. It's painfully obvious from the user's (and developer's) standpoint that DBMSes have quite a bit of maturing to do. (That's not really a flame, I can't realistically expect a DBMS to show up "fully-formed and wearing the latest style hat" -- it's just frustrating to be aware of the limitations and not be able to do anything about it. Such is the price of the exponential rate of software development, as seen from my vantagepoint.) ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc