On 3/14/06, Dave Brown <[EMAIL PROTECTED]> wrote:
> Thanks Jay, but perhaps you could provide some useful links to the reading
> material you suggest instead of just stating what you think I need to do?
I tried to be helpful and point out where to start.
The encyclopedia is in front of you, but yo
Thanks Jay, but perhaps you could provide some useful links to the reading
material you suggest instead of just stating what you think I need to do?
For example, http://www.sqlite.org/lockingv3.html provides only minimal
information on the lock types in Sqlite3.
At any rate, I do understand what i
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
> say I don't see why I need to do this. Perhaps the implicit transaction
> which is created in my 1-line INSERT statement isn't an immediate
> transaction??
>
> Seems lik
Yeah if I put BEGIN IMMEDIATE in thread1 as well, then it works, but as you
say I don't see why I need to do this. Perhaps the implicit transaction
which is created in my 1-line INSERT statement isn't an immediate
transaction??
Seems like there should be a flag or pragma or something to force all
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 "BEGIN IMMEDIATE" statement. So I then put that
in a
do-while( rc == SQLITE_BUSY) loop, and now my first thread is getting
SQLITE_BUSY returned when it tries to e
5 matches
Mail list logo