Re: [sqlite] SQLITE_BUSY, database is locked in "PRAGMA journal_mode"

On 9/4/19, Simon Slavin wrote: > On 4 Sep 2019, at 12:39pm, test user wrote: > >> Is it normal to get a `SQLITE_BUSY_RECOVERY` > > This code should only ever follow a crash, Just to be clear, "crash" in the above statement can also mean "program exits without calling sqlite3_close()". -- D.

Re: [sqlite] SQLITE_BUSY, database is locked in "PRAGMA journal_mode"

On 4 Sep 2019, at 12:39pm, test user wrote: > Is it normal to get a `SQLITE_BUSY_RECOVERY` This code should only ever follow a crash, or some operation which has corrupted a database. If your hardware does not crash you should never see it. Something is wrong.

Re: [sqlite] SQLITE_BUSY, database is locked in "PRAGMA journal_mode"

Thanks Rowan, this is useful. Is it normal to get a `SQLITE_BUSY_RECOVERY` response from an API when: - No processes have crashed. - All API uses close/finalize their db/stmt objects. I am testing some code I wrote to make sure it retires on BUSY by creating many processes that acquire locks

Re: [sqlite] SQLITE_BUSY, database is locked in "PRAGMA journal_mode"

On Fri, 30 Aug 2019 at 04:18, test user wrote: > B. Is there any method for determining lock transitions for connections? > - Is there an API? > - Would it be possible to use dtrace to instrument SQLite to detect > lock transitions? > - Where should I be looking? > On unix

Re: [sqlite] SQLITE_BUSY, database is locked in "PRAGMA journal_mode"

Just some more details to clarify the issue: If I do a `BEGIN IMMEDIATE` on one connection, and then a `PRGAMA journal_mode` on another, BUSY is not returned (as expected). But if I have around 7 connections contending for a write lock via `BEGIN IMMEDIATE`, and a different connection runs

[sqlite] SQLITE_BUSY, database is locked in "PRAGMA journal_mode"

Hello, Im getting this message in the log: `SQLITE_BUSY, database is locked in "PRAGMA journal_mode"` I get this response when running the query `PRAGMA journal_mode`. The file is in journal_mode=WAL. Another connection holds a write transaction. Seeing as `PRAGMA journal_mode` is just a

Re: [sqlite] SQLITE_BUSY (SQLITE_BUSY_SNAPSHOT) due to a simple SELECT query -- Documentation needed!

> On Aug 12, 2019, at 12:34 AM, Kira Backes wrote: > > Our code base does not use > transactions at all (we have a segmented code base protected by > mutexes for a whole section, so reads/writes do not conflict ever). This will really hurt performance of multiple writes, since each write

Re: [sqlite] SQLITE_BUSY (SQLITE_BUSY_SNAPSHOT) due to a simple SELECT query -- Documentation needed!

Thank you very much, I hope my example which probably many users tap into unknowingly might help :-) mit freundlichen Grüßen, Kira Backes On Mon, 12 Aug 2019 at 12:58, Richard Hipp wrote: > > The documentation on transactions at > https://www.sqlite.org/lang_transaction.html was written long,

Re: [sqlite] SQLITE_BUSY (SQLITE_BUSY_SNAPSHOT) due to a simple SELECT query -- Documentation needed!

The documentation on transactions at https://www.sqlite.org/lang_transaction.html was written long, long ago, apparently long before WAL mode was available, and is in serious need of updating and improvement. I'm working on that now -- D. Richard Hipp d...@sqlite.org

Re: [sqlite] SQLITE_BUSY (SQLITE_BUSY_SNAPSHOT) due to a simple SELECT query -- Documentation needed!

Thank you Rowan, in the context of *locks* it is kinda documented, but not in the context of transactions :( Just have a look at the error description: https://www.sqlite.org/rescode.html#busy_snapshot > The SQLITE_BUSY_SNAPSHOT error code is an extended error code for SQLITE_BUSY > that

Re: [sqlite] SQLITE_BUSY (SQLITE_BUSY_SNAPSHOT) due to a simple SELECT query -- Documentation needed!

On Mon, 12 Aug 2019 at 16:55, Kira Backes wrote: > > When you do not use explicit transactions, SQLite will automatically > create implicit transactions. > > But the documentation only says that an implicit transaction is > created for data-changing queries like INSERT: > >

Re: [sqlite] SQLITE_BUSY (SQLITE_BUSY_SNAPSHOT) due to a simple SELECT query -- Documentation needed!

> When you do not use explicit transactions, SQLite will automatically create > implicit transactions. But the documentation only says that an implicit transaction is created for data-changing queries like INSERT: https://www.sqlite.org/lang_transaction.html > Any command that changes the

Re: [sqlite] SQLITE_BUSY (SQLITE_BUSY_SNAPSHOT) due to a simple SELECT query -- Documentation needed!

Kira Backes wrote: > Our code base does not use transactions at all When you do not use explicit transactions, SQLite will automatically create implicit transactions. says: | An implicit transaction (a transaction that is started automatically, |

[sqlite] SQLITE_BUSY (SQLITE_BUSY_SNAPSHOT) due to a simple SELECT query -- Documentation needed!

Dear sqlite mailing list, I had to spend 2 days debugging a SQLITE_BUSY_SNAPSHOT, and reading the documentation did not help me. Our code base does not use transactions at all (we have a segmented code base protected by mutexes for a whole section, so reads/writes do not conflict ever). We

[sqlite] SQLITE_BUSY/SQLITE_LOCKED

Hi, I just thought I'd point out something that confused me, in the hope of helping others. from the source, where the constants are defined: #define SQLITE_BUSY 5 /* The database file is locked */ #define SQLITE_LOCKED 6 /* A table in the database is locked */ and from

Re: [sqlite] SQLITE_BUSY on rare occasions, single thread, single connection

- You have another open operation or transaction which has not been committed or finalized or in some way completed. If I only have one connection, there can't be another uncommitted transaction? Well there can be, which would cause a BUSY signal. Unless you've had success beginning the new

Re: [sqlite] SQLITE_BUSY on rare occasions, single thread, single connection

Thank you all very much for your answers.. On Mon, Jul 22, 2013 at 9:07 AM, RSmith wrote: > - You have another open operation or transaction which has not been > committed or finalized or in some way completed. If I only have one connection, there can't be another

Re: [sqlite] SQLITE_BUSY on rare occasions, single thread, single connection

On 22 Jul 2013, at 7:28am, Jesper Baekdahl wrote: > there should not be anything holding a > lock. Please check the return values of all the sqlite3_ API calls before the one which is getting SQLITE_BUSY, even those which are apparently working. For instance, do not do

Re: [sqlite] SQLITE_BUSY on rare occasions, single thread, single connection

On Mon, Jul 22, 2013 at 3:48 PM, Simon Slavin wrote: > assert(sqlite3_finalize(S) == SQLITE_OK) > Nononono - in non-debug builds assert() is compiled out, so the above disappears. (Been there, done that!) -- - stephan beal

Re: [sqlite] SQLITE_BUSY on rare occasions, single thread, single connection

Hi Jesper, the code you posted is not the offending code, it's just the symptom of a problem happening somewhere else. We will need to see the other operations also done by the DB code to know what goes on with it, but from some experiences on the list the following is likely: - You have

[sqlite] SQLITE_BUSY on rare occasions, single thread, single connection

Hey everybody. I'm getting SQLITE_BUSY on sqlite_step on insert statement, that is part of an explicit transaction of multiple statements. There is only 1 thread and 1 connection, so there should not be anything holding a lock. It does not happen very often, so I'm having a hard time debugging

Re: [sqlite] SQLITE_BUSY exceptions

On 9 May 2012, at 12:15am, Cyndy Koobs wrote: > I am using SQLite with hibernate 4.1.0 (multithreaded but not heavily > loaded). I am frequently getting SQLITE_BUSY exceptions. Have you set a SQLite timeout ? The default is zero, which means that any contention will

[sqlite] SQLITE_BUSY exceptions

I am using SQLite with hibernate 4.1.0 (multithreaded but not heavily loaded). I am frequently getting SQLITE_BUSY exceptions. When the database is created, is the journal mode default WAL? What is the default size of the journal? What is the default threading mode when compiled? If I

Re: [sqlite] SQLITE_BUSY

On 26 Nov 2011, at 4:00pm, Jean-Christophe Deschamps wrote: >> So I make up for it by using an 'exec' which executes only the first >> command, and by hashing the command so that tampering with it would make it >> fail the hash. > > AFAIK sqlite3_exec will hapilly prepare and run more than

Re: [sqlite] SQLITE_BUSY

So I make up for it by using an 'exec' which executes only the first command, and by hashing the command so that tampering with it would make it fail the hash. AFAIK sqlite3_exec will hapilly prepare and run more than one statements in a row. I use it all the time. But there's no reason

Re: [sqlite] SQLITE_BUSY

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/11/11 02:07, joel.bertr...@external.gdfsuez.com wrote: > If sqlite3_step() returns BUSY_TIMEOUT, I try to restart statement : > > While((result = sqlite3_step(stmt)) == SQLITE_BUSY) { Usleep(_random > [0s, 1s[_); } Is there any particular

Re: [sqlite] SQLITE_BUSY

And it's convenient to be able to do the prepare during startup. I've just never had to worry about this situation. It means you have to do special handling for the first _step, but it's a reasonably compact way of handling the potential problem. I can't use prepared statements in

Re: [sqlite] SQLITE_BUSY

On 26 Nov 2011, at 2:29pm, Jean-Christophe Deschamps wrote: > Hi Simon, > >> Ah, so it's the first _step which does the locking, rather than the _prepare. > > That makes sense to me. If I had a serious application using, say, a hundred > of different prepared queries, I'd rather

Re: [sqlite] SQLITE_BUSY

Hi Simon, Ah, so it's the first _step which does the locking, rather than the _prepare. That makes sense to me. If I had a serious application using, say, a hundred of different prepared queries, I'd rather batch-prepare them all up front then use them when needed without asking question.

Re: [sqlite] SQLITE_BUSY

On 26 Nov 2011, at 2:15pm, Pavel Ivanov wrote: > On Sat, Nov 26, 2011 at 9:03 AM, Simon Slavin wrote: >> On 26 Nov 2011, at 2:00pm, Pavel Ivanov wrote: >> >>> When sqlite3_step returned SQLITE_BUSY you have to call sqlite3_reset >>> before calling sqlite3_step again. >>

Re: [sqlite] SQLITE_BUSY

On Sat, Nov 26, 2011 at 9:03 AM, Simon Slavin wrote: > On 26 Nov 2011, at 2:00pm, Pavel Ivanov wrote: > >> When sqlite3_step returned SQLITE_BUSY you have to call sqlite3_reset >> before calling sqlite3_step again. > > If your statement is a SELECT returning 50 rows, and

Re: [sqlite] SQLITE_BUSY

If your statement is a SELECT returning 50 rows, and you've already read 20 of them by the time you get the _BUSY, do you get the first 20 again after doing the _reset ? I don't believe we can get _BUSY in the middle of a SELECT. Am I wrong?

Re: [sqlite] SQLITE_BUSY

On 26 Nov 2011, at 2:00pm, Pavel Ivanov wrote: > When sqlite3_step returned SQLITE_BUSY you have to call sqlite3_reset > before calling sqlite3_step again. If your statement is a SELECT returning 50 rows, and you've already read 20 of them by the time you get the _BUSY, do you get the first 20

Re: [sqlite] SQLITE_BUSY

> While((result = sqlite3_step(stmt)) == SQLITE_BUSY) > { >                Usleep(_random [0s, 1s[_); > } When sqlite3_step returned SQLITE_BUSY you have to call sqlite3_reset before calling sqlite3_step again. So your loop should look like this: While((result = sqlite3_step(stmt)) ==

[sqlite] SQLITE_BUSY

I have two threads in a Linux process using sqlite 3.6.12 in shared cache mode. One thread opens the database file in read only mode (sqlite3_open_v2()), sets to read uncommitted and only ever performs selects from the database. The other thread inserts, updates and deletes rows from the

Re: [sqlite] SQLITE_BUSY

General suggestion to you, Mark, would be change your database engine, use something else than SQLite. Application that continuously writing to the database thousands of rows (what size database can reach with it, I wonder?) from one process and tries to read from another process is DOA with

Re: [sqlite] SQLITE_BUSY

On 26 Oct 2009, at 8:21am, Mark Flipphi wrote: > Now an other application is running on a desktop pc and opens the > database from the server harddisk (shared drive) Please verify for us that it's using a standard Windows shared folder. This tells us how the sharing is achieved. > We need

[sqlite] SQLITE_BUSY

Hello, We have a sqlite database that is used to strore measurement data. One application is on a server and is continuous storing data to the database. We use : BEGIN INSERT INSERT COMMIT The commit is called when there are more then 100.000 inserts or 1 second has elapsed. Now an

[sqlite] SQLITE_BUSY on a remote server host

Hello, as a beginning SQlite user, I'm trying to build a simple request counter for a web site on top of SQlite (version 3.6.6.2). I started off with the following simple and unfinished test code, which works fine on my home computer (Ubuntu 9.04), but on our hosted server I always get an error

Re: [sqlite] SQLITE_BUSY question

Oops, I RTFMed poorly. Thanks for the help. :-) Dennis Cote wrote: > George Ryan wrote: > >> Hello. I'm a first-time sqlite user, and I have a question. I'm using >> the C/C++ API as shown in the code below, and the sqlite3_step() >> function always seems to return SQLITE_BUSY for me. I'm

Re: [sqlite] SQLITE_BUSY question

Nope, it's a local ext3 filesystem. D. Richard Hipp wrote: > On Jul 9, 2008, at 11:00 AM, George Ryan wrote: > > >> Hello. I'm a first-time sqlite user, and I have a question. I'm using >> the C/C++ API as shown in the code below, and the sqlite3_step() >> function always seems to return

Re: [sqlite] SQLITE_BUSY question

George Ryan wrote: > Hello. I'm a first-time sqlite user, and I have a question. I'm using > the C/C++ API as shown in the code below, and the sqlite3_step() > function always seems to return SQLITE_BUSY for me. I'm not sure what I > am doing wrong. I'm running on Ubuntu 8.04, and I don't have

Re: [sqlite] SQLITE_BUSY question

On Jul 9, 2008, at 11:00 AM, George Ryan wrote: > Hello. I'm a first-time sqlite user, and I have a question. I'm using > the C/C++ API as shown in the code below, and the sqlite3_step() > function always seems to return SQLITE_BUSY for me. I'm not sure > what I > am doing wrong. I'm running

[sqlite] SQLITE_BUSY question

Hello. I'm a first-time sqlite user, and I have a question. I'm using the C/C++ API as shown in the code below, and the sqlite3_step() function always seems to return SQLITE_BUSY for me. I'm not sure what I am doing wrong. I'm running on Ubuntu 8.04, and I don't have any multiple threads or

[sqlite] SQLITE_BUSY frequent error

Hello! I have an application that will try to access an sqlite database for some database operations such as selecting, deleting, inserting, and/or updating records. This application spawns some children that will also do the same transactions to the database. I have developed a locking

Re: [sqlite] SQLITE_BUSY returned from sqlite3_finalize

On Fri, 9 May 2008 09:09:03 -0500, "Jay A. Kreibich" <[EMAIL PROTECTED]> said: > On Thu, May 08, 2008 at 11:39:17AM -0700, [EMAIL PROTECTED] scratched > on the wall: > > If I run the following code I get some unexpected results: > > > >sqlite3* db1_p = 0; > >const

Re: [sqlite] SQLITE_BUSY returned from sqlite3_finalize

On Thu, May 08, 2008 at 11:39:17AM -0700, [EMAIL PROTECTED] scratched on the wall: > If I run the following code I get some unexpected results: > >sqlite3* db1_p = 0; >const int open1Res = sqlite3_open16(L"test.db", _p); >sqlite3* db2_p = 0; >

[sqlite] SQLITE_BUSY returned from sqlite3_finalize

If I run the following code I get some unexpected results: sqlite3* db1_p = 0; const int open1Res = sqlite3_open16(L"test.db", _p); sqlite3* db2_p = 0; const int open2Res = sqlite3_open16(L"test.db", _p); sqlite3_stmt*

Re: [sqlite] SQLITE_BUSY retry

ovember 29, 2007 1:34 am Subject: Re: [sqlite] SQLITE_BUSY retry > You could use a BEGIN IMMEDIATE to lock the DB before you launch > the > transaction and loop on SQLITE_BUSY or use the plain BEGIN which > will > allow reads during the transaction and not lock the DB until

Re: [sqlite] SQLITE_BUSY retry

nal Message From: John Stanton <[EMAIL PROTECTED]> To: sqlite-users@sqlite.org Sent: Wednesday, November 28, 2007 12:04:34 PM Subject: Re: [sqlite] SQLITE_BUSY retry You could use a BEGIN IMMEDIATE to lock the DB before you launch the transaction and loop on SQLITE_BUSY or use the pl

Re: [sqlite] SQLITE_BUSY retry

AIL PROTECTED]> To: sqlite-users@sqlite.org Sent: Wednesday, November 28, 2007 12:04:34 PM Subject: Re: [sqlite] SQLITE_BUSY retry You could use a BEGIN IMMEDIATE to lock the DB before you launch the transaction and loop on SQLITE_BUSY or use the plain BEGIN which will allow reads

Re: [sqlite] SQLITE_BUSY retry

to issue the "END" transaction again or What should I do in this case to handle SQLITE_BUSY. Thanks a lot in advance for the help or advice. JP - Original Message From: Joanne Pham <[EMAIL PROTECTED]> To: sqlite-users@sqlite.org Sent: Wednesday, November 28, 2007 11

Re: [sqlite] SQLITE_BUSY retry

ND" transaction again or What should I do in this case to handle SQLITE_BUSY. Thanks a lot in advance for the help or advice. JP - Original Message From: Joanne Pham <[EMAIL PROTECTED]> To: sqlite-users@sqlite.org Sent: Wednesday, November 28, 2007 11:27:52 AM Subject: [sql

[sqlite] SQLITE_BUSY retry

Hi All, I have used "BEGIN" and "END" Transaction to insert the data to SQLite database. BEGIN insert ... insert ... END When I issued the "END" operation the error message return back is "SQLITE_BUSY". What should I do if I want to handle SQLITE_BUSY /retry the

Re: [sqlite] SQLITE_BUSY error in multi-threaded environment

I came across some OS's over the years which implemented file locks as a single global lock. Yours may do that. Mark Brown wrote: Hi John- There is a .lock file for each database. From my understanding, that should prohibit 2 connections from using the same database at the same time.

RE: [sqlite] SQLITE_BUSY error in multi-threaded environment

"As recommended, BEGIN IMMEDIATE should prevent thread2 from even starting a transaction if thread1 did so first, however I think this will only work correctly if the same connection handle is used in both, else they still may not know about eachother." Simply not true... If you

RE: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment

If they are different files then you should not have any of these problems. -Original Message- From: RaghavendraK 70574 [mailto:[EMAIL PROTECTED] Sent: 16 August 2007 11:21 AM To: sqlite-users@sqlite.org Subject: Re: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment hi, Am

Re: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment

<[EMAIL PROTECTED]> Date: Thursday, August 16, 2007 4:36 pm Subject: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment > Ok well I guess I forgot to mention this is what has made me want to > pull my hair out a few times :) the fact that you have to worry about > both sc

RE: [sqlite] SQLITE_BUSY error in multi-threaded environment

Hope this helps -Original Message- From: Mark Brown [mailto:[EMAIL PROTECTED] Sent: 15 August 2007 04:34 PM To: sqlite-users@sqlite.org Subject: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment Hi Andre- After rereading your post, I wanted to confirm something. In your example

RE: [sqlite] SQLITE_BUSY error in multi-threaded environment

ust 15, 2007 12:39 PM > To: sqlite-users@sqlite.org > Subject: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment > > > It should not. > > As long as those two connections are not used across threads > and point to truely different databases. > &g

RE: [sqlite] SQLITE_BUSY error in multi-threaded environment

gt; Subject: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment > > > It should not. > > As long as those two connections are not used across threads > and point to truely different databases. > > The

RE: [sqlite] SQLITE_BUSY error in multi-threaded environment

It should not. As long as those two connections are not used across threads and point to truely different databases. They wouldn't be a soft link would they? I Mark Brown <[EMAIL PROTECTED]> wrote: Hi John- There is a .lock file for each database. From my understanding, that should

RE: [sqlite] SQLITE_BUSY error in multi-threaded environment

--- Mark Brown <[EMAIL PROTECTED]> wrote: > There is a .lock file for each database. From my understanding, that should > prohibit 2 connections from using the same database at the same time. > However, that is not the situation I am wondering about. I am specifically > wondering if database

RE: [sqlite] SQLITE_BUSY error in multi-threaded environment

Hi John- There is a .lock file for each database. From my understanding, that should prohibit 2 connections from using the same database at the same time. However, that is not the situation I am wondering about. I am specifically wondering if database activity on a connection to DB 1 would have

Re: [sqlite] SQLITE_BUSY error in multi-threaded environment

[mailto:[EMAIL PROTECTED] Sent: Wednesday, August 15, 2007 5:05 AM To: sqlite-users@sqlite.org Subject: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment Being a newbie to SQLite I've had the same problems working with SQLite so maybe I can help, It does not matter how well your

RE: [sqlite] SQLITE_BUSY error in multi-threaded environment

> -Original Message- > From: Andre du Plessis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 15, 2007 5:05 AM > To: sqlite-users@sqlite.org > Subject: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment > > > Being a newbie to SQLite I've had t

RE: [sqlite] SQLITE_BUSY error in multi-threaded environment

Hi Andre- Thank you for your insight. Looks like we have some redesign scheduled for today. :) Thanks, Mark > -Original Message- > From: Andre du Plessis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 15, 2007 5:05 AM > To: sqlite-users@sqlite.org > Subje

RE: [sqlite] SQLITE_BUSY error in multi-threaded environment

ers@sqlite.org Subject: [sqlite] SQLITE_BUSY error in multi-threaded environment Hi- I've got an application that has many different SQLite databases. Each database connection is opened in its own thread. Each database has only one connection. I created some test cases that create a database and sch

[sqlite] SQLITE_BUSY error in multi-threaded environment

Hi- I've got an application that has many different SQLite databases. Each database connection is opened in its own thread. Each database has only one connection. I created some test cases that create a database and schema on the fly and perform various SELECT, INSERTS, UPDATES on it. The

[sqlite] SQLITE_BUSY "database is locked" when db is on network drive...

running sqlite 3.4.1 on mac os x 10.4 i've set up a file share on another mac running 10.4 and placed a small db file on the share and chmod'ed it to 777 (full access). i go to the development mac and log into the other mac as the user who owns that db file. the path on my dev mac to that

[sqlite] SQLITE_BUSY "database is locked" when db is on network drive...

running sqlite 3.4.1 on mac os x 10.4 i've set up a file share on another mac running 10.4 and placed a small db file on the share and chmod'ed it to 777 (full access). i go to the development mac and log into the other mac as the user who owns that db file. the path on my dev mac to that

Re: [sqlite] SQLITE_BUSY scenario

No, I did not explicitly set it. John Stanton wrote: Do you set the inherit handles flag on your CreateProcess call? Dixon Hutchinson wrote: The basic problem is that I am getting SQLITE_BUSY on a call to sqlite3_exec where the SQL passed is simply "COMMIT;" Notes: 1. This in on a

Re: [sqlite] SQLITE_BUSY scenario

Dixon Hutchinson wrote: The basic problem is that I am getting SQLITE_BUSY on a call to sqlite3_exec where the SQL passed is simply "COMMIT;" Notes: 1. This in on a WIN32 platform. 2. There is only one process (the main process) that makes any calls to sqlite3 for the DB in question.

[sqlite] SQLITE_BUSY scenario

The basic problem is that I am getting SQLITE_BUSY on a call to sqlite3_exec where the SQL passed is simply "COMMIT;" Notes: 1. This in on a WIN32 platform. 2. There is only one process (the main process) that makes any calls to sqlite3 for the DB in question. 3. The process is

Re: [sqlite] SQLITE_BUSY [5] database is locked

I tried it. Apparently the error gets thrown by the stmt.execDML() statement. It never makes it to any code past the execDML. Paul - Original Message - From: "Jay Sprenkle" <[EMAIL PROTECTED]> To: <sqlite-users@sqlite.org> Sent: Friday, March 31, 2006 10:49 A

Re: [sqlite] SQLITE_BUSY [5] database is locked

On 3/31/06, Paul Pigott <[EMAIL PROTECTED]> wrote: > Greetings all, Greetings :) > The C_DAOService class works fine. It gives me no problems. But when I try > to insert a row with the C_DAOPerformer class, I'm getting an "SQLITE_BUSY > [5] database is locked" error. And I don't know why.

[sqlite] SQLITE_BUSY [5] database is locked

Greetings all, I imagine this has been covered before, but I've been through the archives and couldn't find what I needed. So I'm appealing to a larger authority. I am writing some C++ objects to handle access to a database. Two of them are virtually identical: C_DAOService and

Re: [sqlite] SQLite_Busy from DBD-SQLite

I'm using Perl 5.8.7 on Windows. When the database is locked, the statement execution returns a FALSE value like it does for any other error. On 3/16/06, Jay Sprenkle <[EMAIL PROTECTED]> wrote: > > On 3/16/06, Sripathi Raj <[EMAIL PROTECTED]> wrote: > > Hi, > > > > How do I know that a statement

Re: [sqlite] SQLite_Busy from DBD-SQLite

On 3/16/06, Sripathi Raj <[EMAIL PROTECTED]> wrote: > Hi, > > How do I know that a statement failed to execute because the database was > locked? > > Raj > Raj, what language are you using?

[sqlite] SQLite_Busy from DBD-SQLite

Hi, How do I know that a statement failed to execute because the database was locked? Raj

[sqlite] sqlite_busy in multithreaded application

Hi, Though they were lot of discussion on this, I could not find solution in my case. To elaborate the happening. Let me say i have two threads 1.ReadThread 2. DeleteThread My ReadThread does the following. 1. Compile and Create SQLStatement 2. Generate QueryObject 3. Query and finalize . 4.

Re: [sqlite] SQLITE_BUSY returned without busy handler called

On Tue, Oct 19, 2004 at 11:58:48AM -0700, Kevin Schmeichel wrote: > > Really, what I was concerned about was getting > SQLITE_BUSY from sqlite_finalize - if I try and call > sqlite_finalize again, I get SQLITE_MISUSE. I haven't > gone through the code in enough detail to determine > what the

Re: [sqlite] SQLITE_BUSY returned without busy handler called

What if transactions only executed if they were able to get an EXCLUSIVE lock? Wouldn't that solve the problem you described? Granted, this would be overkill for transactions that only did SELECTs, but... --- "b.bum" <[EMAIL PROTECTED]> wrote: > > Not in a transaction. > > The purpose

Re: [sqlite] SQLITE_BUSY returned without busy handler called

On Oct 19, 2004, at 11:58 AM, Kevin Schmeichel wrote: Maybe I'm a bit confused - wouldn't (A) first give up it's SHARED lock before trying to get the RESERVED lock, thus giving (B) a chance to get the EXCLUSIVE lock? Not in a transaction. The purpose of a transaction is to group together a

Re: [sqlite] SQLITE_BUSY returned without busy handler called

Maybe I'm a bit confused - wouldn't (A) first give up it's SHARED lock before trying to get the RESERVED lock, thus giving (B) a chance to get the EXCLUSIVE lock? Really, what I was concerned about was getting SQLITE_BUSY from sqlite_finalize - if I try and call sqlite_finalize again, I get

Re: [sqlite] SQLITE_BUSY returned without busy handler called

On Oct 18, 2004, at 12:01 PM, Kevin Schmeichel wrote: What are some examples of circumstances when waiting and retrying a lock won't help? Consider two processes, A and B. Lock state is in [BRACKETS]. (A) does a BEGIN TRANSACTION (B) does a BEGIN TRANSACTION (A) does a SELECT [SHARED] (B) does

Re: [sqlite] SQLITE_BUSY returned without busy handler called

What are some examples of circumstances when waiting and retrying a lock won't help? Kevin --- "D. Richard Hipp" <[EMAIL PROTECTED]> wrote: > Kevin Schmeichel wrote: > > By examining the code, it can be seen that there > are > > many places where SQLITE_BUSY is returned (from an > API >

Re: [sqlite] SQLITE_BUSY returned without busy handler called

Kevin Schmeichel wrote: By examining the code, it can be seen that there are many places where SQLITE_BUSY is returned (from an API function) without the busy handler being called. Anyone know if there is any reason for this? I would have thought that the busy handler would be called *every*

[sqlite] SQLITE_BUSY returned without busy handler called

By examining the code, it can be seen that there are many places where SQLITE_BUSY is returned (from an API function) without the busy handler being called. Anyone know if there is any reason for this? I would have thought that the busy handler would be called *every* time that the db is