os.refid=pots.id
In this second join, the photos.kind=2 condition can never be met
because every row in the result of the previous join has photos.kind==1.
Hence, the result set contains no rows. A COUNT() of a empty result
set gives NULL.
--
D. Richard Hipp <[EMAIL PROTECTED]>
On Mon, 2005-09-19 at 13:42 -0400, D. Richard Hipp wrote:
> On Mon, 2005-09-19 at 19:04 +0200, Guillaume Fougnies wrote:
> > Hello,
> >
> > During the upgrade from 3.2.5 to 3.2.6, i removed my
> > compile time option SQLITE_DEFAULT_PAGE_SIZE.
> >
> &
t the same database handle, they
will not be isolated. I do not understand why you would expect
that they would be.
--
D. Richard Hipp <[EMAIL PROTECTED]>
nnot debug this problem unless you provide more
information. What were you setting DEFAULT_PAGE_SIZE to,
for example. Are you sure the original database is
readable by a stock copy of 3.2.5? Can you provide
a copy of the database that does not work?
--
D. Richard Hipp <[EMAIL PROTECTED]>
oesn't exist...)
>
> The second seems to be a limitation of VS6 - it certainly isn't a
> problem in VS7. Can't really think of any neat solution around it
> either...
>
http://www.sqlite.org/cvstrac/chngview?cn=2720
--
D. Richard Hipp <[EMAIL PROTECTED]>
Do you have
> any suggestions on how I can use a variable in my ORDER BY clause?
> Thanks,
> Nicole Hinderman
>
>
Changes to the ORDER BY modify the choice of algorithms used
to process the query. This requires that you rerun
sqlite3_prepare() in order to generate new code for th
On Sun, 2005-09-18 at 01:03 +0400, Alexander J. Kozlovsky wrote:
> Hence, SQLite deferred transactions is not serializable ones.
>
Your understanding is incorrect. SQLite does *not* release
locks in the middle of a transaction - ever. It is always
serializable.
--
D. Richard Hipp &
rewritten.
COUNT(DISTINCT) is now supported.
The LIKE operator might use indices to speed its
search if the column being searched uses COLLATE NOCASE.
Lots of smaller bug fixes and miscellaneous
enhancements.
--
D. Richard Hipp <[EMAIL PROTECTED]>
ns of
windows.
So to answer your question, COMMIT is much faster on Win98 because of
a bug in the operating system that can cause data loss or data
corruption
after a power failure or operating system crash.
--
D. Richard Hipp <[EMAIL PROTECTED]>
, I'm
obliged to support it forever. So I want to ponder the
issue a bit more first.
--
D. Richard Hipp <[EMAIL PROTECTED]>
.
--
D. Richard Hipp <[EMAIL PROTECTED]>
On Thu, 2005-09-15 at 13:59 +0100, Da Martian wrote:
> Hi
>
> I have 3 million rows in a table which takes up about 3.1GB on disk. The
> count(*) is slow.
>
> I have run the analyze, but apart from creating the stats table it does
> nothing.
>
> Any reason why this is? Can it be improved ?
parse.c and no hand editing
is required.
--
D. Richard Hipp <[EMAIL PROTECTED]>
default release. In the meantime,
you can find the patches at:
http://www.sqlite.org/cvstrac/tktview?tn=1240
--
D. Richard Hipp <[EMAIL PROTECTED]>
On Tue, 2005-09-13 at 09:08 +0200, Laurent wrote:
> I get the error :
>
>Assertion failed: xHash!=0, file hash.c, line 299
>Abnormal program termination
>
I tried the same sequence of commands and it worked
fine for me.
--
D. Richard Hipp <[EMAIL PROTECTED]>
load version 3 of the TCL bindings
first, then version 2.
--
D. Richard Hipp <[EMAIL PROTECTED]>
the optimizer without
creating any incompatibilities.
--
D. Richard Hipp <[EMAIL PROTECTED]>
On Fri, 2005-09-09 at 15:43 -0400, D. Richard Hipp wrote:
> There may be something wrong with version 3.2.5. See, for example,
> ticket #1414: http://www.sqlite.org/cvstrac/tktview?tn=1414
If you read the comments on the ticket above, you'll see that
the problem was solved by r
= 0
sum() == NULL
sum() == the correct sum
--
D. Richard Hipp <[EMAIL PROTECTED]>
send me both a query and a database to
run it on, I will look into the matter and hopefully get a fix
out right away.
--
D. Richard Hipp <[EMAIL PROTECTED]>
mperature FROM antartica WHERE temperature < -150 LIMIT 1
Which gives the result you seek.
Thank you for the suggestion, though...
--
D. Richard Hipp <[EMAIL PROTECTED]>
tand Martin's point of view. The SQL standard
point of view makes no sense to me at all.
--
D. Richard Hipp <[EMAIL PROTECTED]>
, which is what I am proposing to do
in SQLite in defiance of the SQL standard.
--
D. Richard Hipp <[EMAIL PROTECTED]>
hen it has no
input.
--
D. Richard Hipp <[EMAIL PROTECTED]>
are
NULL, then the answer is the sum of the non-NULL entries.
But if the number of entries is greater than zero and
they are all NULL, then the answer is NULL.
Logical, right
The more I learn about NULLs in SQL the less sense they
make...
--
D. Richard Hipp <[EMAIL PROTECTED]>
files. They are used to make
sure that commits to multiple databases occurs atomically.
They should be deleted automatically. I do not know why they
are not being removed for you. I will look into it.
--
D. Richard Hipp <[EMAIL PROTECTED]>
b) FROM TEST;
>
AVG is implemented as SUM/COUNT. But the count is zero. So
you get a NULL.
--
D. Richard Hipp <[EMAIL PROTECTED]>
SQLite uses 64-bit signed integers (8 bytes).
--
D. Richard Hipp <[EMAIL PROTECTED]>
ve assumes that ROWIDs are consecutive, which may or may
not be the case. (Probably it is not the case.) To get the last 10
rows, I would suggest this:
SELECT * FROM mytable ORDER BY rowid DESC limit 10;
That will work as long as the optimizer doesn't try to use an index
to satisfy terms of your WHERE clause.
--
D. Richard Hipp <[EMAIL PROTECTED]>
in step 2 will acquire a read-lock on the
database file which will insure that no other process modifies the file
during step 3. But it is also only a read-lock so other processes can
continue to read the database while you are copying it. Step 4 releases
the file lock.
--
D. Richard Hipp <[EMAIL PROTECTED]>
l
end up doing unless somebody can suggest a good reason not
to.
--
D. Richard Hipp <[EMAIL PROTECTED]>
Can somebody with access to Win95/98/ME please test
check-in [2656] for me to make sure it didn't break
anything?
http://www.sqlite.org/cvstrac/chngview?cn=2656
--
D. Richard Hipp <[EMAIL PROTECTED]>
ing DB handles in multiple threads is
a problem.
--
D. Richard Hipp <[EMAIL PROTECTED]>
/cvstrac/tktview?tn=1272 and
http://www.sqlite.org/cvstrac/tktview?tn=1285.
--
D. Richard Hipp <[EMAIL PROTECTED]>
uires the locks immediately and would thus cause the
EBUSY error when thread2 did its BEGIN. This simplifies
recovery at the price of some concurrency.
--
D. Richard Hipp <[EMAIL PROTECTED]>
d are now
detected sooner rather than later.
--
D. Richard Hipp <[EMAIL PROTECTED]>
the lastest version of SQLite and if circumstances
are just right, LIKE will use an index.
See http://www.sqlite.org/optoverview.html#like_opt
--
D. Richard Hipp <[EMAIL PROTECTED]>
arate handle for
each thread.
--
D. Richard Hipp <[EMAIL PROTECTED]>
On Fri, 2005-09-02 at 11:59 +0200, Michael Schoen wrote:
> (1) Multiple Insert Statements
> We need to insert around 300-500 datasets/sec constantly (24/7) with 8
> till 16 fields indexed. So far we are using mysql, not only due to the
> general dbms speed, but mainly because it has a csv
Thanks everybody!
All the results so far seem to be in agreement with each
other and with the current behavior of SQLite. So I think
everything is good. Thx for the help.
--
D. Richard Hipp <[EMAIL PROTECTED]>
INTO t1 SELECT * FROM t1;
SELECT a, b, sum(c) FROM t1 GROUP BY a, b ORDER BY 3;
Thanks.
--
D. Richard Hipp <[EMAIL PROTECTED]>
1|1|zzz
> 1|2|xxx
> 1|3|yyy
>
Fix is at http://www.sqlite.org/cvstrac/chngview/cn=2655.
--
D. Richard Hipp <[EMAIL PROTECTED]>
sqlite.org/cvstrac/tktview?tn=1272
http://www.sqlite.org/cvstrac/chngview?cn=2521
--
D. Richard Hipp <[EMAIL PROTECTED]>
0 && exp<=350 ){ realvalue *= 0.1; exp++; }
>
Thanks. This is the problem and it is being fixed now.
--
D. Richard Hipp <[EMAIL PROTECTED]>
own.
So I'm not overly worried when I see round(9.95,1) come out
with 9.9. But I am concerned about the people who are seeing
results like ":.0". I wish I could reproduce that problem.
--
D. Richard Hipp <[EMAIL PROTECTED]>
s just do a better job of it.
--
D. Richard Hipp <[EMAIL PROTECTED]>
ct
the key.
The usual defense against this attack (and the one used by SQLite)
is to discard the first 1000 bytes or so of information coming out
of the PRNG. No key information leaks into later bytes of the
PRNG stream (at least as far as we know) so this secures the cypher
from attack.
--
D. Richard Hipp <[EMAIL PROTECTED]>
interface does not take advantage of the new features of sqlite
> version 3 with the integers and doubles, as it convert everything to one
> string. Are there any plans to change it?
>
What version are you looking at? The latest Tcl bindings already
do this.
--
D. Richard Hipp <[EMAIL PROTECTED]>
SD make.
>
OK. The line above was in a patch someone sent in for ticket
#1292: http://www.sqlite.org/cvstrac/tktview?tn=1292.
Can someone who understands make and configure perhaps suggest a
fix for this so that it will work on OpenBSD and Mac OS-X at the
same time?
--
D. Richard Hipp <[EMAIL PROTECTED]>
u find a specific problem with the 3.2.4 Makefiles, I'll be
happy to look at it. But from what I've seen so far, this looks
like a problem in your environment, not in SQLite.
--
D. Richard Hipp <[EMAIL PROTECTED]>
iew?cn=2366
--
D. Richard Hipp <[EMAIL PROTECTED]>
o imagine what might have broken...
--
D. Richard Hipp <[EMAIL PROTECTED]>
3.2.5 will be forthcoming.
But I'm going to wait a few days for other bugs to emerge
before I do the next release. I would very much appreciate
it if as many people as possible will try out version 3.2.4
over the next few days and report any problems you run
across.
--
D. Richard Hipp <[EM
I see the problem. I'm working on the fix now. This will
result in 3.2.5, eventually.
The bug has been in the code for 2 months. Apparently nobody
tests out of CVS. :-(
--
D. Richard Hipp <[EMAIL PROTECTED]>
);
>
It works fine when I try it. Please send me your database
if you can. Use ".dump" to convert to text, then compress
the text and send private email to [EMAIL PROTECTED]
--
D. Richard Hipp <[EMAIL PROTECTED]>
Version 3.2.3 contained a memory allocation bug which could cause
a segfault when complex WHERE clauses are parsed. The problem is
fixed in version 3.2.4 which is now available on the website.
--
D. Richard Hipp <[EMAIL PROTECTED]>
supports variable-length records with automatic
compaction and defragmentation. Records are subject to
being moved about on the disk after any change to nearby
records.
--
D. Richard Hipp <[EMAIL PROTECTED]>
I just ran a speed comparison between version 2.8.16 and 3.2.3.
Version 3.2.3 is faster in almost every case. See
http://www.sqlite.org/speed-2816-v-323.html
--
D. Richard Hipp <[EMAIL PROTECTED]>
ittle slower to commit, but it is also safer in
the face of power failures. In spite of this handicap,
SQLite version 3 still manages to be faster than version 2
in many tests.
--
D. Richard Hipp <[EMAIL PROTECTED]>
prevent data loss after a power failure. So this
is not a real high priority.
--
D. Richard Hipp <[EMAIL PROTECTED]>
e that caused the assert if posssible.
Or better, provide a short SQL script that causes the assert to fail
when run from the command-line client.
We'll try to get to it...
--
D. Richard Hipp <[EMAIL PROTECTED]>
to write,
easier to maintain, has fewer bugs, and just works better.
--
D. Richard Hipp <[EMAIL PROTECTED]>
On Mon, 2005-08-22 at 16:54 -0600, Dennis Cote wrote:
> select *
> from MyTable
> join (select random(*) as number) as rand
> where start_col >= rand.number
> and end_col < rand.number;
>
Very nice. Dennis Cote wins todays prize for
cleverest use (abuse?) of a join!
--
it's encrypted might have it use as well)
>
An encrypted SQLite database appears to be white noise
from beginning to end. There is no header. Many users
prefer it that way.
--
D. Richard Hipp <[EMAIL PROTECTED]>
lso make known or chosen plaintext attacks considerably more
difficult.
--
D. Richard Hipp <[EMAIL PROTECTED]>
the problem?
Actually, that looks like it might work. Have you tried it?
You might also need to comment out some code further down in the
file that attempts to create new WideInt objects in Tcl.
--
D. Richard Hipp <[EMAIL PROTECTED]>
On Mon, 2005-08-22 at 08:42 -0700, Clark Christensen wrote:
>
> --- "D. Richard Hipp" <[EMAIL PROTECTED]> wrote:
> > ...
> > SQLite never "blows away" a file that is not a database.
> >
> > --
> > D. Richard Hipp <[EMAIL
sing Tcl 8.4 and it worked fine.
I would recommend that you upgrade. Going to Tcl 8.4
(or 8.5) will cost you perhaps 1 day of work, but will
easily pay back that much and more as you continue to
work with the code.
--
D. Richard Hipp <[EMAIL PROTECTED]>
Version 3.2.3 of SQLite is now available on the website
http://www.sqlite.org/
In addition to fixing a lot of minor bugs, this release
adds a number of important new enhancements. Most of
the enhancements are centered around the much-improved
query optimizer, but there are some unrelated
store
that value in a separate column in the table.
CREATE TABLE object(
size INT,
data BLOB
);
Then when you need to know the size, just do
a query for the size.
Note: This will only work if the "size" column
comes before the "data" column in the table
definition.
--
D. Richard Hipp <[EMAIL PROTECTED]>
QLite are you using? What platform? What
language binding?
--
D. Richard Hipp <[EMAIL PROTECTED]>
When the index above is
used, things will come out sorted or by name just because of
the way they work in SQLite. SQL does not guarantee that behavior
so it probably will not work that way on other database engines,
but it should work fine in SQLite.
--
D. Richard Hipp <[EMAIL PROTECTED]>
and each row uses in
excess of 1KB or memory, this is apparently causing your
machine to thrash.
--
D. Richard Hipp <[EMAIL PROTECTED]>
On Sat, 2005-08-20 at 13:36 -0700, Will Leshner wrote:
> On Aug 20, 2005, at 9:21 AM, D. Richard Hipp wrote:
>
> > SQLite never "blows away" a file that is not a database.
>
> Sorry to use such crude language :) But I believe I have run into an
> issue with S
contains a database. The file is not actually opened
until you try to do something with it.
SQLite never "blows away" a file that is not a database.
--
D. Richard Hipp <[EMAIL PROTECTED]>
l.
The code shown was for reading the database. You'll also need
to find and fix the spot where the database is written, of course.
--
D. Richard Hipp <[EMAIL PROTECTED]>
on foo begin
update foo set date_lch=current_timestamp where rowid=new.rowid;
end;
--
D. Richard Hipp <[EMAIL PROTECTED]>
On Thu, 2005-08-18 at 14:10 -0400, D. Richard Hipp wrote:
> On Thu, 2005-08-18 at 09:40 -0700, Robert Simpson wrote:
> > http://www.psc.edu/general/software/packages/ieee/ieee.html
> >
> > The way I interpreted this site, is that the IEEE standard for floating
> >
x%02x%02x%02x%02x%02x\n",
x.z[0], x.z[1], x.z[2], x.z[3], x.z[4], x.z[5], x.z[6], x.z[7]);
x.i = 1;
printf("%02x%02x%02x%02x%02x%02x%02x%02x\n",
x.z[0], x.z[1], x.z[2], x.z[3], x.z[4], x.z[5], x.z[6], x.z[7]);
return 0;
}
--
D. Richard Hipp <[EMAIL PROTECTED]>
On Thu, 2005-08-18 at 12:24 -0400, D. Richard Hipp wrote:
> On Thu, 2005-08-18 at 18:04 +0200, Frank van Vugt wrote:
> > L.S.
> >
> > It looks like there's something wrong with the endiannes when using sqlite3
> > (v3.2.2) on an ARM architecture (SA1100 nanobo
stored in the IEEE 64-bit
format with the same byte order as the machine integer.
--
D. Richard Hipp <[EMAIL PROTECTED]>
c/chngview?cn=2596.
Do "cvs update" and try again.
--
D. Richard Hipp <[EMAIL PROTECTED]>
und the problem
by defeating the optimizer:
ORDER BY +eidh.ekey, kinapo.polhths
^-- unary "+" here
--
D. Richard Hipp <[EMAIL PROTECTED]>
the latest code
in CVS will. 3.2.3 will probably be released relatively soon.
--
D. Richard Hipp <[EMAIL PROTECTED]>
On Thu, 2005-08-04 at 12:59 -0700, L. S. wrote:
> What is the prescribed way to create the complete documentation (without
> having to learn yet another scripting language--or whatever it is)?
>
make doc
--
D. Richard Hipp <[EMAIL PROTECTED]>
which will appear in the next release.
--
D. Richard Hipp <[EMAIL PROTECTED]>
On Tue, 2005-08-02 at 09:30 -0400, D. Richard Hipp wrote:
> On Mon, 2005-08-01 at 22:04 +0200, Jens Miltner wrote:
> > we get an assertion (no crash here, though) in btree.c
> > and the backtrace looks similar to the one scunacc provided, which
> > made me think the
It looks like this may be the same problem. I will let
everybody know as soon as I have a fix.
--
D. Richard Hipp <[EMAIL PROTECTED]>
havior be changed?
> Thanks.
>
SQLite never blocks for any reason. If it cannot get a
lock, it returns SQLITE_BUSY. Even if you call
sqlite3_busy_timeout() it doesn't block - it polls.
What OS are you using? What wrappers around SQLite are
you using? What version of SQLite?
--
D. Richard Hipp <[EMAIL PROTECTED]>
mething like that.
--
D. Richard Hipp <[EMAIL PROTECTED]>
avior in platform
printf() functions. The fix was for SQLite to always use
it's own internal printf() function.
--
D. Richard Hipp <[EMAIL PROTECTED]>
lename in the database.
--
D. Richard Hipp <[EMAIL PROTECTED]>
t;
The text is wrong and has now been corrected.
See http://www.sqlite.org/cvstrac/chngview?cn=2559
TEMP tables in SQLite work like they do in every other
SQL database engine.
--
D. Richard Hipp <[EMAIL PROTECTED]>
ingle thread.
--
D. Richard Hipp <[EMAIL PROTECTED]>
l the
> records* to return me the last 50 and while doing that it locked the
> DB! Maybe I constructed my query wrong
> It looks something like this:
>
> select fields from table order by id desc limit 50;
>
Try putting and index on table.id.
--
D. Richard Hipp <[EMAIL PROTECTED]>
The Philips MP3 players use SQLite version 2.x. You probably
downloaded version 3.x. Version 3.x will not read or write
version 2.x database files. Try using version 2.8.16 instead
of whatever version it is you downloaded.
On Sun, 2005-07-17 at 12:08 +0200, Karl Sinn wrote:
> Hi,
>
> I am
But threading
bugs tend to manifest themselves as timing-dependent
glitches and lock-ups that are hardware and platform
dependent, that never happen the same way twice, and that
only appear for customers after deployment and never in a
testing environment.
--
D. Richard Hipp <[EMAIL PROTECTED]>
at one table in a
separate database and ATTACH it. Then when you want
to erase it all, DETACH the separate database, delete
the file, then reinitialize the database and re-ATTACH
it.
--
D. Richard Hipp <[EMAIL PROTECTED]>
ur program crashes for any reason,
the *entire* database file will be irrecoverably
corrupted if you do not have a journal?
--
D. Richard Hipp <[EMAIL PROTECTED]>
o me. What about the memory cost of prepared
> statements? I know with some database drivers that I've used, having
> a large number of prepared statements caused the memory usage of the
> connections to grow significantly.
>
Prepared statements use a few KiB each.
--
D. Richard Hipp <[EMAIL PROTECTED]>
801 - 900 of 1539 matches
Mail list logo
