Might i humbly suggest you do this.... 1. user app writes data in CSV format to a file (each user program has a defined datafile name and extension to it now if there is more than 1 file from the same user already in the directory it's extension is made unuiqe - eg user1.1, user1.2, user2.1 etc).
2. you write another program that polls that directory and if a file is found the data is processed and that file then deleted BUT it also handles the reading So if your database "controller" isn't processing a read requst it is processing write's if there are any to be done. this way you have a fudged way of allowing writes to be performed regardless of the backed being tried up with a read operation at the time another user goes to "post" a change. all this i also presume (and it's a big one) is that the reads and writes are not going to take very long (this time frame is the catch - 1sec or 10 milliseconds which is acceptable)? this would give zero config setup of the DB backend but adds a little more complexity in code for the programmer to manage. cheers, dave (a not so novice DB programmer but novice to SQLite). 2009/9/10 Iker Arizmendi <i...@research.att.com> > I'm hopeful that it's possible to devise a scheme that will let SQLite > support > multiple readers and writers while completely preserving all of its current > benefits (eg, serverless, efficient, zero-conf, simple API, small > footprint). > To that end, I'm trying to understand some of the "sub problems" that get > in > the way of multiple writers in order to take a stab at working them out. I > can > see that the overall problem is nontrivial and an acceptable solution has > not > been found. But this only proves that the problem is hard, not that it's > impossible (*). > > Iker > > (*) Of course, if folks have actually shown that solving this problem > amounts to squaring the circle then that's another story. > > Pavel Ivanov wrote: > > > > I just keep wondering: do you want to write some new database engine > > based on SQLite so that it will heed all these caveats? Otherwise this > > discussion is useless because all these features are not implementable > > on top of SQLite and are way nontrivial to implement inside SQLite... > > > > Pavel > > -- > Iker Arizmendi > AT&T Labs - Research > Speech and Image Processing Lab > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
