Keep It Simple, Keep It Small Foot Print.
If the multi-access, multi writter can be implemented without compromising
these two tenets, then great. Otherwise, let's use a different RDBMS.
Regards,
Uriel_Carrasquilla
jed
<[EMAIL PROTECTED]> To:
sqlite-users@sqlite.org
cc:
03/13/2005 09:33 Subject: [sqlite] Re:
[unclassified] Re: [sqlite] getting rid of dirty SQLITE_BUSY
PM workaround
Please respond to
sqlite-users
I like sqlite for it's simplicity in administration, small footprint, and
reliability, this coupled with a very robust implementation of SQL. a lot
embedded and web applications fit well into the model of "many readers, one
writer", sqlite does this very well. Applications that need many concurrent
tasks doing updates might think about using a server based RDBMS that has
the added complexity and size for this purpose.
All this said ...
It might me nice to have an option where you can have sqlite "wait
forever" might be nice to implement as a pragma. the downside is that ...
well things might wait for a very long time and appear to hang.
Just an idea,
Jim Dodgen
At 06:01 PM 3/13/2005, you wrote:
>On Sun, 2005-03-13 at 16:49 -0500, D. Richard Hipp wrote:
> > On Sun, 2005-03-13 at 21:56 +0100, Thomas Lotterer wrote:
> >
> > > I cannot believe it is normal behavior of a database application
running
> > > on a multitasking operating system to assume there will only be one
> > > writer and otherwise let the application fail or do retries by
itself.
> > >
> >
> > I'll look into it.
> >
>
>http://www.sqlite.org/cvstrac/chngview?cn=2385
>
>--
>D. Richard Hipp <[EMAIL PROTECTED]>
