Re: [sqlite] Pre-compiled products

On Fri, Mar 20, 2009 at 11:07:01AM -0500, William Kyngesburye scratched on the wall: > Indeed, configuring sqlite to compile as a dylib on OSX is easy (it's > the default). Duh. I really hate the way autoconf hides things in ".libs". I was doing a huge series of test builds and wasn't

Re: [sqlite] How to get the previous row before rows matching a where clause...

What about: select blah from blah where rowid < windowstartrowid order by rowid desc limit 1 to get the row before, and: select blah from blah where rowid > windowlastrowid limit 1 to get the row after. Jim On 3/22/09, sorka wrote: > > I have a table of events

Re: [sqlite] How to get the previous row before rows matching a where clause...

sorka wrote: > I have a table of events that have a title, start time, and end time. > > The start time is guaranteed unique, so I've made it my primary integer key. > > I need all events that overlap the a window of time between say windowstart > and windowend. Currently, the statement > >

Re: [sqlite] How to get the previous row before rows matching a where clause...

On Sun, Mar 22, 2009 at 4:23 PM, sorka wrote: > > I have a table of events that have a title, start time, and end time. > > The start time is guaranteed unique, so I've made it my primary integer key. > > I need all events that overlap the a window of time between say

[sqlite] SQLite3 & Code::Blocks

Hello everyone. While not new to Code::Blocks and SQLite3, I have never until today tried to use them together. I am having a problem getting my proof-of-concept code to compile. Any assistance would be appreciated. First, my environment: - WinXP - Code::Blocks 8.02 w/ MinGW compiler -

[sqlite] How to get the previous row before rows matching a where clause...

I have a table of events that have a title, start time, and end time. The start time is guaranteed unique, so I've made it my primary integer key. I need all events that overlap the a window of time between say windowstart and windowend. Currently, the statement SELECT title FROM event WHERE

Re: [sqlite] Schema syntax error

On Mar 18, 2009, at 9:39 PM, Tristan Seligmann wrote: > Divmod Axiom[1] is a Python ORM built on SQLite; one of the book > keeping tables it creates in the database has a column named > "indexed", which became a reserved word around SQLite 3.6.4 (?). The > "obvious" fix for this problem is to

Re: [sqlite] Replacement for sqlite_exec_printf

"BOB_GOREN" wrote in message news:ba7de4bcd2b86346ad08e3483a9a721e10a9a...@inetsrv.hv.amtote.com > I am converting from sqlite 2.8.13 to 3.6.11 and am wondering what is > the replacement for sqlite_exec_printf. The most direct replacement is sqlite3_mprintf followed by

[sqlite] Table problem

Hi, I've choosen sqlite 3.6.11 for a small purpose in my organisation. The software runs on a proprietroy OS. SQLite is used by a single process, there are no other threads using SQLite, hence SQLITE_THREADSAFE = 0. I have written the memory and OS functions. My Schema table is very simple, as

Re: [sqlite] Use sqlite3_update_hook() to watch for changes

One method you can use to see changes is to hook up triggers on update/insert. Since you can add functions to be called from SQL, you just have to add whatever IPC system you desire as an SQLite function (see sqlite_create_function). This function can then be invoked through your triggers, and

[sqlite] Replacement for sqlite_exec_printf

I am converting from sqlite 2.8.13 to 3.6.11 and am wondering what is the replacement for sqlite_exec_printf. Also, are there any general instructions for converting an application from 2.8 to 3.6.11? Thanks, Bob Goren This email, and any documents or data attached hereto, is intended for

Re: [sqlite] speeding up row by row lookup in a large db

On Sun, Mar 22, 2009 at 6:14 AM, Stefan Evert wrote: .. > > However, Perl does introduce a lot of overhead, so it may not be the best > choice for high-performance applications.  In my simplistic benchmarks, Perl > did not achieve more than approx. 400,000 subroutine calls

Re: [sqlite] speeding up row by row lookup in a large db

On 22 Mar 2009, at 00:27, P Kishor wrote: > Stefan, you were right about "Depends on how much data" part, but it > applied to the weather data, not the lookup tables for lc (or > landcover) or dist (or disturbance). > > Also, "Even for Perl/DBI" makes it seem there is something wrong with >