[sqlite] 答复: Best way to terminate a dead-transaction: commit or rollback?

I prefer to COMMIT TRANSACTION, because 1. As a rule, all successfully executed transactions should be commit, otherwise should be rollback. 2. To rollback a transaction with no errors occurred will misguide some developers. 3. if someone puts a writing statement or function in the " read

[sqlite] Database is locked

Thanks a lot Simon. Now I understand a little bit better. Last question: (hopefully :-) ) Takes your suggestion with PDO setAttribute(PDO:: ATTR_TIMEOUT, the same effect as Richards with PRAGMA busy_timeout? For example I do a: $dbConnection =$db->query('PRAGMA busy_timeout=6') ; instead

[sqlite] Database is locked

On 15 Jan 2016, at 7:51am, Werner Kleiner wrote: > Takes your suggestion with PDO setAttribute(PDO:: ATTR_TIMEOUT, the same > effect as Richards with PRAGMA busy_timeout? > For example I do a: > > $dbConnection =$db->query('PRAGMA busy_timeout=6') ; > > instead of > >

[sqlite] Setting SQLITE_OMIT_FLOATING_POINT has surprising undocumented consequences

On 14 January 2016 at 22:31, Warren Young wrote: > For no especially good reason, I decided to turn off all SQLite features I?m > not using now and which I have no plans to use in the future. > > My current DB doesn?t use any FP columns, so I rebuild SQLite with > SQLITE_OMIT_FLOATING_POINT and

[sqlite] sqlite3_wal_checkpoint_v2() returning SQLITE_LOCKED: in what circumstances?

Dear all, What are the circumstances leading to: int status = sqlite3_wal_checkpoint_v2(conn, "main", SQLITE_CHECKPOINT_PASSIVE, 0, 0); returning SQLITE_LOCKED immediately? It looks like that the simple fact of having a select statement prepared, then ran, but not yet finalized, on that

[sqlite] sqlite3_wal_checkpoint_v2() returning SQLITE_LOCKED: in what circumstances?

> Le 15 janv. 2016 ? 11:54, Olivier Mascia a ?crit : > > What are the circumstances leading to: > > int status = sqlite3_wal_checkpoint_v2(conn, "main", > SQLITE_CHECKPOINT_PASSIVE, 0, 0); > > returning SQLITE_LOCKED immediately? > > > It looks like that the simple fact of having a select

[sqlite] sqlite3_wal_checkpoint_v2() returning SQLITE_LOCKED: in what circumstances?

I think you may mean "database connection" instead of "statement handle". When you are finished with processing a statement, you should either reset (if you intead to use it again later) or finalize it. Otherwise SQLite must assume that you want to continue later and needs to keep around

[sqlite] Database is locked

Hello Richard, I am not a SQLITE expert. As I understand WAL it is especially made for transactions? But our application do not have transactions, just normal SQL queries like Select, Insert and Updates. So does WAL makes sense for that? 2016-01-14 14:20 GMT+01:00 Richard Hipp : > On 1/14/16,

[sqlite] Database is locked

On 1/15/16, Werner Kleiner wrote: > Hello Richard, > I am not a SQLITE expert. > As I understand WAL it is especially made for transactions? > But our application do not have transactions, just normal SQL queries like > Select, Insert and Updates. Every "normal SQL query" is a transaction unto

[sqlite] Using sqlite3.exe as a subprocess

It seems that sqlite3.exe (console) doesn't work as a subprocess with pipes. I've tried it with both C++ code calling the CreateProcessW win32 API and with python and both resulted in the same behaviour. Which is the sub-process doesn't return anything when I try and read it's output (just

[sqlite] Using sqlite3.exe as a subprocess

On Fri, Jan 15, 2016 at 4:53 AM, Matthew Allen wrote: > It seems that sqlite3.exe (console) doesn't work as a subprocess with > pipes. > [...] I expect there is something funny going on with sqlite3.exe's > stdout/stdin. Sorry to highjack your thread Matthew, but I have what I consider a

[sqlite] WAL: difference between IMMEDIATE and DEFERRED transaction

Hello all, I would like to be sure I understand the difference between an IMMEDIATE transaction and a DEFERRED transaction, in WAL mode. Sorry for my bad english. Here is what I understand: Example of an IMMEDIATE transaction: - BEGIN IMMEDIATE TRANSACTION - SELECT - UPDATE - SELECT - UPDATE

[sqlite] WAL: difference between IMMEDIATE and DEFERRED transaction

On 1/15/16, Olivier Vidal wrote: > > Hello all, > > I would like to be sure I understand the difference between an IMMEDIATE > transaction and a DEFERRED transaction, in WAL mode. BEGIN IMMEDIATE claims a write lock on the database file immediately, so that no other process or thread can come

[sqlite] WAL: difference between IMMEDIATE and DEFERRED transaction

Than you Mr Hipp! So DEFERRED advantage is that less time locked (if there are SELECTS between BEGIN and UPDATE). But its drawback is that other threads can write between BEGIN and the first UPDATE / DELETE .. ? > Richard Hipp > vendredi 15 janvier 2016 15:19 > >

[sqlite] Using sqlite3.exe as a subprocess

Good day, Assuming you don't want to alter the code of the shell tool to take a named pipe (this isn't that difficult to do, unfortunately due to the business logic I can't go into, it was not allowed): Have you tried to create a command prompt shell, begin the sqlite shell tool in that and

[sqlite] Using sqlite3.exe as a subprocess

On 1/14/16, Matthew Allen wrote: > It seems that sqlite3.exe (console) doesn't work as a subprocess with > pipes. > Yeah it does. The test suite does this, in the shellN.test test scripts (N=1..5, ex: https://www.sqlite.org/src/artifact/ce5e744870387164) Those these are written in TCL, not in

[sqlite] sqlite3_wal_checkpoint_v2() returning SQLITE_LOCKED: in what circumstances?

> Le 15 janv. 2016 ? 13:08, Hick Gunter a ?crit : > > I think you may mean "database connection" instead of "statement handle". > > When you are finished with processing a statement, you should either reset > (if you intead to use it again later) or finalize it. Otherwise SQLite must >

[sqlite] sqlite3_wal_checkpoint_v2() returning SQLITE_LOCKED: in what circumstances?

On 1/15/16, Olivier Mascia wrote: > But the finalize of a > statement (using the C++ wrapper we build for our use over C SQLite API) is > currently differed until another prepare is done using the same Statement > object, or until the Statement object goes out of scope (destructor). That's a

[sqlite] sqlite3_wal_checkpoint_v2() returning SQLITE_LOCKED: in what circumstances?

On 15 Jan 2016, at 3:18pm, Olivier Mascia wrote: > Be sure I'm not reusing any statement handle without finalizing it. No > leaks, we have a checker in place to detect. But the finalize of a statement > (using the C++ wrapper we build for our use over C SQLite API) is currently > differed

[sqlite] sqlite3_wal_checkpoint_v2() returning SQLITE_LOCKED: in what circumstances?

Richard, Simon, > Le 15 janv. 2016 ? 16:30, Richard Hipp a ?crit : > >> But the finalize of a >> statement (using the C++ wrapper we build for our use over C SQLite API) is >> currently differed until another prepare is done using the same Statement >> object, or until the Statement object goes

[sqlite] Setting SQLITE_OMIT_FLOATING_POINT has surprising undocumented consequences

On Jan 15, 2016, at 3:11 AM, Simon Davies wrote: > > On 14 January 2016 at 22:31, Warren Young wrote: >> >> I rebuild SQLite with SQLITE_OMIT_FLOATING_POINT and ran ran into a bunch of >> breakage: > > http://www.sqlite.org/compile.html#omitfeatures > > SQLITE_OMIT_xxx options "may only be

[sqlite] Using sqlite3.exe as a subprocess

On Jan 14, 2016, at 8:53 PM, Matthew Allen wrote: > >p = subprocess.Popen(["sqlite3.exe", "Database.sqlite"], > stdout=subprocess.PIPE) It looks like you?re trying to use both stdin and stdout, but you really only need stdout here, since sqlite3.exe will accept SQL or sqlite3 shell

[sqlite] sqlite3_wal_checkpoint_v2() returning SQLITE_LOCKED: in what circumstances?

On 15 Jan 2016, at 4:20pm, Olivier Mascia wrote: > I'm only left with the case of a row returning query which the programmer > would not want to step() up to the end. In this case, it is very reasonable > to have the programmer think of "freeing" the query in some way through > either the

[sqlite] Setting SQLITE_OMIT_FLOATING_POINT has surprisingundocumented consequences

Hello ! When we declare SQLITE_OMIT_FLOATING_POINT what really happens is that this is activated (mainly #define double sqlite_int64): /* ** If compiling for a processor that lacks floating point support, ** substitute integer for floating-point */ #ifdef SQLITE_OMIT_FLOATING_POINT # define

[sqlite] Best way to terminate a dead-transaction: commit or rollback?

On Thu, 14 Jan 2016 16:54:04 +0100 Olivier Mascia wrote: > Let a transaction (started with BEGIN TRANSACTION) which did only > reads. Is it any better to end it by COMMIT TRANSACTION or ROLLBACK > TRANSACTION, or is it completely insignificant? Why not do the right thing and remove the begin &

[sqlite] Best way to terminate a dead-transaction: commit or rollback?

On Friday, 15 January, 2016 11:14, James K. Lowden , > On Thu, 14 Jan 2016 16:54:04 +0100 Olivier Mascia wrote: > > Let a transaction (started with BEGIN TRANSACTION) which did only > > reads. Is it any better to end it by COMMIT TRANSACTION or ROLLBACK > > TRANSACTION, or is it completely

[sqlite] Work toward making the schema parsing logic simplier

Hello Richard ! Now that you are refactoring on the schema parsing could be nice if somehow sqlite3 expose the schema/sql parser for developers. A kind of sax style parser, with callbacks given option to do some rewrite/extend syntax ? (ideas welcome) An interesting project can be seem

[sqlite] Best way to terminate a dead-transaction: commit or rollback?

On Fri, Jan 15, 2016 at 7:25 PM, Keith Medcalf wrote: > While it is true that without further action each statement is carried out > in a separate transaction, it may very well be that the OP wants to have > what is called Repeatable-Read. The only way to obtain Repeatable-Read > between

[sqlite] Best way to terminate a dead-transaction: commit or rollback?

... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/attachments/20160115/1962271c/attachment.pgp>

[sqlite] Using sqlite3.exe as a subprocess

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/01/16 19:53, Matthew Allen wrote: > It seems that sqlite3.exe (console) doesn't work as a subprocess > with pipes. There is a bit of a problem with using apps via pipes. Generally when stdout is a terminal, output will be line buffered (ie you

[sqlite] Work toward making the schema parsing logic simplier

On 1/15/16, Domingo Alvarez Duarte wrote: > Now that you are refactoring on the schema parsing could be nice if somehow > sqlite3 expose the schema/sql parser for developers. Note that sqlite3 already exposes most of the schema in a form readable to an application. The SQLITE_MASTER and

[sqlite] Best way to terminate a dead-transaction: commit or rollback?

On Fri, 15 Jan 2016 20:39:15 +0100 Olivier Mascia wrote: > write transactions committed after the read transaction began, are > not seen by that read transaction. Allowing it to have a stable view > on the whole database. As Keith correctly surmised, you need repeatable read. Never having

[sqlite] out of the void: xDlSym

I spent a fair number of hours scrutinizing xDlSym today, and I'd just like to confirm my understanding. Despite having worked with C on and off since the Reagan administration, I was unprepared for void (*(*xDlSym)(sqlite3_vfs*,void*, const char *zSymbol))(void); IIUC xDlSym is a pointer

[sqlite] out of the void: xDlSym

On 1/15/16, James K. Lowden wrote: > I spent a fair number of hours scrutinizing xDlSym today, and I'd just > like to confirm my understanding. Despite having worked with C on and > off since the Reagan administration, I was unprepared for > >void (*(*xDlSym)(sqlite3_vfs*,void*, const char

[sqlite] out of the void: xDlSym

A reason for a function pointer like void (*f)(void) is that C guarantees that all function pointers are 'compatible' in the sense that you can cast a function pointer to a different type of function pointer and then back again and get a working pointer. This is the same guarantee that void*