Re: [sqlite] [EXTERNAL] strftime("%Y", "-1234-01-01") returns -123

2019-07-16 Thread Hick Gunter
You should be using single quotes for string delimiters. Additionally, you are seeing right handed truncation of a 5 character string in a 4 character field asql> select strftime('%Y','-0123-04-05'); strftime('%Y','-0123-04-05') -123 -Original Message-

Re: [sqlite] strftime("%Y", "-1234-01-01") returns -123

2019-07-16 Thread Richard Hipp
On 7/16/19, Tanaka Akira wrote: > Hi. > I found a doubtful behavior of strftime("%Y"). > > strftime("%Y", "-1234-01-01") returns -123 Perhaps you overlooked the following paragraph from the documentation: "These functions only work for dates between -01-01 00:00:00 and -12-31 23:59:59

[sqlite] strftime("%Y", "-1234-01-01") returns -123

2019-07-16 Thread Tanaka Akira
Hi. I found a doubtful behavior of strftime("%Y"). strftime("%Y", "-1234-01-01") returns -123 but I feel it should be -1234. (But it can be error because the manual describes "%Y year: -".) % ./sqlite3 SQLite version 3.29.0 2019-07-10 17:32:03 Enter ".help" for usage hints. Connected to

Re: [sqlite] sqlite3_close() drops wal and shm files despite of other processes holding DB open

2019-07-16 Thread Andreas Kretzer
Interessting insights! Dan pointed out, that I should check the locks on the DB files and report that information back. Unluckily, my 'lsof' just reports PIDs, executable name and open file. It is a Busybox multicall binary. The good thing is: I have 'lslocks' on my system, which gives me

Re: [sqlite] [EXTERNAL] Re: sqlite3_close() drops wal and shm files despite of other processes holding DB open

2019-07-16 Thread Andreas Kretzer
Sure - I loose my locks when calling daemon(). I already have changed my program to close and re-open the DB when daemonizing. I was not aware, that daemon() by itself would do a fork(). There is no explicit fork() in my program... Anyway, it is now clear what should be avoided: carrying an open

Re: [sqlite] [EXTERNAL] Re: sqlite3_close() drops wal and shm files despite of other processes holding DB open

2019-07-16 Thread Hick Gunter
I think your file locks are getting stranded in the parent process during your daemon() call. When you open the SQLite db, you are opening file descriptors and generating memory state. Accessing the db to read config creates further memory state plus some file level locks. Which will persist

Re: [sqlite] sqlite3_close() drops wal and shm files despite of other processes holding DB open

2019-07-16 Thread Andreas Kretzer
... and here is the solution! I daemonize my programs using daemon (1, 1); If I do that, before I open the DB, then everything is alright, locks are held - fine! In the other case I was first opening the DB to fetch some configuration options from it before I took care of program args and

Re: [sqlite] sqlite3_close() drops wal and shm files despite of other processes holding DB open

2019-07-16 Thread Andreas Kretzer
Interessting insights! Dan pointed out, that I should check the locks on the DB files and report that information back. Unluckily, my 'lsof' just reports PIDs, executable name and open file. It is a Busybox multicall binary. The good thing is: I have 'lslocks' on my system, which gives me

Re: [sqlite] Safe saving of in-memory db to disk file

2019-07-16 Thread Dominique Devienne
On Tue, Jul 16, 2019 at 4:44 AM Adrian Ho wrote: > On 15/7/19 11:25 PM, Nelson, Erik - 2 wrote: > > Dominique Devienne wrote on Monday, July 15, 2019 2:41 AM > >> That's when you reach for virtual tables (and their "virtual indices"). > >> I.e. you keep your data in native data-structures