Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

On 08/26/2016 01:20 PM, David Raymond wrote: [snip] > Many do not persist after closing your connection, including synchronous and > foreign_keys that you mentioned. In fact, I'd say that the number that do > persist is pretty small, and those that do usually require a vacuum or such > after

Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

for subsequent connections. -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Adam Jensen Sent: Friday, August 26, 2016 12:55 PM To: sqlite-users@mailinglists.sqlite.org Subject: Re: [sqlite] Locking databases - Possibly (probably?) a dumb

Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

On 08/25/2016 04:41 PM, Adam Jensen wrote: > On 08/20/2016 01:01 PM, Simon Slavin wrote: >> On 20 Aug 2016, at 5:56pm, Lev wrote: > [snip] >>> So this 'setting' is stored in the database file? Is it enough to do the >>> PRAGMA when the database is created? >> >> Yes and

Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

On 08/20/2016 01:01 PM, Simon Slavin wrote: > On 20 Aug 2016, at 5:56pm, Lev wrote: [snip] >> So this 'setting' is stored in the database file? Is it enough to do the >> PRAGMA when the database is created? > > Yes and yes, but do it this way. > > 1) Create the database

Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

One minor optional addition below On Sat, 20 Aug 2016 18:01:46 +0100, Simon Slavin wrote: > >On 20 Aug 2016, at 5:56pm, Lev wrote: [...] >> So this 'setting' is stored in the database file? Is it enough to do the >> PRAGMA when the database is

Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

On Sat, 20 Aug 2016 18:01:46 +0100 Simon Slavin wrote: > Yes and yes, but do it this way. > > 1) Create the database file by opening it. > 2) Do something that makes the file non-blank, like creating a table. > 3) Issue "PRAGMA journal_mode=WAL"

Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

On 20 Aug 2016, at 5:56pm, Lev wrote: > I read in the documentation: > > The WAL journaling mode uses a write-ahead log instead of a rollback journal > to implement transactions. The WAL journaling mode is persistent; after being > set it stays in effect across multiple

Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

On Sat, 6 Aug 2016 17:03:30 -0400 Richard Hipp wrote: > Doing "PRAGMA journal_mode=WAL;" on your database (just once, perhaps > from a command-line shell) will fix this for you. I read in the documentation: The WAL journaling mode uses a write-ahead

Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

Rob, At 18:27 07/08/2016, you wrote: Too little sleep and far too much coffee. I was in the same situation, multiplying by 2 instead of dividing, as Ryan pointed out. Nice to see that WAL fits your use case. I for one found it rock solid and very useful. -- Jean-Christophe

Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

Jean-Christophe Thanks for the update on wal-mode. Your explanation is clear and makes sense to us. We can see what we would have a 224MB -wal file, we experimented with killing processes whilst updating and generally messing around and SQLite did what is was supposed to do. I wouldn’t say

Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

Ryan, Thanks for the update. We have done a few more tests during the day and not had any issues to date. This is still on a test version but we are getting a warm, cuddly feeling about using WAL mode. The -wal file grows as you describe and you have explained it very well. We were groping

Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

On 2016/08/07 8:55 AM, Rob Willett wrote: Richard, Ryan, Thanks for this. We were dimly aware of WAL but until now hadn’t needed to use it. We’ve done a quick check with it and it *seems* to work on a test database. We’ve all read the docs again and paid attention to

Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

Rob, At 08:55 07/08/2016, you wrote: We think that using WAL mode works for us, indeed inspection seems to indicate it does, but the size of the -wal file appears to be far larger than would be expected. Is there a problem here? It doesn't appear to be a problem but would welcome any

Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

Richard, Ryan, Thanks for this. We were dimly aware of WAL but until now hadn’t needed to use it. We’ve done a quick check with it and it *seems* to work on a test database. We’ve all read the docs again and paid attention to https://www.sqlite.org/wal.html#bigwal To test if it works we

Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

On 2016/08/06 10:50 PM, Rob Willett wrote: Our understanding of this is that many processes can READ the database at the same time but NO process can INSERT/UPDATE if another is reading. We had thought that one process can write and multiple processes can read. Our reading (no pun

Re: [sqlite] Locking databases - Possibly (probably?) a dumb question

On 8/6/16, Rob Willett wrote: > > What we have now found is that when we are running the analytics query > in one Perl process, we can no longer UPDATE the main database through > another Perl process. We are getting “database is locked” errors. Doing "PRAGMA

[sqlite] Locking databases - Possibly (probably?) a dumb question

Hi, We’ve been using Sqlite though Perl for some time now and have started to get more adventurous. Our SQLite database is around 32GB in size, is created and manipulated by a single Perl process and is working well. What we now want to do is mine the database using a very long running

Re: [sqlite] Locking semantics are broken?

In Mr Smiths examples, one statement effect is a direct result of an action you (subjectively speaking) knowingly did, or did not do, to the car. You did not fuel the car. You did take the wheels off. There by, your car is essentially a hunk of metal taking up space. It doesn't function as

Re: [sqlite] Locking semantics are broken?

On 2016/06/28 5:46 PM, John Found wrote: On Wed, 29 Jun 2016 01:03:28 +1000 "dandl" wrote: But if everything is configured right and working right and nothing bad happens then it is highly reliable over very large volumes of transactions. For me, this is a clear definition

Re: [sqlite] Locking semantics are broken?

On Wed, 29 Jun 2016 01:03:28 +1000 "dandl" wrote: > But if everything is configured right and working right and nothing bad > happens then it is highly reliable over very large volumes of transactions. For me, this is a clear definition of the term "not reliable". Isn't it? --

Re: [sqlite] Locking semantics are broken?

age- > From: sqlite-users-boun...@mailinglists.sqlite.org [mailto:sqlite-users- > boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin > Sent: Tuesday, 28 June 2016 7:28 PM > To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> > Subject: Re: [sqlite] Lock

Re: [sqlite] Locking semantics are broken?

On Tue, 28 Jun 2016 at 19:17 Rowan Worth wrote: > On 28 June 2016 at 16:07, dandl wrote: > > > > Do not use SQLite for concurrent access over a network connection. > > Locking > > > semantics are broken for most network filesystems, so you will have > > >

Re: [sqlite] Locking semantics are broken?

On 28 Jun 2016, at 9:07am, dandl wrote: >> Do not use SQLite for concurrent access over a network connection. Locking >> semantics are broken for most network filesystems, so you will have >> corruption issues that are no fault of SQLite. > > I have seen this comment made more

Re: [sqlite] Locking semantics are broken?

On 28 June 2016 at 16:07, dandl wrote: > > Do not use SQLite for concurrent access over a network connection. > Locking > > semantics are broken for most network filesystems, so you will have > > corruption issues that are no fault of SQLite. > > I have seen this comment made

Re: [sqlite] Locking semantics are broken?

dandl wrote: >> Do not use SQLite for concurrent access over a network connection. Locking >> semantics are broken for most network filesystems, so you will have >> corruption issues that are no fault of SQLite. > > I have seen this comment made more than once on this list. Is there any > reliable

[sqlite] Locking semantics are broken?

> Do not use SQLite for concurrent access over a network connection. Locking > semantics are broken for most network filesystems, so you will have > corruption issues that are no fault of SQLite. I have seen this comment made more than once on this list. Is there any reliable evidence to support

Re: [sqlite] Locking errors on network

On Mon, 10 Nov 2014 20:33:04 +0200 RSmith wrote: > > On 2014/11/10 20:22, Mike McWhinney wrote: > > So SQLite shouldn't be used at all on a network? Aren't there any > > other provisions to handled the locking errors if/when they occur? > > It is not about SQLite, it is

Re: [sqlite] Locking errors on network

On Mon, Nov 10, 2014 at 12:56 PM, wrote: > On 2014-11-10 18:33, RSmith wrote: > > >> There is one Client-Server implementation of SQLite (SQLightening I >> think) but it is neither free nor easy to convert to. >> > > Doing some Googling, this looks like the thing: > >

Re: [sqlite] Locking errors on network

On 10 Nov 2014 at 19:38, Mike McWhinney wrote: > I am using Sqlite.NET client in C#. How would I go about defining a sqlite > busy timeout handler? Is the API not documented somewhere (I don't know what Sqlite.NET client or C# are, so can't help)? Surely you must have

Re: [sqlite] Locking errors on network

On Mon, Nov 10, 2014 at 12:56 PM, wrote: > On 2014-11-10 18:33, RSmith wrote: > > >> There is one Client-Server implementation of SQLite (SQLightening I >> think) but it is neither free nor easy to convert to. >> > > Doing some Googling, this looks like the thing: > >

Re: [sqlite] Locking errors on network

On 2014-11-10 18:33, RSmith wrote: There is one Client-Server implementation of SQLite (SQLightening I think) but it is neither free nor easy to convert to. Doing some Googling, this looks like the thing: http://sqlitening.com They don't seem to sell it any more (last version was released

Re: [sqlite] Locking errors on network

I am using Sqlite.NET client in C#. How would I go about defining a sqlite busy timeout handler? Thanks Mike On Monday, November 10, 2014 1:35 PM, Tim Streater wrote: On 10 Nov 2014 at 18:22, Mike McWhinney wrote: > So SQLite shouldn't

Re: [sqlite] Locking errors on network

On 10 Nov 2014 at 18:22, Mike McWhinney wrote: > So SQLite shouldn't be used at all on a network? Aren't there any other > provisions to handled the locking errors if/when > they occur? You tried setting a timeout as pointed to here?

Re: [sqlite] Locking errors on network

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/10/2014 10:22 AM, Mike McWhinney wrote: > So SQLite shouldn't be used at all on a network? Aren't there any > other provisions to handled the locking errors if/when they occur? Network filesystems do not implement locking and other operations

Re: [sqlite] Locking errors on network

On 10 Nov 2014, at 6:22pm, Mike McWhinney wrote: > So SQLite shouldn't be used at all on a network? SQLite is not designed for hosting a database on a server for access by lots of different computers at the same time. To do that efficiently you need a client/server

Re: [sqlite] Locking errors on network

On 2014/11/10 20:22, Mike McWhinney wrote: So SQLite shouldn't be used at all on a network? Aren't there any other provisions to handled the locking errors if/when they occur? It is not about SQLite, it is about the Networking systems lying about whether a file is locked or not. No RDBMS

Re: [sqlite] Locking errors on network

So SQLite shouldn't be used at all on a network? Aren't there any other provisions to handled the locking errors if/when they occur? On Monday, November 10, 2014 12:10 PM, Roger Binns wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/10/2014 09:41 AM,

Re: [sqlite] Locking errors on network

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/10/2014 09:41 AM, Mike McWhinney wrote: > Please let know if there are any other solutions to this database > locking problem as used on a network. Yes. Do not do it. See the FAQ: https://www.sqlite.org/faq.html#q5 Roger -BEGIN PGP

[sqlite] Locking errors on network

Hello, I continue to have "database is locked errors" when running an application which accesses a SQLite dabase on a network. I have tried many of the connection string options: pooling, changing default time out. I just recently tried a block of code which does a BeginTransaction and

Re: [sqlite] Sqlite locking issue with ATTACH'ed databases

I've narrowed this locking issue down to a very simply test case. It seems as though having the same file attached multiple times with different names prevents exclusive or immediate transactions from acquiring a lock. Deferred transactions still seem to work fine. Try the following code:

Re: [sqlite] Sqlite locking issue with ATTACH'ed databases

Wed, 17 Jul 2013 17:21:15 +0100 >> From: Simon Slavin <slav...@bigfraud.org> >> To: General Discussion of SQLite Database <sqlite-users@sqlite.org> >> Subject: Re: [sqlite] Sqlite locking issue with ATTACH'ed databases >> Message-ID: <f0ad438b-1165-419d-99

Re: [sqlite] Sqlite locking issue with ATTACH'ed databases

On 18 Jul 2013, at 8:26pm, Loren Keagle wrote: > It definitely seems to be related to having the same database attached > multiple times with different names. Okay. I have absolutely no idea how well SQLite copes with that. I'm not saying it's bad, I just have

Re: [sqlite] Sqlite locking issue with ATTACH'ed databases

>Date: Wed, 17 Jul 2013 17:21:15 +0100 >From: Simon Slavin <slav...@bigfraud.org> >To: General Discussion of SQLite Database <sqlite-users@sqlite.org> >Subject: Re: [sqlite] Sqlite locking issue with ATTACH'ed databases >Message-ID: <f0ad438b-1165-419d-99bf-57faf9de5.

Re: [sqlite] Sqlite locking issue with ATTACH'ed databases

>> Prepare query statement; >> Iterate through one or more rows; >> Reset statement; >> >> Attempt to begin transaction; <--- SQLITE_BUSY "The sqlite3_reset() function is called to reset a prepared statement object back to its initial state, ready to be re-executed. Any SQL statement

Re: [sqlite] Sqlite locking issue with ATTACH'ed databases

If you remove a busy check, does it output any statements? Do you have any custom functions/operations running so they could block sqlite in creating new statement? 2013/7/17 Loren Keagle > Hi everyone, > > I have an interesting locking problem that I'm wondering

Re: [sqlite] Sqlite locking issue with ATTACH'ed databases

On 16 Jul 2013, at 11:24pm, Loren Keagle wrote: > Begin EXCLUSIVE TRANSACTION; > insert several rows of data; > Commit transaction; > > Prepare query statement; > Iterate through one or more rows; > Reset statement; > > Attempt to begin transaction; <---

[sqlite] Sqlite locking issue with ATTACH'ed databases

Hi everyone, I have an interesting locking problem that I'm wondering if someone can help with some insight. I have a master database with some metadata, and several sub-databases to store logging events. I have one reader object and one writer object that attach to the sub-databases and

Re: [sqlite] System.Data>SQLite locking problem

I can confirm that the problem only exist when the database is encrypted. On Sat, Sep 15, 2012 at 11:00 AM, Serge Fournier wrote: > I work with an encrypted database and it look like it could be part of the > problem. > > > On Wed, Sep 12, 2012 at 3:05 PM, Serge Fournier

Re: [sqlite] System.Data>SQLite locking problem

Doing more testing on this I can say that I have the same problems with Windows 7. On Wed, Sep 12, 2012 at 8:08 AM, Serge Fournier wrote: > The thing here is that my code was working perfectly with the prior > version of the library and Windows 7. > The same code with 1.0.82

Re: [sqlite] System.Data>SQLite locking problem

The thing here is that my code was working perfectly with the prior version of the library and Windows 7. The same code with 1.0.82 and Windows 8 doesn't work anymore. I cannot use your solution, because the way my appliation works; it creates the database at first run and miust be able to run on

Re: [sqlite] System.Data>SQLite locking problem

Did you try it with a Windows 8? I have a feeling that the problem is more with this OS then the library. Here's something simple that doesn't work: SQLconnect.ConnectionString = "Data Source=" & Application.StartupPath & "\data.db;" SQLconnect.SetPassword(infoConnection) SQLconnect.Open()

Re: [sqlite] System.Data>SQLite locking problem

I've experienced this problem in the past. According to here, I found a solution. *Brandon's Tips on How to Unlock SQLite Databases* 1. Open a command line prompt window. 2. Type *sqlite* *dbname*.sqlite in the command line prompt, replacing "dbname"

Re: [sqlite] System.Data>SQLite locking problem

Serge Fournier wrote: > > Simply put, it's only possible to open a database once in the application > for writing; it's like the lock > doesn't get released until the application is closed. > I'm unable to reproduce the issue you describe here. Could you show us some sample code that

Re: [sqlite] System.Data>SQLite locking problem

Yes, all command have been disposed; everything works until I close the connection. Then when I open it again it the same application; either I get a "database is locked" when trying to write to it or I get "SQL queries are still processing" when I just opened it and send a VACUUM pragma to it.

Re: [sqlite] System.Data>SQLite locking problem

Serge Fournier wrote: > > Simply put, I open a database and then close it in an application then I > reopen it again, > I cannot write to it anymore; it is always locked. I tried doing a close, > dispose and shutdown > to my connection and then reopning it and do a simple vaccum; it tell me >

[sqlite] System.Data>SQLite locking problem

Hi, I'm not sure if it's Windows 8 or the latest version of the library (1.0.82) but I have a new problem with the same code that was working before. Simply put, i I open a database and then close it in an application then I reopen it again, I cannot write to it anymore; it is always locked. I

Re: [sqlite] Locking/Concurrency

KUSHAL SHAH wrote: > My scenario: Multiple processes want to access the database. How do I > configure so that I can get as much concurrency w.r.t read > and write. Meaning, have multiple readers and writers. The best concurrency between separate processes (and thus,

Re: [sqlite] Locking/Concurrency

, crash recovery, etc. Correct?   Thanks, Kushal.   From: Igor Tandetnik <itandet...@mvps.org> To: sqlite-users@sqlite.org Sent: Saturday, May 5, 2012 6:02 PM Subject: Re: [sqlite] Locking/Concurrency KUSHAL SHAH <adroi...@yahoo.com> wrote: >

Re: [sqlite] Locking/Concurrency

KUSHAL SHAH wrote: > I am starting simple where I have exe1 having 1 connection and exe2 having > another connection. > Now if both of them open the connections in mutex mode, will the read/write > requests be serialized. It seems you are saying No. I'm not sure what you

Re: [sqlite] Locking/Concurrency

012 11:04 AM Subject: Re: [sqlite] Locking/Concurrency On 5/4/2012 1:52 PM, KUSHAL SHAH wrote: > I am trying to use SQLite in my .NET project. Client APIs are from > System.Data.SqLite. Can you please help with below: > > It seemsthat multiple > threads can actually read simulta

Re: [sqlite] Locking/Concurrency

On 5/4/2012 1:52 PM, KUSHAL SHAH wrote: I am trying to use SQLite in my .NET project. Client APIs are from System.Data.SqLite. Can you please help with below: It seemsthat multiple threads can actually read simultaneously from a sqlite Db. However, I am confused about the write part. Will

[sqlite] Locking/Concurrency

I am trying to use SQLite in my .NET project. Client APIs are from System.Data.SqLite. Can you please help with below:   It seemsthat multiple threads can actually read simultaneously from a sqlite Db. However, I am confused about the write part. Will SQLite manage the write requests or the user

Re: [sqlite] SQLite Locking Issue From Another Process

On 22 Nov 2011, at 3:07pm, David Levinson wrote: > So my basic question is why is Process B locking the database when it is > opening the file for read-only access and not performing any writes on > the database being written to by Process A. > > > > Is it possible that a select statement

Re: [sqlite] SQLite Locking Issue From Another Process

...@sqlite.org] on behalf of David Levinson [dlevin...@worldnow.com] Sent: Tuesday, November 22, 2011 9:07 AM To: sqlite-users@sqlite.org Subject: EXT :[sqlite] SQLite Locking Issue From Another Process We have Process A which writes constantly to our SQLite database and we have Process B which

[sqlite] SQLite Locking Issue From Another Process

We have Process A which writes constantly to our SQLite database and we have Process B which occasionally reads from this same database. When Process B opens the database for read-only access and performs a select statement on the database it causes Process A to get SQLITE_BUSY errors when

Re: [sqlite] Addition: Re: SQLite locking question

> My understanding of the shared cache model was that it just ist intended > for solving our problem by relaxing the locking a little and that there > should not be any mutexes at all when using the uncomitted read mode. > > Have I missed anything? Yes, you are involved in a "magical" thinking.

Re: [sqlite] Addition: Re: SQLite locking question

Hi Pavel, > >> Any other chance to speed this up (apart from the obvious "optimize the > >> query, do not use distinct on large tables)= > > > > Without seeing the query or database schema? Not really... Depending > > on the exact query an index on "xyz" might help. > > Another suggestion

Re: [sqlite] Addition: Re: SQLite locking question

Hi Dan, >[...] > Mutexes are held for the duration of an sqlite3_step() call to make > sure SQLite doesn't segfault when two threads try to access the same > shared-cache object. Ok, I see, so there is no chance to access the data realy in _parallel_? (Just for reading). > > Any other chance to

Re: [sqlite] Addition: Re: SQLite locking question

>> Any other chance to speed this up (apart from the obvious "optimize the >> query, do not use distinct on large tables)= > > Without seeing the query or database schema? Not really... Depending > on the exact query an index on "xyz" might help. Another suggestion could be to turn off shared

Re: [sqlite] Addition: Re: SQLite locking question

Hi Dan, > > I have to correct myself a little... the hanging sqlite3_open_v2() does > > not happe while the prepare of the first query but during the first > > sqlite3_step() of the first query... > > Each shared-cache has a mutex associated with it. When > sqlite3_step is called it grabs the

Re: [sqlite] Addition: Re: SQLite locking question

On 05/06/2011 05:53 PM, Ole Reinhardt wrote: > Hi Dan, > >>> I have to correct myself a little... the hanging sqlite3_open_v2() does >>> not happe while the prepare of the first query but during the first >>> sqlite3_step() of the first query... >> >> Each shared-cache has a mutex associated with

Re: [sqlite] Addition: Re: SQLite locking question

On 05/06/2011 05:17 PM, Ole Reinhardt wrote: > Hi all, > > I have to correct myself a little... the hanging sqlite3_open_v2() does > not happe while the prepare of the first query but during the first > sqlite3_step() of the first query... Each shared-cache has a mutex associated with it. When

[sqlite] SQLite locking question

Hi all, we have a little problem with the locking of sqlite connections in combination with the shared cache model. We are using sqlite 3.6.10 (on Ubuntu 9.04) or later. Same problem occurs on the latest ubuntu version with sqlite 3.7.4. Problem: We have a multi threaded application that

Re: [sqlite] Locking issue on NFS filesystem

> int sqlite3_open_v2( > const char *filename, /* Database filename (UTF-8) */ > sqlite3 **ppDb, /* OUT: SQLite db handle */ > int flags, /* Flags */ > const char *zVfs/* Name of VFS module to use */ > ); > > With the last argument "unix-dotfile". > > Does it

Re: [sqlite] Locking issue on NFS filesystem

, Prakash From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] On Behalf Of Roger Binns [rog...@rogerbinns.com] Sent: Monday, June 14, 2010 8:30 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] Locking issue on NFS filesystem -BEGIN PGP SIGNED MESSAGE

Re: [sqlite] Locking issue on NFS filesystem

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/14/2010 02:56 AM, Prakash Reddy Bande wrote: > Our application is a simple desktop application with a simple install and run > setup. It is not possible to tell users to apply workaround of sharing the > drive via SMB etc. BTW SMB won't be

Re: [sqlite] Locking issue on NFS filesystem

of SQLite Database Subject: Re: [sqlite] Locking issue on NFS filesystem On 14 Jun 2010, at 3:16am, Prakash Reddy Bande wrote: > I have stumbled upon the issue as described in http://sqlite.org/faq.html#q5 > (But use caution: this locking mechanism might not work correctly if the > data

Re: [sqlite] Locking issue on NFS filesystem

On 14 Jun 2010, at 3:16am, Prakash Reddy Bande wrote: > I have stumbled upon the issue as described in http://sqlite.org/faq.html#q5 > (But use caution: this locking mechanism might not work correctly if the > database file is kept on an NFS filesystem.) > > The question is, do we have a

[sqlite] Locking issue on NFS filesystem

Hi, I have stumbled upon the issue as described in http://sqlite.org/faq.html#q5 (But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem.) The question is, do we have a workaround. Our application has to store data in user home

Re: [sqlite] Locking under various Windows versions

Simpson Sent: Friday, April 16, 2010 3:57 PM To: 'General Discussion of SQLite Database' Subject: Re: [sqlite] Locking under various Windows versions WinCE has no lockfile support, so it's fudged on the device by means of a shared memory block to handle the locking. If you open a SQLite database

Re: [sqlite] Locking under various Windows versions

Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Noah Hart Sent: Friday, April 16, 2010 3:48 PM To: General Discussion of SQLite Database Subject: [sqlite] Locking under various Windows versions I am trying to determine if SQLite holds

[sqlite] Locking under various Windows versions

I am trying to determine if SQLite holds an exclusive lock on a database opened under Windows-CE, will that lock be honored by a connection opened under another version of Windows? What about the opposite case? When the database is first opened under Windows 7, an exclusive lock is acquired,

Re: [sqlite] locking across the network...

http://www.sqlite.org/whentouse.html "...file locking logic of many network filesystems implementation contains bugs (on both Unix and Windows). If file locking does not work like it should, it might be possible for two or more client programs to modify the same part

[sqlite] locking across the network...

I am currently using SQLite in my client/server application: Server: Apache Web Server -- the sole process that access the SQLite databases Client A: Admin Client to configure the server, there is only 1 instance of this client. Client B: Kiosk Client, there is 1 or more of these, some have over

Re: [sqlite] Locking bug?

s-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Nico Coesel > Sent: Wednesday, November 04, 2009 4:19 PM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] Locking bug? > > > -Original Message- > > From: sqlite-users-boun..

Re: [sqlite] Locking bug?

ico Coesel Sent: Wednesday, November 04, 2009 4:19 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Locking bug? > -Original Message- > From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- > boun...@sqlite.org] On Behalf Of Simon Slavin > Sent: woensdag 4 n

Re: [sqlite] Locking bug?

On Wed, Nov 04, 2009 at 05:19:11PM +0100, Nico Coesel scratched on the wall: > > > > I'm using the sqlite3_exec function to execute a query; this function > > > calls slite3_finalize at the end so this should release the locks. > > Yes, I check every return value. I also see errors from process

Re: [sqlite] Locking bug?

> -Original Message- > From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- > boun...@sqlite.org] On Behalf Of Simon Slavin > Sent: woensdag 4 november 2009 16:09 > To: General Discussion of SQLite Database > Subject: Re: [sqlite] Locking bug? > > > On

Re: [sqlite] Locking bug?

On 4 Nov 2009, at 1:17pm, Nico Coesel wrote: > Two seperate processes (process A and process B) on a Linux system > read > and write to the same database. Process A performs a transaction > every 5 > seconds. Every now and then the locks from process A are not released > (judging from

[sqlite] Locking bug?

Hello, I have the following situation: Two seperate processes (process A and process B) on a Linux system read and write to the same database. Process A performs a transaction every 5 seconds. Every now and then the locks from process A are not released (judging from /proc/locks). It seems this

Re: [sqlite] SQLite locking problem with mozStorage

On 16 Aug 2009, at 11:55am, Sebastian Arcus wrote: > Just to thank you both for your suggestions and to let you know the > problem is solved. I'm glad you solved it, and thanks for your thanks. In a week like this one it's nice to know I'm doing someone some good somewhere. > I've tried

Re: [sqlite] SQLite locking problem with mozStorage

Hi Simon and Roger, Simon Slavin wrote: > On 15 Aug 2009, at 9:58am, Sebastian Arcus wrote: > > >> I've just noticed another interesting thing. A read operation after a >> write on same table (like a SELECT statement after an INSERT) works >> perfectly fine - instantly. Which is bizarre, as I

Re: [sqlite] SQLite locking problem with mozStorage

On 15 Aug 2009, at 9:58am, Sebastian Arcus wrote: > I've just noticed another interesting thing. A read operation after a > write on same table (like a SELECT statement after an INSERT) works > perfectly fine - instantly. Which is bizarre, as I would have > expected a > write to keep a much

Re: [sqlite] SQLite locking problem with mozStorage

Roger Binns wrote: > > Sebastian Arcus wrote: > >> Hi and thanks for the suggestion. I did as you advised and ran 'vmstat >> 1' in a terminal. Very little activity - maybe 20-40kb every 6-7 seconds >> on the bo - pretty much nothing on bi. Also, zeros all around on so/si. >> > > That

Re: [sqlite] SQLite locking problem with mozStorage

Roger Binns wrote: > > Sebastian Arcus wrote: > >> Hi and thanks for the suggestion. I did as you advised and ran 'vmstat >> 1' in a terminal. Very little activity - maybe 20-40kb every 6-7 seconds >> on the bo - pretty much nothing on bi. Also, zeros all around on so/si. >> > > That

Re: [sqlite] SQLite locking problem with mozStorage

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastian Arcus wrote: > Hi and thanks for the suggestion. I did as you advised and ran 'vmstat > 1' in a terminal. Very little activity - maybe 20-40kb every 6-7 seconds > on the bo - pretty much nothing on bi. Also, zeros all around on so/si.

Re: [sqlite] SQLite locking problem with mozStorage

Roger Binns wrote: > Sebastian Arcus wrote: > >> The SQLite documentation talks about entire database locks by operations >> of the order of milliseconds - 10 seconds seems a long way off. >> > > There is a possible but unlikely cause for what you are seeing. In order to > ensure the

Re: [sqlite] SQLite locking problem with mozStorage

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastian Arcus wrote: > The SQLite documentation talks about entire database locks by operations > of the order of milliseconds - 10 seconds seems a long way off. There is a possible but unlikely cause for what you are seeing. In order to ensure

[sqlite] SQLite locking problem with mozStorage

Hi all, I'm using the mozStorage implementation from Mozilla foundation, with Javascript and XUL (for the UI) to build a business-type app. I'm having this problem where I seem to get a lock of about 10 seconds after a read operation on a table, before I can perform a write operation on the

Re: [sqlite] Locking in sqlite

So if A, B and C are different files then they will not block despite leaving inside the same connection, right? BTW, by "block" I mean retrying after SQLITE_BUSY too. That's very good and convenient thing. Thank you, Pavel On Sat, May 2, 2009 at 10:05 PM, Nuno Lucas wrote: >

  1   2   3   >