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?B?QmrDtnJuIEx1bmRpbg==?= <b.f.lundin@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Compiling GNATColl on Windows
Date: Tue, 16 Dec 2014 11:21:05 +0100
Organization: A noiseless patient Spider
Message-ID: <m6p11t$7n9$1@dont-email.me>
References: <09729271-32e5-4d7e-999f-2299a9c975fd@googlegroups.com>
 <27f6331d-31d4-4626-9b41-327c49bcbb6e@googlegroups.com>
 <5988fe56-ed84-4a6b-b5dd-d453b3c3b2f6@googlegroups.com>
 <8e88a5bd-30ab-4a23-974f-6fbeff11fb8c@googlegroups.com>
 <9a7fe568-2d34-42be-b1be-ce0653af005b@googlegroups.com>
 <m6nl8c$25m$1@dont-email.me> <1ifoukt5d2s2z$.6d9y7y2fiufo$.dlg@40tude.net>
 <m6orjs$h7n$1@dont-email.me> <1bkd0huwbs9ok$.158823hior2e7.dlg@40tude.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 16 Dec 2014 10:20:45 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="23e59b4906029a0ce22afc4c4b1f25ee";
	logging-data="7913"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19iPsPirQR7+asi38oaLTYk"
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Icedove/31.2.0
In-Reply-To: <1bkd0huwbs9ok$.158823hior2e7.dlg@40tude.net>
Cancel-Lock: sha1:86CbTVs/afu68mvu+abZzbFN6Sw=
Xref: news.eternal-september.org comp.lang.ada:24041
Date: 2014-12-16T11:21:05+01:00
List-Id: <comp.lang.ada>

On 2014-12-16 11:10, Dmitry A. Kazakov wrote:
> On Tue, 16 Dec 2014 09:48:16 +0100, Björn Lundin wrote:
> 
>> But the table grows, and I expect it to be ca 33 M rows at the ens of
>> the year. And next year, if I record the whole year, I'll end up with
>> 60M+ rows.
> 
> But you could use the time stamp in the SELECT's WHEN? 
> 

well no, not in a clean way. As I said


"The outcome is somewhat based on previous outcome, so I do not want
to split the recordset.-- "

That is I do NOT want a to use a where-clause based on the timestamp.

But I could, if I restructure the simulator. But then,
we are into redesign because of limitations in the implementation.
Yes, sometimes reality comes and bites you,
and you need to give in.
But if it can be avoided, I prefer not to change programs
just because data size increases.


>The greatest problem of ODBC is that it practically does not mandate
>anything. So you must question the capabilities of the actual driver
>and then adapt your application to what is available. For an Ada
>programmers it is the world turned upside-down, and a patented
>nightmare to write a minimally robust and maintainable application.

Indeed.

--
Björn