Rajan, Vivek K wrote:
I have a need to store spatial and connectivity data (think verilog
netlist with x, y coordinate information) in a persistence on-disk file.
I am looking at different SQL-based databases and am wondering if anyone
has recommendations/opinions on how good SQLite is for:
-
On 9/7/05, Mark Drago [EMAIL PROTECTED] wrote:
The problem I'm seeing is that (I'm half guessing) after I run a
rollback, when I try and run 'begin transaction' I get: 'cannot start a
transaction within a transaction'. As far as I can tell there is no way
to get out of this part of my code
On 9/7/05, Alexander van der Merwe [EMAIL PROTECTED] wrote:
Hi,
I have a huge ( 40 000 lines) insert-script I want to run.
Some of the lines may have something wrong with them, and I want to
check if there are are any errors on importing the data.
Is there a way to tell SQLite only to
Richard Nagle wrote:
you didn't happen to ftp any files in the incorrect mode did you?
ascii rather than binary perhaps for the tar/tar.gz file?
Just downloaded the source, from sqlite.org
and that it. why?
-Rick
downloading a binary file ( .tar .tgz, .bz , etc ) in ascii mode will
you have major problems. As someone else suggested, could you have
possibly downloaded the source wrong... could something have gotten
munged up? All the above gobbledegook is binary stuff.
By the way, wiping the hard drive and reinstalling everything is a
waste of time. That is no way to
On 9/8/05, Richard Nagle [EMAIL PROTECTED] wrote:
you have major problems. As someone else suggested, could you have
possibly downloaded the source wrong... could something have gotten
munged up? All the above gobbledegook is binary stuff.
Or bad RAM or hard disk in your computer.
Downloaded this, version, and got the same kind of output.
VÒjx?Âê#McaronÉfl#?sjKöyæ9[EMAIL
PROTECTED]sum
ºhUZ£/S?÷é©='¿l?/ëÿ:ìRb}öVÙ¥( Å[¿.Q`hYF¢+¨÷ùáü!ÀLOÎ
í k?ïë¢xeÃb?e·fi,[breve\¡N¨=
Ã?Ê3}ì?âò=În'T£?/Ñïô= âó+I#¢âù?·ÎPAmëÑcÄ å.
Â1 ÜÙ
ÅÕô/+
On Wed, 2005-09-07 at 17:20 -0400, Mark Drago wrote:
On Tue, 2005-09-06 at 16:07 -0400, D. Richard Hipp wrote:
On Tue, 2005-09-06 at 15:49 -0400, Mark Drago wrote:
2. I could continue to write to the database in the single thread, but
if the write fails, add the data to a queue and
So, its something with the C compiler...
Well, you can test your compiler pretty easily.. Are you able to
compile anything else? At minimum, try compiling hello world first:
create a file test.c :
---
#include stdio.h
int main( ) {
printf(oh my, 1 step closer to
On September 08 2005, Cam Crews [EMAIL PROTECTED] wrote:
So, its something with the C compiler...
Well, you can test your compiler pretty easily.. Are you able to
compile anything else? At minimum, try compiling hello world first:
create a file test.c :
---
Ok... try downloading the sqlite source again. Maybe the mac browser
isn't downloading correctly or your unzip utility is corrupting
things. Try performing these operations (downloading and unzipping)
through the command line:
--
wget
How did you download the archive? Using which client?
I never had any problems using the source archives (may not have used
that exact version, but I never had any problems using the .tar.gz
archives on Mac OS X...)
Make sure you don't use any older version of Stuffit or the like to
Say I have a column called 'b' in a table called 'test' and every
field in 'b' has a NULL value. What is the expected behavior of the
following query:
SELECT SUM(b) FROM TEST;
I guess I'm thinking I'll get back NULL. Instead I get 0 (or, in the
3.2.5 code, 0.0).
On the other hand, the
Say I have a column called 'b' in a table called 'test' and every
field in 'b' has a NULL value. What is the expected behavior of the
following query:
SELECT SUM(b) FROM TEST;
I guess I'm thinking I'll get back NULL. Instead I get 0 (or, in the
3.2.5 code, 0.0).
On the other hand, the
On September 08 2005, Cam Crews [EMAIL PROTECTED] wrote:
Ok... try downloading the sqlite source again. Maybe the mac browser
isn't downloading correctly or your unzip utility is corrupting
things. Try performing these operations (downloading and unzipping)
through the command line:
Richard,
You can use 'curl' to download the file instead of wget. So, run the
following command instead:
curl -o sqlite-2.8.16.tar.gz http://www.sqlite.org/sqlite-2.8.16.tar.gz
I don't seem to have the 'md5sum' program installed on the mac that I
have here, but getting the md5sum on linux
Nope,
done that, still the same errors.
Have another person, whom is trying to figure this out as well,
in fact, he thinks, something in my shell is mess up..
snip
foofile.txt
Wow, your results are completely different. When the shell trys to
read the here-document, it gets the garbage.
So
On Sep 8, 2005, at 1:24 PM, Mark Drago wrote:
Richard,
You can use 'curl' to download the file instead of wget. So, run the
following command instead:
curl -o sqlite-2.8.16.tar.gz http://www.sqlite.org/sqlite-2.8.16.tar.gz
wget is not available by default on Panther. On the other hand, as
On Thu, 2005-09-08 at 10:24 -0700, Will Leshner wrote:
Say I have a column called 'b' in a table called 'test' and every
field in 'b' has a NULL value. What is the expected behavior of the
following query:
SELECT SUM(b) FROM TEST;
I guess I'm thinking I'll get back NULL. Instead I get
On Thu, 2005-09-08 at 10:48 -0400, Mark Drago wrote:
However, it seems that for every rollback that I do there is a file left
in the directory with the databases. I have 30-something files named
like the following: 'ame_log.db-mj0E2E1262'. ame_log.db is the filename
of the main log database.
Mark Drago wrote:
I don't seem to have the 'md5sum' program installed on the mac that I
have here, but getting the md5sum on linux returns the following. So,
if you have some means of getting the md5sum of the file, make sure it
matches this:
9c79b461ff30240a6f9d70dd67f8faea
On Sep 8, 2005, at 11:33 AM, D. Richard Hipp wrote:
SUM ignores NULLs. So if it ignores everything, it returns the
sum of nothing, which is 0. (Not the 0.0 issue is fixed in CVS HEAD.)
Ah. Perhaps I shouldn't have filed a bug report then. Sorry about
that. I wonder what other databases
On Sep 8, 2005, at 11:33 AM, D. Richard Hipp wrote:
SUM ignores NULLs. So if it ignores everything, it returns the
sum of nothing, which is 0. (Not the 0.0 issue is fixed in CVS HEAD.)
As a data point, MySQL returns NULL for a SUM over fields that are
all NULL. I am not suggesting, of
On 9/8/05, D. Richard Hipp [EMAIL PROTECTED] wrote:
SUM ignores NULLs. So if it ignores everything, it returns the
sum of nothing, which is 0. (Not the 0.0 issue is fixed in CVS HEAD.)
I would expect the sum of nothing is nothing, not zero, but that's
interpretation
and I can see how
Actually, every database I'm aware of returns NULL for any aggregate
whenever the inputs are NULL, and also when no input rows are processed
(i.e. if no rows match the criteria in the WHERE clause, the result of
the aggregation is NULL).
-Tom
-Original Message-
From: Will
Just for information:
Oracle returns NULL's in both cases: for SUM() and for
AVG().
I checked it for ver. 8.1.7 and 9.2.0
--- D. Richard Hipp [EMAIL PROTECTED] wrote:
On Thu, 2005-09-08 at 10:24 -0700, Will Leshner
wrote:
Say I have a column called 'b' in a table called
'test' and every
At http://www.oreilly.com/catalog/sqlnut/chapter/ch04.html
I read:
The AVG function computes the average of values in
a column or an expression. SUM computes the sum.
Both functions ... ignore NULL values.
PostgreSQL docs say that NULL is returned if all inputs
to sum are NULL.
So
On 9/8/05, D. Richard Hipp [EMAIL PROTECTED] wrote:
So then, if there are no input rows at all (if no rows
match the WHERE clause) then SUM returns 0. (This makes
sense because if you say:
SELECT sum(amt) FROM sales WHERE month='october';
and you didn't sell anything in October, you
So then, if there are no input rows at all (if no rows
match the WHERE clause) then SUM returns 0. (This makes
sense because if you say:
SELECT sum(amt) FROM sales WHERE month='october';
and you didn't sell anything in October, you want an
answer of 0, not NULL.) Or if *some* of
On 9/8/05, Thomas Briggs [EMAIL PROTECTED] wrote:
You (and I) may want an answer of 0, but I unfortunately believe NULL
is the correct answer. The answer isn't 0 - the answer is there is no
answer, because there were no inputs. If that translates to 0 in
reality that's up to you to
From postgresql 8.0.1 on FreeBSD:
syslog-ng=# select NULL is null;
?column?
--
t
(1 row)
syslog-ng=# select (0+NULL) is null;
?column?
--
t
(1 row)
syslog-ng=# select (0) is null;
?column?
--
f
(1 row)
syslog-ng=# create table tmp1 ( a int4 );
CREATE TABLE
syslog-ng=#
On 9/8/05, D. Richard Hipp [EMAIL PROTECTED] wrote:
PostgreSQL docs say that NULL is returned if all inputs
to sum are NULL.
So then, if there are no input rows at all (if no rows
match the WHERE clause) then SUM returns 0.
Actually PostgreSQL 8.0.3 and FirebirdSQL 1.5.2 return NULL in
So, in some cases (explicite addition), NULL + 0 = NULL. (we all know
that NULL != NULL). However, the sum function skips NULLs. This
seems inconsistant.
NULL + 0 is not valid since you can't do a binary operation on only one
number (zero is
a number, NULL is not). So it returns an
Can somebody come up with a realistic scenario where they would
actually want SUM() to return NULL instead of 0? NULL is such
a profoundly broken return value for sum() in my mind that I'm
thinking of ignoring the standard and just coding SQLite to do
the Right Thing. But I am open to the
Jay Sprenkle wrote:
So, in some cases (explicite addition), NULL + 0 = NULL. (we all know
that NULL != NULL). However, the sum function skips NULLs. This
seems inconsistant.
NULL + 0 is not valid since you can't do a binary operation on only one
number (zero is
a number, NULL is not).
On 9/8/05, D. Richard Hipp [EMAIL PROTECTED] wrote:
Can somebody come up with a realistic scenario where they would
actually want SUM() to return NULL instead of 0? NULL is such
a profoundly broken return value for sum() in my mind that I'm
thinking of ignoring the standard and just coding
On 9/8/05, Dennis Jenkins [EMAIL PROTECTED] wrote:
The point being that if I sum up the rows using sum(), I could get one
answer. However, if I iterate the cursor in a stored procedure and
manually sum them up using accum += value I would get a different
answer. The math is inconsistant (in
Can somebody come up with a realistic scenario where they would
actually want SUM() to return NULL instead of 0? NULL is such
I think your example of totaling sales in October makes the argument
itself - you didn't make sales totaling $0 in October, you just didn't
make any sales. A
On 9/8/05, Thomas Briggs [EMAIL PROTECTED] wrote:
Can somebody come up with a realistic scenario where they would
actually want SUM() to return NULL instead of 0? NULL is such
I think your example of totaling sales in October makes the argument
itself - you didn't make sales totaling
I would think that if you are looking to know the total of something
(which is what SUM provides), and there is nothing to total, the total
should be 0. If you want to know if any sales were made, it seems you
should be using COUNT and not SUM.
Just my opinion, of course.
Bob
Envision
D. Richard Hipp wrote:
Can somebody come up with a realistic scenario where they would
actually want SUM() to return NULL instead of 0?
I have found that, when dealing with NULL values, it helps to think of a
Null as I don't know, I have no data.
So, if the where clause returns no records,
On Thu, 2005-09-08 at 16:43 -0400, Thomas Briggs wrote:
Can somebody come up with a realistic scenario where they would
actually want SUM() to return NULL instead of 0?
I think your example of totaling sales in October makes the argument
itself - you didn't make sales totaling $0
- Original Message -
From: D. Richard Hipp [EMAIL PROTECTED]
To: sqlite-users@sqlite.org
Sent: Thursday, September 08, 2005 1:24 PM
Subject: Re: [sqlite] SUM and NULL values
Can somebody come up with a realistic scenario where they would
actually want SUM() to return NULL instead of
On Thu, 2005-09-08 at 23:05 +0200, Martin Engelschalk wrote:
I have found that, when dealing with NULL values, it helps to think of a
Null as I don't know, I have no data.
So, if the where clause returns no records, I do know the result: It is 0.
If there where clause returns records with
Robert Simpson wrote:
SUM without any rows should return NULL. It had no type affinity with
which to obtain an answer for the question, and no meaningful rows
were available with which to glean an answer.
If SUM returns 0 when no rows were evaluated, then SQLite is making an
assumption
On Thu, 2005-09-08 at 14:12 -0700, Robert Simpson wrote:
If SUM returns 0 when no rows were evaluated, then SQLite is making an
assumption about what the answer should be, which is incorrect.
SELECT SUM(temperature) FROM antartica WHERE temperature -150 LIMIT 1
Does it makes sense for
D. Richard Hipp schrieb:
On Thu, 2005-09-08 at 23:05 +0200, Martin Engelschalk wrote:
I have found that, when dealing with NULL values, it helps to think of a
Null as I don't know, I have no data.
So, if the where clause returns no records, I do know the result: It is 0.
If there where
There is one other thing, though. Allthough the sql standard is
(insert your favorite 4-letter word), and although I personally hate
nulls, I try to write applications where the sql is as portable as it
can be. So, in the name of portability, you should follow the sql
standard.
- Original Message -
From: Martin Engelschalk [EMAIL PROTECTED]
To: sqlite-users@sqlite.org
Sent: Thursday, September 08, 2005 2:23 PM
Subject: Re: [sqlite] SUM and NULL values
SUM() itself does imply an numerical type return and does not need any
rows
from which to get a type - even
SELECT SUM(temperature) FROM antartica WHERE temperature -150 LIMIT 1
Ignore the obvious logic error in this statement, since it will always
return 1 row ... the meaning was that 0 does not always answer every
question.
Robert
For some reason I have to agree with the SQL standard, which I would
interprete as the following (and this may not be all that bullet proof):
If the result set contains numeric values, sum them up, ignoring NULLs. If
there are no numeric values present (the result set is either empty or
contains
If SQLite doesn't conform to the SQL standard, it'll break several other
dependencies on the standard:
CREATE TABLE salaries (empid int, hourlywage money, yearlywage money,
emptype int)
INSERT INTO salaries VALUES(1, 12.95, null, 1)
INSERT INTO salaries VALUES(2, null, 8.00, 2)
SELECT
NULL is the absence of value.
Any aggregation operation on a set where ALL the elements of the set
are absences of values should return an absence of value. If ALL
the elements are NOT NULL then the aggregation operation should be
applied to the elements that have a presence of value.
The
Robert Simpson wrote:
Lets take the October sales further. Lets say if there were any sales
in October, that you had to subtract $100 from the total sales for
October to account for ... lets say shipping costs.
SELECT SUM(amt) - 100 from sales where month = 'october'
If there were no sales,
On Sep 8, 2005, at 5:20 PM, Ted Unangst wrote:
Robert Simpson wrote:
Lets take the October sales further. Lets say if there were any
sales in October, that you had to subtract $100 from the total sales
for October to account for ... lets say shipping costs.
SELECT SUM(amt) - 100 from sales
- Original Message -
From: Ted Unangst [EMAIL PROTECTED]
To: sqlite-users@sqlite.org
Sent: Thursday, September 08, 2005 3:20 PM
Subject: Re: [sqlite] SUM and NULL values
Robert Simpson wrote:
Lets take the October sales further. Lets say if there were any sales in
October, that you
If SELECT SUM(amt) means How much did I sell?
Then the NULL should mean, You didn't sell anything., no?
To me, there is a difference between 0 (You sold merchandise worth $0
perhaps because of sweepstakes, giveaway, rebate coupons, etc) and NULL
(You didn't sell anything.).
I think that Robert
On Sep 8, 2005, at 5:45 PM, Marcus Welz wrote:
If SELECT SUM(amt) means How much did I sell?
Then the NULL should mean, You didn't sell anything., no?
no... NULL means, I don't have any data to answer that question which
is very different from I sold $0 worth of things or I didn't sell
Yes, the NULL as it is returned by SUM means No data to answer your
question.
I was talking in context with the example of the fictional sales situation,
rather than the technical description of what SUM() exactly does, because,
as I see it, we're trying to figure out whether the technical
Robert Simpson wrote:
Perhaps a pragma is the right answer?
There shouldn't have to be a pragma to enforce SQL conformance.
I should have clarified it should default to conforming, if there were
to be such a thing. Like pragma friendly_null, defaulting to off. But
your salary example is
Hi all,
I guess this isn't really all that complex, but I just can't think of
a query that does what I need.
Here's an example table:
CREATE TABLE t1 (fname TEXT, vers TEXT, chng INT, UNIQUE(fname,vers));
INSERT INTO t1 VALUES('file1', '1', 0);
INSERT INTO t1 VALUES('file1', '2', 1);
INSERT INTO
On Thu, 08 Sep 2005 16:24:14 -0400, D. Richard Hipp [EMAIL PROTECTED] wrote:
Can somebody come up with a realistic scenario where they would
actually want SUM() to return NULL instead of 0? NULL is such
a profoundly broken return value for sum() in my mind that I'm
thinking of ignoring the
Nemanja Corlija wrote:
Here's an example table:
CREATE TABLE t1 (fname TEXT, vers TEXT, chng INT, UNIQUE(fname,vers));
INSERT INTO t1 VALUES('file1', '1', 0);
INSERT INTO t1 VALUES('file1', '2', 1);
INSERT INTO t1 VALUES('file1', '3', 2);
INSERT INTO t1 VALUES('file2', '1', 0);
SELECT fname,
On Thu, 8 Sep 2005, Marcus Welz wrote:
Yes, the NULL as it is returned by SUM means No data to answer your
question.
If that query returned 0 (as SQLite currently does), rather than NULL (as
the standard specifies), it would not allow me to figure out whether I sold
$0 worth of items or if
64 matches
Mail list logo
