[sqlite] Using amalgamation *.[ch] files on different architectures

Hi, I have generated the amalgamation file using the command "make sqlite3.c". This was done on an x86 machine running Linux. Can I use the generated sqlite3.[ch] files on a different architecture machine running Linux? Regards, chandan ___

Re: [sqlite] Feature request

Looks like feature bloat. If you need such features for a particular application just add the code to your application or create a modified version of Sqlite for just that application. It makes no sense to burden all users with overhead for a feature required by only a handful of

Re: [sqlite] Re-try logic on SQLITE_BUSY/deadlocked?

P Kishor wrote: > On Sat, May 23, 2009 at 6:34 AM, Rosemary Alles > wrote: > >> Thanks Simon. I have been leaning that way too - considering switching. >> >> -rosemary. >> >> On May 22, 2009, at 5:55 PM, Simon Slavin wrote: >> >> >>> On 23 May 2009, at 12:10am,

Re: [sqlite] queries for a fulltext-engine

"Lukas Haase" wrote in message news:gv9fcm$5r...@ger.gmane.org > I have a database containing thousands of HTML pages ("topics"). There > is a fulltext index for these topics. First there is a table > containing all single words. Each word is identified by its > "fulltextID":

Re: [sqlite] queries for a fulltext-engine

On 23 May 2009, at 7:30pm, Lukas Haase wrote: > SELECT topic_fulltext.topicID > FROM fulltext > JOIN topic_fulltext ON topic_fulltext.fulltextID = fulltext.fulltextID > WHERE word LIKE 'Word%'; > > But now I want to be able to search with more complex queries. For > example: > > * List all

Re: [sqlite] Re-try logic on SQLITE_BUSY/deadlocked?

Thanks Olaf. > > schrieb im Newsbeitrag > news:634ea812687a6d75a1ddf17adce883fc.squir...@webmail.ipac.caltech.edu... > > >> >> My primary concern now is to prevent a dead-lock. >> > That seems to make sense now (I assume you're working >> > "near a deadlock" with your

[sqlite] queries for a fulltext-engine

Hi, Sorry for the subject - I just do not know for what to search of what to ask - I actually do not know where is exactly my problem :-( I have a database containing thousands of HTML pages ("topics"). There is a fulltext index for these topics. First there is a table containing all single

Re: [sqlite] Bad UPDATE performance

Version 3.6.14.1 solved the problem. Thanks. ---Original Message--- From: Dan Date: 14/05/2009 11:21:33 To: General Discussion of SQLite Database Subject: Re: [sqlite] Bad UPDATE performance On May 14, 2009, at 2:33 PM, Ofir Neuman wrote: > Dan, > > Before I got your reply I

Re: [sqlite] Feature request

I'd like to suggest that features such as this be implemented with PRAGMA commands whenever possible, the reason being that the new functionality will then be immediately available to folks using non-C bindings, without waiting for an update to a binding package that may or may not occur. Jim On

Re: [sqlite] Feature request

On 23 May 2009, at 3:32pm, Filip Navara wrote: > PRAGMA schema_version ... for the second case. Hey, you're right. I thought it started from zero when your application's connection was opened, but testing shows that it's persistent with the file on disk. Thanks very much. That's the way

Re: [sqlite] Feature request

PRAGMA schema_version ... for the second case. F. On Sat, May 23, 2009 at 4:20 PM, Simon Slavin wrote: > > On 21 May 2009, at 5:59am, Simon Slavin wrote: > >> int sqlite3_change_count(sqlite3*) >> >> Returns an integer which is incremented whenn a change is made to

Re: [sqlite] Feature request

On 21 May 2009, at 5:59am, Simon Slavin wrote: > int sqlite3_change_count(sqlite3*) > > Returns an integer which is incremented whenn a change is made to any > table in the database. May be the value stored in bytes 24..27 of > file header or something else if that's not what I really want.

Re: [sqlite] Re-try logic on SQLITE_BUSY/deadlocked?

schrieb im Newsbeitrag news:634ea812687a6d75a1ddf17adce883fc.squir...@webmail.ipac.caltech.edu... > >> My primary concern now is to prevent a dead-lock. > > That seems to make sense now (I assume you're working > > "near a deadlock" with your multipe-client-requests,

Re: [sqlite] Re-try logic on SQLITE_BUSY/deadlocked?

Dear Olaf, Many thanks for your excellent analysis. > >> My primary concern now is to prevent a dead-lock. > That seems to make sense now (I assume you're working > "near a deadlock" with your multipe-client-requests, not > going to sleep properly before the next retry). Still makes no sense to