On 5/24/2012 10:17 PM, Andrew Cherednik wrote:
Thanks guys. You really helped me. I think I know what I am going to do. You
see, as I am using a single connection object there is at least one selection
statement executed at the beginning of each process. Then, during the program
lifecycle
Thanks guys. You really helped me. I think I know what I am going to do. You
see, as I am using a single connection object there is at least one selection
statement executed at the beginning of each process. Then, during the program
lifecycle there could be a few updates executed, that use the
Also it suggests that transaction was began as read-only (with a
select statement) and then there was attempt to transform it to a
writing transaction (with insert, update or delete statement) when
there was another writing transaction in progress waiting for this
transaction to finish.
and
On 25 May 2012, at 2:52am, Pavel Ivanov wrote:
> Also it suggests that transaction was began as read-only (with a
> select statement) and then there was attempt to transform it to a
> writing transaction (with insert, update or delete statement) when
> there was another
On Thu, May 24, 2012 at 9:48 PM, Simon Slavin wrote:
>
> On 25 May 2012, at 2:45am, Andrew Cherednik
> wrote:
>
>> Tried different timeouts. The timeouts will basically make the program hang,
>> but eventually the transaction will end
On 5/24/2012 9:41 PM, Andrew Cherednik wrote:
On 5/24/2012 11:36 AM, Igor Tandetnik wrote:
Before first select. Use BEGIN IMMEDIATE instead of regular BEGIN, to start the
transaction.
Thanks. Will do. Do you still believe I need to get rid of the global
connection object?
What do you
On 25 May 2012, at 2:45am, Andrew Cherednik
wrote:
> Tried different timeouts. The timeouts will basically make the program hang,
> but eventually the transaction will end with SQLITE_BUSY error.
Hmm. _BUSY with a timeout of 13 seconds suggests an
On 5/24/2012 11:35 AM, Simon Slavin wrote:
> On 5/24/2012 9:06 PM, Igor Tandetnik wrote:
>
>> What exactly do you mean by "database lockout problems"? What error in what
>> API call are you getting?
>
> I am getting SQLITE_BUSY error very often, and it does not go away, as if the
> database is
On 5/24/2012 11:36 AM, Igor Tandetnik wrote:
> Before first select. Use BEGIN IMMEDIATE instead of regular BEGIN, to start
> the transaction.
Thanks. Will do. Do you still believe I need to get rid of the global
connection object?
___
sqlite-users
On 5/24/2012 9:27 PM, Andrew Cherednik wrote:
Do you use explicit transactions? If yes, do any of those follow the pattern
where you start with a SELECT, and then perform an INSERT or UPDATE or DELETE
(in other words, a transaction starts as a
reader, and then wants to upgrade to a writer)?
On 25 May 2012, at 2:13am, Andrew Cherednik
wrote:
> On 5/24/2012 9:06 PM, Igor Tandetnik wrote:
>
>> What exactly do you mean by "database lockout problems"? What error in what
>> API call are you getting?
>
> I am getting SQLITE_BUSY error very often,
> I believe from the description that this is one single threaded application
> per computer, for N computers, each using a single connection object pointing
> to the same database file on a remote filesystem.
> Therefore, each database access is locking out all the others. Multiple
>
> Are you resetting your prepared statements?
I believe I am resetting all the statements.
> Do you use explicit transactions? If yes, do any of those follow the pattern
> where you start with a SELECT, and then perform an INSERT or UPDATE or DELETE
> (in other words, a transaction starts as a
On 5/24/2012 9:13 PM, Andrew Cherednik wrote:
On 5/24/2012 9:06 PM, Igor Tandetnik wrote:
Actually, scratch that. Multiple statements running on the same connection will
never lock each other out. Are multiple instances of your application running
at the same time, connecting to the
same
I believe from the description that this is one single threaded application per
computer, for N computers, each using a single connection object pointing to
the same database file on a remote filesystem.
Therefore, each database access is locking out all the others. Multiple
connections will
On 5/24/2012 9:06 PM, Igor Tandetnik wrote:
> Actually, scratch that. Multiple statements running on the same connection
> will never lock each other out. Are multiple instances of your application
> running at the same time, connecting to the
> same database?
Yes, they are connecting to the
On 5/24/2012 9:06 PM, Igor Tandetnik wrote:
On 5/24/2012 8:55 PM, Andrew Cherednik wrote:
The program is a multi-user program that runs across the network in
Windows environment. The users constantly experience database lockout
problems. I suspect that it is due to the fact that the sqlite*
On 5/24/2012 8:55 PM, Andrew Cherednik wrote:
The program is a multi-user program that runs across the network in Windows
environment. The users constantly experience database lockout problems. I
suspect that it is due to the fact that the sqlite* object that has been used
for database
On 25 May 2012, at 1:55am, Andrew Cherednik
wrote:
> The program is a multi-user program that runs across the network in Windows
> environment. The users constantly experience database lockout problems. I
> suspect that it is due to the fact that the
19 matches
Mail list logo