Re: [sqlite] Automatic index creation for unique columns

On Fri, 16 Dec 2005, Eggert, Henri wrote: > >Hi all, > >Can anyone confirm following ? > >Create table t ( t1 integer primary key , t2 text unique , t3 ... ) >The table is created with 2 indexes : >First index : t1 ( the primary key ) >Second index : t2 because t2 has the attribute unique Being

[sqlite] bug with progress handler and sql functions.

Hello, Using sqlite3_progress_handler with functions in the sql request (like ifnull()) seems to make the nProgressOps (in vdbe.c) not increment properly. Set a sqlite3_progress_handler with a frequency of 10 virtual machine opcodes. The sql request contains 9 calls on ifnull. sqlite3_step never

[sqlite] [ANN] DragonDB - MVB Edition 1.1 Released

Danic Systems releases DragonDB - MVB Edition 1.1 for AppForge MobileVB. EAST BRUNSWICK, NJ, USA (December 16, 2005) -- Danic Systems, LLC announced today availability of an updated version of its DragonDB - MVB Edition product. Release 1.1 is a free update for those with an existing DragonDB

Re: [sqlite] Threads and locking

Have you thought of using a lock to synchronise access to the databaseso that only one thread at a time could change the database although both could read simultaneously? JS Barry Paul wrote: Hi, I am having some unexpected locking issues with SQLite. I have a desktop application that uses

RE: [sqlite] Threads and locking

Yes, but I think that will just lead to the same problem. Essentially that is what SQLite is doing for me already. What is happening is that the high priority user interface thread is waiting for the low priority worker thread to complete its transaction. This effectively is reducing the

RE: [sqlite] Threads and locking

I used to have the same issue. I finally did two things: 1. The background worker thread is at least normal priority. If you own the DB, you need to get in and get out. I put sleeps in to make sure I wasn't hitting the DB too often from this thread 2. All connections to the database happen

Re: [sqlite] Threads and locking

Increasing priority does not speed up anything, it just denies time to lower priority threads. If you use a lock to prevent the background thread from running while you have foreground activity then you won't get a busy situation and your foreground thread will run unimpeded. Having your

Re[2]: [sqlite] Threads and locking

Hello Barry, Essentially, if it might lock ever, it shouldn't be done in the context of the GUI. You may not have run into it yet but, any locking in the GUI is sure to cause deadlocks when things get busy. At least in Microsoft Windows, message handling is all reentrant so, it's very easy to

[sqlite] seem to need write permission on db's parent directory

hi, using sqlite-3.2.7 via the perl module, DBD-SQLite-1.11, from a cgi script via apache on linux on a local filesystem, i received this error: DBD::SQLite::st execute failed: unable to open database file(1) at dbdimp.c line 398 the database, /var/db/mydb/mydb.db, had already been

[sqlite] Re: seem to need write permission on db's parent directory

raf wrote: using sqlite-3.2.7 via the perl module, DBD-SQLite-1.11, from a cgi script via apache on linux on a local filesystem, i received this error: DBD::SQLite::st execute failed: unable to open database file(1) at dbdimp.c line 398 the database was publically writable (for use via

Re: [sqlite] Re: seem to need write permission on db's parent directory

Igor Tandetnik wrote: > raf wrote: > >using sqlite-3.2.7 via the perl module, DBD-SQLite-1.11, > >from a cgi script via apache on linux on a local filesystem, > >i received this error: > > > > DBD::SQLite::st execute failed: unable to open database file(1) at > >dbdimp.c line 398 > > > >the

[sqlite] Can I have access to in-memory DB from different threads?

Hi, all! Can I have access to in-memory DB from two different threads? Best regards, Alexander mailto:[EMAIL PROTECTED]

Re: [sqlite] Can I have access to in-memory DB from different threads?

Both thread would have to use the same sqlite3* handle. And access would have to be protected externally by a mutex or similar. With in-memory databases I don't think there are any problems with using a single handle from multiple threads. With regular databases you can run into trouble doing