Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ll-xn!oberon!sdcrdcf!hplabs!oracle!rbradbur From: rbradbur@oracle.UUCP (Robert Bradbury) Newsgroups: comp.databases Subject: Re: ORACLE on the cheap... questions Summary: Oracle features explanation Message-ID: <178@turbo.oracle.UUCP> Date: 8 Jul 88 23:19:35 GMT References: <5165@dasys1.UUCP> <8208@ncoast.UUCP> Organization: ORACLE Corporation, Belmont CA, USA Lines: 67 In article <8208@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon S. Allbery) writes: > > The only restriction in the $199/$399 version is in the license: you can > only use it for development, to use it as a "live" system you have to fork > over the rest of the full price. --But, judging from how many people pay > for "shareware" programs, I daresay that in practice people use it as if > they had a full license anyway. (I do *not* advocate doing so, I'm merely > making an observation.) > The $199/$399 customers are also not entitled to upgrades. Soooo when version 6 comes out they will have to pay if they want the latest and greatest. > > 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) > and SQL*Forms and SQL*Report are miserable compared to tools designed for > Unix (they both act like what they are: designed for VMS -- and they are > therefore lacking in flexibility Unix types take for granted, such as > support for multiple terminals/printers). 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 and Ingres in a good percentage of the DeWitt benchmarks on a number of machines. The functionality of a full-function RDBMS (transaction logs, security, rollback, roll-forward, read-consistancy, etc.) imposes a certian amount of overhead. You cannot compare the performance of database systems which have those features with those that do not. 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 was *NOT* designed for VMS or UNIX. It was designed to be portable across a variety of operating systems (VM,MVS,AOS,VMS,UNIX,DOS,AEGIS,etc.) and to do that we have our own terminal definitions. (You can support any type of terminal you are willing to provide a terminal defninition for - there is even a utility on UNIX systems to turn termcap definitions into Oracle terminal definitions.) Can I ask how many menuing systems based on termcap you have running under VM, MVS and DOS? :-) > > 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 functions. The problem with this is that it requires shipping an Oracle link kit (I assume you have megabytes of disk space to spare :-)) and it results in a support nightmare ("oh, you added these functions and your database is now corrupted... hmmm, you don't think it could be the functions you added do you?") > (Oracle, if you're listening, this would be a big help!!! So would (a) > making multiple terminals w/graphics in SQL*Forms work and (b) releasing > that new SQL*ReportWriter for more than just VMS.) We do listen, you have to realize though that the marketplace we are trying to serve is not just the UNIX marketplace. SQL*FORMS will work with multiple terminal types if you provide the terminal description. The UNIX group is actively working on shrinking the time between VMS announcement and general UNIX availabiliy. The goal for the end of the year is a 45 day lag on primary UNIX ports and no more than a 90 day lag for secondary UNIX ports. I would expect your sales person could do some investigation and come up with an availability date for SQL*ReportWriter on UNIX. -- Robert Bradbury Oracle Corporation (206) 784-9474 hplabs!oracle!rbradbur