From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.36.54.12 with SMTP id l12mr3189235itl.1.1463673016926;
        Thu, 19 May 2016 08:50:16 -0700 (PDT)
X-Received: by 10.157.56.116 with SMTP id r49mr128850otd.19.1463673016902;
 Thu, 19 May 2016 08:50:16 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!i5no10028067ige.0!news-out.google.com!f14ni547ita.0!nntp.google.com!i5no10028059ige.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Thu, 19 May 2016 08:50:16 -0700 (PDT)
In-Reply-To: <nha9u9$s97$1@dont-email.me>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=75.161.30.145;
 posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC
NNTP-Posting-Host: 75.161.30.145
References: <d7d3f9d8-4514-4794-bfc9-b835e7a2eac4@googlegroups.com>
 <af8f5334-d94c-4934-b36b-2be556fe96fd@googlegroups.com>
 <nh78u1$sp9$1@dont-email.me>
 <10e06a66-379a-453b-9d69-1a01695ceab2@googlegroups.com>
 <nha9u9$s97$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <59f2706f-8c0e-4159-b35a-2de322907d5d@googlegroups.com>
Subject: Re: ANN: Introducing AdaBase - Thick database bindings for Ada
From: Shark8 <onewingedshark@gmail.com>
Injection-Date: Thu, 19 May 2016 15:50:16 +0000
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:30435
Date: 2016-05-19T08:50:16-07:00
List-Id: <comp.lang.ada>

On Sunday, May 15, 2016 at 11:03:29 AM UTC-6, bj=C3=B6rn lundin wrote:
> On 2016-05-15 15:59, Shark8 wrote:
> > On Saturday, May 14, 2016 at 7:27:52 AM UTC-6, Georg Bauhaus wrote:
> >>
> >> The fact that SQL is a vendor run ISO standardization business is
> >> related matter. But it is not stopping portability entirely.
> >=20
> > If we're being fair, the reason that the SQL ISO is a failure as a stan=
dard=20
> >is precisely because it has so many optional features (and alternate syn=
tax forms)
> > that it's rather common that two implementations would reject each othe=
r's
> > SQL-statements for any non-trivial operation.
>=20
> Does that matter in practice ?
> I've ported a system with 700-800 sql-statements from
> Oracle to MS Sql Server
> where all of them where one of
>=20
> *select
> *insert
> *update
> *delete
>=20
>=20
> (and 500 + are not trivial - inner and/or outer joins, sub-selects,
> aggregates and so on)
>=20
> I ended up with looking at what database is in use at 1 single statement.
>=20
> Oracle calls it substr
> and MS sql server calls it substring
>=20
> I find it harsh to call that a failure.
>=20
> Sure, the creation of tables/indexes/views are all different,
> but that is of no significance (at least to me)
>=20
> --
> Bj=C3=B6rn

Yes, it does matter.
Just look at these popular implementations compared against the standard: h=
ttp://troels.arvin.dk/db/rdbms/