[sqlite] sqlite3_interrupt and explicit transactions

I have a few questions about how sqlite3_interrupt interacts with explicit transaction operations. The docs say that "If the interrupted SQL operation is an INSERT, UPDATE, or DELETE that is inside an explicit transaction, then the entire transaction will be rolled back automatically." 1. Can

Re: [sqlite] Handling ROLLBACK

It didn't work correctly because the sequence of commands you sent doesn't make sense. BEGIN; ... RELEASE point1; ... ROLLBACK; ... END; First you began an explicit transaction. Then you tried to release a savepoint that you never created. (Hence the "no such savepoint" error message.) Then

Re: [sqlite] Disk I/O errors

No idea how you would call it from PHP, but the sqlite3_system_errno function may also be of use for determining the underlying cause of the SQLITE_IOERR error code. https://www.sqlite.org/c3ref/system_errno.html -- Sent from: http://sqlite.1065341.n5.nabble.com/

Re: [sqlite] Variable Declaration

What language do you want to use? Parameter binding is a feature of the SQLite C API. So pretty much any language with a C FFI will suffice. There's a list on Wikipedia, not sure how authoritative it is. https://en.wikipedia.org/wiki/SQLite#Programming_language_support (Note: When it says they

Re: [sqlite] Database locking problems

Not sure if this is the problem you are running into, but it might be because SQLite is detecting a potential deadlock. When you just use BEGIN, SQLite will acquire locks lazily - the first read operation will acquire a shared lock, and the first write operation will acquire a reserved lock. Any

[sqlite] sqlite3_open_v2 and sqlite3_prepare_v2 string lifetimes

Is it safe to free the filename string immediately after calling sqlite3_open_v2? What about the zSql string immediately after calling sqlite3_prepare_v2? Will it ever cause any problems (like calling the sqlite3_db_filename or sqlite3_sql methods)? -- Sent from:

Re: [sqlite] Using sqlite3_interrupt with a timeout

Simon Slavin-3 wrote > it can be long only if you're a bad SQL programmer To be fair, the query in question might not get run frequently enough to warrant the overhead of maintaining an index. -- Sent from: http://sqlite.1065341.n5.nabble.com/ ___

Re: [sqlite] Using sqlite3_interrupt with a timeout

Simon Slavin-3 wrote > You can calculate an "end time" yourself, check it each time you're ready > to call sqlite3_step(), and jump straight to sqlite3_finalize() if your > time is up. I'm not familiar with the inner workings of sqlite3_step, but if that itself takes time, then I'd like to

Re: [sqlite] Using sqlite3_interrupt with a timeout

Keith Medcalf wrote > What are you trying to accomplish? Perhaps what you really want is a > progress callback? I'm trying to write a function to run a query with a timeout. If the timeout expires, the query must stop execution within a "reasonable" amount of time. To use a progress callback, it

Re: [sqlite] Using sqlite3_interrupt with a timeout

To be clear, is it sqlite3_step returning SQLITE_DONE that marks it as "not running", or calling sqlite3_reset/sqlite3_finalize? Also, is there any way to mark a statement as "running" other than calling sqlite_step on it? Otherwise, it sounds like I'll have to wait until after sqlite3_step gets

[sqlite] Using sqlite3_interrupt with a timeout

Consider the following pseudo-code. void interrupt_timeout(sqlite3* db, int timeout) { sleep(timeout); sqlite3_interrupt(db); } int main() { sqlite3* db = sqlite3_open_v2(...); sqlite3_stmt* stmt = sqlite3_prepare_v2(db, ...); ... pthread_create(interrupt_timeout, db,

[sqlite] Thread-Safety of Multi-Thread Connection

I have some questions about multi-thread (as opposed to serialized, see https://www.sqlite.org/threadsafe.html) connections. 1. If I have two multi-thread connections that are using a shared cache, is it safe to use those two connections concurrently with each other? 2. Same as (1), but what if

Re: [sqlite] Shared Cache vs. Serialized

Keith Medcalf wrote > See also Write Ahead Logging journal mode (WAL) where in the case you > specified B's operation will succeed even if it is updating a table being > read by connection A. Oh, good to know! For anyone who stumbles across this thread in the future, note that this requires that

Re: [sqlite] Shared Cache vs. Serialized

Jens Alfke-2 wrote > But since the connections are sharing a cache, they still end up seeing > uncommitted writes. I believe this is managed by the read_uncommitted pragma . Another interesting distinction between shared and private

[sqlite] Shared Cache vs. Serialized

I've been reading about the shared cache feature and I have a question. It seems to me that there are two ways we can have multiple threads all accessing a database via a "single" connection. One, establish a single serialized private cache connection up front, and give it to all the threads. Two,