Path: utzoo!attcan!uunet!snorkelwacker!apple!oracle!news
From: tgreenla@oracle.uucp (Terry Greenlaw)
Newsgroups: comp.databases
Subject: Re: SQL Poser
Keywords: portability
Message-ID: <1990Jun5.162450.18575@oracle.com>
Date: 5 Jun 90 16:24:50 GMT
References: <6588@umd5.umd.edu> <jkrueger.644204650@dgis.dtic.dla.mil> <1990Jun1.132731.6699@oracle.com> <jkrueger.644437146@dgis.dtic.dla.mil> <1990Jun4.151555.3479@oracle.com> <548@iss-rb.SanDiego.NCR.COM>
Reply-To: tgreenla@oracle.UUCP (Terry Greenlaw)
Organization: Oracle Corporation, Atlanta, GA
Lines: 57

In article <548@iss-rb.SanDiego.NCR.COM> benl@adt.SanDiego.NCR.COM (Ben.Lheureux) writes:
>In article <1990Jun4.151555.3479@oracle.com> tgreenla@oracle.UUCP (Terry Greenlaw) writes:
>>In article <jkrueger.644437146@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes:
>>>
>>>> Oracle has an extension to SQL which was designed for tree traversal
>>>
>>>Sounds great.  Except for one small problem: the only reason I use
>>>SQL is compatibility and applications portability.
>>
>>Then you must be one very frustrated individual, since SQL compatability 
>>between
>>vendors falls into the "virgin nymphomaniac" class of events. I don't think SQL
>>is mature enough at this point to freeze expansion of the language in the name
>>of compatability. 
>
>Let's not forget that every vendor's ME-TOO desire to support SQL and the 
>relational model provided -- for the first time -- a meaningful level of
>compatibility among divergent DMS's.  
>
>Unfortunately because SQL is not SQL is not SQL, there is a strong desire 
>to identify a commonly used subset of SQL features among vendors, so that 
>the highly marketed compatibility supposedly provided by SQL can actually 
>be realized by users.  I.e. formation of SAG, Ingres Open SQL, etc.
>
>>The extensions that Oracle and other vendors have provided
>>are the driving forces that will lead to a language robust enough to be used 
>>in a unextended form. 
>
>A convenient position to take, since Oracle just happens to have one of 
>the (perhaps THE) most robust SQL languages :-)   Exceptions anyone?
>
>>For now, the basic SQL syntax is a good starting point
>>for understanding a relational query language, but I wouldn't be relying on it
>>for portability across vendors.
>
>I'm sure your disclaimer disqualifies you from speaking for all Oracle
>Marketing organizations, but perhaps you can reconcile this position
>with Oracle's HIGHLY-TOUTED SQL*Star concept, where Oracle applications,
>presumably carefully coded in THE WONDERFUL, COMPATIBLE SQL language may 
>transparently run against Oracle, DB2, SQL/DS, or <name of your favorite
>version of SQL*Connect here>?
>
>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      ####################################

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.

   
Terry O. Greenlaw             Sheathed within the Walkman, 
Staff Engineer                Wear a halo of distortion.
Oracle Corporation            Aural contraceptive,
tgreenla@oracle.oracle.com    Aborting pregnant conversation - Marillion