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 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.36.110.210 with SMTP id w201mr527137itc.7.1471542308997; Thu, 18 Aug 2016 10:45:08 -0700 (PDT) X-Received: by 10.157.24.83 with SMTP id t19mr286593ott.17.1471542308951; Thu, 18 Aug 2016 10:45:08 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!f6no10988074ith.0!news-out.google.com!d68ni31659ith.0!nntp.google.com!f6no11010344ith.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 18 Aug 2016 10:45:08 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=76.218.37.33; posting-account=W2gdXQoAAADxIuhBWhPFjUps3wUp4RhQ NNTP-Posting-Host: 76.218.37.33 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <7a1eaa60-3be9-4e9b-b67a-d174f3960276@googlegroups.com> Subject: Re: GNATCOLL SQLite3 vs Ada.Calendar.Time From: Stephen Leake Injection-Date: Thu, 18 Aug 2016 17:45:08 +0000 Content-Type: text/plain; charset=UTF-8 Xref: news.eternal-september.org comp.lang.ada:31458 Date: 2016-08-18T10:45:08-07:00 List-Id: On Thursday, August 18, 2016 at 6:19:45 AM UTC-5, G.B. wrote: > On 17.08.16 23:05, Stephen Leake wrote: > > One solution would be to replace the "DATETIME" field type in the .sql file with "TEXT", always pass strings for times, and rely on lexicographic sorting for time comparison. But that seems extreme. > > It seems advisable to use SQLite's Date And Time Functions > when using SQLite for SQL. Thus, > > " ... WHERE Modified >= datetime(?) ... " > Yes, that works. Although I'm not clear why; https://www.sqlite.org/lang_datefunc.html defines that function to return a string, and the examples are about output formatting. Apparently it has a different meaning when processing bound parameters. > Testing SQL scripts using standard SQL syntax and several > SQL DBMSs has proven to be useful in detecting caveats. > SQLite's .dump command seems pretty good at producing > standard SQL syntax. That gives: INSERT INTO "Title" VALUES(2,'2000-01-02 00:00:00','Foundation'); no "datetime" function call. But we are talking about bound parameters, which could easily be different. I need to remember SQL is not Ada; it can silently do the wrong thing any time it wants :(. -- Stephe