[sqlite] last_insert_rowid() and changes() per statement instead of per connection?

Thanks. I'm reading you with attention. > Clemens: > Please note that transactions work on the connection level. That was clear. > Simon: > Which, of course, decreases the point of you having competing threads in the > first place. Which is related to the FAQ pointing at >

[sqlite] Bug with DATETIME('localtime')

On Sun, Dec 13, 2015 at 6:44 PM, Keith Medcalf wrote: > We have been doing daylight savings changes to and from twice a year for > as long as I remember (that is more than 100 times) and we still cannot > manage to do it properly. Leap years have been occurring for a long time > and somehow we s

[sqlite] Problem when upgrading from FTS3/4 toFTS5modules(revisited)

I apologize for the mistake, but you must forget my last two posts (probably due the tiredness or the excitement of the moment). In fact, the query "DELETE TABLE IF EXIST database_name.table_name" goes flawlessly, but indeed does not drop the table. Sorry for the confusion. -- Adolfo J. Millan

[sqlite] Bug with DATETIME('localtime')

Or in python using pytz: import datetime import pytz UTC = pytz.UTC EST = pytz.timezone('Canada/Eastern') MSK = pytz.timezone('Europe/Moscow') tm = datetime.datetime(2014, 10, 25, 20, 0 ,0) tm tm = UTC.localize(tm) tm ms = MSK.normalize(tm.astimezone(MSK)) ms es = EST.normalize(tm.astimezone(ES

[sqlite] Bug with DATETIME('localtime')

On Sun, Dec 13, 2015 at 5:00 PM, James K. Lowden wrote: > On Thu, 10 Dec 2015 06:34:44 -0700 > "Keith Medcalf" wrote: > > > The only way to convert datetime data on windows is to use a > > third-party package that does it properly, or write it yourself. > > Using the WinAPI functions is equivale

[sqlite] Problem when upgrading from FTS3/4 toFTS5modules(revisited)

Oops: Sorry for the typo. I mean "DROP TABLE IF EXISTS database_name.table_name" -- Adolfo J. Millan

[sqlite] last_insert_rowid() and changes() per statement instead of per connection?

On Sunday, 13 December, 2015 17:04, Olivier Mascia wrote: > Thanks. I'm reading you with attention. > > Clemens: > > Please note that transactions work on the connection level. > That was clear. > > Simon: > > Which, of course, decreases the point of you having competing threads in > the fir

[sqlite] Problem when upgrading from FTS3/4 toFTS5modules(revisited)

> > Mensaje original > De: Dan Kennedy > Para: sqlite-users at mailinglists.sqlite.org > Fecha: Fri, 11 Dec 2015 22:54:45 +0700 > Asunto: Re: [sqlite] Problem when upgrading from FTS3/4 > toFTS5modules(revisited) > > > >Are you able to compile a debugging build of SQLite and set a

[sqlite] Bug with DATETIME('localtime')

On Thu, 10 Dec 2015 06:34:44 -0700 "Keith Medcalf" wrote: > The only way to convert datetime data on windows is to use a > third-party package that does it properly, or write it yourself. > Using the WinAPI functions is equivalent to "writing it yourself" > because they do not actually do anythin

[sqlite] last_insert_rowid() and changes() per statement instead of per connection?

On 13 Dec 2015, at 5:34pm, Clemens Ladisch wrote: > Olivier Mascia wrote: >> should the design of competing threads revolve around each one having >> a distinct connection handle? > > Yes. Which, of course, decreases the point of you having competing threads in the first place. Which is rela

[sqlite] last_insert_rowid() and changes() per statement instead of per connection?

Olivier Mascia wrote: > even if using two distinct sqlite3_stmt* handles (linked to a same > sqlite3* handle), two competing threads would get unusable answers > from both these API. Yes. Please note that transactions work on the connection level. > should the design of competing threads revolve

[sqlite] last_insert_rowid() and changes() per statement instead of per connection?

Dear all, Why isn't there some: sqlite3_int64 sqlite3_stmt_last_insert_rowid(sqlite3_stmt*); int sqlite3_stmt_changes(sqlite3_stmt*); in addition to these: sqlite3_int64 sqlite3_last_insert_rowid(sqlite3*); int sqlite3_changes(sqlite3*); Reading this: "If a sep

[sqlite] last_insert_rowid() and changes() per statement instead of per connection?

On Sun 2015-12-13 13:47, Simon Slavin wrote: > On 13 Dec 2015, at 5:34pm, Clemens Ladisch wrote: > > Olivier Mascia wrote: > >> should the design of competing threads revolve around each one having > >> a distinct connection handle? > > Yes. > Which, of course, decreases the point of you havi

[sqlite] Checking Foreign Keys

On 2015/12/13 2:17 PM, Cecil Westerhof wrote: > I am continuing with my exploration of SQLite. :-) > > At the moment I am working with Foreign Keys. They need to be enabled. When > you do not do this it is possible to enter records that break the Foreign > Key rules. Is there a way to check for t

[sqlite] Checking Foreign Keys

On 13 Dec 2015, at 12:52pm, R Smith wrote: > I don't think there would be a point of turning off FK checks, adding > non-relation data to the tables, then turning it back on, and simply get a > permanent error condition. Agreed. There is a reason to turn the checks off, however. Suppose you

[sqlite] Set update time, but not always

On 2015/12/13 1:31 PM, Cecil Westerhof wrote: > I have a table where I would most of the time update a field lastChecked to > current_date when I update the record. But it is possible that I sometimes > want to update a record without updating lastChecked. Is this possible, or > should I update it

[sqlite] Checking Foreign Keys

2015-12-13 13:53 GMT+01:00 Dominique Devienne : > On Sun, Dec 13, 2015 at 1:17 PM, Cecil Westerhof > wrote: > > > At the moment I am working with Foreign Keys. They need to be enabled. > When > > you do not do this it is possible to enter records that break the Foreign > > Key rules. Is there a w

[sqlite] Checking Foreign Keys

2015-12-13 13:52 GMT+01:00 R Smith : > > > On 2015/12/13 2:17 PM, Cecil Westerhof wrote: > >> I am continuing with my exploration of SQLite. :-) >> >> At the moment I am working with Foreign Keys. They need to be enabled. >> When >> you do not do this it is possible to enter records that break the

[sqlite] Problem when upgrading from FTS3/4 toFTS5modules(revisited)

> > Mensaje original > De: Dan Kennedy > Para: sqlite-users at mailinglists.sqlite.org > Fecha: Fri, 11 Dec 2015 22:54:45 +0700 > Asunto: Re: [sqlite] Problem when upgrading from FTS3/4 > toFTS5modules(revisited) > >>> 1a.- Delete the previous table. DROP TABLE IF EXIST fts

[sqlite] Checking Foreign Keys

On Sun, Dec 13, 2015 at 1:17 PM, Cecil Westerhof wrote: > At the moment I am working with Foreign Keys. They need to be enabled. When > you do not do this it is possible to enter records that break the Foreign > Key rules. Is there a way to check for this. > > For example in a session where Forei

[sqlite] Set update time, but not always

2015-12-13 13:18 GMT+01:00 R Smith : > > On 2015/12/13 1:31 PM, Cecil Westerhof wrote: > >> I have a table where I would most of the time update a field lastChecked >> to >> current_date when I update the record. But it is possible that I sometimes >> want to update a record without updating lastC

[sqlite] Checking Foreign Keys

I am continuing with my exploration of SQLite. :-) At the moment I am working with Foreign Keys. They need to be enabled. When you do not do this it is possible to enter records that break the Foreign Key rules. Is there a way to check for this. For example in a session where Foreign Keys where n

[sqlite] Set update time, but not always

I have a table where I would most of the time update a field lastChecked to current_date when I update the record. But it is possible that I sometimes want to update a record without updating lastChecked. Is this possible, or should I update it (almost) always manually? -- Cecil Westerhof

[sqlite] website documentation wording

On 5/12/2015 2:08 AM, Keith Medcalf wrote: > Well, a Gartner Report paid for by Microsoft, which said that if you > pronounced it "ess queue ell" you were labelling yourself as a professional > programmer who understood relational database technologies, had probably used > them since the 1970's