RE: [sqlite] sqlite3_step() returning SQLITE_DONE for query that should return results
OK, I'm an idiot. I apologize if anybody wasted their time on this, it turned out to be something stupid I was doing. (An unrelated bug was changing the index value I was looking up, and though I thought I turned transactions off for this operation, it was turned off for the earlier but not the later part where the problem is, so when I went to verify that the value was actually in the column it had been rolled back.) I hate it when I do that. > From: [EMAIL PROTECTED] > To: sqlite-users@sqlite.org > Date: Fri, 18 Jan 2008 17:01:56 -0800 > Subject: [sqlite] sqlite3_step() returning SQLITE_DONE for query that should > return results > > -- Joe Cosby http://joecosby.com/ I've been on aol for something like ten years. But I still hate it. :: Currently listening to The Last Supper, 1973, by Andrew Lloyd Webber/Tim Rice, from "Jesus Christ Superstar" _ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Quick question about multithread and SQLITE_BUSY/SQLITE_LOCKED in 3.5.4
Using read and write locks around your statements gives you protection and lets you compile without thread safe so that Sqlite does not use internal mutexes as much for synchronization saving you considerable overhead as well as avoiding the logic necessary to handle BUSYs from Sqlite and skipping any polling or busy waits. Pthreads provides all the capabilities in the API. Windows needs a little work to implement read locks. Jens Miltner wrote: Am 19.1.08 um 03:13 schrieb [EMAIL PROTECTED]: OK I figured out SQLITE_THREADSAFE=0 for the second question... And it seems the answer for the first question is yes, but if you know a simpler way please share it with us, thanks! You could use a read-write mutex to serialize access to your database connection. That way you can have multiple readers, but modifying the database becomes an exclusive operation. This matches the sqlite requirements. Alternatively, you can just retry your write queries if you get SQLITE_BUSY errors... -- sword On Sat, 19 Jan 2008 09:57:10 +0900 "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: Hello all, I've read http://www.sqlite.org/lockingv3.html but am still not sure about multithread and locking in 3.5.4. I have a multithread application that has a single connection to a single SQLite3 database. Since it's multithreaded, SQL statements are thrown to a single SQLite3 object concurrently. I'm using http://www.sqlite.org/sqlite-amalgamation-3_5_4.zip on VC8 + WindowsXP. Prior to this version (I was using SQLite2) I'd serialized all these database access using critical sections and didn't care about SQLITE_BUSY or SQLITE_LOCKED since they never happen. It was very simple as I didn't need to implement access retry for a busy case. However, I learned that SQLite 3.5 does mutexing by default. So I removed all synchronization stuff in my SQLite access code, and now it seems it's not working as I intended. Unfortunately I can't reproduce it in my development environment and I've not yet implemented logging to see if it's due to SQLITE_BUSY or SQLITE_LOCKED. I saw it's entering sqlite3_mutex_enter multiple times in the debugger though, so it's thread-safe at least. My question is, 1. Do I still have to synchronize all SQLite access in my client code not to encounter SQLITE_BUSY or SQLITE_LOCKED? (Or is there any better way?) 2. If so, how can I turn off all these mutexes (critical sections) in SQLite 3.5.4? They are needless if I serialize all SQLite access in the client code. Regards, -- sword - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Quick question about multithread and SQLITE_BUSY/SQLITE_LOCKED in 3.5.4
Am 19.1.08 um 03:13 schrieb [EMAIL PROTECTED]: OK I figured out SQLITE_THREADSAFE=0 for the second question... And it seems the answer for the first question is yes, but if you know a simpler way please share it with us, thanks! You could use a read-write mutex to serialize access to your database connection. That way you can have multiple readers, but modifying the database becomes an exclusive operation. This matches the sqlite requirements. Alternatively, you can just retry your write queries if you get SQLITE_BUSY errors... -- sword On Sat, 19 Jan 2008 09:57:10 +0900 "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: Hello all, I've read http://www.sqlite.org/lockingv3.html but am still not sure about multithread and locking in 3.5.4. I have a multithread application that has a single connection to a single SQLite3 database. Since it's multithreaded, SQL statements are thrown to a single SQLite3 object concurrently. I'm using http://www.sqlite.org/sqlite-amalgamation-3_5_4.zip on VC8 + WindowsXP. Prior to this version (I was using SQLite2) I'd serialized all these database access using critical sections and didn't care about SQLITE_BUSY or SQLITE_LOCKED since they never happen. It was very simple as I didn't need to implement access retry for a busy case. However, I learned that SQLite 3.5 does mutexing by default. So I removed all synchronization stuff in my SQLite access code, and now it seems it's not working as I intended. Unfortunately I can't reproduce it in my development environment and I've not yet implemented logging to see if it's due to SQLITE_BUSY or SQLITE_LOCKED. I saw it's entering sqlite3_mutex_enter multiple times in the debugger though, so it's thread-safe at least. My question is, 1. Do I still have to synchronize all SQLite access in my client code not to encounter SQLITE_BUSY or SQLITE_LOCKED? (Or is there any better way?) 2. If so, how can I turn off all these mutexes (critical sections) in SQLite 3.5.4? They are needless if I serialize all SQLite access in the client code. Regards, -- sword - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] fts3 - primary key doesn't seem to do anything
SQLite version 3.5.4
sqlite> create virtual table foo using fts3(content, id primary key);
sqlite> insert or replace into foo values('anything', 1);
sqlite> insert or replace into foo values('anything', 1);
sqlite> insert or replace into foo values('anything else', 1);
sqlite> select * from foo;
anything|1
anything|1
anything else|1
For comparison's sake:
SQLite version 3.5.4
Enter ".help" for instructions
sqlite> create table foo (content, id primary key);
sqlite> insert or replace into foo values('anything', 1);
sqlite> insert or replace into foo values('anything', 1);
sqlite> insert or replace into foo values('anything else', 1);
sqlite> select * from foo;
anything else|1
Why doesn't inserting a row with a duplicate primary key trigger a conflict?
Is this part of fts3's design, or is it an oversight? Am I missing something?
For now, I will avoid this problem by deleting rows matching the primary key
before inserting/replacing them.
--
Andy Goth
<[EMAIL PROTECTED]>
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
[sqlite] fts3 - "SQL logic error or missing database" on all match words negated
SQLite version 3.5.4
sqlite> create virtual table foo using fts3;
sqlite> insert into foo values('anything');
sqlite> select * from foo where foo match '-all -words -are -negated';
SQL error: SQL logic error or missing database
Yeah, I know it's not really a useful thing to search for nothing but negated
words, but I think it should result in an empty list, not an SQL error. I
mean, the match words often come from a Web , and I don't think I should
have to write code to check for this situation.
--
Andy Goth
<[EMAIL PROTECTED]>
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
[sqlite] RE: Assertion for Virtual Table INSERT
I tracked down the cause of this problem to an experimental change made locally to SQLite. :-( All is well with SQLite! :-) Mark > -Original Message- > From: Evans, Mark (Tandem) > Sent: Friday, January 18, 2008 3:45 PM > To: sqlite-users@sqlite.org > Subject: [sqlite] Assertion for Virtual Table INSERT > > Hi all, > > SQLite version 3.5.3 - with custom virtual table module. > > I am having a problem with assertion failure following > processing of an INSERT statement relative to a virtual > table. Everything works through the call for VUpdate, then > it asserts in vdbe.o in leg for Dup. I'm wondering if this > is a bug in SQLite vdbe code generation. What is the purpose > of Dup following VUpdate below? I have duplicated the > problem on two different architectures. > > > sqlite> explain insert into t1 values (0,'foo', 0); > 0|Goto|0|16| > 1|Null|0|0| > 2|Null|0|0| > 3|Integer|0|0| > 4|String8|0|0|foo > 5|Integer|0|0| > 6|VUpdate|1|5|vtab:9E002B8:FD0A60 > 7|Dup|2|1| > 8|NotNull|1|10| > 9|Halt|19|2|T1.X may not be NULL > 10|Dup|0|1| > 11|NotNull|1|13| > 12|Halt|19|2|T1.Z may not be NULL > 13|MakeRecord|3|0|dad > 14|Insert|0|3|T1 > 15|Halt|0|0| > 16|Transaction|0|1| > 17|VerifyCookie|0|2| > 18|VBegin|0|0|vtab:9E002B8:FD0A60 > 19|Goto|0|1| > 20|Noop|0|0| > sqlite> insert into t1 values (0,'foo', 0); > sqlite3: ../../../../Source/sqlite-3.5.3-hp/src/vdbe.c:893: > sqlite3VdbeExec: Assertion `pFrom<=pTos && pFrom>=p->aStack' failed. > Abort (core dumped) > [EMAIL PROTECTED] MSE]$ > > Many thanks, > Mark > > - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] Slow query on one machine
I can't do anything like that as it is a machine of a customer and I have no access to it. Just wondering what possibly could explain such a difference. The relevant thing is that are load of queries coming after this and they are all fine. So it specific to that particular table at that particular point on that particular machine, all else behaves normal. RBS -Original Message- From: Jay Sprenkle [mailto:[EMAIL PROTECTED] Sent: 19 January 2008 14:12 To: sqlite-users@sqlite.org Subject: Re: [sqlite] Slow query on one machine On Jan 18, 2008 3:32 PM, RB Smissaert <[EMAIL PROTECTED]> wrote: > The application > that runs this is exactly the same on both machines. The slow machine is > actually slightly slower specification wise, but that can't explain the huge > differences in timings. > Have you run spinrite ( a disk diagnostic/maintenance program ) on the slow machine? - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Slow query on one machine
On Jan 18, 2008 3:32 PM, RB Smissaert <[EMAIL PROTECTED]> wrote: > The application > that runs this is exactly the same on both machines. The slow machine is > actually slightly slower specification wise, but that can't explain the huge > differences in timings. > Have you run spinrite ( a disk diagnostic/maintenance program ) on the slow machine? - To unsubscribe, send email to [EMAIL PROTECTED] -
