> Keith:
>
> The documentation for sqlite3_last_insert_rowid clearly states that it
> returns the rowid last inserted on the connection, as does the documentation
> for sqlite3_changes. While I agree that it may very well be possible to
> maintain the data by statement, that is not what the
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
>
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
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
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
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
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
7 matches
Mail list logo
