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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Bj=c3=b6rn_Lundin?= <b.f.lundin@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: ANN: Introducing AdaBase - Thick database bindings for Ada
Date: Sun, 15 May 2016 19:03:42 +0200
Organization: A noiseless patient Spider
Message-ID: <nha9u9$s97$1@dont-email.me>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 15 May 2016 16:59:53 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="4a14fbc3936a9349c7c59849b8b21d41";
	logging-data="28967"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+6aNCY5FYgl69HTLHyGNnG"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Icedove/38.7.0
In-Reply-To: <10e06a66-379a-453b-9d69-1a01695ceab2@googlegroups.com>
Cancel-Lock: sha1:UKRRwaJiN0PSBxUtXldgFMMyiTM=
Xref: news.eternal-september.org comp.lang.ada:30414
Date: 2016-05-15T19:03:42+02:00
List-Id: <comp.lang.ada>

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.
> 
> If we're being fair, the reason that the SQL ISO is a failure as a standard 
>is precisely because it has so many optional features (and alternate syntax forms)
> that it's rather common that two implementations would reject each other's
> SQL-statements for any non-trivial operation.

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

*select
*insert
*update
*delete


(and 500 + are not trivial - inner and/or outer joins, sub-selects,
aggregates and so on)

I ended up with looking at what database is in use at 1 single statement.

Oracle calls it substr
and MS sql server calls it substring

I find it harsh to call that a failure.

Sure, the creation of tables/indexes/views are all different,
but that is of no significance (at least to me)

--
Björn