Re: [sqlite] Regarding the effects of the COMMIT keyword

Thanks for all the input, all of your comments put me on exactly the right track. I was too focused on the behavior of the writes and I didn’t consider the behavior of the reads. I reviewed the logs again and it turns out there was a longer running query that surrounded the entire PUT / GET

Re: [sqlite] converting unix10 and unix13 dates in the same column

Note that if you want the extra precision to show as fractional seconds you have to ensure floating point is passed (particularly if column dt is of integer affinity) and use strftime() rather than datetime() so you can specify the format string explicitly using %f to get SS.SSS. Datetime()

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

On Thu, Sep 22, 2016 at 9:43 PM, Darren Duncan wrote: > On 2016-09-22 12:16 PM, Petite Abeille wrote: > >> >> On Sep 22, 2016, at 9:04 PM, Richard Hipp wrote: >>> >>> (https://www.sqlite.org/draft/releaselog/3_15_0.html). >>> >> >> Oh! Row Values!

Re: [sqlite] converting unix10 and unix13 dates in the same column

All sorted now thank you ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] converting unix10 and unix13 dates in the same column

On 29 Sep 2016 at 14:14, Paul Sanderson wrote: > I have a table with dates in different formats, either 10 digit or 13 > digit unix dates > > 1234345087123 > 1234567890 > 1432101234 > 1456754323012 Are these strings or numbers? What is your SQL to get these into

Re: [sqlite] converting unix10 and unix13 dates in the same column

ah OK - being dull thank you Paul www.sandersonforensics.com skype: r3scue193 twitter: @sandersonforens Tel +44 (0)1326 572786 http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit -Forensic Toolkit for SQLite email from a work address for a fully functional demo licence On

Re: [sqlite] converting unix10 and unix13 dates in the same column

When you have a base expression in the CASE, then it compares each of the WHEN values to that base value. So in your situation there you have it written like if dt = (unix10and13.dt < 100) then... if dt = (unix10and13.dt > 100) then... I think if you get rid of the dt

Re: [sqlite] converting unix10 and unix13 dates in the same column

You query is incorrect. It should be: SELECT CASE WHEN (unix10and13.dt < 100) THEN DateTime(unix10and13.dt, 'unixepoch') WHEN (unix10and13.dt > 100) THEN DateTime(unix10and13.dt / 1000, 'unixepoch') ELSE dt END AS converted FROM unix10and13; When your case, you

[sqlite] converting unix10 and unix13 dates in the same column

I have a table with dates in different formats, either 10 digit or 13 digit unix dates 1234345087123 1234567890 1432101234 1456754323012 I want a sql query that will convert both dates, I tried this SELECT CASE dt WHEN (unix10and13.dt < 100) THEN DateTime(unix10and13.dt,

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

On Thu, Sep 29, 2016 at 2:37 PM, James K. Lowden wrote: > On Fri, 23 Sep 2016 16:35:07 + > Quan Yong Zhai wrote: > > > Quote << > > A "row value" is an ordered list of two or more scalar values. In > > other words, a "row value" is a vector.>> > > > >

Re: [sqlite] SQLite 3.15.0 scheduled for 2016-10-14

On Fri, 23 Sep 2016 16:35:07 + Quan Yong Zhai wrote: > Quote << > A "row value" is an ordered list of two or more scalar values. In > other words, a "row value" is a vector.>> > > A ?row value? is a tuple, not a vector. When your using a tuple, you > know how many items in it,

Re: [sqlite] Regarding the effects of the COMMIT keyword

Hick Gunter wrote: > Reading "stale" data (i.e. the DB state at the beginning of a transaction) > is at least almost always caused by indvertently leaving a transaction > open. Setting the journal mode to WAL hides this problem, because the > writer is no longer blocked by the reader's

Re: [sqlite] Regarding the effects of the COMMIT keyword

>I am using multiple threads, but in this instance just 2 inside of one >process. I do not change any PRAGMA settings other than user_version and >journal_mode. The two >connections differ only by the fact that one is read >only and one is read-write. It’s possible that I’ve forgotten a

Re: [sqlite] Regarding the effects of the COMMIT keyword

It’s less complicated than a web service. There is no “server” per se, only a lightweight listener object that can accept and respond to HTTP requests (C# HttpListener class). The short explanation is that the library I develop (Couchbase Lite) has a replication function that allows it to

Re: [sqlite] Regarding the effects of the COMMIT keyword

On 29 Sep 2016, at 8:59am, Jim Borden wrote: > There is a web API If you're using a conventional server as the front end to your web service (e.g. Apache, with your code written in PHP/Python/C/whatever) then the server spawns a new process to handle each incoming

Re: [sqlite] Regarding the effects of the COMMIT keyword

I am using multiple threads, but in this instance just 2 inside of one process. I do not change any PRAGMA settings other than user_version and journal_mode. The two connections differ only by the fact that one is read only and one is read-write. It’s possible that I’ve forgotten a finalize

Re: [sqlite] Regarding the effects of the COMMIT keyword

There is a web API, and the application flow is sending a PUT request, which stores the data and then returns a successful status. After that status is received, a GET request is sent. The way the write connection works is that everything is pumped through a single thread and all other

Re: [sqlite] Regarding the effects of the COMMIT keyword

On 29 Sep 2016, at 8:39am, Jim Borden wrote: > I found the following snippet from https://www.sqlite.org/lockingv3.html > > ➢ The SQL command "COMMIT" does not actually commit the changes to disk. It > just turns autocommit back on. Then, at the conclusion of the

Re: [sqlite] Regarding the effects of the COMMIT keyword

Jim Borden wrote: > I found the following snippet from https://www.sqlite.org/lockingv3.html > > The SQL command "COMMIT" does not actually commit the changes to disk. > It just turns autocommit back on. Then, at the conclusion of the > command, the regular autocommit logic takes over and

[sqlite] Regarding the effects of the COMMIT keyword

I found the following snippet from https://www.sqlite.org/lockingv3.html ➢ The SQL command "COMMIT" does not actually commit the changes to disk. It just turns autocommit back on. Then, at the conclusion of the command, the regular autocommit logic takes over and causes the actual commit to