Re: [sqlite] Is there any way to close a connection without checkpointing the WAL?

On 5 Dec 2016, at 9:46pm, Scott Hess wrote: > I don't think so, that seems like it could result in corruption. > Unless you mean something more like causing the OS to block all fsync > calls on the filesystem and release them as a single uber-sync? Yeah, that’s what I meant.

Re: [sqlite] Is there any way to close a connection without checkpointing the WAL?

On Mon, Dec 5, 2016 at 1:34 PM, Simon Slavin wrote: > On 5 Dec 2016, at 9:26pm, Scott Hess wrote: >> An obvious solution would be to simply not call sqlite3_close(), >> though that has various other unfortunate side effects. > > Yeah. Don’t do that, eh ?

Re: [sqlite] Is there any way to close a connection without checkpointing the WAL?

On Mon, Dec 5, 2016 at 1:38 PM, Richard Hipp wrote: > On 12/5/16, Scott Hess wrote: >> Is there any clean way to request no WAL checkpoint on sqlite3_close()? > > sqlite3_db_config(SQLITE_DBCONFIG_NO_CKPT_ON_CLOSE, db). See >

Re: [sqlite] Is there any way to close a connection without checkpointing the WAL?

On 12/5/16, Scott Hess wrote: > > Is there any clean way to request no WAL checkpoint on sqlite3_close()? sqlite3_db_config(SQLITE_DBCONFIG_NO_CKPT_ON_CLOSE, db). See https://www.sqlite.org/draft/c3ref/c_dbconfig_enable_fkey.html at the bottom. -- D. Richard Hipp

Re: [sqlite] Is there any way to close a connection without checkpointing the WAL?

On 5 Dec 2016, at 9:26pm, Scott Hess wrote: > An obvious solution would be to simply not call sqlite3_close(), > though that has various other unfortunate side effects. Yeah. Don’t do that, eh ? What you’re actually trying to do is disable/delay fsync() for a time for a

[sqlite] Is there any way to close a connection without checkpointing the WAL?

At Chromium shutdown, various services desire to write data to their SQLite databases, which results in a (small) thundering herd of fsyncs, which makes shutdown slower than it could be. Normally, one could enable WAL mode to amortize the fsync cost across longer periods than a single

Re: [sqlite] like operator

On 12/5/2016 3:43 PM, Don V Nielsen wrote: Igor, I'm not sure if you gain anything from"length(lower(name))". Just "length(name)" would suffice. I'm guarding against various Unicode weirdnesses that could cause string length to change on case transformation. While SQLite only folds ASCII

Re: [sqlite] like operator

Igor, I'm not sure if you gain anything from"length(lower(name))". Just "length(name)" would suffice. On Mon, Dec 5, 2016 at 10:11 AM, Dominique Devienne wrote: > On Mon, Dec 5, 2016 at 4:24 PM, Igor Tandetnik wrote: > > > On 12/5/2016 10:19 AM, Igor

Re: [sqlite] like operator

On Mon, Dec 5, 2016 at 4:24 PM, Igor Tandetnik wrote: > On 12/5/2016 10:19 AM, Igor Tandetnik wrote: > >> On 12/5/2016 7:30 AM, ravi.shan...@cellworksgroup.com wrote: >> >>> select name from employee table where name like '%Araya%' or name like >>> '%Amul%' or name like

Re: [sqlite] like operator

On 12/5/2016 10:19 AM, Igor Tandetnik wrote: On 12/5/2016 7:30 AM, ravi.shan...@cellworksgroup.com wrote: select name from employee table where name like '%Araya%' or name like '%Amul%' or name like '%Aj%'; Table - Employee Id | Name | age | 1 | Arayan Kuma | 29 | 2 | Amul Kanth |

Re: [sqlite] like operator

On 12/5/2016 7:30 AM, ravi.shan...@cellworksgroup.com wrote: select name from employee table where name like '%Araya%' or name like '%Amul%' or name like '%Aj%'; Table - Employee Id | Name | age | 1 | Arayan Kuma | 29 | 2 | Amul Kanth | 30 | 3 | Ajay Kumar | 45 | I dont

Re: [sqlite] Problem with CASE in WHERE clause

> Le 5 déc. 2016 à 12:36, Simon Slavin a écrit : > > And defining a column with a type of INTEGER is as close to BOOL as SQLite > gets. It is even better when you take into account that SQLite internally has a storage type for 'integer value 0' and 'integer value 1'

[sqlite] like operator

Hi Guys, select name from employee table where name like '%Araya%' or name like '%Amul%' or name like '%Aj%'; Table - Employee Id | Name | age | 1 | Arayan Kuma | 29 | 2 | Amul Kanth | 30 | 3 | Ajay Kumar | 45 | I dont like to use may or conditions for pattern matching

Re: [sqlite] Problem with CASE in WHERE clause

Hi Simon, At 11:41 05/12/2016, you wrote: On 5 Dec 2016, at 7:48am, Jean-Christophe Deschamps wrote: > The choice of literals representing true and false is merely cosmetic. You got me interested in that. I had thought that "TRUE" and "FALSE" were reserved words in

Re: [sqlite] Problem with CASE in WHERE clause

At 12:18 05/12/2016, you wrote: From: Jean-Christophe Deschamps Sent: Monday, December 05, 2016 9:48 AM To: SQLite mailing list Subject: Re: [sqlite] Problem with CASE in WHERE clause > > At 06:29 05/12/2016, you wrote: > >My app supports sqlite3, SQL Server, and PostgreSQL. > > > >SQL Server

Re: [sqlite] Problem with CASE in WHERE clause

On 5 Dec 2016, at 11:18am, Frank Millman wrote: > So if I understand correctly, it makes sense to use ‘1’/’0’ to *set* the > boolean value in a cross-database manner, but there are a variety of ways to > test for it. Rather than the strings it would be better to use the

Re: [sqlite] Problem with CASE in WHERE clause

From: Jean-Christophe Deschamps Sent: Monday, December 05, 2016 9:48 AM To: SQLite mailing list Subject: Re: [sqlite] Problem with CASE in WHERE clause > > At 06:29 05/12/2016, you wrote: > >My app supports sqlite3, SQL Server, and PostgreSQL. > > > >SQL Server has a ‘bit’ data type,

Re: [sqlite] Problem with CASE in WHERE clause

On 5 Dec 2016, at 7:48am, Jean-Christophe Deschamps wrote: > The choice of literals representing true and false is merely cosmetic. You got me interested in that. I had thought that "TRUE" and "FALSE" were reserved words in SQLite. But I can find nothing to back that up,