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 bei
save the change 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 - Possibl
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 yes, but do it this way.
>>
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 file by opening it.
> 2)
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 created?
>
> Yes and yes, but do it this way.
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"
> 4) Close the file
>
> From that point onwards t
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 database connections and
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 log instead of a rollback journal
to implemen
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
___
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 we
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
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
https://www.sqlite.or
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 comments.
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 st
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 intended)
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 journal_mode=WAL;" on your database (
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
desi
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 of the term "not
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?
--
http://fresh.fla
ginal Message-
> 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
> Subject: 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
> > > corruption issues that are no fault of S
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 than once on this
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 more than once on th
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
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 about the Networking sy
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:
>
> http://sqlitening.com
>
>
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 some doc or how else do y
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:
>
> http://sqlitening.com
>
>
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
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 be used at all on a network? Aren't there any
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?
https://www.sqlite.org/faq.html#q5
(not that this would
-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
*
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 design and SQLite doesn't
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 can
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, Mike McWhinney wrote:
>
-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 SI
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, necessarily,
separate conn
n behavior, crash recovery,
etc. Correct?
Thanks,
Kushal.
From: Igor Tandetnik
To: sqlite-users@sqlite.org
Sent: Saturday, May 5, 2012 6:02 PM
Subject: Re: [sqlite] Locking/Concurrency
KUSHAL SHAH wrote:
> I am starting simple where I have exe1 having
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 mean by "mutex mode" -
: [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
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 SQLit
> 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. Al
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 cou
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
>> 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
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 mut
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 i
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
sql
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...
So in pseudo code the database access looks like this:
first thread:
sqlite3_open_v2("log.sqlite", SQLITE_OPEN
> 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 work
,
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
-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 muc
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
> databas
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 worka
Of Robert 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 y
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 on
a network share from a CE device, then it will not be able to use the
network share's locking mechanisms. In short, don't do it.
-Original Mes
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 o
Message-
> From: sqlite-users-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-
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...@sqlite.org [mailto:sqlite-users-
> boun...@sqlite.org] On Behalf Of Simon Slavin
> Sent: woensda
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 B
> -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
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 /proc/l
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:
> On Sat, May 2, 2009
On Sat, May 2, 2009 at 3:48 PM, Pavel Ivanov wrote:
[...]
> update main.t set x = 1
> update B.t set x = 1
> update C.t set x = 1
>
> My question is will these statements be able to execute in connections
> in parallel simultaneously because they use different databases and
> should lock only thos
Speaking of documentation of locks... my one beef with the sqlite
documentation is that its not very explicit about implicit locking. To
find out about implicit locks, you have to read
http://www.sqlite.org/lang_transaction.html, even though implicit
locks aren't necessarily associated with transac
On Mon, Dec 15, 2008 at 11:40:45AM -0600, Jay A. Kreibich wrote:
> On Mon, Dec 15, 2008 at 09:08:34AM -0600, Mike Mestnik scratched on the wall:
> > The locking is well documented, but it's not vary clear that the
> > BEGIN command can be used to acquire locks. The relation between the
> > diffe
On Mon, Dec 15, 2008 at 09:08:34AM -0600, Mike Mestnik scratched on the wall:
> The locking is well documented, but it's not vary clear that the
> BEGIN command can be used to acquire locks. The relation between the
> different locking stats and parameters to the BEGIN command could be
> spelled
Yes, for write transactions, begin immediate will cause the second write
transaction to wait on the first. However, the reads are done without an
explicity transaction so the reads should still proceed while the writes
have a reserved lock in place, right?
And even if there is no concurrency, at
By using BEGIN IMMEDIATE you lose any chance of concurrency.
Samuel Neff wrote:
> We're running into a lot of very slow queries and db locks when running with
> multiple processes accessing the same database. As a test we created a
> small application that has only two threads and a small single
Do you have posix-locks enabled with your glusterfs? If you have use
regular Sqlite locking logic and hope that the locks work properly.
Lanyi Zoltan wrote:
> Hello!
>
> I have shared disc system with glusterfs.
> When i read or write on this disc system then i get error: database is locked
> B
On 8/23/07, Pavan <[EMAIL PROTECTED]> wrote:
> As per my understanding I see that SQLite supports only database locking, as
> opposed to table/row locking. Does anyone know if you can read from a locked
> database ? (i.e. if one application has locked the database for writing,
> then can another a
On 12/11/06, "LEGRAND, Véronique" <[EMAIL PROTECTED]> wrote:
I found in the sqlite3 documentation that there were locking problems when
several processes running on different machines where trying to access an
sqlite3 database located on an NFS filesystem and that this problem could be
solved by
On 9/23/06, Martin Alfredsson <[EMAIL PROTECTED]> wrote:
>
> Windows XP, SQLite 3.3.4.
>
> /Martin
> ma1999ATjmaDOTse
Martin, did anyone mention virus scanners can lock your database file?
Do you have any other processes that might be reading the database file?
---
Hi !
I'm getting a lots of "database is locked" (code:5).
My app keeps giving up on one machine, it might be that
there is a network problem but I not 100% sure.
Anyway, when the app hangs all the other machines
including the machine where the database file is get
the "database is locked" (code
RohitPatel wrote:
> FoxPro supports row level locking. Ofcourse FoxPro creates one file for each
> table. There must be some way to implement row level locking. Probable by
> locking region in a file or somehow.
>
> Just thinking curiously...how MS could have implemented row level locking in
>
FoxPro supports row level locking. Ofcourse FoxPro creates one file for each
table. There must be some way to implement row level locking. Probable by
locking region in a file or somehow.
Just thinking curiously...how MS could have implemented row level locking in
FoxPro.
Rohit
--
View this mes
> Hello,
> I have a question regarding sqlite's behavior when auto commit is disabled.
>
> I have two conflicting transactions, A & B, where A is started first.
> B starts by executing some SELECT queries (which all succeed), then on
> the first UPDATE I get SQLITE_BUSY (as A is holding a conflicti
Ridgeview Medical Center
-Original Message-
From: Dan Petitt [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 24, 2005 11:37 AM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] Locking
> Isolation in SQLite is SERIALIZABLE. Note that SERIALIZABLE implies
> that locking can
> Isolation in SQLite is SERIALIZABLE. Note that SERIALIZABLE
> implies that locking can be no more fine-grained than table-level.
> You can obtain table-level locking in SQLite now. Just put each
> table in a separate database file and ATTACH as many tables to
> your connection as you require.
> Does your flat file support ACID transactions? That´s the killer feature
fo
> my app. I want to store financial transactions and I don´t trust normal
flat
> files.
No it isnt acid, its not got critical information in it but it does need
very fast read access and write access that doesnt block re
Joe Wilson <[EMAIL PROTECTED]> wrote:
> Does Sqlite support the ability to have several concurrent non-blocking
> database read operations
> in a single thread?
>
> What about the more traditional many-threads-each-with-a-blocking-read model?
>
Two or more connections can all read at the same
Does Sqlite support the ability to have several concurrent non-blocking
database read operations
in a single thread?
What about the more traditional many-threads-each-with-a-blocking-read model?
--- [EMAIL PROTECTED] wrote:
> Beginning with version 3.3.0, you will be able to configure SQLite
>
"Dan Petitt" <[EMAIL PROTECTED]> wrote:
> Are there any plans for sqlite to support row or table level locking, or
> possibly even Multiversion Concurrency Control, MVCC, its definition being:
>
"Axel Mammes \(gmail\)" <[EMAIL PROTECTED]> wrote:
> Does your flat file support ACID transactions?
Does your flat file support ACID transactions? That´s the killer feature fo
my app. I want to store financial transactions and I don´t trust normal flat
files.
-Original Message-
From: Dan Petitt [mailto:[EMAIL PROTECTED]
Sent: Viernes, 23 de Diciembre de 2005 08:00 p.m.
To: sqlite-users@
Nah, ignore that, I was talking garbage...
Using the view is a neater way of doing that select statement, but you
still need to create the temp table to avoid the locking issues...
Rachel
On 03/12/05, Rachel Willmer <[EMAIL PROTECTED]> wrote:
> (Replying to my own email so I can find this answer
(Replying to my own email so I can find this answer again via google
in the future...)
I have an even better solution...
CREATE VIEW NewView AS SELECT * FROM table1 LEFT JOIN table2 on
table1.field=table2.field WHERE table2.field is NULL;
Works just fine...
Cheers
Rachel
Back In Oct, I asked:
> Solution 1 is to use a TEMP table:
>
> CREATE TEMP TABLE diffs AS
> SELECT * FROM table1 LEFT JOIN table2 ;
> SELECT * FROM diffs; -- Insert into table1 in the callback;
> DROP TABLE diffs;
that sounds like the answer for me
thanks
Rachel
> I'm not sure I understand your logic. Your left join
> indicates that there are records missing from table2,
> so I would expect that you want to insert the missing
> records into table2. Assuming that's what you meant,
>
> insert into table2
> select * from table1
> where table1.field not
> SELECT * FROM table1 LEFT JOIN table2 on table1.field=table2.field
> WHERE table2.field is NULL
>
> So far, so good, I get the records I want. Then in the callback, I try
>
> INSERT INTO table1 etc...
I'm not sure I understand your logic. Your left join
indicates that there are records missing f
Why do it in the call back? Why not just do it in sql:
CREATE TEMP TABLE diffs AS
SELECT * FROM table1 LEFT JOIN table2 ;
insert into table1
SELECT * FROM diffs; -- Insert into table1
DROP TABLE diffs;
On 10/14/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Rachel Willmer <[EMAIL PR
Rachel Willmer <[EMAIL PROTECTED]> wrote:
> Hi, apologies if this is a trivial question, but I'm a newbie to
> sqlite3. (very impressed so far)
>
> I want to search two tables which should contain the same records and
> add any that are missing from the second into the first.
>
> So I do
>
> SEL
Jay writes:
> I did this for my writer operations:
>
> begin immediate;
> if busy keep retrying for a reasonable period, if still no lock then error
> out.
> // lock is now established
> // the following should never fail because I have an exclusive lock
But you don't have an exclusive lock yet:
On 4/28/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi! SQLite 3.2.1 on win32.
>
> I'm having trouble wrapping my mind around where I have to be
> paranoid about locking issues. In particular, the behavior when
> readers and writers overlap, or two writers overlap, is not 100%
> clear to
On 4/28/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi! SQLite 3.2.1 on win32.
>
> I'm having trouble wrapping my mind around where I have to be
> paranoid about locking issues. In particular, the behavior when
> readers and writers overlap, or two writers overlap, is not 100%
> clear to
> 1) You have to loop through the resultset twice,
> once to put it in memory, the other to process
> it in your application.
Yes.
>
> 2) The sqlite3_prepare() and sqlite3_finalize()
> both should be in a loop as well right? Since
> they can throw SQLITE_BUSY and SQLITE_SCHEMA
> themselves. So
What did your code look like before you started storing results in
memory?
> -Original Message-
> From: Jay Sprenkle [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 20, 2005 10:06 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Locking Methods
>
I think we're all on the same
page; I think what we're unclear about is exactly how you're trying to
accomplish this.
Thanks
-Tom
-Original Message-
From: Ben Clewett [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 20, 2005 3:32 AM
To: sqlite-users@sqlite.org
Subject: Re: [s
re trying to
> accomplish this.
>
>Thanks
>-Tom
>
> > -Original Message-
> > From: Ben Clewett [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, April 20, 2005 3:32 AM
> > To: sqlite-users@sqlite.org
> > Subject: Re: [sqlite] Locking Methods
think what we're unclear about is exactly how you're trying to
accomplish this.
Thanks
-Tom
> -Original Message-
> From: Ben Clewett [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 20, 2005 3:32 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite
With the current design you have to save your query results to memory
then do your
updates from that list.
On 4/20/05, Ben Clewett <[EMAIL PROTECTED]> wrote:
> This is exactly my problem. My version is 3.1.6. The error is
> SQLITE_LOCKED.
>
> Ben
>
> Jay Sprenkle wrote:
> > I had the same trou
1 - 100 of 165 matches
Mail list logo
