RE: [sqlite] sqlite with eVC++

2003-11-22 Thread Nuno Lucas
=== On 2003-11-21, Clark, Chris wrote === .. >Check out http://sqlite-wince.sourceforge.net/ its not been updated in a while so its >the 2.80 version. > >Good luck, > >Chris Just a small correction, the sqlite-wince release uses the last stable sqlite version (version 2.8.6). What needs to be

[sqlite] PHP, queries between databases and network

2003-11-22 Thread Bronislav Klučka
Hi, I've got few questions: 1/ I've got sqlite like PHP module (under windows). I tried this: a)execute script 1 (selecting from some table), it tooks 2 minutes b)execute script 2 , it tooks 3 minutes c)execute them both at the same time (from different browser windows),

Re: [sqlite] Improving concurrency in SQLite

2003-11-22 Thread Gerry Snyder
D. Richard Hipp wrote: Feedback is requested on the paper found at: Richard, SQLite is one of my favorite examples of good open-source s/w. I read (with great interest) your paper, and would not have a problem with any of the proposals being implemented. All would have some benefits. However,

Re: [sqlite] Improving concurrency in SQLite

2003-11-22 Thread Doug Currie
My uses of SQLite are multithreaded (mostly) single process. So, an approach that would appeal to me is "client-server" where the server is a thread in my process, and the clients are other threads. Adding a lock manager to the server thread would permit fine grained locking with ACID properties.

Re: [sqlite] Improving concurrency in SQLite

2003-11-22 Thread Mrs. Brisby
This is more rambling than anything else. I hope I'm reasonably coherent before coffee... Instead of keeping an "undo" journal- consider using a "changes" journal-- each writer could use it's own journal then only at commit would each worker actually start making changes to the database.

Re: [sqlite] Improving concurrency in SQLite

2003-11-22 Thread Richard Heyes
> Feedback is requested on the paper found at: > > http://www.sqlite.org/concurrency.html > > Your analysis and ideas will help to make SQLite a > better database engine. Thanks. In my somehwhat limited knowledge of database design, I'd advocate all the options in section 4 (ie transaction