Re: [sqlite] 3.2.7 and russian characters

[Slavomir Svetlik]

>   Why 3.2.7 version can not open database with path that contains

>   russian characters?

>

> Best regards  Sergey Startsev



I can not open database with sqlite.dll v. 3.2.7 which contains slovak 
characters too. For example with 3.2.2 this is no problem.


__
Web hosting a registrácia domén za skvelé ceny - http://www.superhosting.sk/

[sqlite] 3.2.7 and russian characters

[Sergey Startsev]

Hi all!

  Why 3.2.7 version can not open database with path that contains
  russian characters?

-- 
Best regards

 Sergey Startsev
 SQLite Analyzer - SQLite database management tool with GUI.
 http://www.kraslabs.com/sqlite_analyzer.html

Re: [sqlite] SQLite is Awesome

[Edward Wilson]

Ditto [almost]

Anyone who blesses the world with such a great gift can spell however they want 
... 

Sqlite is a 'weapon of the warriors' -- it completely changes the game.

Thanks Mr. Hipp, and congrats on your well deserved award.

-
e


--- Chris Gurtler <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> Ok, so Mr. Hipp's spelling may need a little work, but SQLite has got to be 
> the best bit of
> software that I have come accross for quite a while.
> 
> Thank you !!
> 
> 
> Regards,
> 
> Chris
> 
> 
> 
> 
> 
> 




__ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/

Re: [sqlite] windowing functions != recursive functions

[drh]

"pilot pirx" <[EMAIL PROTECTED]> wrote:
 
> Now, for the recursive function like exponential moving average 
> the defintion is that
>
> ema(i+1) =  val(i) * coef  + ema(i) * (1-coef).
>
> That is I have to know the previous value of both EMA _and_  VALUE 
> (while for moving avearage I need to know _only_ the previous value(s)
> of VALUE. 
> 

You could write an "ema()" function for SQLite using the
scarcely documented API functions sqlite3_get_auxdata() and
sqlite3_set_auxdata().  (Those routines were intended to allow
functions like "regexp" to compile a constant regular expression
once and then reused the compiled regular expression on
subsequent calls.  But they have never been used for anything,
as far as I am aware.)

The ema() function would work like this:

   SELECT ema(x, 0.45) FROM table1;

Where 0.45 is the "coef".

I was wondering if it would be possible to write a "prev()"
function that returned the value of a column in the result
set from the previous row.  prev() could be used to implement
ema() in pure SQL.  But, alas, I do not see how you could
write a general-purpose prev() function using the current
API.  Some kind of extension would be required, I think.
--
D. Richard Hipp <[EMAIL PROTECTED]>

[sqlite] wiindow functions and recursive functions

[pilot pirx]

> I don't see why this is such a great feature.  Without it, worst case,
> you could still write a simple little loop which would issue one
> update statement for each row, all within a single transaction.  No?

that would require writing in C, bindind etc. Or, for some other databases,
writing in some stored procedure language. Here I have that with
stadard-looking sql in a small database. One 'quirk' of the implementation
(i am not sure it was intended) gives enormous additional
programming facility without any additional work :-)

> > Vastly more useful for moving average and the like would be real
> > windowing/grouping functions, like Oracle's "analytic" functions.  I'm

Example of computing moving average with standard sql is in one of my earlier 
mails.
I think that adding OLAP functions to such a small engine would be an overkill,
especially as most such functionality can be expressed with standard SQL
(admittedly, convoluted a bit).
The owner of the project will ultimately decide. 
It may not fit into the 'lite' 
image this project is after.


P.S. I remember seeing a public domain code adding 
correlation and regression to SQLite, but it was
about 3 years old - it was rather short. Yet, even that
did not make it into the mainstream project. 

- Original Message -
From: "Andrew Piskorski" <[EMAIL PROTECTED]>
To: sqlite-users@sqlite.org
Subject: [sqlite] SQL Window/OLAP functions
Date: Wed, 12 Oct 2005 08:34:02 -0400

> 
> On Wed, Oct 12, 2005 at 05:12:05AM -0500, pilot pirx wrote:
> > Subject: [sqlite] Please, please do _not_ remove this feature from SQLite...
> 
> > While using SQLite for some time (with R package, www.r-project.org)
> > I did admire its functionality and speed. Then I did discover a
> > hidden SQLite feature of immense usefulness - not available in other
> > databases. SQLite can compute Fibonacci numbers! (I will explain why
> 
> Transaction visibility features do vary, although often it doesn't
> matter anyway.  E.g., here's a dicussion of how (at least as of early
> 2004), PostgreSQL's docs were quite confused about certain subtleties,
> but what I find interesting, is this was still something that in
> practice had never really mattered to the mostly hard-core RDBMS
> programmers talking about it in that thread:
> 
>http://openacs.org/forums/message-view?message_id=176198
> 
> > UPDATE fib SET
> > val =  (SELECT h1.val FROM fib as h1 where pos = fib.pos - 1) +
> >(SELECT h2.val FROM fib as h2 where pos = fib.pos - 2)
> > WHERE pos > 2;
> 
> I don't see why this is such a great feature.  Without it, worst case,
> you could still write a simple little loop which would issue one
> update statement for each row, all within a single transaction.  No?
> 
> > This is an _immensely_ useful functionality when one needs to
> > compute various recursive functions. For example exponential moving
> > average, used frequently in financials. Or Kalman filter (and many
> 
> Vastly more useful for moving average and the like would be real
> windowing/grouping functions, like Oracle's "analytic" functions.  I'm
> not thrilled by their particular syntax, but the functionality is
> INCREDIBLY useful.  (And on the other hand, I haven't thought of any
> obviously better syntax, either.)
> 
> Hm, an amendement to the SQL:1999 spec added windowing support, and
> SQL:2003 includes that, I think as features T611, "Elementrary OLAP
> functions" and T612, "Advanced OLAP functions".  Apparently Fred Zemke
> of Oracle was the author of that SQL spec, and IBM also supported it,
> so the SQL:2003 syntax and behavior is probably very similar (maybe
> identical?) to what Oracle 8i, 9i, and 10g and IBM's DB2 already have.
> PostgreSQL, as of 8.0, doesn't support it yet.
> 
>http://www.wintercorp.com/rwintercolumns/SQL_99snewolapfunctions.html
>http://www.ncb.ernet.in/education/modules/dbms/SQL99/OLAP-99-154r2.pdf
>http://www.wiscorp.com/sql/SQL2003Features.pdf
>http://troels.arvin.dk/db/rdbms/#select-limit-offset
>http://www.postgresql.org/docs/8.0/interactive/features.html
>http://en.wikipedia.org/wiki/SQL
>http://www.sigmod.org/sigmod/record/issues/0403/E.JimAndrew-standard.pdf
>http://www.oracle.com/oramag/oracle/01-jul/o41industry.html
> 
> SQLite basically supports just SQL-92, it doesn't have any of these
> newer SQL:1999 or SQL:2003 features, right?
> 
> Using SQLite in conjunction with a powerful statistical data analysis
> programming language like R is an excellent example of a use where
> windowing functions can be hugely helpful.  Unfortunately, I've never
> had a compelling need to use SQLite for that, otherwise I'd probably
> take a shot at adding support for the SQL:2003 Window/OLAP stuff.  :)
> 
> --
> Andrew Piskorski <[EMAIL PROTECTED]>
> http://www.piskorski.com/


-- 
___
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

[sqlite] windowing functions != recursive functions

[pilot pirx]

I was unaware of the windowing functions discusssion.
Having a look at the first link, it looks like we may be
talking about two subtly different issues.
The windowing functions described in the link
are different from recursive functions. 
There is no problem in computing moving average
or cumulative sum etc 
with the existing SQL (or dealing with time windows
in general)  - it just the SQL gets nasty - examples
are in 'SQL for smarties' by Joe Celko. Therefore
adding such functions to SQLite is 'nice' but does
not really increase the functionality.

In contrast, computation of the recursion function
adds it. 

example with moving averages, since they
are mentioned in the windowing functions

assuming original series is
VALUE = 1 2 3 4 5 6 7

following statement will compute 5-day moving average for the whole column
UPDATE data SET 
MAVE5 = (SELECT AVG(val) FROM data AS h1 WHERE h1.dayno <=  data.dayno 
AND h1.dayno > data.dayno-05);
But this statement operates always on existing data in the existing column - to 
compute new value of MAVE5 it only needs to know values of VALUE. (When, for 
the element one, there is not enough data (because there is no dayno < 1)  SQL 
simply averages over existing data.)

Now, for the recursive function like exponential moving average the defintion 
is that
ema(i+1) =  val(i) * coef  + ema(i) * (1-coef). That is I have to know the 
previous value of
both EMA _and_  VALUE (while for moving avearage I need to know _only_
the previous value(s) of VALUE. 


- Original Message -
From: "Andrew Piskorski" <[EMAIL PROTECTED]>
To: sqlite-users@sqlite.org
Subject: [sqlite] SQL Window/OLAP functions
Date: Wed, 12 Oct 2005 08:34:02 -0400

> 
> On Wed, Oct 12, 2005 at 05:12:05AM -0500, pilot pirx wrote:
> > Subject: [sqlite] Please, please do _not_ remove this feature from SQLite...
> 
> > While using SQLite for some time (with R package, www.r-project.org)
> > I did admire its functionality and speed. Then I did discover a
> > hidden SQLite feature of immense usefulness - not available in other
> > databases. SQLite can compute Fibonacci numbers! (I will explain why
> 
> Transaction visibility features do vary, although often it doesn't
> matter anyway.  E.g., here's a dicussion of how (at least as of early
> 2004), PostgreSQL's docs were quite confused about certain subtleties,
> but what I find interesting, is this was still something that in
> practice had never really mattered to the mostly hard-core RDBMS
> programmers talking about it in that thread:
> 
>http://openacs.org/forums/message-view?message_id=176198
> 
> > UPDATE fib SET
> > val =  (SELECT h1.val FROM fib as h1 where pos = fib.pos - 1) +
> >(SELECT h2.val FROM fib as h2 where pos = fib.pos - 2)
> > WHERE pos > 2;
> 
> I don't see why this is such a great feature.  Without it, worst case,
> you could still write a simple little loop which would issue one
> update statement for each row, all within a single transaction.  No?
> 
> > This is an _immensely_ useful functionality when one needs to
> > compute various recursive functions. For example exponential moving
> > average, used frequently in financials. Or Kalman filter (and many
> 
> Vastly more useful for moving average and the like would be real
> windowing/grouping functions, like Oracle's "analytic" functions.  I'm
> not thrilled by their particular syntax, but the functionality is
> INCREDIBLY useful.  (And on the other hand, I haven't thought of any
> obviously better syntax, either.)
> 
> Hm, an amendement to the SQL:1999 spec added windowing support, and
> SQL:2003 includes that, I think as features T611, "Elementrary OLAP
> functions" and T612, "Advanced OLAP functions".  Apparently Fred Zemke
> of Oracle was the author of that SQL spec, and IBM also supported it,
> so the SQL:2003 syntax and behavior is probably very similar (maybe
> identical?) to what Oracle 8i, 9i, and 10g and IBM's DB2 already have.
> PostgreSQL, as of 8.0, doesn't support it yet.
> 
>http://www.wintercorp.com/rwintercolumns/SQL_99snewolapfunctions.html
>http://www.ncb.ernet.in/education/modules/dbms/SQL99/OLAP-99-154r2.pdf
>http://www.wiscorp.com/sql/SQL2003Features.pdf
>http://troels.arvin.dk/db/rdbms/#select-limit-offset
>http://www.postgresql.org/docs/8.0/interactive/features.html
>http://en.wikipedia.org/wiki/SQL
>http://www.sigmod.org/sigmod/record/issues/0403/E.JimAndrew-standard.pdf
>http://www.oracle.com/oramag/oracle/01-jul/o41industry.html
> 
> SQLite basically supports just SQL-92, it doesn't have any of these
> newer SQL:1999 or SQL:2003 features, right?
> 
> Using SQLite in conjunction with a powerful statistical data analysis
> programming language like R is an excellent example of a use where
> windowing functions can be hugely helpful.  Unfortunately, I've never
> had a compelling need to use SQLite for that, otherwise I'd probably
> take a shot at adding support for the SQL:2003 Window/OLAP stuff.  :

Re: [sqlite] SQL Window/OLAP functions

[pilot pirx]

I did use R extensively for years and with SQLite for the last year. 
My observations, for what they are worth, about statistics and databases.

A stats package, especially as powerful as R, makes any database functions
less relevant. After trying various approaches I use now the database mostly 
 - to reduce data somewhat before getting them to R. 
   For example, with 2 mln records in 500 groups I can compute group 
   averages in the database and read into R only 500 records. 
- to reduce overall memory requirements - I can process the whole 
  data set on group-by-group basis - reading one group at a time.
  thus requiring less memory internally

Any stats package will have many functions, most of them impossible to
implement in standard SQL and very difficult to implement in general.
(like clustering etc).

So why do I write filters in the database, instead of using vastly superior 
R capabilities? Firstly, for fun - just liked to push SQL as far as possible.
Secondly - it is sometimes useful to compute some basic things during
or immediately after data acquisition. If we can compute some 
_simple_ metrics at that stage _quickly_ then R does not have to
read and process that much, as only data withing some range of metric
may be of interest. Also, we can index on a metric and provide very
fast extraction of data subsets.

In summary it seems to me that adding too heavy functions to any database
may be difficult and, for SQLite, going against the basic idea of 
having a 'lite' db. 






- Original Message -
From: Laurent <[EMAIL PROTECTED]>
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] SQL Window/OLAP functions
Date: Wed, 12 Oct 2005 15:36:22 +0200

> 
> Hello,
> 
> I was just looking for a statiscal package linked with SQLITE.
> >
> > Using SQLite in conjunction with a powerful statistical data analysis
> > programming language like R is an excellent example of a use where
> > windowing functions can be hugely helpful.  Unfortunately, I've never
> > had a compelling need to use SQLite for that, otherwise I'd probably
> > take a shot at adding support for the SQL:2003 Window/OLAP stuff.  :)
> >
> I can confirm that there would be some interest in having such a library.
> 
> Best regards,
> 
> Laurent.
> 
> ==
> 
> - Original Message -
> From: "Andrew Piskorski" <[EMAIL PROTECTED]>
> To: 
> Sent: Wednesday, October 12, 2005 2:34 PM
> Subject: [sqlite] SQL Window/OLAP functions
> 
> 
> > On Wed, Oct 12, 2005 at 05:12:05AM -0500, pilot pirx wrote:
> > > Subject: [sqlite] Please, please do _not_ remove this feature from
> SQLite...
> >
> > > While using SQLite for some time (with R package, www.r-project.org)
> > > I did admire its functionality and speed. Then I did discover a
> > > hidden SQLite feature of immense usefulness - not available in other
> > > databases. SQLite can compute Fibonacci numbers! (I will explain why
> >
> > Transaction visibility features do vary, although often it doesn't
> > matter anyway.  E.g., here's a dicussion of how (at least as of early
> > 2004), PostgreSQL's docs were quite confused about certain subtleties,
> > but what I find interesting, is this was still something that in
> > practice had never really mattered to the mostly hard-core RDBMS
> > programmers talking about it in that thread:
> >
> >   http://openacs.org/forums/message-view?message_id=176198
> >
> > > UPDATE fib SET
> > > val =  (SELECT h1.val FROM fib as h1 where pos = fib.pos - 1) +
> > >(SELECT h2.val FROM fib as h2 where pos = fib.pos - 2)
> > > WHERE pos > 2;
> >
> > I don't see why this is such a great feature.  Without it, worst case,
> > you could still write a simple little loop which would issue one
> > update statement for each row, all within a single transaction.  No?
> >
> > > This is an _immensely_ useful functionality when one needs to
> > > compute various recursive functions. For example exponential moving
> > > average, used frequently in financials. Or Kalman filter (and many
> >
> > Vastly more useful for moving average and the like would be real
> > windowing/grouping functions, like Oracle's "analytic" functions.  I'm
> > not thrilled by their particular syntax, but the functionality is
> > INCREDIBLY useful.  (And on the other hand, I haven't thought of any
> > obviously better syntax, either.)
> >
> > Hm, an amendement to the SQL:1999 spec added windowing support, and
> > SQL:2003 includes that, I think as features T611, "Elementrary OLAP
> > functions" and T612, "Advanced OLAP functions".  Apparently Fred Zemke
> > of Oracle was the author of that SQL spec, and IBM also supported it,
> > so the SQL:2003 syntax and behavior is probably very similar (maybe
> > identical?) to what Oracle 8i, 9i, and 10g and IBM's DB2 already have.
> > PostgreSQL, as of 8.0, doesn't support it yet.
> >
> >   http://www.wintercorp.com/rwintercolumns/SQL_99snewolapfunctions.html
> >   http://www.ncb.ernet.in/education/modules/dbms/SQL99/OLAP-99-154r2.pdf
> >   http

Re: [sqlite] fdatasync and 3.2.7

[drh]

"Fletcher Mattox" <[EMAIL PROTECTED]> wrote:
> Hi.
> 
> I'm new.  I searched the archives and see where the problem
> of an undefined fdatasync in 3.2.6 was discussed.  I assumed
> it was fixed, but I just got it in 3.2.7 under Solaris 9, which
> defines _POSIX_SYNCHRONIZED_IO.  This define triggers the
> error.  Am I missing something obvious?
> 

http://www.sqlite.org/cvstrac/chngview?cn=2741

SQLite now uses only fsync by default. Only if the configure
script detects the fdatasync function does it attempt to use
fdatasync.  

The change will appear in the next release.

You can always do "-Dfdatasync=fsync" on your compiler
command line to clear the problem in the meantime.
--
D. Richard Hipp <[EMAIL PROTECTED]>

[sqlite] fdatasync and 3.2.7

[Fletcher Mattox]

Hi.

I'm new.  I searched the archives and see where the problem
of an undefined fdatasync in 3.2.6 was discussed.  I assumed
it was fixed, but I just got it in 3.2.7 under Solaris 9, which
defines _POSIX_SYNCHRONIZED_IO.  This define triggers the
error.  Am I missing something obvious?

Thanks
Fletcher

Re: [sqlite] SQL Window/OLAP functions

[rbundy]

Seconded.



|-+>
| |   "Laurent"|
| |   <[EMAIL PROTECTED]|
| |   ternet.fr>   |
| ||
| |   12/10/2005 23:36 |
| |   Please respond to|
| |   sqlite-users |
| ||
|-+>
  
>--|
  | 
 |
  |   To:  
 |
  |   cc:   
 |
  |   Subject:  Re: [sqlite] SQL Window/OLAP functions  
 |
  
>--|




Hello,

I was just looking for a statiscal package linked with SQLITE.
>
> Using SQLite in conjunction with a powerful statistical data analysis
> programming language like R is an excellent example of a use where
> windowing functions can be hugely helpful.  Unfortunately, I've never
> had a compelling need to use SQLite for that, otherwise I'd probably
> take a shot at adding support for the SQL:2003 Window/OLAP stuff.  :)
>
I can confirm that there would be some interest in having such a library.

Best regards,

Laurent.

==

- Original Message -
From: "Andrew Piskorski" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, October 12, 2005 2:34 PM
Subject: [sqlite] SQL Window/OLAP functions


> On Wed, Oct 12, 2005 at 05:12:05AM -0500, pilot pirx wrote:
> > Subject: [sqlite] Please, please do _not_ remove this feature from
SQLite...
>
> > While using SQLite for some time (with R package, www.r-project.org)
> > I did admire its functionality and speed. Then I did discover a
> > hidden SQLite feature of immense usefulness - not available in other
> > databases. SQLite can compute Fibonacci numbers! (I will explain why
>
> Transaction visibility features do vary, although often it doesn't
> matter anyway.  E.g., here's a dicussion of how (at least as of early
> 2004), PostgreSQL's docs were quite confused about certain subtleties,
> but what I find interesting, is this was still something that in
> practice had never really mattered to the mostly hard-core RDBMS
> programmers talking about it in that thread:
>
>   http://openacs.org/forums/message-view?message_id=176198
>
> > UPDATE fib SET
> > val =  (SELECT h1.val FROM fib as h1 where pos = fib.pos - 1) +
> >(SELECT h2.val FROM fib as h2 where pos = fib.pos - 2)
> > WHERE pos > 2;
>
> I don't see why this is such a great feature.  Without it, worst case,
> you could still write a simple little loop which would issue one
> update statement for each row, all within a single transaction.  No?
>
> > This is an _immensely_ useful functionality when one needs to
> > compute various recursive functions. For example exponential moving
> > average, used frequently in financials. Or Kalman filter (and many
>
> Vastly more useful for moving average and the like would be real
> windowing/grouping functions, like Oracle's "analytic" functions.  I'm
> not thrilled by their particular syntax, but the functionality is
> INCREDIBLY useful.  (And on the other hand, I haven't thought of any
> obviously better syntax, either.)
>
> Hm, an amendement to the SQL:1999 spec added windowing support, and
> SQL:2003 includes that, I think as features T611, "Elementrary OLAP
> functions" and T612, "Advanced OLAP functions".  Apparently Fred Zemke
> of Oracle was the author of that SQL spec, and IBM also supported it,
> so the SQL:2003 syntax and behavior is probably very similar (maybe
> identical?) to what Oracle 8i, 9i, and 10g and IBM's DB2 already have.
> PostgreSQL, as of 8.0, doesn't support it yet.
>
>   http://www.wintercorp.com/rwintercolumns/SQL_99snewolapfunctions.html
>   http://www.ncb.ernet.in/education/modules/dbms/SQL99/OLAP-99-154r2.pdf
>   http://www.wiscorp.com/sql/SQL2003Features.pdf
>   http://troels.arvin.dk/db/rdbms/#select-limit-offset
>   http://www.postgresql.org/docs/8.0/interactive/features.html
>   http://en.wikipedia.org/wiki/SQL
>
http://www.sigmod.org/sigmod/record/issues/0403/E.JimAndrew-standard.pdf
>   http://www.oracle.com/oramag/oracle/01-jul/o41industry.html
>
> SQLite basically supports just SQL-92, it doesn't have any of these
> newer SQL:1999 or SQL:2003 features, right?
>
> Using SQLite in conjunction with a powerful statistical data analysis
> programming language like R is an excellent example of a use where
> windowing functions can be hugely helpful.  Unfortunately, I've never
> had a compelling need to use SQLite for that, otherwise I'd probably

[sqlite] RE: full column names in 3.2.7

[Radu Lodina]

Hi,

This pragma works for me (3.2.7):

sqlite> pragma short_column_names=0;
sqlite> pragma full_column_names=1;
sqlite> .header on


Set short_ = 0 and full_ = 1

You can check the curent value of pragma directive with: pragma 


sqlite> pragma short_column_names;
0  // -> display of short column name deactivated


sqlite> pragma full_column_names;
1  // -> display of full column name ACTIVATED

Regards
Radu Lodina

[sqlite] How to retreive (for a column): original field name and base table name from a sqlite3_stmt*

[Radu Lodina]

Hi,

1. Retrieve original field name:

 CREATE TABLE A (ID int, Name );
SELECT ID AS MyID, Name As MyName FROM A

sqlite3_column_name - return the alias MyID - It's a way to obtain the real
name of column (ID) based on sqlite3_stmt* pointer ?

2. Retrieve base table name:

 CREATE TABLE B (ID int );
SELECT B.ID  AS MyID, A.Name As MyName FROM A LEFT OUTER JOIN B
ON A.ID  = B.ID 

It's there a way to obtain the base table name for MyID field (B).


For both case I only have sqlite3_stmt* pointer ( parse sqlStatement string
it's not a acceptable solution).

Thank you.


Regards
Radu Lodina

[sqlite] SQLite vs. Firebird wiki page

[Robert Simpson]

I don't really want to update it myself, but under the section regarding the 
database sizes being similar -- I've found that not to be the case at least 
in the one very simplistic case I tried:


Using the following schema:
CREATE TABLE Foo ([Id] INTEGER NOT NULL PRIMARY KEY)

Inserting 100,000 items into a sqlite and firebird database, then updating 
all 100,000 with an UPDATE statement, the final database size was:


SQLite (3.2.5) :   819,200 bytes
Firebird (1.5.2.4731 embedded) : 8,736,768 bytes

Robert

RE: [sqlite] vxworks

[Mr. Tezozomoc]

We have been successfully been using sqlite in several flavors of Vxworks.

I have ported it over to PPC604, X86, and PC_SIM.

We had to do some kludging to get it to work concurrently and coherently.

1.  We modified os.c and added a semaphore for the singleton file.
2.  We wrote our own arbitration handle between processes so, if one 
data base is common across tasks, it needs arbitration and separate handles 
to it.
3.  If you plan on using in memory databases we switched them over to a ram 
drive and it the rest of the arbitration works just fine.


We have used this port successfully across several projects.

Please let me know if this helps.

Tezozomoc.


Original Message Follows
From: Martin Pfeifle <[EMAIL PROTECTED]>
Reply-To: sqlite-users@sqlite.org
To: sqlite-users@sqlite.org
Subject: [sqlite] vxworks
Date: Wed, 12 Oct 2005 15:01:32 +0200 (CEST)

Hi,
I am in deep trouble. I would like to use sqlite on
vxworks. There are no fysnc, fcntl calls available
which are used in os_unix.c.
Can anybody help me? PLEASE!







___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: 
http://mail.yahoo.de

Re: [sqlite] sqlite and spatial extension

[Noel Frankinet]

Rajan, Vivek K wrote:

Hello- 


Are there spatial extensions available for sqlite? And/or is there any
add-on library/shareware/freeware which can enable spatial
extensions/queries with SQLite? 


Rajan



 


Hello,

None that I'm aware of also I do use sqlite to store geagraphical info, 
but as a blob.
I have a crude spatial indexing but I would like to find a better 
solution. Any idea ?


--
Noël Frankinet
Gistek Software SA
http://www.gistek.net

Ant: Re: [sqlite] vxworks

[Martin Pfeifle]

Hi,
I used the  DJGPP compile option and replaced the
Fsync call by ioctl(fd, FIOSYNC, 0).
I hope this works. Thank you.
Best Martin
--- John Stanton <[EMAIL PROTECTED]> schrieb:

> Fcntl is only used for locking.  Would your
> application be multi-user? 
> if so you could replace the file locking with some
> form of co-operative 
> lock or find out if a Windriver alternative file
> locking mechanism 
> exists and use it.  I would imagine a single user
> application can just 
> omit the locks by using the DJGPP compile option to
> insert a dummy fcntl.
> 
> Fsync just syncs the file by writing through the
> buffers.  Does Vxworks 
> have buffering on its file system?  Fsync may be
> unecessary and you can 
> compile Sqlite with the SQLITE_NO_SYNC option to
> omit it.
> 
> JS
> 
> Martin Pfeifle wrote:
> > Hi,
> > I am in deep trouble. I would like to use sqlite
> on
> > vxworks. There are no fysnc, fcntl calls available
> > which are used in os_unix.c. 
> > Can anybody help me? PLEASE!
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
>
___
> 
> > Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher
> kostenlos - Hier anmelden: http://mail.yahoo.de
> 
> 







___ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: 
http://mail.yahoo.de

[sqlite] sqlite and spatial extension

[Rajan, Vivek K]

Hello- 

Are there spatial extensions available for sqlite? And/or is there any
add-on library/shareware/freeware which can enable spatial
extensions/queries with SQLite? 

Rajan

Re: [sqlite] vxworks

[John Stanton]

Fcntl is only used for locking.  Would your application be multi-user? 
if so you could replace the file locking with some form of co-operative 
lock or find out if a Windriver alternative file locking mechanism 
exists and use it.  I would imagine a single user application can just 
omit the locks by using the DJGPP compile option to insert a dummy fcntl.


Fsync just syncs the file by writing through the buffers.  Does Vxworks 
have buffering on its file system?  Fsync may be unecessary and you can 
compile Sqlite with the SQLITE_NO_SYNC option to omit it.


JS

Martin Pfeifle wrote:

Hi,
I am in deep trouble. I would like to use sqlite on
vxworks. There are no fysnc, fcntl calls available
which are used in os_unix.c. 
Can anybody help me? PLEASE!








___ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

Re: [sqlite] help needed with syntax error in between.test script

[drh]

Jacob Dall <[EMAIL PROTECTED]> wrote:
> Yes, I understand.
> 
> Would you mind to enlighten me a bit?
> 
> This test script, is it pure Tcl?
> 

Pure Tcl?  Not sure what you mean.  The "testfixture"
program adds dozens of new commands and variable linkages
used for testing the SQLite code.  See the source
files test1.c through test5.c for details.  But there
is still a pure unmodified Tcl core underneath.
--
D. Richard Hipp <[EMAIL PROTECTED]>

Re: [sqlite] help needed with syntax error in between.test script

[Jacob Dall]

Yes, I understand.

Would you mind to enlighten me a bit?

This test script, is it pure Tcl?

If so, I guess I've to look into the compilation of Tcl.

Thank you for your time,

Jacob

At 15:41 12/10/2005, you wrote:

Jacob Dall <[EMAIL PROTECTED]> wrote:
> Hello everyone,
>
> I've just managed to get SQLite v3.2.7 compiled and installed on a
> QNX platform.
>
> When executing the test suite (make test) I'm notified of an error in
> the between-1.0 test. The message is:
>
> Error: syntax error in expression "int(log($i)/log(2))": extra tokens
> at end of expression
>
> The involved line (line 29) in the script reads:
>
>  set x [expr {int(log($i)/log(2))}]
>
> I'm a complete newbie on this kind of test scripts, so I really
> appreciate any help I can get.
>

I really have no idea what could be causing this. The
test script in question works fine on every other flavor
of Unix and on Windows.  And since I cannot reproduce the
problem, there is not much I can do to debug it.
--
D. Richard Hipp <[EMAIL PROTECTED]>


---
EURISCO
Forskerparken 10
DK-5230 Odense M
Tlf. 63 15 71 00
www.eurisco.dk
--- 

Re: [sqlite] Very Slow delete times on larger databases, please help!

[drh]

"Allan, Mark" <[EMAIL PROTECTED]> wrote:
> We are experiencing incredibly slow delete times when deleting a 
> large number of rows:-
> 
> We are using SQLite on an embdedded platform with an ARM7 processor,
> 2Mb RAM and 32Mb NOR Flash memory 25Mb of which is allocated for 
> storage for our database. 
>

What operating system?

Can you send the output of sqlite3_analyzer run against your
database file prior to doing the delete?

Have you tried upgrading to a later version of SQLite?

--
D. Richard Hipp <[EMAIL PROTECTED]>

Re: [sqlite] help needed with syntax error in between.test script

[drh]

Jacob Dall <[EMAIL PROTECTED]> wrote:
> Hello everyone,
> 
> I've just managed to get SQLite v3.2.7 compiled and installed on a 
> QNX platform.
> 
> When executing the test suite (make test) I'm notified of an error in 
> the between-1.0 test. The message is:
> 
> Error: syntax error in expression "int(log($i)/log(2))": extra tokens 
> at end of expression
> 
> The involved line (line 29) in the script reads:
> 
>  set x [expr {int(log($i)/log(2))}]
> 
> I'm a complete newbie on this kind of test scripts, so I really 
> appreciate any help I can get.
> 

I really have no idea what could be causing this. The
test script in question works fine on every other flavor
of Unix and on Windows.  And since I cannot reproduce the
problem, there is not much I can do to debug it.
--
D. Richard Hipp <[EMAIL PROTECTED]>

Re: [sqlite] SQL Window/OLAP functions

[Laurent]

Hello,

I was just looking for a statiscal package linked with SQLITE.
>
> Using SQLite in conjunction with a powerful statistical data analysis
> programming language like R is an excellent example of a use where
> windowing functions can be hugely helpful.  Unfortunately, I've never
> had a compelling need to use SQLite for that, otherwise I'd probably
> take a shot at adding support for the SQL:2003 Window/OLAP stuff.  :)
>
I can confirm that there would be some interest in having such a library.

Best regards,

Laurent.

==

- Original Message - 
From: "Andrew Piskorski" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, October 12, 2005 2:34 PM
Subject: [sqlite] SQL Window/OLAP functions


> On Wed, Oct 12, 2005 at 05:12:05AM -0500, pilot pirx wrote:
> > Subject: [sqlite] Please, please do _not_ remove this feature from
SQLite...
>
> > While using SQLite for some time (with R package, www.r-project.org)
> > I did admire its functionality and speed. Then I did discover a
> > hidden SQLite feature of immense usefulness - not available in other
> > databases. SQLite can compute Fibonacci numbers! (I will explain why
>
> Transaction visibility features do vary, although often it doesn't
> matter anyway.  E.g., here's a dicussion of how (at least as of early
> 2004), PostgreSQL's docs were quite confused about certain subtleties,
> but what I find interesting, is this was still something that in
> practice had never really mattered to the mostly hard-core RDBMS
> programmers talking about it in that thread:
>
>   http://openacs.org/forums/message-view?message_id=176198
>
> > UPDATE fib SET
> > val =  (SELECT h1.val FROM fib as h1 where pos = fib.pos - 1) +
> >(SELECT h2.val FROM fib as h2 where pos = fib.pos - 2)
> > WHERE pos > 2;
>
> I don't see why this is such a great feature.  Without it, worst case,
> you could still write a simple little loop which would issue one
> update statement for each row, all within a single transaction.  No?
>
> > This is an _immensely_ useful functionality when one needs to
> > compute various recursive functions. For example exponential moving
> > average, used frequently in financials. Or Kalman filter (and many
>
> Vastly more useful for moving average and the like would be real
> windowing/grouping functions, like Oracle's "analytic" functions.  I'm
> not thrilled by their particular syntax, but the functionality is
> INCREDIBLY useful.  (And on the other hand, I haven't thought of any
> obviously better syntax, either.)
>
> Hm, an amendement to the SQL:1999 spec added windowing support, and
> SQL:2003 includes that, I think as features T611, "Elementrary OLAP
> functions" and T612, "Advanced OLAP functions".  Apparently Fred Zemke
> of Oracle was the author of that SQL spec, and IBM also supported it,
> so the SQL:2003 syntax and behavior is probably very similar (maybe
> identical?) to what Oracle 8i, 9i, and 10g and IBM's DB2 already have.
> PostgreSQL, as of 8.0, doesn't support it yet.
>
>   http://www.wintercorp.com/rwintercolumns/SQL_99snewolapfunctions.html
>   http://www.ncb.ernet.in/education/modules/dbms/SQL99/OLAP-99-154r2.pdf
>   http://www.wiscorp.com/sql/SQL2003Features.pdf
>   http://troels.arvin.dk/db/rdbms/#select-limit-offset
>   http://www.postgresql.org/docs/8.0/interactive/features.html
>   http://en.wikipedia.org/wiki/SQL
>   http://www.sigmod.org/sigmod/record/issues/0403/E.JimAndrew-standard.pdf
>   http://www.oracle.com/oramag/oracle/01-jul/o41industry.html
>
> SQLite basically supports just SQL-92, it doesn't have any of these
> newer SQL:1999 or SQL:2003 features, right?
>
> Using SQLite in conjunction with a powerful statistical data analysis
> programming language like R is an excellent example of a use where
> windowing functions can be hugely helpful.  Unfortunately, I've never
> had a compelling need to use SQLite for that, otherwise I'd probably
> take a shot at adding support for the SQL:2003 Window/OLAP stuff.  :)
>
> -- 
> Andrew Piskorski <[EMAIL PROTECTED]>
> http://www.piskorski.com/
>

Re: [sqlite] Infinite loop on sqlite3_close()

[drh]

"Preston Zaugg" <[EMAIL PROTECTED]> wrote:
> While running some performance tests i ran into a condition where 
> sqlite3_close got caught in an infinite loop.
> The loop it gets caught in is on line main.c 194:
> while( pPrev && pPrev->pNext!=db ){
>   pPrev = pPrev->pNext;
> }
> 
> This did not happen until i upgraded to 3.2.7, not the only change, but the 
> most significant. This is repeatable, but does not happen in the same spot 
> each time.
> 

I am unable to reproduce the problem.

--
D. Richard Hipp <[EMAIL PROTECTED]>

Re: [sqlite] vxworks

[drh]

Martin Pfeifle <[EMAIL PROTECTED]> wrote:
> Hi,
> I am in deep trouble. I would like to use sqlite on
> vxworks. There are no fysnc, fcntl calls available
> which are used in os_unix.c. 
> Can anybody help me? PLEASE!
> 

You can comment-out those function calls.  SQLite will
still work, mostly.  If two or more processes try to
access a database at the same time, they will likely
collide and corruption the database file.  (That is what
fcntl() prevents).  So you should make sure that only
one process is using a database file at a time.  Also,
If you lose power while writing the database file it might
become corrupted.  (fsync() prevents that problem.) 
But apart from those two problems, everything should
still work.

Longer term, you should figure out how to lock files
and sync files in vxworks then write a new backend
(call it "os_vxworks.c") specifically designed for that
operating system.

--
D. Richard Hipp <[EMAIL PROTECTED]>

[sqlite] Very Slow delete times on larger databases, please help!

[Allan, Mark]

We are experiencing incredibly slow delete times when deleting a large number 
of rows:-

We are using SQLite on an embdedded platform with an ARM7 processor, 2Mb RAM 
and 32Mb NOR Flash memory 25Mb of which is allocated for storage for our 
database. 

There are 3 tables in the database but the two we are concerned with here are 
created as follows:-

CREATE TABLE EXAMINATIONS (
'EXAM_ID' integer PRIMARY KEY AUTOINCREMENT,
'PATIENT_ID' varchar(15) NOT NULL,
'STATUS_FLAG' smallint,
'DATE' timestamp,
'EXAM_TYPE' smallint, 
'DATE' timestamp,
'EXAM_TYPE' smallint,
'HEIGHT' smallint,
'WEIGHT' smallint,
'DYSPNOEA_SCORE' smallint,
'NOTES' varchar(450),
FOREIGN KEY (PATIENT_ID) REFERENCES PATIENTS(PATIENT_ID) ON DELETE 
CASCADE )

CREATE TABLE SPIRO_TEST(
'TEST_ID' integer PRIMARYKEY AUTOINCREMENT,
'EXAM_ID' integer NOT NULL,
'STATUS_FLAG' smallint,
'TEST_TYPE' smallint,
'DATE' timestamp,
'CONTENT' blob,
FOREIGN KEY (EXAM_ID) REFERENCES EXAMINATIONS(EXAM_ID) ON DELETE 
CASCADE )

Note: the following columns are indexed:-

EXAMINATIONS:-

PATIENT_ID
DATE
EXAM_TYPE
STATUS_FLAG

SPIRO_TEST

EXAM_ID



It is taking 6 minutes just to execute the following SQL:-

DELETE FROM SPIRO_TEST

Where SPIRO_TEST contains 11,601 records.

In reality we will never peform the above SQL on the database, we did this only 
to test how long it would take to delete all the records from the SPIRO_TEST 
table.

We did this as during testing we noticed that when running the following SQL it 
took 11 minutes to complete:-

DELETE FROM EXAMINATIONS WHERE DATE < datetime('2005-10-11 00:00:00')

There is a trigger on the SPIRO_TEST table to clear out related records in the 
module tables when an exam is deleted as such:-

CREATE TRIGGER MODULE_EXAM_TRIGG
BEFORE DELETE ON EXAMINATIONS
FOR EACH ROW BEGIN
DELETE FROM SPIRO_TEST WHERE EXAM_ID = OLD.EXAM_ID
END;

We have also tried removing this trigger and deleting related records from the 
SPIRO_TEST table maunually before deleting the exams but this took 20 minutes 
to complete.

We also notice that queries generally run slower when the database contains a 
large number of records.

Can anyone please help us determine what the problem is and suggest any fix?


Kind Regards

Mark Allan


PS

The SQL:- DELETE FROM EXAMINATIONS WHERE DATE < datetime('2005-10-11 
00:00:00'), when the trigger exists, results in the following opcodes:-

0   Goto0   112 
1   Statement   0   0   
2   Integer 0   0   
3   OpenRead2   14  keyinfo(1,BINARY)
4   KeyAsData   2   1   
5   SetNumColumns   2   2   
6   String8 0   0   11/10/2005 00:00
7   Function1   1   dateTime(1)
8   NotNull -1  11  
9   Pop 1   0   
10  Goto0   21  
11  MakeRecord  1   0   n
12  MemStore0   1   
13  Rewind  2   21  
14  MemLoad 0   0   
15  IdxGE   2   21  
16  RowKey  2   0   
17  IdxIsNull   1   20  
18  IdxRecno2   0   
19  ListWrite   0   0   
20  Next2   14  
21  Close   2   0   
22  OpenPseudo  0   0   
23  SetNumColumns   0   9   
24  ListRewind  0   0   
25  ListRead0   110 
26  Dup 0   0   
27  Integer 0   0   
28  OpenRead1   9   # EXAMINATIONS
29  SetNumColumns   1   9   
30  MoveGe  1   0   
31  Recno   1   0   
32  RowData 1   0   
33  PutIntKey   0   0   
34  Close   1   0   
35  ContextPush 0   0   # begin trigger fkd_SPIRO_TEST_EXAM_ID
36  ResetCount  0   0   
37  Integer 0   0   
38  OpenRead4   19  keyinfo(1,BINARY)
39  KeyAsData   4   1   
40  SetNumColumns   4   2   
41  Recno   0   0   
42  NotNull -1  45  
43  Pop 1   0   
44  Goto0   55  
45  MakeRecord  1   0   i
46  MemStore1   0   
47  MoveGe  4   55  
48  MemLoad 1   0   
49  IdxGE   4   55  +
50  RowKey  4   0   
51  IdxIsNull   1   54  
52  IdxRecno4   0   
53  ListWrite   0   0   
54  Next4   48  
55  Close   4   0   
56  ListRewind  0   0   
57  Integer 0   0   
58  OpenWrite   3   16  # SPIRO_TEST
59  SetNumColumns   3   6   
60  Integer 0   0   
61  OpenWrite   4   20  keyinfo(1

[sqlite] vxworks

[Martin Pfeifle]

Hi,
I am in deep trouble. I would like to use sqlite on
vxworks. There are no fysnc, fcntl calls available
which are used in os_unix.c. 
Can anybody help me? PLEASE!







___ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: 
http://mail.yahoo.de

[sqlite] SQL Window/OLAP functions

[Andrew Piskorski]

On Wed, Oct 12, 2005 at 05:12:05AM -0500, pilot pirx wrote:
> Subject: [sqlite] Please, please do _not_ remove this feature from SQLite...

> While using SQLite for some time (with R package, www.r-project.org)
> I did admire its functionality and speed. Then I did discover a
> hidden SQLite feature of immense usefulness - not available in other
> databases. SQLite can compute Fibonacci numbers! (I will explain why

Transaction visibility features do vary, although often it doesn't
matter anyway.  E.g., here's a dicussion of how (at least as of early
2004), PostgreSQL's docs were quite confused about certain subtleties,
but what I find interesting, is this was still something that in
practice had never really mattered to the mostly hard-core RDBMS
programmers talking about it in that thread:

  http://openacs.org/forums/message-view?message_id=176198

> UPDATE fib SET
> val =  (SELECT h1.val FROM fib as h1 where pos = fib.pos - 1) +
>(SELECT h2.val FROM fib as h2 where pos = fib.pos - 2)
> WHERE pos > 2;

I don't see why this is such a great feature.  Without it, worst case,
you could still write a simple little loop which would issue one
update statement for each row, all within a single transaction.  No?

> This is an _immensely_ useful functionality when one needs to
> compute various recursive functions. For example exponential moving
> average, used frequently in financials. Or Kalman filter (and many

Vastly more useful for moving average and the like would be real
windowing/grouping functions, like Oracle's "analytic" functions.  I'm
not thrilled by their particular syntax, but the functionality is
INCREDIBLY useful.  (And on the other hand, I haven't thought of any
obviously better syntax, either.)

Hm, an amendement to the SQL:1999 spec added windowing support, and
SQL:2003 includes that, I think as features T611, "Elementrary OLAP
functions" and T612, "Advanced OLAP functions".  Apparently Fred Zemke
of Oracle was the author of that SQL spec, and IBM also supported it,
so the SQL:2003 syntax and behavior is probably very similar (maybe
identical?) to what Oracle 8i, 9i, and 10g and IBM's DB2 already have.
PostgreSQL, as of 8.0, doesn't support it yet.

  http://www.wintercorp.com/rwintercolumns/SQL_99snewolapfunctions.html
  http://www.ncb.ernet.in/education/modules/dbms/SQL99/OLAP-99-154r2.pdf
  http://www.wiscorp.com/sql/SQL2003Features.pdf
  http://troels.arvin.dk/db/rdbms/#select-limit-offset
  http://www.postgresql.org/docs/8.0/interactive/features.html
  http://en.wikipedia.org/wiki/SQL
  http://www.sigmod.org/sigmod/record/issues/0403/E.JimAndrew-standard.pdf
  http://www.oracle.com/oramag/oracle/01-jul/o41industry.html

SQLite basically supports just SQL-92, it doesn't have any of these
newer SQL:1999 or SQL:2003 features, right?

Using SQLite in conjunction with a powerful statistical data analysis
programming language like R is an excellent example of a use where
windowing functions can be hugely helpful.  Unfortunately, I've never
had a compelling need to use SQLite for that, otherwise I'd probably
take a shot at adding support for the SQL:2003 Window/OLAP stuff.  :)

-- 
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com/

[sqlite] Please, please do _not_ remove this feature from SQLite...

[pilot pirx]

While using SQLite for some time (with R package, www.r-project.org) I did 
admire its functionality and speed. Then I did discover a hidden SQLite feature 
of immense usefulness - not available in other databases. SQLite can compute 
Fibonacci numbers! (I will explain why this is important later).

The are defined as follows: F1 = 1, F2 = 1; F3 = F1 + F2; F4 = F2 +F3  etc. So 
they are defined recursively, with the first two values known and each next 
value depending on the previous values. The SQL statement for that is (the full 
script at the end of this mail):

UPDATE fib SET
val =  (SELECT h1.val FROM fib as h1 where pos = fib.pos - 1) +
   (SELECT h2.val FROM fib as h2 where pos = fib.pos - 2)
WHERE pos > 2;

Now, in the standard SQL that should result in: 1,1,2,null,null,null... - 
because the assumption is that the operations on all rows are done at the same 
time.  So F4 will get null, because F3 was null etc. All other databases seem 
to do it - I tested HSQLDB, Firebird, SQLServer, Derby. 

Fortunately (for me) SQLite apparently stores rows after computation and the 
previous row's value is available when the next row is being computed. Also, 
the operations are executed in row order.  So I do get 1,1, 2, 3, 5, 8 ... 
(though some table/index declarations have to be right to achieve that for 
larger tables).

This is an _immensely_ useful functionality when one needs to compute various 
recursive functions. For example exponential moving average, used frequently in 
financials. Or Kalman filter (and many other filters) used in data smoothing 
and analysis.  Naturally, one could argue that databases are not for numerical 
computations. But it is very useful to be able to do simple computations in 
database,  especially if one does not have to write stored procedures or write 
external procedures for that - in essence getting something for free and 
without added complexity. So I hope that this feature will stay...


P.S. On somewhat related note: since sqlite is written in C - why it does not 
expose some basic functions from the standard C library (log, exp, sqrt, sin), 
at least optionally? Understandably, the idea is to keep it 'lite'. But, may 
be, an approach similar to ant and other packages could be applied to SQLite - 
that is there is a set of standard (but still simple) extensions, including 
things which may add some bulk, but do not require any large implementation 
effort.


= the test

DROP TABLE fib;
CREATE TABLE fib ( pos INTEGER, val INTEGER);
CREATE UNIQUE INDEX fib_ix ON fib(pos);
INSERT INTO fib VALUES (1,1);
INSERT INTO fib VALUES (2,1);
INSERT INTO fib VALUES (3,NULL);
INSERT INTO fib VALUES (4,NULL);
INSERT INTO fib VALUES (5,NULL);
INSERT INTO fib VALUES (6,NULL);
INSERT INTO fib VALUES (7,NULL);
INSERT INTO fib VALUES (8,NULL);
INSERT INTO fib VALUES (9,NULL);
INSERT INTO fib VALUES (10,NULL);
INSERT INTO fib VALUES (11,NULL);
INSERT INTO fib VALUES (12,NULL);
INSERT INTO fib VALUES (13,NULL);
INSERT INTO fib VALUES (14,NULL);
INSERT INTO fib VALUES (15,NULL);
INSERT INTO fib VALUES (16,NULL);
INSERT INTO fib VALUES (17,NULL);
INSERT INTO fib VALUES (18,NULL);
INSERT INTO fib VALUES (19,NULL);
INSERT INTO fib VALUES (20,NULL);
UPDATE fib SET -- compute fibonacci numbers
val =  (SELECT h1.val FROM fib as h1 where pos = fib.pos - 1) +
   (SELECT h2.val FROM fib as h2 where pos = fib.pos - 2)
WHERE pos > 2;

select * from fib; -- show the results



-- 
___
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

[sqlite] SQLite is Awesome

[Chris Gurtler]

Hi,

Ok, so Mr. Hipp's spelling may need a little work, but SQLite has got to be the 
best bit of software that I have come accross for quite a while.

Thank you !!


Regards,

Chris