[sqlite] NaN in, 0.0 out?

Thanks for all the answers. The solution to check first the type with sqlite3_column_type() and, if NULL, return NaN seems the most practicable one from a user's standpoint. A future sqlite3_column_double_v2() or another way to control the conversion of non-numeric values to double would be nice an

Re: [sqlite] NaN in, 0.0 out?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/03/12 21:48, Simon Slavin wrote: > But it's not what the docs say: NaN support changed in SQLite 3.5.9 (May 2008): http://www.sqlite.org/changes.html#version_3_5_9 However cvstrac no longer shows code so I couldn't work out if NaN was conver

Re: [sqlite] 64-bit Windows Command Shell

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/03/12 20:14, Jay A. Kreibich wrote: > Not to nit-pick, but an OS doesn't make it, or not make it, difficult > to compile something. That's usually due to crappy tools and poor > support. Yes, but the tools primarily come from the OS vendor.

Re: [sqlite] NaN in, 0.0 out?

On 25 Mar 2012, at 3:48am, "Jay A. Kreibich" wrote: > On Sat, Mar 24, 2012 at 07:32:32AM -0400, Richard Hipp scratched on the wall: > >> SQLite converts NaN inputs into NULL. > > I think this is the right choice. It is what I would expect. But it's not what the docs say:

Re: [sqlite] 64-bit Windows Command Shell

On Sat, Mar 24, 2012 at 06:56:16PM -0700, Roger Binns scratched on the wall: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 24/03/12 18:23, Jay A. Kreibich wrote: > > That depends on the OS. Some 64-bit OSes will give nearly all the 4GB > > address space to a 32-bit application. > > Th

Re: [sqlite] NaN in, 0.0 out?

On Sat, Mar 24, 2012 at 07:32:32AM -0400, Richard Hipp scratched on the wall: > SQLite converts NaN inputs into NULL. I think this is the right choice. It is what I would expect. Well, no... what I would actually expect is that sqlite3_bind_double() should return an error, since it was

Re: [sqlite] Could/should Windows build of SQLite use #define

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [I am the author of APSW] On 24/03/12 14:22, Larry Brasfield wrote: > Except for its clever hiding of SQLite's C API names (via "#define > SQLITE_API static"), There is nothing "clever" about it - SQLite exposes various things like that so compilati

Re: [sqlite] 64-bit Windows Command Shell

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/03/12 18:23, Jay A. Kreibich wrote: > That depends on the OS. Some 64-bit OSes will give nearly all the 4GB > address space to a 32-bit application. Those same OSes make it very easy to compile SQLite in 64 bits so this isn't an issue. > Other

Re: [sqlite] 64-bit Windows Command Shell

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/03/12 18:16, Udi Karni wrote: > (1) On the SQLite Download page - the Linux version just says "x86" > while the Windows version is "Win-32 x86". Does this mean that the > Linux version is a 64-bit version? In other words - if run on, say, > Re

Re: [sqlite] 64-bit Windows Command Shell

On 25 Mar 2012, at 2:16am, Udi Karni wrote: > (2) On Windows - a RamDisk "drive letter" can be used beneficially in 2 > ways - > (a) to contain the database itself > (b) to serve as a destination for the TEMP and TMP - which SQLite (through > Windows I suppose) uses often as a scratchpad. > Is i

Re: [sqlite] 64-bit Windows Command Shell

On Sat, Mar 24, 2012 at 05:36:09PM -0700, Roger Binns scratched on the wall: > > In my particular scenario - while the raw data being attached and read > > is hundreds of GB - the result sets are only a few GB. > > 2GB is the threshold to switch to 64 bits. That depends on the OS. Some 64-b

Re: [sqlite] 64-bit Windows Command Shell

Very interesting. 2 questions - (1) On the SQLite Download page - the Linux version just says "x86" while the Windows version is "Win-32 x86". Does this mean that the Linux version is a 64-bit version? In other words - if run on, say, RedHat 5.5 64-bit - it will be able to use >4GB of RAM? (2) On

Re: [sqlite] 64-bit Windows Command Shell

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/03/12 13:48, Udi Karni wrote: > I tried the SQLite in-memory DB feature - but when it exceeded about > 2GB - I got the "out of memory" message. Technically it ran out of address space, not ram. > In my particular scenario - while the raw data b

Re: [sqlite] Could/should Windows build of SQLite use #define

On March 23, Jeff Robbins wrote: While #define WINDOWS_LEAN_AND_MEAN is only a compile-time setting, it trims down extraneous #defines that Windows.h creates that can interfere with reasonable uses of SQLite, such as the excellent APSW extension for Python: The problem I happened upon was tryi

Re: [sqlite] 64-bit Windows Command Shell

I tried the SQLite in-memory DB feature - but when it exceeded about 2GB - I got the "out of memory" message. In my particular scenario - while the raw data being attached and read is hundreds of GB - the result sets are only a few GB. A 64-bit version of SQLite that could handle an in-memory DB

Re: [sqlite] slightly confusing documentation on limits.html page

On 03/23/2012 01:19 AM, Jeff Robbins wrote: Item 12 on the limits page (http://www.sqlite.org/limits.html) states that a maximum SQLite database size is about 140 terabytes. But item 13 on the same page refers to 14 terabytes as the maximum. The calculation given in item 12 yields this value:

Re: [sqlite] NaN in, 0.0 out?

Stephan, > Occasionally the sensor has a fault or the values are invalid (like > negative temperatures). To mark them once and for all as invalid, the > faulty values are replaced (in a C environment) by NaNs. Then the data are > inserted into the database with a C porgram, in a loop with the

[sqlite] slightly confusing documentation on limits.html page

Item 12 on the limits page (http://www.sqlite.org/limits.html) states that a maximum SQLite database size is about 140 terabytes. But item 13 on the same page refers to 14 terabytes as the maximum. The calculation given in item 12 yields this value: 2147483646 * 65536 = 140,737,488,224,256

Re: [sqlite] NaN in, 0.0 out?

On Sat, Mar 24, 2012 at 3:18 AM, Stephan Buchert wrote: > Here the simplified scenario: > > We have measurements from a sensor array. The data are checked and plotted. > Then they are inserted into an SQLITE database. We find out that after > retrieving (selecting) the data back from the database,

Re: [sqlite] NaN in, 0.0 out?

On 24 Mar 2012, at 7:18am, Stephan Buchert wrote: > Occasionally the sensor has a fault or the values are invalid (like > negative temperatures). To mark them once and for all as invalid, the > faulty values are replaced (in a C environment) by NaNs. Then the data are > inserted into the databas

[sqlite] NaN in, 0.0 out?

Here the simplified scenario: We have measurements from a sensor array. The data are checked and plotted. Then they are inserted into an SQLITE database. We find out that after retrieving (selecting) the data back from the database, the plots look different, the data have been changed! First we su