Re: [sqlite] Validating a file is a SQLite DB

Unless they are encrypted using the encryption extension... On Thu, Apr 23, 2009 at 4:46 PM, Tommy Ocel wrote: > Great. Thanks for the tip. > > > On 4/23/09 4:24 PM, "Igor Tandetnik" wrote: > > Tommy Ocel wrote: > > Other than using

Re: [sqlite] step() fails with SQLITE_BUSY after BEGIN EXCLUSIVE TRANSACTION

Wow this sounds exactly like my post of a few days ago titled "Strange sqlite_busy deadlock behavior". On Sat, Apr 11, 2009 at 7:11 AM, wrote: > Hi, > > I'm using the latest amalgation of sqlite on Windows NTFS, compiled with > SQLITE_THREADSAFE=1, from Visual C++. > > I have

Re: [sqlite] Strange sqlite_busy deadlock behavior

Each thread has it's own connection handle (stated this in the original email). anyone want to see a stack trace? On Wed, Apr 8, 2009 at 2:22 PM, Lawrence Gold <lawrence.g...@gmail.com>wrote: > On Apr 8, 2009, at 3:12 PM, Dave Brown wrote: > > > Thread A is in the pr

Re: [sqlite] Strange sqlite_busy deadlock behavior

e longer than a few millisecs at most. >> >> Any thoughts on my latest test with the begin exclusive method? >> >> On 4/8/09, Griggs, Donald <donald.gri...@allscripts.com> wrote: >>> >>> >>> -Original Message- >>> From: sqlite-us

Re: [sqlite] Strange sqlite_busy deadlock behavior

sqlite.org] On Behalf Of Dave Brown > Sent: Wednesday, April 08, 2009 1:16 PM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] Strange sqlite_busy deadlock behavior > > I tried the BEGIN EXCLUSIVE method, but now the problem is that thread-A > is in the middle

Re: [sqlite] Strange sqlite_busy deadlock behavior

4/8/09, D. Richard Hipp <d...@hwaci.com> wrote: > > On Apr 8, 2009, at 2:13 AM, Dave Brown wrote: > >> But why is this deadlocking at all? I thought there shouldn't be a >> problem doing this, especially since thread B is using a transaction. >> Shouldn't either

Re: [sqlite] Strange sqlite_busy deadlock behavior

gt; On Apr 7, 2009, at 8:57 PM, Dave Brown wrote: > >> I do finalize it - the steps I wrote were just pseudocode, but yes >> after the >> thread-A statement executes I call finalize ( or reset if I'm going >> to use >> it again ). The problem is that thread-A *never*

[sqlite] Strange sqlite_busy deadlock behavior

I am seeing the equivalent of a deadlock, with SQLITE_BUSY being returned forever from my code which has 2 threads using SQLite. I can repro this at will. Each thread is using it's own connection to the sqlite database, so they are not sharing the same connection. Here is what is happening in

Re: [sqlite] Problems with file locks on USB keys

t;n...@nobswolf.info> wrote: > On Thu, Apr 02, 2009 at 08:20:38PM -0700, Dave Brown wrote: > > Our software often runs into problems when run on USB keys. Specifically, > > calls to sqlite to read/write to the database hang infinitely, or return > > Does it work on harddisk? > >

[sqlite] Problems with file locks on USB keys

Our software often runs into problems when run on USB keys. Specifically, calls to sqlite to read/write to the database hang infinitely, or return SQLITE_BUSY after even 10 seconds of waiting. The problem seems to be that the database file gets locked and remains locked, presumably by some problem

Re: [sqlite] FTS and upgrades

ng all the content data across to fts2). [Let me know if I misread your question.] -scott On 7/6/07, Dave Brown <[EMAIL PROTECTED]> wrote: > Right, but what I'm asking is: > > If version 1.0 of my program uses Sqlite with *only* fts1, and then I > upgrade users to version 2.0 of my

Re: [sqlite] FTS and upgrades

without crashing the program? Thanks again! On 7/5/07, Dan Kennedy <[EMAIL PROTECTED]> wrote: On Thu, 2007-07-05 at 21:08 -0700, Dave Brown wrote: > I am considering using FTS for a new feature. My question is: > > - If I use fts1 (or fts2) now, and then a new version of fts

[sqlite] FTS and upgrades

I am considering using FTS for a new feature. My question is: - If I use fts1 (or fts2) now, and then a new version of fts comes out which is not backwards compatible, will I at least be able to upgrade users by simply deleting the old FTS table and re-building it using the new FTS system? In

Re: [sqlite] 3.3.17 Source code ZIP file missing most files?

Aha, got it. Thanks! On 5/7/07, Trey Mack <[EMAIL PROTECTED]> wrote: > The 3.3.17 ZIP file seems to only contain 2 source files, instead of the > full SQLite source. Is this on purpose? It is the full source. See http://www.sqlite.org/cvstrac/wiki?p=TheAmalgamation and a big ol' thread at

[sqlite] 3.3.17 Source code ZIP file missing most files?

The 3.3.17 ZIP file seems to only contain 2 source files, instead of the full SQLite source. Is this on purpose? http://www.sqlite.org/sqlite-source-3_3_17.zip Thanks, Dave

Re: [sqlite] Re: Re: Multithreaded SQLITE_BUSY not handled?

(executed without a formal transaction wrapper) to also be begin-immediate. -Dave On 3/14/06, Jay Sprenkle <[EMAIL PROTECTED]> wrote: > > On 3/13/06, Dave Brown <[EMAIL PROTECTED]> wrote: > > Yeah if I put BEGIN IMMEDIATE in thread1 as well, then it works, but as > you >

Re: [sqlite] Re: Re: Multithreaded SQLITE_BUSY not handled?

transactions to be immediate. -Dave On 3/13/06, Igor Tandetnik <[EMAIL PROTECTED]> wrote: > > Dave Brown <[EMAIL PROTECTED]> wrote: > > Igor - ok I tried this, and now I am getting SQLITE_BUSY returned > > when I try > > to sqlite3_exec my "B

Re: [sqlite] Re: Multithreaded SQLITE_BUSY not handled?

3/06, Igor Tandetnik <[EMAIL PROTECTED]> wrote: > > Dave Brown <[EMAIL PROTECTED]> wrote: > > Hi all - I am seeing a strange problem where I have multiple threads > > trying to both do writes to the database, and one thread gets back an > > immediate SQLITE_BUSY even tho

[sqlite] Multithreaded SQLITE_BUSY not handled?

Hi all - I am seeing a strange problem where I have multiple threads trying to both do writes to the database, and one thread gets back an immediate SQLITE_BUSY even though *both* have set the busy handler to 10 seconds, and the write operation is much much faster than this (on the order of