On 8/22/06, Christian Smith <[EMAIL PROTECTED]> wrote:
Laura Longo uttered:
>
>
>> On 8/21/06, Laura Longo <[EMAIL PROTECTED]> wrote:
>>> I've tried also executing the query "begine exclusive" before the
>>> "update",
>>> and "commit" to end the entire routine, and the query that now returns the
>>> exit code 5 (database locked) is "begin exclusive", I don't know if this
>>> can be meaningful...
>>
>> It sounds like some other application has locked the database file.
>> Do you have a virus scanner? This can sometimes cause problems.
>> It will lock the file you use for the database.
>
> My applications are running under Linux (CentOS, kernel 2.6.16) and I have no
> virus scanner.
Try using sqlite3_busy_timeout(), to get round the temporary locks if
possible. SQLite will retry locked database access until the command
either succeeds or times out.
She already has a nice variable delay retry in her code.
As long as she seeds the random number generator with a different
seed for each process It should eliminate problems with synchronized
retry collisions.
http://www.sqlite.org/capi3ref.html#sqlite3_busy_timeout
If this does not fix your problem, it is possible that an application has
a read lock permanently open. Check that your readers are not doing a
begin without a commit.
That was my thought too. It sounds like something else has the file
locked.
Laura is there a backup program that might be reading your database
and locking it?
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
