Path: utzoo!attcan!uunet!samsung!emory!hubcap!ncrcae!ncr-sd!iss-rb!adt!benl From: benl@adt.SanDiego.NCR.COM (Ben.Lheureux) Newsgroups: comp.databases Subject: Re: SQL Poser Keywords: portability Message-ID: <564@iss-rb.SanDiego.NCR.COM> Date: 10 Jun 90 06:24:55 GMT References: <6588@umd5.umd.edu> <1990Jun1.132731.6699@oracle.com> <1990Jun4.151555.3479@oracle.com> <548@iss-rb.SanDiego.NCR.COM> Sender: news@iss-rb.SanDiego.NCR.COM Reply-To: benl@adt.SanDiego.NCR.COM (Ben.Lheureux) Organization: NCR Corporation, Rancho Bernardo Lines: 45 In article jkrueger@dgis.dtic.dla.mil (Jon) writes: > >benl@adt.SanDiego.NCR.COM (Ben.Lheureux) writes: >>A convenient position to take, since Oracle just happens to have >>one of the (perhaps THE) most robust SQL languages :-) > >What does "robust" mean as used above? > >I am familiar with robust implementations; what makes a language >itself "robust"? Ability "to be used in an unextended form"? If so, >good, I need to write device drivers, "robust" SQL will be just the >thing. If not, how about letting us know what you're talking about? > That was a misleading use of "robust". I meant to say that Oracle supports a large number of SQL extensions like ROWID, statistical aggregate functions, and hierarchical queries, along with recently announced object-oriented features. Are these in SQL Level 1, 2 or 3? Nice to have, unless you're... ... developing portable applications which attempt to utilize a subset of SQL in its evolving state. Then this issue, rather than "robust" to define completeness of SQL as the-solution-to-all-DBMS-requirements, which is a concern. Vendors' products (Oracle*Star, Ingres Star, SQL/Windows from Gupta, Free-Form, etc.) base some application portability claims on SQL's "portability" values -- and in this case extensions are difficult to reconcile. Consider... >In article <1990Jun4.151555.3479@oracle.com> tgreenla@oracle.UUCP (Terry Greenlaw) writes: > >Actually, the SQL*Connect products (previously grouped under the SQL*Star blob >of information) use SQL plus OUR extensions to SQL. We don't use DB2's SQL when >connecting to a DB2 database. Our architecture is designed to seperate the >underlying database type from the applications. ...how is this accomplished? If you do not use "DB2's SQL", what do you mean by saying you use "SQL plus OUR extensions"? When using Oracle tools or applications through SQL*Connect (e.g. DB2), all, some or none of Oracle's SQL extensions must be handled by SQL*Connect. And DB2 must receive some form of the SQL command. Benoit.Lheureux@sandiego.NCR.COM #################################### Application Dev Tools, Dept 4775 # Opinions are my own, not NCR's # 16550 West Bernardo Drive # Farewell Micro C Magazine # San Diego, CA 92127 619/485-3578 ####################################