code\n"
" insert SQL insert statements for TABLE\n"
|
913 |
code
|
fixed
|
2004 Sep
|
anonymous
|
|
2004 Oct
|
|
3
|
2
|
Locking in os_unix.c
|
edit |
Downgrading an EXCLUSIVE_LOCK to SHARED_LOCK does not
change the POSIX advisory lock from F_WRLCK to F_RDLCK.
Please consider the following patch:
--- sqlite.orig/src/os_unix.c Fri Sep 17 21:48:57 2004
+++ sqlite/src/os_unix.c Mon Sep 20 22:29:48 2004
@@ -1038,12 +1038,17 @@
assert( pLock->cnt!=0 );
if( id->locktype>SHARED_LOCK ){
assert( pLock->locktype==id->locktype );
+ lock.l_type = F_RDLCK;
+ lock.l_whence = SEEK_SET;
+ lock.l_start = SHARED_FIRST;
+ lock.l_len = SHARED_SIZE;
+ fcntl(id->h, F_SETLK, &lock);
+ pLock->locktype = SHARED_LOCK;
lock.l_type = F_UNLCK;
lock.l_whence = SEEK_SET;
lock.l_start = PENDING_BYTE;
lock.l_len = 2L; assert( PENDING_BYTE+1==RESERVED_BYTE );
fcntl(id->h, F_SETLK, &lock);
- pLock->locktype = SHARED_LOCK;
}
if( locktype==NO_LOCK ){
struct openCnt *pOpen;
|
2004-Sep-24 13:17:56 by anonymous:
After inspecting os_win.c I think the same problem exists for
Win32, too. When an EXCLUSIVE lock is downgraded to a
SHARED_LOCK, all locks held are released effectively. |
|
912 |
code
|
fixed
|
2004 Sep
|
anonymous
|
|
2004 Sep
|
|
1
|
1
|
sqlite3 crashes in join statement
|
edit |
The attached (admittedly complicated) SQL file causes sqlite3 to crash. The same SQL worked fine with 3.0.6 as of approx last Tuesday. |
2004-Sep-20 20:08:37 by anonymous:
bt.txt is the gdb backtrace. This is on Win32, compiled w/ mingw32
2004-Sep-20 20:18:19 by anonymous:
--
It also repros on Linux |
|
911 |
code
|
fixed
|
2004 Sep
|
anonymous
|
Shell
|
2004 Oct
|
|
3
|
3
|
The sqlite command ".mode csv" doesn't work correctly
|
edit |
I am including here a diff against shell.c, which properly implements the 'csv' mode and also fixes a typo.
The problem is that the output is like:
Joe, Mama,1234
When it should be like:
"Joe, Mama",1234
Attached is the diff. |
|
910 |
build
|
fixed
|
2004 Sep
|
dougcurrie
|
Unknown
|
2004 Oct
|
dougcurrie
|
2
|
2
|
Windows doesn't (usually) have or need pthread
|
edit |
Check-in [1968]
added -lpthread to Makefile.in but Windows, e.g., MinGW/MSYS, doesn't have or need pthread, so the build fails with "cannot find -lpthread" -- e |
|
908 |
event
|
fixed
|
2004 Sep
|
anonymous
|
|
2004 Sep
|
|
5
|
5
|
corrupt sqlite-3.0.7.so.gz file on download page
|
edit |
the link:
http://sqlite.org/sqlite-3.0.7.so.gz
is an ascii file containing
sh: ./sqlite-3.0.7.so.gz: cannot execute binary file |
|
907 |
build
|
fixed
|
2004 Sep
|
anonymous
|
|
2004 Oct
|
|
1
|
2
|
If --enable-threadsafe then pthreads library is not linked in
|
edit |
If you build sqlite with configure --enagle-threadsafe, the linked will fail later with the message:
(cd .libs && rm -f libsqlite3.la && ln -s ../libsqlite3.la libsqlite3.la)
./libtool --mode=link gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DHAVE_READLINE=1 -I/usr/include/readline -o sqlite3 ./src/shell.c \
libsqlite3.la -lreadline -lncurses
gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DHAVE_READLINE=1 -I/usr/include/readline -o .libs/sqlite3 ./src/shell.c ./.libs/libsqlite3.so -lreadline -lncurses -Wl,--rpath -Wl,/proj/lib
./.libs/libsqlite3.so: undefined reference to `pthread_create'
./.libs/libsqlite3.so: undefined reference to `pthread_join'
collect2: ld returned 1 exit status
make: *** [sqlite3] Error 1
This with RedHat Enterprise 3.0 |
See ticket #910. |
|
905 |
code
|
fixed
|
2004 Sep
|
anonymous
|
VDBE
|
2004 Oct
|
|
2
|
4
|
assertion failed in vdbe.c (it fails to not crash upon user error?)
|
edit |
For what it's worth in case the same happens in version 3:
SQLite version 2.8.15
Enter ".help" for instructions
sqlite> create table a (b,c);
sqlite> insert into a values (1,2);
sqlite> insert into a values (1,4);
sqlite> insert into a values (1,8);
sqlite> insert into a values (1,16);
sqlite> insert into a values (2,16);
sqlite> select sum(b),c from a;
6|
sqlite> select b,c from a;
1|2
1|4
1|8
1|16
2|16
sqlite> select sum(b),c from a;
6|
sqlite> select sum(b),c from a group by b;
2|16
4|2
sqlite> select sum(b),c from a group by sum(b);
sqlite: src/vdbe.c:2081: sqliteVdbeExec: Assertion `pRec->flags & 0x0002' failed.
Aborted
|
|
904 |
build
|
fixed
|
2004 Sep
|
anonymous
|
|
2004 Sep
|
|
3
|
3
|
x86_64: please use $(libdir) instead of $(prefix)/lib
|
edit |
Mulitiple-architecture linux x86_64 uses /usr/lib64 for 64-bit libraries. Thus hardcoded constructs like $(exec_prefix)/lib make it impossible to install into /usr/lib64. Please use $(libdir). |
|
903 |
build
|
fixed
|
2004 Sep
|
anonymous
|
|
2004 Sep
|
|
3
|
3
|
make doc fails (please use mkdir -p)
|
edit |
make doc fails:
$ ./configure
$ make doc
...
tclsh ./www/datatypes.tcl >datatypes.html
tclsh ./www/datatype3.tcl >datatype3.html
tclsh ./www/docs.tcl >docs.html
mkdir doc
mkdir: cannot create directory `doc': File exists
$
Please always use `mkdir -p'.
--- Makefile.in~ 2004-08-28 15:22:30 +0000
+++ Makefile.in 2004-09-15 23:23:26 +0000
@@ -208,7 +209,7 @@
#
target_source: $(SRC) $(VDBEHDR)
rm -rf tsrc
- mkdir tsrc
+ mkdir -p tsrc
cp $(SRC) $(VDBEHDR) tsrc
rm tsrc/sqlite.h.in tsrc/parse.y
cp parse.c opcodes.c tsrc
@@ -443,7 +444,7 @@
tclsh $(TOP)/www/docs.tcl >docs.html
download.html: $(TOP)/www/download.tcl
- mkdir doc
+ mkdir -p doc
tclsh $(TOP)/www/download.tcl >download.html
faq.html: $(TOP)/www/faq.tcl
|
|
901 |
code
|
fixed
|
2004 Sep
|
anonymous
|
BTree
|
2004 Sep
|
|
1
|
1
|
invalid btree cursor read locks honored?
|
edit |
I'm having problems with code that starts a transaction, creates a
table, commits, begins a new transaction, creates a temporary table,
inserts data into the temporary table, and the inserts into the table
the results of a select from the temporary table. The insert
statement results in a SQLITE_ERROR on sqlite3_step. This is because
there are two open btree cursors, one invalid read cursor, one write
cursor. I don't totally understand the significance of the isValid
flag of a btree cursor, but if I ignore cursors with isValid == 0 in
checkReadLocks(), the attached test case succeeds.
Current HEAD CVS has 15 failures both with and without the attached
patch, but this is in a subtle area of the database, so I'm not
certain this is the right fix. |
2004-Sep-15 19:24:43 by anonymous:
#include <assert.h>
#include <sqlite3.h>
#include <stdio.h>
#include <stdlib.h>
void exec(sqlite3 *pDb, const char *sql) {
sqlite3_stmt *pStmt;
const char *zLeftover;
int rc;
rc = sqlite3_prepare(pDb, sql, -1, &pStmt, &zLeftover);
if (rc != SQLITE_OK) {
printf("error occurred while preparing statement: %s\n",
sqlite3_errmsg(pDb));
abort();
}
assert(rc == SQLITE_OK);
assert(*zLeftover == '\0');
rc = sqlite3_step(pStmt);
if (rc != SQLITE_DONE) {
printf("error: sqlite3_step returned %d, expected %d.\n",
rc, SQLITE_DONE);
abort();
}
rc = sqlite3_finalize(pStmt);
assert(rc == SQLITE_OK);
}
int main(void) {
sqlite3 *pDb;
int rc;
rc = sqlite3_open(":memory:", &pDb);
assert(rc == SQLITE_OK);
exec(pDb, "BEGIN");
exec(pDb, "CREATE TABLE Dependencies(depId integer primary key,"
"class integer, name str, flag str);");
exec(pDb, "COMMIT");
exec(pDb, "BEGIN");
exec(pDb, "CREATE TEMPORARY TABLE DepCheck(troveId INT, depNum INT, "
"flagCount INT, isProvides BOOL, class INTEGER, name STRING, "
"flag STRING)");
exec(pDb, "INSERT INTO DepCheck "
"VALUES(-1, 0, 1, 0, 2, 'libc.so.6', 'GLIBC_2.0')");
exec(pDb, "INSERT INTO Dependencies \
SELECT DISTINCT \
NULL, \
DepCheck.class, \
DepCheck.name, \
DepCheck.flag \
FROM DepCheck LEFT OUTER JOIN Dependencies ON \
DepCheck.class == Dependencies.class AND \
DepCheck.name == Dependencies.name AND \
DepCheck.flag == Dependencies.flag \
WHERE \
Dependencies.depId is NULL");
exec(pDb, "ROLLBACK");
printf("success\n");
return 0;
}
2004-Sep-15 19:25:21 by anonymous:
Index: src/btree.c
===================================================================
RCS file: /sqlite/sqlite/src/btree.c,v
retrieving revision 1.189
diff -u -r1.189 btree.c
--- src/btree.c 8 Sep 2004 20:13:05 -0000 1.189
+++ src/btree.c 15 Sep 2004 18:54:31 -0000
@@ -3498,7 +3498,7 @@
static int checkReadLocks(Btree *pBt, Pgno pgnoRoot, BtCursor *pExclude){
BtCursor *p;
for(p=pBt->pCursor; p; p=p->pNext){
- if( p->pgnoRoot!=pgnoRoot || p==pExclude ) continue;
+ if( p->pgnoRoot!=pgnoRoot || p==pExclude || p->isValid == 0) continue;
if( p->wrFlag==0 ) return SQLITE_LOCKED;
if( p->pPage->pgno!=p->pgnoRoot ){
moveToRoot(p);
2004-Sep-17 17:17:04 by drh:
Here is a script to reproduce the problem:
CREATE TABLE Dependencies(depId integer primary key,
class integer, name str, flag str);
CREATE TEMPORARY TABLE DepCheck(troveId INT, depNum INT,
flagCount INT, isProvides BOOL, class INTEGER, name STRING,
flag STRING);
INSERT INTO DepCheck
VALUES(-1, 0, 1, 0, 2, 'libc.so.6', 'GLIBC_2.0');
INSERT INTO Dependencies
SELECT DISTINCT
NULL,
DepCheck.class,
DepCheck.name,
DepCheck.flag
FROM DepCheck LEFT OUTER JOIN Dependencies ON
DepCheck.class == Dependencies.class AND
DepCheck.name == Dependencies.name AND
DepCheck.flag == Dependencies.flag
WHERE
Dependencies.depId is NULL;
The problem is actually in the code generator for the INSERT
statement. The code generator does not notice that the
SELECT on the right-hand side of the INSERT statement is reading
from the same table that the INSERT is trying to insert into.
This causes it to generate code that assumes that the SELECT is
disjoint from the INSERT. The bug is in the logic of the INSERT
code generator that detects the use of the insert table in the
SELECT statement. |
|
900 |
new
|
fixed
|
2004 Sep
|
anonymous
|
|
2004 Sep
|
|
4
|
4
|
sqlite3_trace and reusing prepared statements
|
edit |
As documented, the trace handler set by sqlite3_trace() is only called on sqlite3_exec() and sqlite3_prepare().
But IMHO the trace handler shouldn't called on sqlite3_prepare() but every time the prepared statement is executed. I. e. on the first sqlite3_step() call to a prepared statement. If the statement is resetted and executed a second time, the trace handler should be called again.
With this behavour, the trace handler will become a really trace handler, not a "statement compiled handler". |
|
899 |
doc
|
fixed
|
2004 Sep
|
anonymous
|
|
2004 Nov
|
|
4
|
3
|
sqlite3_create_function / negative nArg glitch
|
edit |
From the documentation of sqlite3_create_function:
" The third parameter is the number of arguments that the function or aggregate takes. If this parameter is negative, then the function or aggregate may take any number of arguments. "
But this works only if nArg (the third parameter) is equal to -1. Other negative values, for example -2 don't work and result in SQLITE_ERROR. |
|
898 |
code
|
fixed
|
2004 Sep
|
anonymous
|
|
2004 Sep
|
|
1
|
1
|
nullif() crashes inside trigger
|
edit |
There is a crash when the nullif() function is called from within a trigger. I checked out the code from CVS earlier tonight and verified it exists in that code base. The following code illustrates the problem:
CREATE TABLE foo(
id integer primary key,
name,
code);
CREATE TABLE foo_history(
id integer primary key,
_id,
_name,
_code);
CREATE TRIGGER foo_updateTrigger AFTER UPDATE ON foo FOR EACH ROW
BEGIN
INSERT INTO foo_history VALUES(NULL, nullif(old.id, new.id), nullif(old.name, new.name), nullif(old.code, new.code));
END;
insert into foo values(NULL, 'tom', 42);
insert into foo values(NULL, 'larry', 42);
update foo set code=41 where name='larry';
When the update is called, my code crashes. I'm running this on Mac OS X 10.3.5. |
|
897 |
code
|
fixed
|
2004 Sep
|
anonymous
|
|
2004 Sep
|
|
3
|
4
|
LEMON: Line numbers in generated parser.c are off. (Windows)
|
edit |
When I make mistakes in my parser.y file, I get compile errors about parser.c. Those errors are reported on the wrong line.
The problem seems to stem from a Windows file peculiarity. If you open a file with mode "w", it defaults to text handling. This means that when you putc a '\n', it actually writes '\r\n'. So an input line which ends with \r\n (as Windows files do) will be written to the generated .c file as \r\r\n, which counts as two line endings. This double-spaces the copied text, which puts the text out-of-synch with the line count.
Yes, the whole thing is a mess, and Windows would have been much better off sticking with a single newline character like Unix. Alas, it is not so.
A simple fix is to change the file open call on line 3358 from:
out = file_open(lemp,".c","w");
to:
out = file_open(lemp,".c","wb");
The 'b' in the mode disables the text-mode "helpfulness", and all is well.
I haven't tested this on Unix. But in my experience, the "b" mode is what Unix just does all the time anyway, and there is no difference. Adding the "b" mode seems to be a common need when using Unix code on Windows. The other alternative is in the output routines, skip writing the '\r' characters.
The other two files you write (parser.h and parser.out) are purely generated, without copying characters from an input file, so they don't have the same double-spacing problem.
More fun from Windows-land!
--Ned. |
2004-Sep-10 00:15:06 by drh:
There used to be systems around that couldn't handle the "b" in "rb"
or "wb". But, come to think of it, I haven't seen that in over a
decade, so I suppose it is probably safe now to use "rb" instead of
"r" and "wb" instead of "w". |
|
896 |
code
|
fixed
|
2004 Sep
|
anonymous
|
Parser
|
2004 Sep
|
anonymous
|
1
|
3
|
Access violation when attempt to execute invalid query
|
edit |
Table struct:
CREATE TABLE t_ip_res (IPR_ADDRESS TEXT ,IPR_PORT INTEGER, PRIMARY KEY (IPR_ADDRESS,IPR_PORT));
db initialization:
connect_info.pDB = sqlite_open(filename, 0444, &zErrMsg);
//all params correctly init. & set
query execution:
rc = sqlite_exec(connect_info.pDB,query,Callback, this, &zErrMsg);
//all params correctly init. & set
Invalid query:
SELECT IPR_ADDRES WHERE IPR_ADDRESS = '192.168.0.193';
Result:
assertion in line 128 in auth.c -> assert( pStack!=0 );
next line access violation
thx |
|
895 |
code
|
fixed
|
2004 Sep
|
anonymous
|
|
2004 Sep
|
|
4
|
4
|
LEMON doesn't like single-line parse_failure code.
|
edit |
If the LEMON input file has a parse_failure on a single line:
%parse_failure { pParser->Fail(); }
then the generated code won't compile:
parser.y(25) : error C2014: preprocessor command must start as first nonwhite space
The parser.c file looks like this:
#line 25 "parser.y"
pParser->Fail(); #line 699 "parser.c"
LemonParseARG_STORE;
The workaround is simple: put the code on more than one line. But I was surprised by the error.
--Ned. |
|
892 |
code
|
fixed
|
2004 Sep
|
anonymous
|
|
2004 Sep
|
|
3
|
1
|
LEMON can't generate well-formed Windows parsers with full paths
|
edit |
If I use a Windows path on the command-line to LEMON:
lemon c:\src\parser.y
then the #line directives are badly formed:
#line 17 "c:\src\parser.y"
resulting in errors during compilation:
Unknown escape sequence \s
Unknown escape sequence \p
I've attached a patch to fix it.
(While I was in there, I got rid of an unused local, and fixed the type of a function from char* to void.)
--Ned. |
|
891 |
build
|
fixed
|
2004 Sep
|
anonymous
|
|
2004 Sep
|
|
4
|
4
|
creating directories in makefile
|
edit |
It seems that recent additions in the Makefile contain some checks for directory creation, but they could be changed so it doesn't interfere with already existing directories.
In the rule to create the file download.html the command "mkdir doc" is executed, but when the directory already exists (and it does...) make will complain about it and abort execution.
In this case, removing the "mkdir doc" line should be the correct action to take keeping documentation creation procedure consistent. (result of copy/paste?) |
Same as ticket #903 |
|
890 |
code
|
fixed
|
2004 Sep
|
anonymous
|
BTree
|
2004 Sep
|
anonymous
|
1
|
1
|
Page sizes other than 1024 bytes result in segfaults
|
edit |
I've tracked down the problem of ticket "#889"
Below is the script to reproduce it.
I only asserts when using a page_size different than 1024. I usually make it 4096 through pragma page_size=4096.
Removing the vacuum line and doing the integrity_check it returns "ok".
Maybe the page_size is not set in the new "vacuumed" db.
SQLite version 3.0.6
Enter ".help" for instructions
sqlite> .read assert.txt
Assertion failed: &pPage->aData[pPage->pBt->pageSize]==(unsigned char*)pPage, file d:\sqlsrv\sqlite\v3\btree.c, line 980
Script assert.txt:
pragma page_size=4096;
CREATE TABLE x(id integer primary key, a TEXT NULL);
INSERT INTO x (a) VALUES ('first');
CREATE TABLE tempx(id integer primary key, a TEXT NULL);
INSERT INTO tempx (a) VALUES ('t-first');
CREATE VIEW tv1 AS SELECT x.id, tx.id FROM x JOIN tempx tx ON tx.id=x.id;
CREATE VIEW tv1b AS SELECT x.id, tx.id FROM x JOIN tempx tx on tx.id=x.id;
CREATE VIEW tv2 AS SELECT * FROM tv1 UNION SELECT * FROM tv1b;
VACUUM;
pragma integrity_check;
|
2004-Sep-04 23:18:34 by drh:
The problem is that VACUUM does not play well with a page size
other than 1024. |
|
888 |
doc
|
fixed
|
2004 Sep
|
anonymous
|
BTree
|
2004 Sep
|
|
5
|
4
|
incorrect (obsolete) comment above sqlite3BtreeOpen in btree.c
|
edit |
This note appears above sqlite3BtreeOpen at or near line 1019 in btree.c:
** Actually, this routine just sets up the internal data structures
** for accessing the database. We do not open the database file
** until the first page is loaded.
In version 3 this is no longer true. Bytes 16 through 23 of page 1 are read inside sqlite3BtreeOpen.
The incorrect comment should be updated or deleted. |
|
886 |
code
|
fixed
|
2004 Sep
|
anonymous
|
Unknown
|
2004 Sep
|
anonymous
|
2
|
2
|
v3 assert with explain
|
edit |
sing v.3.0.5 and executing:
explain pragma page_size;
or whatever pragma is entered,
it throws an assert in function sqlite3VdbeSetNumCols called from main.c line 1037:
sqlite3VdbeSetNumCols(sParse.pVdbe, 5); |
|
885 |
code
|
fixed
|
2004 Sep
|
drh
|
VDBE
|
2004 Sep
|
|
1
|
1
|
Sqlite3_step() does not return SQLITE_BUSY after a commit fails
|
edit |
Commits do not happen until sqlite3_finalize(). This means that
if a commit fails due to lock contention, there is no opportunity
to retry using a subsequent call to sqlite3_step(). Better behavior
would be for the commit to occur inside sqlite3_step() so that
sqlite3_step() could return SQLITE_BUSY and give the calling routine
a chance to retry the commit. |
|
881 |
code
|
fixed
|
2004 Sep
|
anonymous
|
BTree
|
2004 Sep
|
|
1
|
3
|
Can not compile under Windows with Borland C++ Builder
|
edit |
Since version 3.0.4, the compiler returns an error in btree.c (line 1538 : static int checkReadLocks(Btree*,Pgno,BtCursor*);).
The exact error message (the compiler is a french version) is : "La classe de stockage 'static' n'est pas autorisee ici." (static is not allowed here)
It seems there was a similar problem descripted in ticket #172. |
This is a bug in Borland C++, not SQLite. Nevertheless, we can
easily work around that bug... |
|
877 |
todo
|
fixed
|
2004 Aug
|
anonymous
|
Parser
|
2004 Aug
|
|
4
|
2
|
Binary garbage in preprocessed source file 'parse.c' (3.0.5)
|
edit |
In the preprocessed file collection, sqlite-source-3_0_5.zip, the file 'parse.c' contains binary garbage (a 0x01 character) in a comment on line 87 (just above '#define YYCODETYPE unsigned char').
Though this doesn't affect compilation, it triggered a message in my Unix-linefeed-to-Dos-linefeed converter. Stylistically, I think it is a bad idea to have nongraphical, nonwhitespace characters in a sourcefile, even if it is in a comment. And it looks like it actually was a bug in the tool that generated parse.c in the first place. |
The \001 character was deliberate, not a bug. But the need for that
character has long since gone away. So the code in lemon that
inserts its has been removed. |
|
875 |
code
|
fixed
|
2004 Aug
|
anonymous
|
VDBE
|
2004 Aug
|
|
1
|
3
|
Error when INTERSECTing more than two subqueries.
|
edit |
Create a simple table:
create temporary table test (label);
insert into test values ('aaa');
insert into test values ('abb');
insert into test values ('acc');
insert into test values ('abc');
SELECT * FROM test WHERE label LIKE '%a%';
-> returns four rows.
SELECT * FROM test WHERE label LIKE '%a%' INTERSECT SELECT * FROM test WHERE label LIKE '%b%';
-> returns two rows
SELECT * FROM test WHERE label LIKE '%a%' INTERSECT SELECT * FROM test WHERE label LIKE '%b%' INTERSECT SELECT * FROM test WHERE label LIKE '%c%';
SQL error: database disk image is malformed
Thanks!
Demitri |
|
873 |
code
|
fixed
|
2004 Aug
|
anonymous
|
|
2004 Sep
|
|
1
|
2
|
VACUUM of database with ' character in filename causes error
|
edit |
On Windows, running Vacuum on a database named a'a.db causes the error "SQL logic error or missing database |
|
872 |
code
|
fixed
|
2004 Aug
|
anonymous
|
|
2005 Sep
|
|
5
|
5
|
SQL does not support non-ASCII IO?
|
edit |
I noticed that if I use the "attach" SQL command to attach a db file, it does not support non-ASCII file path. |
2004-Aug-27 13:51:31 by anonymous:
For example:
"ATTACH 'c:\some non-ASCII characters here\myDB.db' AS myDB" |
|
871 |
code
|
fixed
|
2004 Aug
|
dougcurrie
|
TclLib
|
2004 Aug
|
|
3
|
1
|
sqlite_temp_directory only defined in os_unix but used in tcl
|
edit |
The variable sqlite_temp_directory is defined in os_unix.c and so is not available on builds for other OSs. However, the variable is referenced in test1.c and makes it impossible to build the testfixture on non-unix platforms. Perhaps the defintion of sqlite_temp_directory should be moved to a more central place, or else the use of it should be made OS_UNIX specific. -- e |
|
870 |
code
|
fixed
|
2004 Aug
|
anonymous
|
|
2004 Aug
|
|
4
|
4
|
Segmentation Fault on sqlite3_step if sqlite3_prepare fails
|
edit |
The following code will not execute properly if the table named "example" already exists. The error produced is Segmentation Fault.
sqlite3_prepare(db, "CREATE TABLE example (id, example)", -1, &statement, NULL);
sqlite3_step(statement); // causes a segmentation fault if the example table already exists
sqlite3_finalize(statement);
The following code will always execute properly:
response = sqlite3_prepare(db, "CREATE TABLE example (id, example)", -1, &statement, NULL);
if(response == SQLITE_OK)
{
sqlite3_step(statement);
sqlite3_finalize(statement);
}
|
|
869 |
code
|
fixed
|
2004 Aug
|
anonymous
|
|
2004 Aug
|
drh
|
3
|
3
|
SQLite 2.x: CREATE INDEX and dbl-quoted index names
|
edit |
This is a reopen of Ticket#695, the following patch against 2.8.15
provides a fix:
diff -ur sqlite.orig/src/build.c sqlite/src/build.c
--- sqlite.orig/src/build.c 2004-07-20 02:50:12.000000000 +0100
+++ sqlite/src/build.c 2004-08-25 11:05:42.000000000 +0200
@@ -1557,7 +1557,7 @@
sqliteSetString(&zName, "(", pTab->zName, " autoindex ", zBuf, (char*)0);
if( zName==0 ) goto exit_create_index;
}else{
- zName = sqliteStrNDup(pName->z, pName->n);
+ zName = sqliteTableNameFromToken(pName);
}
/* Check for authorization to create an index.
|
|
862 |
code
|
fixed
|
2004 Aug
|
anonymous
|
VDBE
|
2004 Aug
|
|
2
|
2
|
Memory is being freed twice when performing VACUUM on corrupted DB
|
edit |
We have found that in some cases memory there's ACCESS VIOLATION error when performing VACUUM on a corrupted database.
We have investigated this problem and found that memory is being freed twice when performing VACUUM on corrupted database.
The problem is in the following function: sqliteVdbeExec while processing OP_Column.
It reserves memory in stack (pTos++;), and after that, because of error due to corrupt databases, it exits OP_Column. As long as previous memory release (macros Release) does not reset MEM_DYN flag, later in SQLFinalize tries to free this memory. Depending on MEM_DYN was set before it happens, it easier works correctly or crashes with ACCESS VIOLATION.
We suggest to fix it by reseting flags during release:
#define Release(P) if((P)->flags&MEM_Dyn){ sqliteFree((P)->z); P->flags = 0; } |
2004-Aug-19 17:57:27 by anonymous:
We just found out that the same problem present while executing any SELECT operation on a corrupted database, not just VACUUM. |
|
860 |
code
|
fixed
|
2004 Aug
|
anonymous
|
Unknown
|
2004 Oct
|
|
3
|
1
|
SQLite 3.0.4 fails under Solaris 9
|
edit |
When attempting to use SQLite on a sparc, it fails with either bus error or segmentation fault. SQLite has been compiled with GCC 3.0.4 and standard flags from the Makefile.
After some debugging, it has been determined that the -O2 flag causes the sqlite3VdbeMemSetInt64() to fail at line 285:
pMem->i = val;
This is most likely due to alignment problems on the sparc architecture.
However, by removing the -O2 flag, SQLite successfully compile and seems to work in my application.
I'm uncertain if this is a problem in SQLite or if it is a problem in GCC, but the fix, for now is to compile SQLite without optimization. |
2004-Sep-02 20:22:16 by anonymous:
I was also seeing this problem when compiling with with gcc-3.3.3 in 32 bit mode. I tried compiling with a 64 bit gcc-3.3.3 and it appears to be working even when compiled optimized. |
|
859 |
doc
|
fixed
|
2004 Aug
|
anonymous
|
|
2004 Aug
|
|
5
|
4
|
typo in comment
|
edit |
In line 507 of date.c please change "occurrance" to "occurrence".
Yes, I know, that's not a serious bug :-) |
2004-Aug-17 10:43:42 by drh:
Fixed. Thanks.
I'm sure you'll find many more such errors in the comments if
you keep reading.... :-) |
|
857 |
event
|
fixed
|
2004 Aug
|
anonymous
|
|
2004 Aug
|
|
1
|
1
|
Unable to download 3.0.4 precompiled binaries for Linux.
|
edit |
http://www.sqlite.org/sqlite3-3.0.4.bin.gz
Unable to download. |
|
855 |
build
|
fixed
|
2004 Aug
|
anonymous
|
Unknown
|
2005 Feb
|
|
4
|
3
|
Unpack directory should include a version: sqlite-3.0.4/
|
edit |
PLease add version number to the archive's unpack directory, so that upgrades of sqlite can be handled more easily. Now the sqlite/ overwrites previous installation.
So use de facto: sqlite-VERSION/ e.g. sqlite-3.0.4/ |
|
848 |
code
|
fixed
|
2004 Aug
|
anonymous
|
Unknown
|
2004 Sep
|
|
3
|
3
|
make test seg fault in blob-1.5 on x86_64 Linux (Gentoo on Opteron)
|
edit |
System has an Opteron CPU and runs Gentoo 2004.1 amd64 (with multilib "USE" option). GCC is v3.3.3 with both 32 and 64 bit build capability; defaults to building 64 bit executables. No options are passed to the configure script. The sqlite code compiles cleanly except for these warnings:
src/func.c: In function `minmaxFunc':
src/func.c:47: warning: cast from pointer to integer of different size
src/main.c: In function `sqliteDefaultBusyCallback':
src/main.c:578: warning: cast from pointer to integer of different size
src/main.c: In function `sqlite3_busy_timeout':
src/main.c:649: warning: cast to pointer from integer of different size
src/table.c: In function `sqlite3_get_table':
src/table.c:146: warning: cast to pointer from integer of different size
src/table.c: In function `sqlite3_free_table':
src/table.c:192: warning: cast from pointer to integer of different size
src/vdbeaux.c: In function `displayP3':
src/vdbeaux.c:366: warning: cast from pointer to integer of different size
"make test" ends with
[...]
blob-1.0... Ok
blob-1.1... Ok
blob-1.2... Ok
blob-1.3... Ok
blob-1.4... Ok
blob-1.5...make: *** [test] Segmentation fault (core dumped)
|
2004-Aug-30 19:44:48 by anonymous:
Progress with the the v3.0.5 beta: "make test" gets farther; now fails at btree-1.7
blob-1.4... Ok
blob-1.5... Ok
blob-1.6... Ok
blob-1.7... Ok
blob-2.0... Ok
blob-2.1... Ok
blob-2.2... Ok
blob-2.3... Ok
blob-2.4... Ok
blob-3.0... Ok
blob-3.1... Ok
blob-2.3... Ok
btree-1.1... Ok
btree-1.1.1... Ok
btree-1.2... Ok
btree-1.3... Ok
btree-1.4... Ok
btree-1.4.1... Ok
btree-1.5... Ok
btree-1.6... Ok
btree-1.7...make: *** [test] Segmentation fault (core dumped)
There are still several type cast warnings for 64 bit compiling (w/the same gcc used above):
src/func.c: In function `minmaxFunc':
src/func.c:47: warning: cast from pointer to integer of different size
src/main.c: In function `sqliteDefaultBusyCallback':
src/main.c:582: warning: cast from pointer to integer of different size
src/main.c: In function `sqlite3_busy_timeout':
src/main.c:653: warning: cast to pointer from integer of different size
src/table.c: In function `sqlite3_get_table':
src/table.c:146: warning: cast to pointer from integer of different size
src/table.c: In function `sqlite3_free_table':
src/table.c:192: warning: cast from pointer to integer of different size
src/vdbeaux.c: In function `displayP3':
src/vdbeaux.c:366: warning: cast from pointer to integer of different size
2004-Sep-04 00:10:09 by anonymous:
With the 3.0.6 beta the number of warnings for a 64 bit compile have been reduced to just three occurrences in two files:
src/table.c: In function `sqlite3_get_table':
src/table.c:146: warning: cast to pointer from integer of different size
src/table.c: In function `sqlite3_free_table':
src/table.c:192: warning: cast from pointer to integer of different size
src/vdbeaux.c: In function `displayP3':
src/vdbeaux.c:366: warning: cast from pointer to integer of different size
Nonetheless it still seg faults in btree-1.7. |
|
844 |
code
|
fixed
|
2004 Aug
|
anonymous
|
VDBE
|
2004 Aug
|
|
1
|
1
|
AFTER DELETE trigger has erroneous values in old.X "variables"!
|
edit |
CREATE TEMP TABLE Item(
a integer PRIMARY KEY NOT NULL ,
b double NULL ,
c int NOT NULL DEFAULT 0
);
CREATE TEMP TABLE Undo(UndoAction TEXT);
INSERT INTO Item VALUES (1,38205.60865,340);
CREATE TEMP TRIGGER trigItem_UNDO_AD AFTER DELETE ON Item FOR EACH ROW
BEGIN
INSERT INTO Undo SELECT 'INSERT INTO Item (a,b,c)
VALUES (' || coalesce(old.a,'NULL') || ',' || quote(old.b) || ',' || old.c || ');';
END;
DELETE FROM Item WHERE a = 1;
SELECT * FROM Undo;
result: INSERT INTO Item (a,b,c) VALUES (1, 38205.60865, 38205.60865);
^^^^^^^^^^^ should be 340 !!
-- NOTICE THAT Undo.c contains the same value as Undo.b!!!! This is a major problem...
|
|
842 |
code
|
fixed
|
2004 Aug
|
anonymous
|
|
2004 Aug
|
|
2
|
2
|
Ignoring an error return from sqlite3_exec causes invalid db.
|
edit |
While debugging my sqlite3 support, I managed to repeatably corrupt my database. Here is C code reproducing the problem:
sqlite3 * db;
int err;
#define DOIT(x) { err = (x); cout << #x << " returned " << err << endl; }
#define DOEXEC(sql) DOIT(sqlite3_exec(db, sql, 0, 0, 0))
DOIT(sqlite3_open("bad.db", &db));
DOEXEC("create table q (s string, id string, constraint pk_q primary key (id));");
DOEXEC("begin;");
DOEXEC("insert into q (s, id) values ('hello', 'id.1');");
DOEXEC("insert into q (s, id) values ('goodbye', 'id.2');");
DOEXEC("insert into q (s, id) values ('again', 'id.3');");
DOEXEC("end;");
sqlite3_stmt * stmt1;
DOIT(sqlite3_prepare(db, "select s, id from q", -1, &stmt1, NULL));
DOIT(sqlite3_step(stmt1));
sqlite3_stmt * stmt2;
DOIT(sqlite3_prepare(db, "select rowid, s, id from q where id = 'id.1'", -1, &stmt2, NULL));
DOIT(sqlite3_step(stmt2));
DOIT(sqlite3_finalize(stmt2));
DOEXEC("delete from q where rowid = 1;");
DOIT(sqlite3_finalize(stmt1));
DOEXEC("commit;");
DOIT(sqlite3_close(db));
The delete returns SQLITE_LOCKED, and the commit returns SQLITE_ERROR, all of which I would expect. But the database is left in an invalid state. A row is in the table, but not in the index:
sqlite> select * from q;
hello|id.1
goodbye|id.2
again|id.3
sqlite> select count(*) from q;
3
sqlite> select count(*) from q where id = 'id.1';
0
sqlite> pragma integrity_check;
rowid 1 missing from index sqlite_autoindex_q_1
wrong # of entries in index sqlite_autoindex_q_1
sqlite>
I understand that I shouldn't try to delete a row while a statement is still in the table, but I didn't think I could corrupt the database.
--Ned. |
|
839 |
code
|
fixed
|
2004 Aug
|
anonymous
|
|
2004 Aug
|
|
2
|
2
|
'int isdigit(int)' causes a crash
|
edit |
when inserting a string into a table which contains characters using more than 7 bits, the microsoft C lib throws an assertion and reads from an array of 256 elements at index 2^32+(char)c, which can cause a crash.
i fixed this problem, wrote a function sqlite3_isdigit and replaced it all over the code, but it is not a proper solution for every new release of sqlite. |
2004-Aug-05 16:09:04 by anonymous:
I encountered this problem as well. The solution is to compile the code with "char" defined as "unsigned char". For Visual Studio, you need the /J switch to the C compiler.
2004-Aug-05 16:09:23 by anonymous:
I meant to sign the last remark. --Ned Batchelder. |
|
838 |
new
|
fixed
|
2004 Aug
|
anonymous
|
|
2004 Aug
|
|
4
|
2
|
Change os_common.h to allow SQLITE_DEBUG on Windows.
|
edit |
Building with SQLITE_DEBUG doesn't work under Visual Studio .NET because of the assembly code for performance tracking. I moved them into a different define so I could enable the debug and performace stuff separately, as we discussed. |
|
837 |
code
|
fixed
|
2004 Aug
|
anonymous
|
|
2004 Sep
|
|
1
|
2
|
VACUUM returns "sql logic error or missing database"
|
edit |
Attempting to vacuum an otherwise working database, I am getting an error:
sqlite> vacuum;
SQL error: SQL logic error or missing database.
This is not an attached database, but the one specified on the command line. No transactions are active, and no clients are attached. Unfortunately the schema shows proprietary information, so I can't show it here. |
2004-Aug-04 14:46:07 by drh:
Unable to reproduce. Please develop a non-proprietary schema that
exhibits that problem and we'll have a look at it.
2004-Aug-04 15:08:26 by anonymous:
I'll see if I can reproduce the schema with the labels turned into "foo" "bar" "baz" etc... I'm under some severe time pressure ATM, so I'll have to do it sometime next week.
Someone here (see below) received (not even sqlite 3.x)... It's short on details, but if you're familiar with any bug behind that, maybe there was a regression? I'm on linux however, and getting it from both perl and commandline (the db was created with perl tho)... Sorry I'm not much help, I'll try to get a sample schema out that duplicates the issue.
Issue with vacuum in Nov 2003 post:
http://www.mail-archive.com/sqlite-users@sqlite.org/msg00496.html
2004-Aug-06 11:36:22 by anonymous:
Probably it is due to a problem with UNIQUE indexes.
It has been fixed; see ticket #829
2004-Sep-02 15:38:53 by drh:
Multiple issues with VACUUM have been fixed since this bug was
first posted. Since the bug report gives insufficient detail to
reproduce the problem, we'll assume it is fixed. |
|
834 |
code
|
fixed
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Aug
|
|
4
|
3
|
No equivalent to sqlite_libversion() API call in SQLite3
|
edit |
SQLite 2.8.x API had sqlite_libversion() API call which enabled access to the SQLite version, particularly from the Windows DLL.
SQlite 3.0.3 API does not have an equivalent, so it is not possible AFAIK to gain access to the version number of the complied library.
Can a sqlite3_libversion() API call be added? |
|
831 |
code
|
fixed
|
2004 Jul
|
anonymous
|
|
2004 Jul
|
|
4
|
3
|
sqlite_mprintf("%q", "") returns random data
|
edit |
sqlite_mprintf("%q", ""); will return a random data due to buffers that are never \0 terminated, causing the copy to grab 1 random byte of memory. |
2004-Jul-27 13:18:59 by anonymous:
The patch for the problem can be found here: patch
2004-Jul-27 13:29:35 by drh:
Already reported and fixed. See ticket #812. |
|
829 |
code
|
fixed
|
2004 Jul
|
drh
|
CodeGen
|
2004 Jul
|
drh
|
1
|
1
|
VACUUM fails if there is a UNIQUE index
|
edit |
The VACUUM command does not work if the database being vacuumed
contains a UNIQUE index. |
|
827 |
code
|
fixed
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Jul
|
|
2
|
3
|
sub-select involving random() does not work
|
edit |
say, we have a song database containing some 1000 songs.
Now if I want to retrieve 5 random songs from it:
First, using a sub-select statement which works fine with sqlite 2.x
(tested with up to 2.8.14) but shows the following erroneous behaviour with 3.0.x (up to x=3 and cvs of 26.7.2004):
frank@moby:~> sqlite3 /tmp/music.db "select id from song where id in ( select id from song order by random(*) limit 5);"
1
2
3
4
5
From all those 1000s of IDs, we just get 1,2,3,4,5 which is not very
random.
So let's see what the sub-select itself returns:
frank@moby:~> sqlite3 /tmp/music.db "select id from song order by random(*) limit 5;"
1212
271
65
2508
5232
Strange enough, random() itself works fine.
So let's be explicit:
frank@moby:~> sqlite3 /tmp/music.db "select id from song where id in ( '1212', '271', '65', '2508', '5232' );"
65
271
1212
2508
5232
|
|
826 |
code
|
fixed
|
2004 Jul
|
drh
|
CodeGen
|
2004 Aug
|
drh
|
1
|
1
|
Nested views do not process * correctly.
|
edit |
Consider the following code:
CREATE TABLE x(id integer primary key, a TEXT NULL);
INSERT INTO x (a) VALUES ('first');
CREATE TABLE tempx(id integer primary key, a TEXT NULL);
INSERT INTO tempx (a) VALUES ('t-first');
CREATE VIEW tv1 AS SELECT x.id, tx.id FROM x JOIN tempx tx ON tx.id=x.id;
CREATE VIEW tv1b AS SELECT x.id, tx.id FROM x JOIN tempx tx on tx.id=x.id;
CREATE VIEW tv2 AS SELECT * FROM tv1 UNION SELECT * FROM tv1b;
SELECT * FROM tv2;
The final SELECT fails with a "corrupt database" error. The
database is not really corrupt. What is happening is that the
outer view (tv2) thinks that the result set of the inner view
(the union of tv1 and tv1b) has only a single column, when in
fact the inner view has two columns. It appears that the "*"
is not being processed early enough.
A temporary work-around is to explicitly name all columns on
nested views instead of using "*". |
|
819 |
code
|
fixed
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Oct
|
|
1
|
2
|
building on linux/FC2 with --enable-threadsafe needs a -lpthread dep.
|
edit |
If I build on linux with thread support enabled I take,
for example...
[gpciceri@annie bld-3.0.3]$ make
./libtool --mode=link gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I../sqlite-3.0.3/src -DNDEBUG -DHAVE_READLINE=1 -I/usr/include/readline -o sqlite3 ../sqlite-3.0.3/src/shell.c \
libsqlite3.la -lreadline -lncurses
gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I../sqlite-3.0.3/src -DNDEBUG -DHAVE_READLINE=1 -I/usr/include/readline -o .libs/sqlite3 ../sqlite-3.0.3/src/shell.c ./.libs/libsqlite3.so -lreadline -lncurses -Wl,--rpath -Wl,/usr/local/lib
./.libs/libsqlite3.so: undefined reference to `pthread_create'
./.libs/libsqlite3.so: undefined reference to `pthread_join'
collect2: ld returned 1 exit status
make: *** [sqlite3] Error 1
If I manually add a -lpthread as a dep. it works.
Thanks for your * exceptional* work
/gp |
this problem happens on 3.0.3, too. |
|
818 |
doc
|
fixed
|
2004 Jul
|
anonymous
|
|
2004 Jul
|
|
4
|
3
|
The SQLite 3 API reference says "sqlite *" instead of "sqlite3 *"
|
edit |
For example, sqlite3_close is described as:
int sqlite3_close(sqlite *);
while sqlite3_open is:
int sqlite3_open(
const char filename, / Database filename (UTF-8) /
sqlite3 **ppDb / OUT: SQLite db handle */
);
Shouldn't they both be sqlite3 *, as the sqlite3.h file actually declares them? |
2004-Jul-22 14:36:45 by anonymous:
Also, some entry points use "db" as the arg name, and others use "pDb". |
|
813 |
code
|
fixed
|
2004 Jul
|
anonymous
|
|
2004 Jul
|
|
2
|
4
|
LEFT OUTER JOIN give wrong result when an index is present
|
edit |
The following sql script shows that the same query gives different (I think wrong) results when an index is created, while looks good when the index is not there.
A thing I noticed is that some different indexes can cause this problem while others don't (see the commented create index lines).
create table main (id int, key varchar(16));
insert into main values (0, 'AAA0');
insert into main values (1, 'AAA1');
insert into main values (2, 'AAA2');
insert into main values (3, 'AAA3');
create table temp (id int, name varchar(40), oid int);
insert into temp values (1, 'OLD', 1);
insert into temp values (1, 'NEW', 1);
insert into temp values (2, 'OLD', 2);
insert into temp values (3, 'NEW', 3);
create table atbl1 (id int, val varchar(10));
insert into atbl1 values (2, 'VAL2');
insert into atbl1 values (3, 'VAL3');
SELECT '################################ without index';
SELECT
main.key,
atbl1.val
FROM
main
LEFT OUTER JOIN atbl1 ON main.id = atbl1.id
LEFT OUTER JOIN temp ON main.id = temp.id
WHERE
temp.name = 'NEW';
CREATE UNIQUE INDEX idx_temp ON temp (name, id); -- FAIL
--CREATE UNIQUE INDEX idx_temp ON temp (name, oid); -- FAIL
--CREATE UNIQUE INDEX idx_temp ON temp (oid, name); -- OK
SELECT '################################ with index';
SELECT
main.key,
atbl1.val
FROM
main
LEFT OUTER JOIN atbl1 ON main.id = atbl1.id
LEFT OUTER JOIN temp ON main.id = temp.id
WHERE
temp.name = 'NEW';
DROP INDEX idx_temp;
SELECT '################################ without index again';
SELECT
main.key,
atbl1.val
FROM
main
LEFT OUTER JOIN atbl1 ON main.id = atbl1.id
LEFT OUTER JOIN temp ON main.id = temp.id
WHERE
temp.name = 'NEW';
Actually I have different, much more complex queries giving spurious results, this one is the one I could strip down more, while still showing the problem, I hope a fix for this works also for the other. |
2004-Jul-19 18:31:08 by drh:
A simpler test case:
create temp table t1(a integer, b varchar(10));
insert into t1 values(1,'one');
insert into t1 values(2,'two');
insert into t1 values(3,'three');
insert into t1 values(4,'four');
create temp table t2(x integer, y varchar(10), z varchar(10));
insert into t2 values(2,'niban','ok');
insert into t2 values(4,'yonban','err');
select 111,* from t1 left outer join t2 on t1.a=t2.x where t2.z='ok';
select 222,* from t1 left outer join t2 on t1.a=t2.x and t2.z='ok';
create index i2 on t2(z);
select 333,* from t1 left outer join t2 on t1.a=t2.x where t2.z='ok';
The 111 query returns 1 row and the 222 query returns 4 rows.
PostgreSQL (which I will take as the gold standard) does the same.
Query 333 is a repeat of 111 except that there is now an index
on t2.z. The result of 333 should be the same as 111 - one row.
But instead it works like query 222 - four rows of result. |
|
812 |
code
|
fixed
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Jul
|
|
3
|
3
|
sqlite_mprintf ("%s", "") - "%s" alone with empty string arg fails
|
edit |
The following code results a a string of garbage being returned:
char * ret;
ret = sqlite_mprintf ("%s", "");
printf ("%s\n", ret);
The basic problem is in printf.c. Since the above never generates any output, vxprintf() never calls the text-consumer function. This is mout() when called from base_vprintf(), and base_vprintf() relies on mout() appending the end-of-string null byte. No null byte == garbage returned.
The following patch seemed to work for me:
--- printf.c.orig 2004-06-15 21:50:58.000000000 -0400
+++ printf.c 2004-07-17 12:01:45.875000000 -0400
@@ -227,6 +227,7 @@
int nsd; /* Number of significant digits returned */
#endif
+ (*func)(arg,"",0);
count = length = 0;
bufpt = 0;
for(; (c=(*fmt))!=0; ++fmt){
@@ -676,8 +677,8 @@
if( pM->zText && nNewChar>0 ){
memcpy(&pM->zText[pM->nChar], zNewText, nNewChar);
pM->nChar += nNewChar;
- pM->zText[pM->nChar] = 0;
}
+ pM->zText[pM->nChar] = 0;
}
/*
|
|
811 |
code
|
fixed
|
2004 Jul
|
drh
|
|
2004 Jul
|
drh
|
1
|
1
|
When ATTACH fails, strange things happen.
|
edit |
SQLite version 3.0.2
Enter ".help" for instructions
sqlite> ATTACH DATABASE "/nodir/nofile.db" as at1;
SQL error: unable to open database: /nodir/nofile.db
sqlite> ATTACH DATABASE "/file.db" as at1;
SQL error: database at1 is already in use
sqlite> DETACH DATABASE at1;
SQL error: no such database: at1
|
|
810 |
code
|
fixed
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Sep
|
|
1
|
3
|
SELECT ROWID, * FROM SOMEVIEW -> crash
|
edit |
See http://bugs.php.net/bug.php?id=28537
"select rowid, * from someview" will crash php.
"select rowid, * from sometable" runs fine.
Result -> cgi will crash, server will close the connection.
This was a bug (#364) in older sqlite versions:
http://www.sqlite.org/cvstrac/tktview?tn=364,16
The PHP folks sent me here:
[10 Jul 3:46pm CEST] wez@php.net
In that case, please report the bug to the sqlite developers, since the crash is inside libsqlite.
I'm marking this as Bogus because it isn't a bug in PHP.
Feel free to reference this report from your sqlite report.
|
2004-Jul-15 15:40:50 by drh:
Unable to reproduce.
Please submit the definition of "someview". The problem is
probably related to some obscure view syntax.
2004-Sep-02 15:40:46 by drh:
This is probably the same as ticket #826 which has now been fixed. |
|
807 |
code
|
fixed
|
2004 Jul
|
anonymous
|
VDBE
|
2004 Jul
|
|
1
|
3
|
Cannot run a prepared CREATE TABLE statement more than once
|
edit |
- Prepare a CREATE TABLE statement. (A CREATE INDEX would probably
also cause the same problem.)
- Run it.
- DROP the table that was created.
- Reset the statement
- Run the statement again.
A crash occurs the second time the statement is executed.
This same bug probably also exists in version 2.8. |
|
806 |
code
|
fixed
|
2004 Jul
|
anonymous
|
VDBE
|
2004 Jul
|
|
3
|
3
|
The maximum number of tables allowed in a join is 32.
|
edit |
The following sql script works as I expected, it uses 32 tables. If the commented lines are uncommented, the query gives no result.
Note that the same holds for plain joins (list of tables in the FROM clause and conditions in the WHERE clause)
CREATE TABLE tbl00 (id integer, fld varchar(9));
CREATE TABLE tbl01 (id integer, fld varchar(9));
CREATE TABLE tbl02 (id integer, fld varchar(9));
CREATE TABLE tbl03 (id integer, fld varchar(9));
CREATE TABLE tbl04 (id integer, fld varchar(9));
CREATE TABLE tbl05 (id integer, fld varchar(9));
CREATE TABLE tbl06 (id integer, fld varchar(9));
CREATE TABLE tbl07 (id integer, fld varchar(9));
CREATE TABLE tbl08 (id integer, fld varchar(9));
CREATE TABLE tbl09 (id integer, fld varchar(9));
CREATE TABLE tbl10 (id integer, fld varchar(9));
CREATE TABLE tbl11 (id integer, fld varchar(9));
CREATE TABLE tbl12 (id integer, fld varchar(9));
CREATE TABLE tbl13 (id integer, fld varchar(9));
CREATE TABLE tbl14 (id integer, fld varchar(9));
CREATE TABLE tbl15 (id integer, fld varchar(9));
CREATE TABLE tbl16 (id integer, fld varchar(9));
CREATE TABLE tbl17 (id integer, fld varchar(9));
CREATE TABLE tbl18 (id integer, fld varchar(9));
CREATE TABLE tbl19 (id integer, fld varchar(9));
CREATE TABLE tbl20 (id integer, fld varchar(9));
CREATE TABLE tbl21 (id integer, fld varchar(9));
CREATE TABLE tbl22 (id integer, fld varchar(9));
CREATE TABLE tbl23 (id integer, fld varchar(9));
CREATE TABLE tbl24 (id integer, fld varchar(9));
CREATE TABLE tbl25 (id integer, fld varchar(9));
CREATE TABLE tbl26 (id integer, fld varchar(9));
CREATE TABLE tbl27 (id integer, fld varchar(9));
CREATE TABLE tbl28 (id integer, fld varchar(9));
CREATE TABLE tbl29 (id integer, fld varchar(9));
CREATE TABLE tbl30 (id integer, fld varchar(9));
CREATE TABLE tbl31 (id integer, fld varchar(9));
CREATE TABLE tbl32 (id integer, fld varchar(9));
INSERT INTO tbl00 VALUES (4, 'tbl00_4');
INSERT INTO tbl01 VALUES (4, 'tbl01_4');
INSERT INTO tbl02 VALUES (4, 'tbl02_4');
INSERT INTO tbl03 VALUES (4, 'tbl03_4');
INSERT INTO tbl04 VALUES (4, 'tbl04_4');
INSERT INTO tbl05 VALUES (4, 'tbl05_4');
INSERT INTO tbl06 VALUES (4, 'tbl06_4');
INSERT INTO tbl07 VALUES (4, 'tbl07_4');
INSERT INTO tbl08 VALUES (4, 'tbl08_4');
INSERT INTO tbl09 VALUES (4, 'tbl09_4');
INSERT INTO tbl10 VALUES (4, 'tbl10_4');
INSERT INTO tbl11 VALUES (4, 'tbl11_4');
INSERT INTO tbl12 VALUES (4, 'tbl12_4');
INSERT INTO tbl13 VALUES (4, 'tbl13_4');
INSERT INTO tbl14 VALUES (4, 'tbl14_4');
INSERT INTO tbl15 VALUES (4, 'tbl15_4');
INSERT INTO tbl16 VALUES (4, 'tbl16_4');
INSERT INTO tbl17 VALUES (4, 'tbl17_4');
INSERT INTO tbl18 VALUES (4, 'tbl18_4');
INSERT INTO tbl19 VALUES (4, 'tbl19_4');
INSERT INTO tbl20 VALUES (4, 'tbl20_4');
INSERT INTO tbl21 VALUES (4, 'tbl21_4');
INSERT INTO tbl22 VALUES (4, 'tbl22_4');
INSERT INTO tbl23 VALUES (4, 'tbl23_4');
INSERT INTO tbl24 VALUES (4, 'tbl24_4');
INSERT INTO tbl25 VALUES (4, 'tbl25_4');
INSERT INTO tbl26 VALUES (4, 'tbl26_4');
INSERT INTO tbl27 VALUES (4, 'tbl27_4');
INSERT INTO tbl28 VALUES (4, 'tbl28_4');
INSERT INTO tbl29 VALUES (4, 'tbl29_4');
INSERT INTO tbl30 VALUES (4, 'tbl30_4');
INSERT INTO tbl31 VALUES (4, 'tbl31_4');
INSERT INTO tbl32 VALUES (4, 'tbl32_4');
SELECT
tbl00.fld
,tbl01.fld
,tbl02.fld
,tbl03.fld
,tbl04.fld
,tbl05.fld
,tbl06.fld
,tbl07.fld
,tbl08.fld
,tbl09.fld
,tbl10.fld
,tbl11.fld
,tbl12.fld
,tbl13.fld
,tbl14.fld
,tbl15.fld
,tbl16.fld
,tbl17.fld
,tbl18.fld
,tbl19.fld
,tbl20.fld
,tbl21.fld
,tbl22.fld
,tbl23.fld
,tbl24.fld
,tbl25.fld
,tbl26.fld
,tbl27.fld
,tbl28.fld
,tbl29.fld
,tbl30.fld
,tbl31.fld
-- ,tbl32.fld
FROM
tbl00
LEFT OUTER JOIN tbl01 ON tbl00.id = tbl01.id
LEFT OUTER JOIN tbl02 ON tbl00.id = tbl02.id
LEFT OUTER JOIN tbl03 ON tbl00.id = tbl03.id
LEFT OUTER JOIN tbl04 ON tbl00.id = tbl04.id
LEFT OUTER JOIN tbl05 ON tbl00.id = tbl05.id
LEFT OUTER JOIN tbl06 ON tbl00.id = tbl06.id
LEFT OUTER JOIN tbl07 ON tbl00.id = tbl07.id
LEFT OUTER JOIN tbl08 ON tbl00.id = tbl08.id
LEFT OUTER JOIN tbl09 ON tbl00.id = tbl09.id
LEFT OUTER JOIN tbl10 ON tbl00.id = tbl10.id
LEFT OUTER JOIN tbl11 ON tbl00.id = tbl11.id
LEFT OUTER JOIN tbl12 ON tbl00.id = tbl12.id
LEFT OUTER JOIN tbl13 ON tbl00.id = tbl13.id
LEFT OUTER JOIN tbl14 ON tbl00.id = tbl14.id
LEFT OUTER JOIN tbl15 ON tbl00.id = tbl15.id
LEFT OUTER JOIN tbl16 ON tbl00.id = tbl16.id
LEFT OUTER JOIN tbl17 ON tbl00.id = tbl17.id
LEFT OUTER JOIN tbl18 ON tbl00.id = tbl18.id
LEFT OUTER JOIN tbl19 ON tbl00.id = tbl19.id
LEFT OUTER JOIN tbl20 ON tbl00.id = tbl20.id
LEFT OUTER JOIN tbl21 ON tbl00.id = tbl21.id
LEFT OUTER JOIN tbl22 ON tbl00.id = tbl22.id
LEFT OUTER JOIN tbl23 ON tbl00.id = tbl23.id
LEFT OUTER JOIN tbl24 ON tbl00.id = tbl24.id
LEFT OUTER JOIN tbl25 ON tbl00.id = tbl25.id
LEFT OUTER JOIN tbl26 ON tbl00.id = tbl26.id
LEFT OUTER JOIN tbl27 ON tbl00.id = tbl27.id
LEFT OUTER JOIN tbl28 ON tbl00.id = tbl28.id
LEFT OUTER JOIN tbl29 ON tbl00.id = tbl29.id
LEFT OUTER JOIN tbl30 ON tbl00.id = tbl30.id
LEFT OUTER JOIN tbl31 ON tbl00.id = tbl31.id
-- LEFT OUTER JOIN tbl32 ON tbl00.id = tbl32.id
WHERE
tbl00.id = 4
;
|
|
805 |
code
|
fixed
|
2004 Jul
|
anonymous
|
|
2004 Jul
|
|
3
|
2
|
coalesce in the where clause doesn't work
|
edit |
consider the query:
select 1 where "234" <= "" return nothing as expected,
however,
select 1 where "234" <= coalesce("","0") return 1
(pls don't ask why I'm writing these queries, this is not the point) |
2004-Jul-19 00:12:45 by drh:
This has nothing to do with coalesce. The following statement
also returns 1:
SELECT 1 WHERE '234'<'';
The reason is that the comparison operator is using numeric affinity.
So the '234' string gets converted into an integer 234. But the ''
string stays a string. And numbers are always less than strings.
The question is: should the < operator in this context use numeric
affinity, or should it be changed to use no affinity.
2004-Jul-19 00:38:18 by drh:
Decision is to change the comparison operators to use no affinity
when the operands are both expressions. |
|
804 |
code
|
fixed
|
2004 Jul
|
anonymous
|
|
2004 Jul
|
|
1
|
1
|
sqliteStrNICmp() and sqliteStrICmp() return wrong value.
|
edit |
sqliteStrNICmp() and sqliteStrICmp() return wrong value.
For example
sqliteStrNICmp("Family", "birthday") == -1
the statement:
return *a - *b;
should probably be:
return UpperToLower[*a] - UpperToLower[*b];
see code below for details:
util.c
502 int sqliteStrICmp(const char *zLeft, const char *zRight){
503 register unsigned char *a, *b;
504 a = (unsigned char *)zLeft;
505 b = (unsigned char *)zRight;
506 while( *a!=0 && UpperToLower[*a]==UpperToLower[*b]){ a++; b++; }
507 return *a - *b;
508 }
509 int sqliteStrNICmp(const char *zLeft, const char *zRight, int N){
510 register unsigned char *a, *b;
511 a = (unsigned char *)zLeft;
512 b = (unsigned char *)zRight;
513 while( N-- > 0 && *a!=0 && UpperToLower[*a]==UpperToLower[*b]){ a++; b++; }
514 return N<0 ? 0 : *a - *b;
515 }
|
2004-Jul-12 02:38:08 by anonymous:
this might be better:
return ((int)UpperToLower[*a]) - ((int)UpperToLower[*b]);
2004-Jul-12 02:49:32 by anonymous:
first line of bug report should read:
sqliteStrNICmp() and sqliteStrICmp() return wrong value. For example
sqliteStrICmp("Family", "birthday") < 0
2004-Jul-15 13:23:23 by drh:
Thank you for reporting this. The problem is now fixed.
Note that this is not a "real" problem in the sense that it does
not make SQLite malfunction. SQLite uses these routines for equality
testing only, and for that purpose they work fine as they are. |
|
800 |
todo
|
fixed
|
2004 Jul
|
anonymous
|
VDBE
|
2004 Jul
|
|
3
|
3
|
Handling of NULLs by set function MIN has been changed to non-standard
|
edit |
As a result of bug ticket #777, check-in [1679]
changed the behavior of aggregate function MIN to be "consistent with" ORDER BY. MIN(C) now returns NULL if column (or expression) C is NULL for any row of the table -- the rationale being that SQLite sorts NULLs before all meaningful (not null) values.
Trying to make MIN "consistent with" ORDER BY is a bad idea:
- it's contrary to the SQL-92 standard
- it's contrary to what all the major SQL DBMSs currently do
- it's contrary to what SQL engines have always done (even before the '92 std)
MIN is intended to produce the smallest known value of a column or
expression. NULL is not a known value; it's a place holder for a
missing value.
A return value of NULL from MIN is significant; it's supposed to
indicate that the value requested cannot be calculated because the set
being scanned (after removal of NULLs) is empty. In other words, it
means that a column contains no data. In SQLite, after check-in
[1679]
, a return of NULL could mean that, or it could just mean that
there's missing data in one row.
Consider another incompatibility this NULL return would introduce if
other implementors adopted it. The standard says that MIN and MAX
should be calculated, after removing NULLs, using the same comparison
predicate that's used by ORDER BY, but that the position of NULLs
after an ORDER BY is implementation dependent. Suppose another SQL
implementor agreed that MIN and MAX should include NULLs and should be
consistent with ORDER BY, but he chose to have NULLs collate after all
meaningful values. Then his MAX would have to return NULL for the
same data set where SQLite's MIN returns NULL.
If a programmer has to have the non-standard behavior, the work-around is simple:
select case when (select count(*) from t where c is null) = 0
then min(c)
else null end AltMinC
from t
MIN should be changed back so that it eliminates NULLs before it tries to calculate the requested value; this is the standard behavior of all aggregate functions except COUNT(*). |
|
794 |
new
|
fixed
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Jul
|
|
4
|
3
|
add API to report number of wildcards in sqlite3_prepare*
|
edit |
Although sqlite3_prepare() et.al. support wildcard literals
(parameter markers in ODBC speak) there's no API to programmatically
determine the number of wildcards in the current SQL statement text.
Proposal:
/*
** Return the number of wildcard literals in the current
** SQL string given to sqlite3_prepare() and sqlite3_prepare16().
*/
int sqlite3_bind_count(sqlite3_stmt *);
|
Experimental API: sqlite3_bind_parameter_count(). |
|
793 |
new
|
fixed
|
2004 Jul
|
anonymous
|
Unknown
|
2005 Feb
|
drh
|
4
|
4
|
Source *.tar.gz Files Should Untar Into Directory sqlite-{version}
|
edit |
When distributing sqlite-{version}-tar.gz compressed source code files, please have them untar into a directory sqlite-{version}. For instance, file sqlite-3.0.2-tar.gz should create and untar into a directory sqlite-3.0.2. Presently, it untars into a directory named sqlite.
Thanks, Bob Cochran |
|
791 |
code
|
fixed
|
2004 Jul
|
anonymous
|
|
2004 Jul
|
|
1
|
1
|
3.0.2 fails to build under Mingw
|
edit |
dcorbit@DANNFAST /e/sqlite
$ ./configure
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for a sed that does not truncate output... /bin/sed
checking for egrep... grep -E
checking for ld used by gcc... u:/mingw/mingw32/bin/ld.exe
checking if the linker (u:/mingw/mingw32/bin/ld.exe) is GNU ld... yes
checking for u:/mingw/mingw32/bin/ld.exe option to reload object files... -r
checking for BSD-compatible nm... /mingw/bin/nm
checking whether ln -s works... yes
checking how to recognise dependent libraries... file_magic file format pei*-i386(.*architecture: i386)?
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... no
checking dlfcn.h presence... no
checking for dlfcn.h... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... g77
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether g77 accepts -g... yes
checking the maximum length of command line arguments... 8192
checking command to parse /mingw/bin/nm output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag works... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT
checking if gcc PIC flag -DDLL_EXPORT works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (u:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... u:/mingw/mingw32/bin/ld.exe
checking if the linker (u:/mingw/mingw32/bin/ld.exe) is GNU ld... yes
checking whether the g++ linker (u:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes
checking for g++ option to produce PIC... -DDLL_EXPORT
checking if g++ PIC flag -DDLL_EXPORT works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (u:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
appending configuration tag "F77" to libtool
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for g77 option to produce PIC... -DDLL_EXPORT
checking if g77 PIC flag -DDLL_EXPORT works... yes
checking if g77 supports -c -o file.o... yes
checking whether the g77 linker (u:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking for a BSD-compatible install... /bin/install -c
Version set to 3.0.2
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ANSI C... (cached) none needed
checking switches for the host compiler... -g -O2
checking target compiler... gcc
checking switches on the target compiler... -g -O2
checking target linker... gcc
checking switches on the target compiler... checking for ranlib... (cached) ranlib
-g -O2
checking if host and target compilers are the same... yes
checking whether to support threadsafe operation... no
checking whether to support shared library linked as release mode or not... no
checking whether to use an in-ram database for temporary tables... yes
checking if executables have the .exe suffix... unknown
checking for sin... yes
checking for dlopen in -ldl... no
checking for library containing Tcl_Init... -ltcl84
checking TCL header files... not specified: still searching...
checking tcl.h usability... yes
checking tcl.h presence... yes
checking for tcl.h... yes
checking for library containing tgetent... -ltermcap
checking for readline in -lreadline... yes
checking readline header files... not specified: still searching...
checking readline.h usability... no
checking readline.h presence... no
checking for readline.h... no
checking for /usr/include/readline.h... no
checking for /usr/include/readline/readline.h... no
checking for /usr/local/include/readline.h... no
checking for /usr/local/include/readline/readline.h... no
checking for /usr/local/readline/include/readline.h... no
checking for /usr/local/readline/include/readline/readline.h... no
checking for /usr/contrib/include/readline.h... no
checking for /usr/contrib/include/readline/readline.h... no
checking for /mingw/include/readline.h... no
checking for /mingw/include/readline/readline.h... yes
checking for usleep... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating sqlite.pc
dcorbit@DANNFAST /e/sqlite
$ make clean
rm -f *.lo *.la *.o sqlite3.exe libsqlite3.la
rm -f sqlite3.h opcodes.*
rm -rf .libs .deps
rm -f lemon.exe lempar.c parse.* sqlite*.tar.gz
rm -f
rm -f *.da *.bb *.bbg gmon.out
rm -f testfixture.exe test.db
rm -rf doc
rm -f common.tcl
rm -f sqlite3.dll sqlite3.lib
dcorbit@DANNFAST /e/sqlite
$ make
sed -e s/--VERS--/`cat ./VERSION`/ \
./src/sqlite.h.in >sqlite3.h
echo '/* Automatically generated file. Do not edit */' >opcodes.h
grep '^case OP_' ./src/vdbe.c | \
sed -e 's/://' | \
awk '{printf "#define %-30s %3d\n", $2, ++cnt}' >>opcodes.h
gcc -g -O2 -o lemon ./tool/lemon.c
cp ./tool/lempar.c .
cp ./src/parse.y .
./lemon parse.y
./libtool --mode=compile gcc -g -O2 -DOS_WIN=1 -I. -I./src -DNDEBUG -c ./src/attach.c
mkdir .libs
gcc -g -O2 -DOS_WIN=1 -I. -I./src -DNDEBUG -c ./src/attach.c -DDLL_EXPORT -DPIC -o .libs/attach.o
gcc -g -O2 -DOS_WIN=1 -I. -I./src -DNDEBUG -c ./src/attach.c -o attach.o >/dev/null 2>&1
./libtool --mode=compile gcc -g -O2 -DOS_WIN=1 -I. -I./src -DNDEBUG -c ./src/auth.c
gcc -g -O2 -DOS_WIN=1 -I. -I./src -DNDEBUG -c ./src/auth.c -DDLL_EXPORT -DPIC -o .libs/auth.o
gcc -g -O2 -DOS_WIN=1 -I. -I./src -DNDEBUG -c ./src/auth.c -o auth.o >/dev/null 2>&1
./libtool --mode=compile gcc -g -O2 -DOS_WIN=1 -I. -I./src -DNDEBUG -c ./src/btree.c
gcc -g -O2 -DOS_WIN=1 -I. -I./src -DNDEBUG -c ./src/btree.c -DDLL_EXPORT -DPIC -o .libs/btree.o
gcc -g -O2 -DOS_WIN=1 -I. -I./src -DNDEBUG -c ./src/btree.c -o btree.o >/dev/null 2>&1
./libtool --mode=compile gcc -g -O2 -DOS_WIN=1 -I. -I./src -DNDEBUG -c ./src/build.c
gcc -g -O2 -DOS_WIN=1 -I. -I./src -DNDEBUG -c ./src/build.c -DDLL_EXPORT -DPIC -o .libs/build.o
./src/build.c: In function `sqlite3OpenMasterTable':
./src/build.c:440: error: `OP_SetNumColumns' undeclared (first use in this function)
./src/build.c:440: error: (Each undeclared identifier is reported only once
./src/build.c:440: error: for each function it appears in.)
./src/build.c: In function `sqlite3StartTable':
./src/build.c:694: error: `OP_String8' undeclared (first use in this function)
./src/build.c: In function `sqlite3EndTable':
./src/build.c:1356: error: `OP_String8' undeclared (first use in this function)
./src/build.c:1377: error: `OP_Concat8' undeclared (first use in this function)
./src/build.c: In function `sqlite3DropTable':
./src/build.c:1667: error: `OP_String8' undeclared (first use in this function)
./src/build.c:1667: error: initializer element is not constant
./src/build.c:1667: error: (near initialization for `dropTable[1].opcode')
./src/build.c:1667: error: initializer element is not constant
./src/build.c:1667: error: (near initialization for `dropTable[1]')
./src/build.c:1668: error: initializer element is not constant
./src/build.c:1668: error: (near initialization for `dropTable[2]')
./src/build.c:1669: error: initializer element is not constant
./src/build.c:1669: error: (near initialization for `dropTable[3]')
./src/build.c:1670: error: initializer element is not constant
./src/build.c:1670: error: (near initialization for `dropTable[4]')
./src/build.c:1671: error: initializer element is not constant
./src/build.c:1671: error: (near initialization for `dropTable[5]')
./src/build.c:1672: error: initializer element is not constant
./src/build.c:1672: error: (near initialization for `dropTable[6].opcode')
./src/build.c:1672: error: initializer element is not constant
./src/build.c:1672: error: (near initialization for `dropTable[6]')
./src/build.c:1673: error: initializer element is not constant
./src/build.c:1673: error: (near initialization for `dropTable[7]')
./src/build.c:1674: error: initializer element is not constant
./src/build.c:1674: error: (near initialization for `dropTable[8]')
./src/build.c:1675: error: initializer element is not constant
./src/build.c:1675: error: (near initialization for `dropTable[9]')
./src/build.c:1676: error: initializer element is not constant
./src/build.c:1676: error: (near initialization for `dropTable[10]')
./src/build.c:1677: error: initializer element is not constant
./src/build.c:1677: error: (near initialization for `dropTable[11]')
./src/build.c:1678: error: initializer element is not constant
./src/build.c:1678: error: (near initialization for `dropTable[12]')
./src/build.c: In function `sqlite3CreateIndex':
./src/build.c:2159: error: `OP_String8' undeclared (first use in this function)
./src/build.c:2180: error: `OP_Concat8' undeclared (first use in this function)
./src/build.c:2188: error: `OP_SetNumColumns' undeclared (first use in this function)
./src/build.c: In function `sqlite3DropIndex':
./src/build.c:2288: error: `OP_String8' undeclared (first use in this function)
./src/build.c:2288: error: initializer element is not constant
./src/build.c:2288: error: (near initialization for `dropIndex[1].opcode')
./src/build.c:2288: error: initializer element is not constant
./src/build.c:2288: error: (near initialization for `dropIndex[1]')
./src/build.c:2289: error: initializer element is not constant
./src/build.c:2289: error: (near initialization for `dropIndex[2]')
./src/build.c:2290: error: initializer element is not constant
./src/build.c:2290: error: (near initialization for `dropIndex[3]')
./src/build.c:2291: error: initializer element is not constant
./src/build.c:2291: error: (near initialization for `dropIndex[4]')
./src/build.c:2292: error: initializer element is not constant
./src/build.c:2292: error: (near initialization for `dropIndex[5]')
./src/build.c:2293: error: initializer element is not constant
./src/build.c:2293: error: (near initialization for `dropIndex[6]')
./src/build.c:2294: error: initializer element is not constant
./src/build.c:2294: error: (near initialization for `dropIndex[7]')
./src/build.c:2295: error: initializer element is not constant
./src/build.c:2295: error: (near initialization for `dropIndex[8]')
./src/build.c: In function `sqlite3BeginTransaction':
./src/build.c:2490: error: `OP_AutoCommit' undeclared (first use in this function)
./src/build.c: In function `sqlite3CommitTransaction':
./src/build.c:2506: error: `OP_AutoCommit' undeclared (first use in this function)
./src/build.c: In function `sqlite3RollbackTransaction':
./src/build.c:2523: error: `OP_AutoCommit' undeclared (first use in this function)
./src/build.c: In function `sqlite3BeginWriteOperation':
./src/build.c:2590: error: `OP_Statement' undeclared (first use in this function)
make: *** [build.lo] Error 1
dcorbit@DANNFAST /e/sqlite
$
|
2004-Jul-02 04:46:28 by anonymous:
I think there is no errors. you just did "make clean" after configure that deletes sqlite3.h. just do "make" after "configure". |
|
789 |
code
|
fixed
|
2004 Jun
|
anonymous
|
|
2004 Jun
|
|
1
|
1
|
the 'LL' qualifier is not supported by MSVC
|
edit |
hello,
in vdbe.c the new 'LL' qualifier are not recognised by MSVC
in contrast (for example source util.c) gcc understands the
qualifierer 'ULL' (if( v & 0xff00000000000000ULL ) |
|
786 |
code
|
fixed
|
2004 Jun
|
anonymous
|
BTree
|
2004 Aug
|
drh
|
1
|
1
|
sqlite3 change SQLITE_PAGE_SIZE to 4096 causes assert
|
edit |
sqlite3 change SQLITE_PAGE_SIZE to 4096 causes assert |
2004-Jul-01 17:46:50 by anonymous:
I think there are some places where 1024 instead of the macro is used. Change it seems to correct the problem.
2004-Aug-28 by drh:
Should have been fixed when SQLITE_PAGE_SIZE was removed. |
|
785 |
code
|
fixed
|
2004 Jun
|
anonymous
|
|
2004 Jun
|
|
1
|
1
|
local variable 'db' used without having been initialized
|
edit |
function: sqlite3VdbeFinalize()
vdbeaux.c(1325) : warning C4700: local variable 'db' used without having been initialized |
|
784 |
code
|
fixed
|
2004 Jun
|
anonymous
|
|
2004 Jul
|
|
2
|
2
|
SQLITE_OMIT_DATETIME_FUNCS code error with Microsoft compilers
|
edit |
When SQLITE_OMIT_DATETIME_FUNCS is defined, a compiler error is generated because Microsoft compilers don't like zero sized array definitions.
The affected file is "date.c", in the sqliteRegisterDateTimeFunctions function:
--- date.c --------------------------------------------------------
void sqliteRegisterDateTimeFunctions(sqlite *db){
static struct {
char *zName;
int nArg;
int dataType;
void (*xFunc)(sqlite_func*,int,const char**);
} aFuncs[] = {
* #ifndef SQLITE_OMIT_DATETIME_FUNCS
* { "julianday", -1, SQLITE_NUMERIC, juliandayFunc },
* { "date", -1, SQLITE_TEXT, dateFunc },
* { "time", -1, SQLITE_TEXT, timeFunc },
* { "datetime", -1, SQLITE_TEXT, datetimeFunc },
* { "strftime", -1, SQLITE_TEXT, strftimeFunc },
* #endif
};
int i;
--- date.c --------------------------------------------------------
A quick fix is to extend #ifndef to englobe the function body, instead of just the array values, like this:
--- date.c --------------------------------------------------------
void sqliteRegisterDateTimeFunctions(sqlite *db){
#ifndef SQLITE_OMIT_DATETIME_FUNCS
static struct {
char *zName;
int nArg;
int dataType;
void (*xFunc)(sqlite_func*,int,const char**);
} aFuncs[] = {
{ "julianday", -1, SQLITE_NUMERIC, juliandayFunc },
{ "date", -1, SQLITE_TEXT, dateFunc },
{ "time", -1, SQLITE_TEXT, timeFunc },
{ "datetime", -1, SQLITE_TEXT, datetimeFunc },
{ "strftime", -1, SQLITE_TEXT, strftimeFunc },
};
int i;
for(i=0; i<sizeof(aFuncs)/sizeof(aFuncs[0]); i++){
sqlite_create_function(db, aFuncs[i].zName,
aFuncs[i].nArg, aFuncs[i].xFunc, 0);
if( aFuncs[i].xFunc ){
sqlite_function_type(db, aFuncs[i].zName, aFuncs[i].dataType);
}
}
#endif
}
--- date.c --------------------------------------------------------
I believe this affects all Microsoft compilers, but only checked Microsoft Visual C++ .NET 2003 and embebed Visual C++ 3.0 (based on the VC++ 6.0 compiler). |
|
782 |
new
|
fixed
|
2004 Jun
|
anonymous
|
Unknown
|
2005 Feb
|
|
3
|
2
|
Correlated subqueries are not supported
|
edit |
When having a subselect, it's impossible to create a backreference from that subselect to its parent select, like follows:
SELECT t1.ID,(SELECT COUNT(*) Cnt FROM t2 WHERE t2.ID=t1.ID) FROM t1
It says the "t1.ID" in the subselect doesn't exist, while it does. |
|
778 |
code
|
fixed
|
2004 Jun
|
anonymous
|
Unknown
|
2004 Jun
|
|
1
|
1
|
output of sqlite3_mprintf isn't correct
|
edit |
After some testing of sqlite 3.0.1 I found problems
with sqlite3_mprintf.
I testet the function with g++ 3.2.2 under linux and
GCC 3.3.1 (cygming special)
Output from the function testva(see below) is
--- using %lu
ul1: 7fffffff, 2147483647, 2147483647
ul2: ffffffff, 4294967295, 18446744073709551615
ul3: 80000000, 2147483648, 18446744071562067968
--- using %u
l1: 7fffffff, 2147483647, 2147483647
l2: ffffffff, 4294967295, 18446744073709551615
l3: 80000000, 2147483648, 18446744071562067968
--- using %d
l1: 7fffffff, 2147483647, 2147483647
l2: ffffffff, -1, -1
l3: 80000000, -2147483648, -18446744071562067968
The function running with sqlite 2.8.x is
--- using %lu
ul1: 7fffffff, 2147483647, 2147483647
ul2: ffffffff, 4294967295, 4294967295
ul3: 80000000, 2147483648, 2147483648
--- using %u
l1: 7fffffff, 2147483647, 2147483647
l2: ffffffff, 4294967295, 4294967295
l3: 80000000, 2147483648, 2147483648
--- using %d
l1: 7fffffff, 2147483647, 2147483647
l2: ffffffff, -1, -1
l3: 80000000, -2147483648, -2147483648
I think these are the correct values
----------------------------------------------
void testva(void)
{
char *s;
unsigned long ul1 = 0x7FFFFFFF;
unsigned long ul2 = 0xFFFFFFFF;
unsigned long ul3 = 0x80000000;
printf ( "--- using %%lu\n");
s = sqlite3_mprintf("%lu", ul1);
printf("ul1: %lx, %lu, %s\n", ul1, ul1 ,s);
s = sqlite3_mprintf("%lu", ul2);
printf("ul2: %lx, %lu, %s\n", ul2, ul2 ,s);
s = sqlite3_mprintf("%lu", ul3);
printf("ul3: %lx, %lu, %s\n", ul3, ul3 ,s);
unsigned l1 = 0x7FFFFFFF;
unsigned l2 = 0xFFFFFFFF;
unsigned l3 = 0x80000000;
printf ( "--- using %%u\n");
s = sqlite3_mprintf("%u", l1);
printf("l1: %x, %u, %s\n", l1, l1, s);
s = sqlite3_mprintf("%u", l2);
printf("l2: %x, %u, %s\n", l2, l2, s);
s = sqlite3_mprintf("%u", l3);
printf("l3: %x, %u, %s\n", l3, l3, s);
printf ( "--- using %%d\n");
s = sqlite3_mprintf("%d", l1);
printf("l1: %x, %d, %s\n", l1, l1, s);
s = sqlite3_mprintf("%d", l2);
printf("l2: %x, %d, %s\n", l2, l2, s);
s = sqlite3_mprintf("%d", l3);
printf("l3: %x, %d, %s\n", l3, l3, s);
}
|
2004-Jun-24 22:24:08 by anonymous:
well, I have traced the function vxprintf()
the reason for the error is in the line:
else if( flag_long ) longvalue = va_arg(ap,long int);
if for an unsigned long int value this line is changed to:
else if( flag_long ) longvalue = va_arg(ap,long unsigned int);
the conversion is correct. I think by calling va_arg() the %u qualifier
must be taken in account.
|
|
777 |
code
|
fixed
|
2004 Jun
|
anonymous
|
|
2004 Jun
|
|
1
|
1
|
MIN() does not return NULL if there is a NULL in the list
|
edit |
select X from tableX ORDER BY 1 will put NULL values first (NULL is
considered the smallest value)
but SELECT min(X), max(X) FROM TableX will not return NULL unless all values
of X are NULL (if non-null values exist in the subset queried, the
min()/max() functions will not report it (I would assume that min() would
return NULL in that case)
Here is some sample sql demonstrating the issue:
-- this query returns min = 0, max = 1 (the NULL is ignored)
select min(t), max(t) from
(select 1
union select NULL
union select 0 AS t);
-- this query implies that the 'min' value is NULL
select t from
(select 1
union select NULL
union select 0 AS t)
order by 1;
I see check-in #597 changed to this current behaviour, but as the above
sample demonstrates, this is misleading (in my opinion). I think all the
functions can ignore NULL's except for min(). I have a query that needs min
to include NULL values, but I don't see any easy workaround the current
behavour (ignoring them).
I suppose there are people that desire the current behaviour, but wouldn't
it be easier for people to have it work as I desire and just exclude records
that have NULL values if you don't want them included (in a where clause)? |
2004-Jul-10 00:27:49 by anonymous:
Having MIN return NULL when there are non-null data in the set being scanned is contrary to the SQL-92 std, incompatible with all other major SQL engines, and an all-around bad idea. See ticket #800. |
|
774 |
code
|
fixed
|
2004 Jun
|
anonymous
|
Unknown
|
2004 Aug
|
|
1
|
1
|
sqlite3_exec not exported in windows sqlite.dll
|
edit |
I was trying to convert my Delphi components from version 2 to 3. Loading the Windows sqlite.dll I was not able to bind to sqlite3_exec. I know that using prepare and step is the prefered method now, but the sqlite3_exec is still documented.
I would like to be able to create my components as flexible as possible, allowing to support both version 2 and 3. However, the dll names are the same. Of course I can rename one of them, but isn't it an idea to rename the sqlite.dll to sqlite3.dll by standard?
Best regards,
Albert Drent |
|
772 |
build
|
fixed
|
2004 Jun
|
anonymous
|
|
2004 Jun
|
|
2
|
2
|
configure with cygwin broken
|
edit |
with the last CVS download configure stops with:
checking for readline.h... no
checking for /usr/include/readline.h... no
checking for /usr/include/readline/readline.h... yes
checking for usleep... yes
configure: creating ./config.status
config.status: creating
.infig.status: error: cannot find input file:
|
2004-Jun-21 21:40:23 by dougcurrie:
Oh, the joy of discovering yet another wonderful feature of autoconf! It seems that when DOS <CR><LF> line endings are used in the ac file, autoconf proceeds to put control characters in the emitted filenames. A new version will be uploaded to cvs shortly. -- e |
|
771 |
doc
|
fixed
|
2004 Jun
|
anonymous
|
|
2004 Jun
|
|
5
|
4
|
Typo on SQLite 3 Overview page
|
edit |
On the web page http://www.hwaci.com/sw/sqlite/version3.html
The sentence shown below:
SQLite is not particular about the text it receives and is more than happen to process text strings that are not normalized or even well-formed UTF-8 or UTF-16.
should read:
SQLite is not particular about the text it receives and is more than happy to process text strings that are not normalized or even well-formed UTF-8 or UTF-16. |
|
770 |
doc
|
fixed
|
2004 Jun
|
anonymous
|
|
2004 Jun
|
|
5
|
4
|
Typo in SQLite 3 Overview doc
|
edit |
On the web page http://www.hwaci.com/sw/sqlite/version3.html
The sentence shown below:
In most other SQL database engines the datatype is associated with the table column the holds the data - with the data container.
should read:
In most other SQL database engines the datatype is associated with the table column that holds the data - with the data container. |
|
768 |
code
|
fixed
|
2004 Jun
|
anonymous
|
|
2004 Jul
|
anonymous
|
1
|
2
|
3.0.0 alpha WHERE-AND evaluation
|
edit |
Hi SQLITE!
Had a test with 3.0.0 (alpha). Ran follwing SQL:
SELECT
*
FROM
Road
LEFT JOIN District ON District.ID = Road.DistrictID
LEFT JOIN City ON City.ID = Road.CityID
LEFT JOIN State ON State.ID = Road.StateID
LEFT JOIN Country ON Country.ID = Road.CountryID
WHERE
Road.Name LIKE 'elster%'
AND City.Name LIKE 'berlin%'
ORDER BY Road.Name, City.Name, District.Name
Result is all roads starting with "elster" but in all cities. The "AND City.Name LIKE 'berlin%'" was ignored.
Swap the both WHERE-parts and you will get all streets in cities starting with "berlin", but the "AND Road.Name LIKE 'elster%'" will be ignored.
Seems that evaluation of WHERE-AND-clause is wrong.
Need more?
Let know!
Good Luck! |
This appears to be the same situation as ticket #813, which has now
been fixed. |
|
765 |
build
|
fixed
|
2004 Jun
|
anonymous
|
|
2004 Jun
|
dougcurrie
|
3
|
2
|
MinGW/MSYS build fails with vrsion 3.0.0
|
edit |
There is a problem in Makefile generated with MinGW/MSYS.
Configure runs OK, but when I run mingw32-make I get error in parse.c target (please see attached file for details) so I changed that line from
parse.c: $(TOP)/src/parse.y lemon
to
parse.c: $(TOP)/src/parse.y lemon.exe
(added extesion to match the lemon target already in Makefile)
Then there is also the problem in dll target because sqlite.def file is from 2.8.14 release
And there is some problem in doc target, but I still didn't figure out why is that so since common.tcl is in place?!?
System is Win2000 with SP2
$ sh --version
GNU bash, version 2.04.0(1)-release (i686-pc-msys)
$ mingw32-make --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-msys
$ mingw32-gcc --version
mingw32-gcc.exe (GCC) 3.2.3 (mingw special 20030504-1)
|
2004-Jun-18 21:45:29 by dougcurrie:
The doc target can be fixed by adding common.tcl as a dependency
doc: common.tcl $(DOC)
and removing the line
cd doc
from www/download.tcl
2004-Jun-18 22:05:34 by anonymous:
I looked into the doc target problem and, to my surprise, it seems like source TCL command (on win/MinGW at least) is interpreting path relative to cwd of tclsh and not relative to script being called.
I made some quick fixes to Makefile.in (diff attached) to fix all above mentioned problems. |
|
760 |
code
|
fixed
|
2004 Jun
|
anonymous
|
Parser
|
2005 Jan
|
|
2
|
3
|
Selects leave tablename in tablename.columname
|
edit |
This has been discussed on the mailing list, but I saw no resolution. the following query:
select stuff.name from user inner join stuff on user.id = stuff.user_id
returns a column "stuff.name". All other databases return "name".
I am writing desktop versions of some web applications, and using sqlite as the database. To avoid having to edit every query and add "AS" for every column, it would be nice if there was at least an option to make sqlite behave the same as postgres, mysql, and oracle. |
See check-ins [2230]
, [2231]
, and [2232]
. |
|
758 |
code
|
fixed
|
2004 Jun
|
anonymous
|
Shell
|
2004 Jul
|
|
1
|
1
|
Incorrect return value form strftime %W
|
edit |
SELECT strftime('%W', '2004-06-02');
Prints 22
(2004-06-02 was Wednesday)
SELECT strftime('%W', '2004-06-03');
Prints 23
(2004-06-03 was Thursday)
This is because 1.1.2004 was Thursday.
The problem is that week of year are counted from 1st day of year instead of 1st monday of year. |
|
757 |
code
|
fixed
|
2004 Jun
|
anonymous
|
VDBE
|
2004 Jun
|
|
3
|
3
|
Indexes on temporary tables leave cursors open
|
edit |
We developed a test case that uses several tables, temporary tables, and indexes (both on the normal tables and temporary tables). For some reason, when we drop the temporary tables, the indexes are not cleaned up properly and commits to a normal table fail with SQLITE_LOCKED. When we drop the index explicitly before the temporary table, we don't run into this problem.
Interestingly, if :memory: is used instead of a database file, we don't see the problem either. |
2004-Jun-09 21:08:14 by anonymous:
Using the attached test case:
$ rm /tmp/testcase; sqlite /tmp/testcase < testcase.sql
INSERT INTO Table3
SELECT NULL, TempTable.col5, TempTable.col6, TempTable.col7, TempTable.col8
FROM TempTable LEFT OUTER JOIN Table3 ON
TempTable.col5 = Table3.col5 AND TempTable.col6 = Table3.col6
WHERE Table3.col3 is NULL;
SQL error: database table is locked
If you add "DROP INDEX TempTableIdx;" on line 61, the test succeeds.
2004-Jun-09 23:17:27 by drh:
The problem does not appear in the latest (2.8 series)
version of SQLite in CVS. And since I'm up to my eyeballs
in version 3.0 I'm disinclined to figure out why. I'm just
going to release version 2.8.14 since that seems to fix the
problem.
2004-Jun-10 00:11:07 by anonymous:
I installed the binary RPMs for 2.8.14 and still see the problem. I rebuilt 2.8.14 from source and it still fails.
I know you're busy with sqlite 3 -- and we have the workaround (drop the index explicitly). I will keep looking at this to see if I can figure out what's going on. |
|
756 |
code
|
fixed
|
2004 Jun
|
anonymous
|
|
2004 Jul
|
|
2
|
3
|
Core Dump - Select From View
|
edit |
The following causes an assertion fault:
CREATE TABLE t1('9' text);
CREATE VIEW v1 AS SELECT a."9" FROM t1 a;
SELECT * FROM v1;
|
2004-Jun-09 10:48:44 by drh:
This is a real bug. But it is easy to work around - choose
sensible column names that do not require quoting. |
|
749 |
code
|
fixed
|
2004 May
|
anonymous
|
CodeGen
|
2004 Jul
|
|
2
|
1
|
SELECT DISTINCT with LIMIT
|
edit |
CREATE TABLE search (Word varchar(50),Page varchar(250);
INSERT INTO search VALUES ('word1','page_1');
INSERT INTO search VALUES ('word2','page_1');
INSERT INTO search VALUES ('word3','page_2');
INSERT INTO search VALUES ('word4','page_2');
SELECT DISTINCT Page FROM search LIMIT 0,2
The result is "page_1" but I think that results must be page_1,page_2 because of LIMIT 0,2
This means that SELECT makes LIMIT before DISTINCT |
|
743 |
code
|
fixed
|
2004 May
|
anonymous
|
Parser
|
2005 Jun
|
|
2
|
2
|
WHERE clause with USING incorrectly requires table name
|
edit |
When using ANSI syntax for a join, using the USING clause, an additional WHERE clause requires that the table name be specified in the WHERE clause, e.g this doesn't work (but should).
SELECT * from tab1 tab2 USING (col1, col2) WHERE col1 = 'foo'
Whereas this does work (but shouldn't):
SELECT * from tab1 tab2 USING (col1, col2) WHERE tab1.col1 = 'foo'
In the same way that table names are not allowed in the USING clause, they also shouldn't be allowed in the WHERE clause. The current behaviour is incompatible with Oracle.
See also ticket #523 |
|
716 |
code
|
fixed
|
2004 Apr
|
anonymous
|
Unknown
|
2005 Jan
|
|
4
|
4
|
create table as should preserve column types
|
edit |
A table resulting from a create table as doesn't have types, which can alter the numeric vs. text treatement of the column.
Here's the example that caught me, which I include because it's a bit interesting. Externally generated id that's alpha numeric, put in a column that is "varchar(4)". As luck would have it, the following values occur: 0E9, 0E8, 0E1, 0E0 (first char is a zero - these are airport identifiers assigned by the government, so I can't eliminate these deginerate cases). As numerics these are all equal, as text they are not equal. In my program they need to be not equal. |
2004-Apr-30 20:41:48 by anonymous:
Does the same thing in 2.8.13. |
|
713 |
code
|
fixed
|
2004 Apr
|
anonymous
|
Unknown
|
2004 Jul
|
drh
|
3
|
3
|
Compiling with SQLITE_OMIT_DATETIME_FUNCS causes error
|
edit |
Compiling with the SQLITE_OMIT_DATETIME_FUNCS define causes the following error in date.c:
date.c(863) : error C2059: syntax error : '}'
Essentially the } bracket should be before the #endif. |
2004-Apr-28 00:40:44 by anonymous:
On second thought, the #ifdef is all messed up, I just made it wrap the entire contents of the sqliteRegisterDateTimeFunctions function, as none of the code is needed. In any case, it's better just to remove the data.c file if one is not going to use the functions. |
|
708 |
code
|
fixed
|
2004 Apr
|
anonymous
|
Unknown
|
2004 Jul
|
rdc
|
4
|
1
|
nonASCII Upper & Lower
|
edit |
Please, change "char *z;" in upperFunc and lowerFunc to "unsigned char *z;".
I use setlocale("russian") and some symbols not converted (lower or upper). After adding "unsigned " all works fine. |
|
705 |
code
|
fixed
|
2004 Apr
|
anonymous
|
Parser
|
2004 Jul
|
|
3
|
3
|
can't handle special char in column name
|
edit |
$ sqlite :memory:
SQLite version 2.8.13
Enter ".help" for instructions
sqlite> create table mytab (#col_a);
sqlite: ./src/main.c:635: sqlite_exec: Assertion `pVm==0 || sqlite_malloc_failed' failed.
Aborted
$
|
2004-Jul-20 00:29:17 by drh:
Unable to reproduce. Perhaps the problem has already been fixed. |
|
703 |
code
|
fixed
|
2004 Apr
|
anonymous
|
|
2004 Jul
|
|
3
|
3
|
Aggregate functions (min/max) fail over sub-queries
|
edit |
Computing min,max of (negative) numeric values from a "union all" subquery generates incorrect results. I have included a shell script which reproduces the problem. |
2004-Apr-23 22:02:48 by anonymous:
create table t (x int);
insert into t values (-1);
insert into t values (-2);
insert into t values (-3);
insert into t values (-4);
insert into t values (-5);
create table t2 (x int);
insert into t2 values (-1);
insert into t2 values (-2);
insert into t2 values (-3);
insert into t2 values (-4);
insert into t2 values (-5);
select min(x),max(x) from t;
select min(x),max(x) from t2;
select min(x), max(x) from
(
select x from t
);
select min(x), max(x) from
(
select x from t2
);
select min(x), max(x) from
(
select x from t
union all
select x from t2
);
Results in:
-5|-1
-5|-1
-5|-1
-5|-1
-1|-5
2004-Apr-23 23:17:59 by drh:
The problem here is that the result of the UNION ALL is being
interpreted as type TEXT instead of as type NUMERIC. And for
TEXT, '-1' really is the minimum and '-5' really is the maximum.
Believe it or not, this is the same bug as #521 - "create as select"
does not preserve datatypes.
The work around is like this:
select min(x+0), max(x+0) from
(
select x from t
union all
select x from t2
);
The "+0" after the "x" in causes the types to
become NUMERIC which makes min() and max() behave
as you expect.
2004-Apr-23 23:37:53 by anonymous:
Thanks for the workaround! |
|
692 |
code
|
fixed
|
2004 Apr
|
anonymous
|
Parser
|
2004 Apr
|
|
3
|
3
|
lemon.c:void emit_destructor_code() pointer unitialized
|
edit |
Code path:
void emit_destructor_code(out,sp,lemp,lineno)
{
char *cp; // unitialized
int linecnt = 0;
if( sp->type==TERMINAL ){
cp = lemp->tokendest;
if( cp==0 ) return;
fprintf(out,"#line %d \"%s\"\n{",lemp->tokendestln,lemp->filename);
}else if( sp->destructor ){
cp = sp->destructor;
fprintf(out,"#line %d \"%s\"\n{",sp->destructorln,lemp->filename);
}else if( lemp->vardest ){
cp = lemp->vardest;
if( cp==0 ) return;
fprintf(out,"#line %d \"%s\"\n{",lemp->vardestln,lemp->filename);
} // no else { } block to catch drop-through
for(; *cp; cp++){
Notice that the cp variable is never explicitly initialized, and that the else blocks can fall through. As a result, if none of the if/else branches are taken, the for loop will execute with a garbage pointer.
I assume that this never happens in practice, but either adding an else () clause, or setting cp initially to NULL would make debugging easier. |
|
690 |
code
|
fixed
|
2004 Apr
|
anonymous
|
|
2005 Jan
|
|
3
|
3
|
NATURAL JOIN does not work with table aliases
|
edit |
NATURAL JOINs do not work if either of the table names are aliased using
the "AS" keyword. Here's example code to reproduce:
CREATE TEMP TABLE table1(f1, f2);
CREATE TEMP TABLE table2(f2, f3);
SELECT table1.f1, table2.f3 FROM table1 NATURAL JOIN table2;
-- this works as expected
SELECT a.f1, table2.f3 FROM table1 AS a NATURAL JOIN table2;
-- fails with: SQL error: no such column: table1.f2
SELECT table1.f1, b.f3 FROM table1 NATURAL JOIN table2 as b;
-- fails with: SQL error: no such column: table2.f2
SELECT a.f1, b.f3 FROM table1 AS a NATURAL JOIN table2 AS b;
-- fails with: SQL error: no such column: table1.f2 |
|
687 |
code
|
fixed
|
2004 Apr
|
anonymous
|
|
2004 Jul
|
|
4
|
2
|
Sqlite incorrectly handles invalid filenames.
|
edit |
When opening an invalid filename, which is resolved to a directory or a directory directly, sqlite_open() fails to return error instead pretends to have opened the directory for read.
The patch below adds a check on open failure that prevents this from happening.
http://ilia.ws/stuff/sq.txt |
|
686 |
code
|
fixed
|
2004 Apr
|
anonymous
|
|
2004 Jul
|
|
2
|
3
|
select + indexes + left join + "in (set)" causes core dump
|
edit |
The following SQL code causes a core dump on SqLite 2.8.13 on FreeBSD 4.9. With the older SqLite 2.8.11, it caused a run time error message, but not a core dump.
I do not know whom to assign this to. This may a VDBE subsystem error, as an assertion is failed in vdbe.c, resulting in a core dump. I do not know what the VDBE subsystem does.
Thanks for supporting SqLite! Please contact me if you have any questions.
-Matthew
-------- begin test.sql --------
-- drop, then recreate the tables
drop table TableA;
drop table TableB;
create table TableA (id integer, ta0 text);
create unique index TableA_index on TableA (ta0);
create table TableB (tb0 integer, id integer);
create unique index TableB_index on TableB (tb0, id);
-- insert some data
insert into TableA values (1,9);
insert into TableA values (2,2);
insert into TableA values (3,3);
insert into TableA values (4,4);
insert into TableA values (5,5);
insert into TableA values (6,6);
insert into TableB values (7,1);
-- this select does not generate an error.
select distinct TableA.id, TableB.tb0 from TableA left join TableB on (TableA.id = TableB.id) where (tb0 = 7) order by ta0;
-- this semantically identical select will core dump with sqlite 2.8.13 on FreeBSD
select distinct TableA.id, TableB.tb0 from TableA left join TableB on (TableA.id = TableB.id) where (tb0 in (7)) order by ta0;
-------- end test.sql --------
Here is what it looks like when I run it:
[user@host dir]$ sqlite test.db
SQLite version 2.8.13
Enter ".help" for instructions
sqlite> .read test.sql
2|
3|
4|
5|
6|
1|7
2|
assertion "pSet->prev" failed: file "./src/vdbe.c", line 4698
Abort trap (core dumped)
|
Same as #813. |
|
683 |
code
|
fixed
|
2004 Apr
|
anonymous
|
Unknown
|
2004 Jul
|
|
1
|
1
|
Impossible to drop index with single quotes in the name
|
edit |
After creating an index with the command
CREATE INDEX 'myIndex' ON 'myTable' (myColumn);
the index can't be dropped with either
DROP INDEX myIndex;
or
DROP INDEX 'myIndex';
An index created in SQLite 2.7.5 with single quotes in its name will appear in SQLITE_MASTER without the quotes, but SQLite 2.8.13 still can't DROP it. |
2004-Apr-01 14:11:24 by drh:
Work-around:
DROP INDEX ['myIndex']
2004-Jul-20 00:32:31 by drh:
Fixed in 3.0 |
|
680 |
code
|
fixed
|
2004 Mar
|
anonymous
|
Parser
|
2004 Jul
|
|
3
|
3
|
Parser fails on quoted table/alias DOT STAR
|
edit |
sqlite> create table product (id integer);
sqlite> insert into product values(1);
sqlite> select "product"."id" from "product";
1
sqlite> select product.* from product;
1
sqlite> select "product".* from "product";
SQL error: no such table: "product"
The last statement should produce the same result as the last but one. I suspect somewhere in the "*" expansion code is a call to dequote the table name missing. |
2004-Apr-18 09:09:03 by anonymous:
Following patch against 2.8.13 seems to work:
diff -ur sqlite.orig/src/select.c sqlite/src/select.c
--- sqlite.orig/src/select.c 2004-03-02 19:37:41.000000000 +0100
+++ sqlite/src/select.c 2004-04-17 20:21:25.000000000 +0200
@@ -952,14 +952,25 @@
for(i=0; i<pTabList->nSrc; i++){
Table *pTab = pTabList->a[i].pTab;
char *zTabName = pTabList->a[i].zAlias;
+ char *zTabName2 = 0;
+ int zTabName2Len;
if( zTabName==0 || zTabName[0]==0 ){
zTabName = pTab->zName;
}
- if( pName && (zTabName==0 || zTabName[0]==0 ||
- sqliteStrNICmp(pName->z, zTabName, pName->n)!=0 ||
- zTabName[pName->n]!=0) ){
+ if( pName ){
+ zTabName2 = sqliteTableNameFromToken(pName);
+ if( zTabName2 ){
+ zTabName2Len = strlen(zTabName2);
+ }
+ }
+ if( zTabName2 && (zTabName==0 || zTabName[0]==0 ||
+ sqliteStrNICmp(zTabName2, zTabName, zTabName2Len)!=0 ||
+ zTabName[zTabName2Len]!=0) ){
continue;
}
+ if( zTabName2 ){
+ sqliteFree(zTabName2);
+ }
tableSeen = 1;
for(j=0; j<pTab->nCol; j++){
Expr *pExpr, *pLeft, *pRight;
|
|
670 |
code
|
fixed
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
|
3
|
3
|
The '.database' trunc file name
|
edit |
When using 'attached' database, the .database command show omit the first 8 characters of the attached file name. This is not usefull, since in most cases, the actual files name is longer. The problem seems to be in the formatting of output, since the Pragma command provides the full name.
sqlite> attach database 'demo.db' as demo
...> ;
sqlite> .da
0 main
1 temp
2 demo /tmp_mnt/h
sqlite> PRAGMA database_list;
0|main|
1|temp|
2|demo|/tmp_mnt/home4/yair/cvstrac/demo.db
sqlite>
Note: This ticket was entered (by mistake) as ticket 297 against cvstrac. |
|
668 |
code
|
fixed
|
2004 Mar
|
anonymous
|
VDBE
|
2004 Mar
|
|
2
|
2
|
sqlite crash on combinng case and not in
|
edit |
The 'Tickets Counts' SQL statement is causing the following error on sqlite 2.8.3. I'm running this again 'out of the box' cvstrac database. The problem occurs on SunOS 5.8. The query seems to work OK on on www.cvstrac.org
Assertion failed: pTos<=&p->aStack[pc], file ../sqlite/src/vdbe.c, line 516
SQL:
SELECT
status,
count(case when type='code' then 'x' end),
count(case when type='doc' then 'x' end),
count(case when type='new' then 'x' end),
count(case when type NOT IN ('code','doc','new') then 'x' end),
count(*)
FROM ticket GROUP BY status
UNION
SELECT
'TOTAL' AS 'Status',
count(case when type='code' then 'x' end) as 'Code Bugs',
count(case when type='doc' then 'x' end) as 'Doc Bugs',
count(case when type='new' then 'x' end) as 'Enhancements',
count(case when type NOT IN ('code','doc','new') then 'x' end)
as 'Other',
count(*) AS 'All Types'
FROM ticket
ORDER BY [All Types]
|
2004-Mar-17 23:04:59 by drh:
Reproducible test case:
CREATE TABLE t1(x);
INSERT INTO t1 VALUES(1);
INSERT INTO t1 VALUES(2);
INSERT INTO t1 SELECT x+2 FROM t1;
INSERT INTO t1 SELECT x+4 FROM t1;
INSERT INTO t1 SELECT x+8 FROM t1;
INSERT INTO t1 SELECT x+16 FROM t1;
INSERT INTO t1 SELECT NULL FROM t1;
SELECT case when x NOT IN (1,2,3) then 'x' end FROM t1;
|
|
667 |
build
|
fixed
|
2004 Mar
|
dougcurrie
|
Unknown
|
2004 Mar
|
dougcurrie
|
2
|
1
|
Makefile.in needs updates for encode, .defs, Makefile target
|
edit |
Now that encode.c is included in the build, the changes need to be propagated to Makefile.in and sqlite.def
Recent updates to Makefile.in have assumed that configure is run in $(TOP) whereas the build instructions specify running configure in a bld directory, e.g., see at the bottom of http://www.sqlite.org/
So, $(TOP)/ should be added before references to Makefile.in and sqlite.def |
|
665 |
code
|
fixed
|
2004 Mar
|
anonymous
|
|
2004 Apr
|
|
3
|
3
|
Lemon.c + OpenWatcom 1.3
|
edit |
Compilation using OW 1.3 using maximum errorlevel ends with errors.
To get lemon.c compiled with no errors I've had to change it.
Please find attached diff file. Changes are cosmetic ones so it
shouldn't break anything:
15,21d14
< extern void qsort();
< extern double strtod();
< extern long strtol();
< extern void free();
< extern int access();
< extern int atoi();
<
43d35
< void Action_add();
377c369
< ap = (struct action *)msort(ap,&ap->next,actioncmp);
---
> ap = (struct action *)msort((char *)ap,(char **)&ap->next,actioncmp);
814c806
< Action_add(&stp->ap,SHIFT,sp,newstp);
---
> Action_add(&stp->ap,SHIFT,sp,(char *)newstp);
915c907
< Action_add(&stp->ap,REDUCE,lemp->symbols[j],cfp->rp);
---
> Action_add(&stp->ap,REDUCE,lemp->symbols[j],(char *)cfp->rp);
1191c1183
< current = (struct config *)msort(current,&(current->next),Configcmp);
---
> current = (struct config *)msort((char *)current,(char **)&(current->next),Configcmp);
1198c1190
< basis = (struct config *)msort(current,&(current->bp),Configcmp);
---
> basis = (struct config *)msort((char *)current,(char **)&(current->bp),Configcmp);
1449a1442
> return (lem.errorcnt + lem.nconflict);
|
|
659 |
code
|
fixed
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
|
4
|
4
|
+1 month issue (dead or defective code) in date.c
|
edit |
On line 617 of date.c, the statement "if( y!=r ){" is never true due to the assignment "y = r" just above it.
r is a double and y is an int, so the comparison is only true
if the fraction part of r is 0. The code is correct as it
stands.
Plus I think the "Compute the last day of the current month" wiki example is either flawed or very magical in how it would handle a date like 2004-01-31. It should read "SELECT date('now','start of month','+1 month','-1 day')" if only for sanity sake.
Anybody can edit the wiki. You need not submit a bug report.
|
|
658 |
code
|
fixed
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
|
3
|
3
|
select max(rowid) from union crashes sqlite command-line
|
edit |
sqlite> select max(rowid) from files;
615
sqlite> select max(rowid) from messages;
6933
sqlite> select max(rowid) from (select rowid from messages union select rowid from files);
999
so that's wrong, but then:
sqlite> select max(rowid) from (select max(rowid) from messages union select max(rowid) from files);
src/vdbe.c:2399: failed assertion `pTos>=p->aStack'
Abort trap
I can reproduce the crashing (though not the weird 999 result) with simple tables:
sqlite> create table a (a);
sqlite> create table b (a);
sqlite> insert into a values (1);
sqlite> insert into b values (2);
sqlite> insert into b values (3);
sqlite> insert into b values (4);
sqlite> insert into b values (5);
sqlite> select max(rowid) from a;
1
sqlite> select max(rowid) from b;
4
sqlite> select max(rowid) from (select rowid from a union select rowid from b);
4
sqlite> select max(rowid) from (select max(rowid) from a union select max(rowid) from b);
src/vdbe.c:2399: failed assertion `pTos>=p->aStack'
Abort trap
|
|
655 |
code
|
fixed
|
2004 Mar
|
anonymous
|
VDBE
|
2004 Jul
|
|
1
|
3
|
Numeric/string confusion with "in"
|
edit |
"number in (number-list)" uses string comparisons, which can lead to invalid results.
Example:
select 1 where 1 in (1);
(outputs 1)
select 1 where 1 in (01);
(no output; should output 1!)
select 1 where 01 in (1);
(no output, wrong)
select 1 where 01+0 in (1);
(outputs 1) |
|
654 |
code
|
fixed
|
2004 Mar
|
anonymous
|
Unknown
|
2004 Mar
|
|
3
|
2
|
Can't compile with CodeWarrior Studio v9.1
|
edit |
I am trying to compile sqlite_source using CW Pro 9.1 and got a compile error:
the line:
randomName(&zTemp[nFilename+1]);
in vacuum.c does not compile 'cos a char * is passing into a function that expects a unsigned char *. Apparently this is no longer valid in ISO C? |
More likely, this is a bug in CW Pro 9.1. Nevertheless, I put in
a typecast to work around the problem.
2004-Mar-10 21:17:21 by anonymous:
just talked to someone at Metrowerks. In the C/C++ language panel in the project settings, there was an option called "Relaxed Pointer Type Rules" until CW Pro 9. That option is now removed ('cos of the standard?).
Typecasting should do the job. Another way they suggested is to use a pragma called "mpwc_relax".
#pragma mpwc_relax on
...
#pragma mpwc_relax off
to allow this kind of compatibility. |
|
648 |
code
|
fixed
|
2004 Mar
|
rdc
|
Unknown
|
2004 Mar
|
|
3
|
3
|
duplicate tracing with revised sqlite_exec implementation
|
edit |
The new non-callback based implementation of the sqlite_exec() API causes duplicate tracing of SQL statments when multiple statements are passed in a single SQL string. Previous versions traced the argument SQL statments once then executed the entire sequence. The current version compiles and executes the sequence one statment at a time, and traces from the current statment to the end of the sequence for each compiled statment. For a sequence of 4 statements, it traces the staments as shown below;
Executed Traced
---------------------------
statement 1 statement 1
statement 2
statement 3
statement 4
statement 2 statement 2
statement 3
statement 4
statement 3 statement 3
statement 4
statement 4 statement 4
|
2004-Mar-04 19:11:45 by rdc:
Checkin [1284]
corrects this bug by changing sqlite_compile() so it only traces the statement it compiled. |
|
641 |
code
|
fixed
|
2004 Mar
|
anonymous
|
Unknown
|
2004 Mar
|
|
1
|
1
|
select query doen't work with binary equations
|
edit |
select query doen't work with binary equations as shown below. Last version this worked on that I tried was 2.8.9
SQLite version 2.8.12
Enter ".help" for instructions
sqlite> select 4 & 5;
sqlite: src/vdbe.c:1216: sqliteVdbeExec: Assertion 'pTos->flags==0x0004' failed.
Aborted |
2004-Mar-03 18:48:26 by anonymous:
Brought to you by GNU/Peter. |
|
640 |
code
|
fixed
|
2004 Mar
|
drh
|
CodeGen
|
2004 Mar
|
|
1
|
1
|
Trigger causes assertion failure
|
edit |
The following code leads to an assertion failure:
CREATE TABLE t1(a);
CREATE TABLE t2(b);
CREATE TABLE t3(c);
CREATE TRIGGER r1 AFTER DELETE ON t1 FOR EACH ROW BEGIN
INSERT INTO t3(c) SELECT b FROM t2 ORDER BY b LIMIT 1;
END;
INSERT INTO t1 VALUES(1);
INSERT INTO t1 VALUES(2);
INSERT INTO t1 SELECT a+2 FROM t1;
INSERT INTO t1 SELECT a+4 FROM t1;
INSERT INTO t1 SELECT a+8 FROM t1;
INSERT INTO t2 SELECT a FROM t1;
DELETE FROM t1;
The failure is as follows:
../sqlite/src/vdbe.c:516: sqliteVdbeExec: Assertion `pTos<=&p->aStack[pc]' failed.
|
|
634 |
warn
|
fixed
|
2004 Feb
|
anonymous
|
Unknown
|
2004 Feb
|
|
3
|
3
|
Compiler warnings when compiling using LCC
|
edit |
Warning f:\data\source\c\sqlite\vdbeaux.c: 1032 possible usage of sqlite_search_count before definition
Warning f:\data\source\c\sqlite\printf.c: 365 indexing array buf[1000] out of bounds (1000)
Warning f:\data\source\c\sqlite\printf.c: 376 indexing array buf[1000] out of bounds (1000)
Warning f:\data\source\c\sqlite\printf.c: 388 indexing array buf[1000] out of bounds (1000)
Warning f:\data\source\c\sqlite\os.c: 1217 no type specified. Defaulting to int
Warning f:\data\source\c\sqlite\expr.c: 322 unreachable code
Warning f:\data\source\c\sqlite\expr.c: 456 possible usage of db before definition
Warning f:\data\source\c\sqlite\date.c: 316 unreachable code
Warning f:\data\source\c\sqlite\btree_rb.c: 272 unreachable code
Warning f:\data\source\c\sqlite\btree_rb.c: 273 missing return value
Warning f:\data\source\c\sqlite\btree_rb.c: 1186 unreachable code
Warning f:\data\source\c\sqlite\btree_rb.c: 1187 missing return value
Warning f:\data\source\c\sqlite\btree_rb.c: 1209 unreachable code
Warning f:\data\source\c\sqlite\btree_rb.c: 1210 missing return value
|
|
626 |
code
|
fixed
|
2004 Feb
|
anonymous
|
Parser
|
2004 Feb
|
|
2
|
2
|
EXPLAIN BEGIN TRANSACTION really starts a transaction
|
edit |
In the sqlite command interpreter, entering the following two SQL statements reproduces the bug.
EXPLAIN BEGIN TRANSACTION;
BEGIN TRANSACTION;
Here's the log:
c:\temp\sqlite>sqlite foo.db
SQLite version 2.8.12
Enter ".help" for instructions
sqlite> EXPLAIN BEGIN TRANSACTION;
0|Transaction|0|0|
1|VerifyCookie|0|0|
2|Transaction|1|0|
3|Halt|0|0|
sqlite> BEGIN TRANSACTION;
SQL error: cannot start a transaction within a transaction
sqlite>
|
|
623 |
code
|
fixed
|
2004 Feb
|
anonymous
|
Unknown
|
2004 Feb
|
|
2
|
3
|
Erroneous min/max on US zip codes
|
edit |
Sorting works correctly, min and max do not, on mixed 5- and 9-digit codes in typical format.
sqlite> pragma table_info(zipbug);
cid name type notnull dflt_value pk
---------- ---------- ---------- ---------- ---------- --
0 Xnum integer 0 <> 1
1 Name char(30) 0 <> 0
2 City char(30) 0 <> 0
3 State char(2) 0 <> 0
4 Zip char(10) 0 <> 0
No other indices.
sqlite> select * from zipbug order by zip;
Xnum Name City State Zip
---------- ---------- ---------- ---------- ----------
5 Speedy Houston TX 77005-1234
4 Daffy Houston TX 77006
1 Donald San Antoni TX 78249-1495
2 Louis Chandler AZ 85226-1832
3 Elmer Buckeye AZ 85326
sqlite> select min(zip) from zipbug;
min(zip)
----------
77006
sqlite> select max(zip) from zipbug;
max(zip)
----------
85226-1832
|
2004-Feb-23 13:13:24 by drh:
Yikes! This problem arises because functions do not distinguish
between text and numeric data types. It will take some serious
changes to fix. Several weeks might pass before you see a
resolution... |
|
620 |
code
|
fixed
|
2004 Feb
|
anonymous
|
Shell
|
2004 Feb
|
|
1
|
1
|
sqlite executable crashes
|
edit |
Command:
sqlite /tmp/res2.sqlite "SELECT Labels.TotalID, Labels.Label FROM Labels, Dimensions, Charts WHERE Dimensions.Label='sessionreferrer' AND Dimensions.ID=Labels.DimensionID AND Labels.ChartID = Charts.ID AND Charts.name = 'refana1'"
Result:
Segmentation fault.
Database:
See attachment (res2.sqlite).
Version:
philip@dev2 ~ ---> dpkg -l sqlite
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-===================-===================-======================================================
ii sqlite 2.8.12-1 A command line interface for SQLite
|
|
617 |
new
|
fixed
|
2004 Feb
|
anonymous
|
Unknown
|
2004 Feb
|
|
5
|
4
|
date() conversion seems to fail on -ve dates
|
edit |
Not certain whether this is just a factor of the date handling being new.
sqlite> SELECT date(5);
-4713-11-29
sqlite> SELECT date('-4713-11-29');
sqlite>
Whether that's by design or not, I'm not certain, but most other dates generated by date() are re-parsable by date() so it would seem sensible that -ve dates should be, also. Or maybe it's that date(5) is just invalid and should never have generated such a -ve date. |
|
615 |
code
|
fixed
|
2004 Feb
|
drh
|
Pager
|
2004 Feb
|
|
2
|
3
|
Assertion fault in pager when synchronous changed within a transaction
|
edit |
The following code causes an assert failure inside pager.c:
BEGIN;
CREATE TABLE t1(x);
PRAGMA synchronous=off;
COMMIT;
|
|
614 |
code
|
fixed
|
2004 Feb
|
anonymous
|
Shell
|
2004 Feb
|
|
2
|
1
|
history not saved after quitting the shell with .quit
|
edit |
exiting the sqlite shell using .quit is triggering exit(0), thus bipassing history saving point.
return 1 will do the job. |
|
612 |
code
|
fixed
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
anonymous
|
3
|
1
|
Pointer 'db' not initialized in function lookupname() (expr.c)
|
edit |
My VC compiler found this error:
C:\Projetos\SqlLite\expr.c(456) : warning C4700: local variable 'db' used without having been initialized
It really uses the unitialized pointer... I think it could crash! |
It was fixed. See Check-in #604 |
|
610 |
code
|
fixed
|
2004 Feb
|
anonymous
|
Parser
|
2004 Feb
|
|
5
|
4
|
REPLACE INTO syntax not allowed in triggers
|
edit |
CREATE TABLE Test1 (x int primary key);
CREATE TABLE Test2 (y int primary key);
-- trying to create this trigger fails with: SQL error or missing database. near "REPLACE": syntax error
CREATE TRIGGER trigTest1_AD AFTER DELETE ON Test1 FOR EACH ROW
BEGIN
REPLACE INTO Test2 (y) VALUES (old.x);
END;
--The obvious workaround is:
CREATE TRIGGER trigTest1_AD AFTER DELETE ON Test1 FOR EACH ROW
BEGIN
INSERT OR REPLACE INTO Test2 (y) VALUES (old.x);
END;
|
|
605 |
warn
|
fixed
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
1
|
1
|
_FILE_OFFSET_BITS redefined
|
edit |
os.h
src/os.h:42: warning: `_FILE_OFFSET_BITS' redefined
#ifndef _FILE_OFFSET_BITS
#define _FILE_OFFSET_BITS
#endif
should do. |
|
604 |
warn
|
fixed
|
2004 Feb
|
anonymous
|
Parser
|
2004 Feb
|
|
4
|
4
|
'db' has been referenced but never assigned a value
|
edit |
Compiling sources 2.18.2 witch OpenWatcom 1.3beta
wcc386 expr.c -wx
reports:
expr.c(418): Warning! W200: 'db' has been referenced but never assigned a value
.
.
.
int cntTab = 0; /* Number of matching table names /
sqlite *db; / The database */
assert( pColumnToken && pColumnToken->z ); /* The Z in X.Y.Z cannot be NULL */
.
.
char *zTabName = pTab->zName;
if( zTabName==0 || sqliteStrICmp(zTabName, zTab)!=0 ) continue;
if( zDb!=0 && sqliteStrICmp(db->aDb[pTab->iDb].zName, zDb)!=0 ){
continue;
}
.
.
.
Variable db is declared, NOT initialized and referenced.
Bartosz Polednia |
|
603 |
code
|
fixed
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
4
|
4
|
compile error date.c if SQLITE_OMIT_DATETIME_FUNCS defined
|
edit |
Compiling date.c with SQLITE_OMIT_DATETIME_FUNCS errors out:
/usr/bin/cc -DSQLITE_OMIT_DATETIME_FUNCS=1 -I. -c date.c
date.c:821: error: parse error before '*' token
date.c: In function `sqliteRegisterDateTimeFunctions':
date.c:826: error: parse error before '*' token
date.c:839: error: `db' undeclared (first use in this function)
date.c:839: error: (Each undeclared identifier is reported only once
date.c:839: error: for each function it appears in.)
Must include of os.h and sqliteInt.h even if SQLITE_OMIT_DATETIME_FUNCS is defined!
Diff:
--- /home/bernd/OS/sqlite/sqlite_src-2.8.12/date.c 2004-02-08 19:08:37.000000000 +0100
+++ date.c 2004-02-10 09:11:05.000000000 +0100
@@ -47,9 +47,9 @@
** Willmann-Bell, Inc
** Richmond, Virginia (USA)
*/
-#ifndef SQLITE_OMIT_DATETIME_FUNCS
#include "os.h"
#include "sqliteInt.h"
+#ifndef SQLITE_OMIT_DATETIME_FUNCS
#include <ctype.h>
#include <stdlib.h>
#include <assert.h>
|
|
602 |
code
|
fixed
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
1
|
1
|
Update tablename set rowid = rowid -1 fails for more than 1000 records
|
edit |
I am facing a problem while deleting emails and updating the rowid column in the SQLite table.
Here I will try to explain my problem:
In my SQLite table I have more than 1000 records ranging from say 1,2,...,1000,1001,...,1111. To delete 1st record using the delete query I wrote the query as follows,
delete from tablename where rowid = 1
After successful execution of this query the remaining records in the table ranges from 2,3,...,1000,1001,...,1111. (rowids)
Now I want to update the rowid column so that the rowids will be reset to 1,2,...,1000,1001,...,1110 after deleting the first record.
To do this I tried the query, which is as follows,
update tablename set rowid = rowid - 1 where rowid > 1
so that all the rowids will be reduced by 1 from rowid 2 to 1111 and will be set to 1 to 1110.
But when I tried this query it gave me an error "PRIMARY KEY must be unique" but in reality there is no any conflict in rowids.
When I executed above query on batches of 1000 records then it worked.
update tablename set rowid = rowid -1 where rowid > 1 and rowid <= 1000
result for rowid column = 1,2,3,...,999,1001,...1111
update tablename set rowid = rowid -1 where rowid > 999 and rowid <= 1111
result for rowid column = 1,2,3,...,999,1000,...1110
But this solution is not feasible for me if I have say one lakh records in my database because it is becoming very slow.
Can you please help me to overcome this problem?
Thanks, |
SQLite does not guarantee that updates will occur in any particular
order. I've added a few lines of code so that, for now, the updates
do occur in search order even for large updates. But I do not want
to be obligated to maintain this behavior in future releases.
Therefore, do not become dependent upon this behavior. |
|
601 |
code
|
fixed
|
2004 Feb
|
anonymous
|
CodeGen
|
2004 Feb
|
|
1
|
1
|
Left-join subquery gives incorrect results
|
edit |
The following join works:
create table t1 (b, c);
insert into t1 values ('dog',3);
insert into t1 values ('cat',1);
insert into t1 values ('dog',4);
create table t2 (c, e);
insert into t2 values (1,'one');
insert into t2 values (2,'two');
insert into t2 values (3,'three');
insert into t2 values (4,'four');
select t2.c as c, e, b
from t2 left join (select b, max(c) as c from t1 group by b) using (c);
But if you make the whole thing a subquery, you get incorrect results:
select * from (
select t2.c as c, e, b
from t2 left join (select b, max(c) as c from t1 group by b) using (c)
);
|
|
599 |
code
|
fixed
|
2004 Feb
|
anonymous
|
Pager
|
2004 Feb
|
|
1
|
2
|
Corrupt problem encountered on Windows NT platform
|
edit |
We are very concerned about SQLite corrupt problem on Windows platform.
We have written a test that consists of two processes: one inserts records in loop, and the other terminates the first process and starts it again.
This test led DB to be corrupted in 5-10 loops in synchronous mode (either NORMAL or FULL), while in synchronous=OFF mode it corrupted in more than 100 loops, and DB could be reopened then (when journal file was deleted).
We have analyzed database crash in synchronous mode, and found out that its journal file consists value 0 in the field nRec of its header.
Debugging rollback operation helped us find out the corruption reason: the DB file was truncated according to the value "initial database page count"(mxPg) while old page values were not recovered due to 0 in value "number of records in journal" (nRec).
Therefore, resulting DB contained links to missing pages (they were deleted by truncate operation).
We also found that the actual number of pages in journal file could be calculated using journal file size if nRec field had contained value 0xffffffff instead of 0.
There is how the nRec field is initialized in pager_open_journal function (pager.c):
rc = write32bits(&pPager->jfd, pPager->noSync ? 0xffffffff : 0);
However this field is updated neither in sqlitepager_write (where old page is written to journal before being modified) nor in sqlitepager_commit function (where journal file buffers are flushed and dirty pages are committed to DB).
As far as we could find, this field is only updated from function syncAllPages which is called from sqlitepager_get only if there is no place in page cache (which happens not very often).
After we replaced code mentioned above with:
rc = write32bits(&pPager->jfd, 0xffffffff);
to make this field be calculated automatically, we could not corrupt DB file by our test anymore.
However we had another problem, instead of DB file we got journal file corrupted. The problem was in its header, which was not written entirely (e.g. only 16 bytes were written so "initial database page count" field was missing), and pager_playback function returned SQLITE_CORRUPT when it tried to read the header of journal file. The next time the DB file opened successfully, because journal file had already been deleted.
We tried to solve this problem by modifying pager_open_journal in the way it wrote journal file header into its buffer at first and then wrote the buffer into a file. It seems to help.
With this two fixes we haven't managed to corrupt the DB by our test again.
We have tested this issue only on Windows platform (on NTFS partition), however it seems to be applicable to any other platforms. Besides, it is possible, that this problem is related to ticket #540. |
The corruption problem described above is real, but the solution
proposed is incorrect. The nRec field of the journal header must
be set to 0 initialize. We cannot rely on using the size of the
journal file to compute nRec because after a power failure, the size
of the journal file might not be correct. The problem was not that
nRec is initialized to zero but that nRec is not updated to the
correct value prior to beginning a COMMIT.
The second problem described above, where database corruption was
reported if the journal file header was incomplete, was solved by
enhancing the size test on the journal file during journal playback
and ignoring journals with incomplete headers. |
|
594 |
code
|
fixed
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
1
|
1
|
TEMP tables not dropped by ROLLBACK if sqlite_interrupt was called
|
edit |
-- setup sql
CREATE TABLE Test (x int primary key);
this sequence doesn't remove temp table(s) created inside a transaction:
BEGIN TRANSACTION;
CREATE TEMP TABLE tempTest(x int primary key);
-- long running insert statement
INSERT INTO Test SELECT * FROM tempTest;
-- call sqlite_interrupt while the above statement is processing
-- the sqlite_exec() call running the INSERT statement returns SQLITE_INTERRUPT
ROLLBACK TRANSACTION;
-- the temp table tempTest is not removed (it was created inside the transaction!)
|
|
593 |
code
|
fixed
|
2004 Feb
|
anonymous
|
VDBE
|
2004 Feb
|
|
3
|
3
|
Interrupted VACUUM returns SQLITE_ERROR not SQLITE_INTERRUPT
|
edit |
If sqlite_interrupt() is called, then the current execution terminates and returns SQLITE_INTERRUPT, unless a VACUUM statement is being executed (which returns SQLITE_ERROR instead). I would consider this unexpected behaviour to be a bug. |
|
587 |
code
|
fixed
|
2004 Jan
|
anonymous
|
Unknown
|
2004 Jan
|
|
3
|
1
|
easy way to operate on a max () value
|
edit |
I also noticed that
select * from ( select x from y )
does not produce the same results as
select x from y
when I tried using that in a workaround.
explain select max ( timestamp ) from rawlog ;
0|ColumnName|0|0|max ( timestamp )
1|VerifyCookie|0|1408|
2|Integer|0|0|
3|OpenRead|0|3|rawlog
4|Integer|0|0|
5|OpenRead|1|8|ix_rawlog_timestamp
6|Last|1|0|
7|IdxRecno|1|0|
8|Close|1|0|
9|MoveTo|0|0|
10|Column|0|0|
11|Callback|1|0|
12|Close|0|0|
13|Halt|0|0|
explain select max ( timestamp ) - 3600 from rawlog ;
0|ColumnName|0|0|max ( timestamp ) - 3600
1|AggReset|0|1|
2|AggInit|0|0|ptr(0x94ab0)
3|String|0|0|
4|AggFocus|0|0|
5|Integer|0|0|
6|OpenRead|0|3|rawlog
7|VerifyCookie|0|1408|
8|Rewind|0|13|
9|Column|0|0|
10|Integer|0|0|
11|AggFunc|0|1|ptr(0x94ab0)
12|Next|0|9|
13|Close|0|0|
14|AggNext|0|20|
15|AggGet|0|0|
16|Integer|3600|0|3600
17|Subtract|0|0|
18|Callback|1|0|
19|Goto|0|14|
20|Noop|0|0|
21|Halt|0|0|
explain select timestamp - 3600 from ( select max ( timestamp ) as 'timestamp' from rawlog ) ;
0|ColumnName|0|0|timestamp - 3600
1|VerifyCookie|0|1408|
2|Integer|0|0|
3|OpenRead|1|3|rawlog
4|Integer|0|0|
5|OpenRead|2|8|ix_rawlog_timestamp
6|Last|2|0|
7|IdxRecno|2|0|
8|Close|2|0|
9|MoveTo|1|0|
10|Column|1|0|
11|MakeRecord|1|0|
12|NewRecno|0|0|
13|Pull|1|0|
14|PutIntKey|0|0|
15|Close|1|0|
16|Rewind|0|22|
17|Column|0|0|
18|Integer|3600|0|3600
19|Subtract|0|0|
20|Callback|1|0|
21|Next|0|17|
22|Halt|0|0|
result of this last query appears blank
|
2004-Jan-30 01:33:16 by anonymous:
Here is my workaround:
explain select timestamp - 3600 as 'timestamp' from rawlog order by timestamp desc limit 1 ;
0|ColumnName|0|0|timestamp
1|Integer|-1|0|
2|MemStore|0|1|
3|Integer|0|0|
4|OpenRead|0|3|rawlog
5|VerifyCookie|0|1537|
6|Integer|0|0|
7|OpenRead|1|4|pk_rawlog
8|Last|1|19|
9|RowKey|1|0|
10|IdxIsNull|0|18|
11|IdxRecno|1|0|
12|MoveTo|0|0|
13|MemIncr|0|19|
14|Column|0|0|
15|Integer|3600|0|3600
16|Subtract|0|0|
17|Callback|1|0|
18|Prev|1|9|
19|Close|0|0|
20|Close|1|0|
21|Halt|0|0|
2004-Jan-30 01:40:33 by drh:
- You will get much more pleasing code listings if you first
execute .explain to set up the column formatting right.
- Any of the following should do what you want:
SELECT max(timestamp-3600) FROM rawlog;
SELECT max(timestamp)-3600 FROM rawlog;
SELECT timestamp-3600 FROM rawlog ORDER BY timestamp DESC LIMIT 1;
- The following should work but does not. This is a bug:
SELECT * FROM (SELECT max(timestamp)-3600 FROM rawlog);
2004-Jan-30 02:03:03 by drh:
I see now. You are trying to get the optimizer to kick in and
that only happens if min() or max() appear by themselves on an
indexed column. Fair enough. Probably the optimizer should
be a little smarter about these things, but for now I'll just
fix the bug.
2004-Sep-15 01:25:34 by anonymous:
i just need to know the definition |
|
583 |
warn
|
fixed
|
2004 Jan
|
anonymous
|
Unknown
|
2004 Feb
|
|
4
|
4
|
_FILE_OFFSET_BITS redefined on 64bit sparc-sun-solaris
|
edit |
bash-2.05b$ gcc -v
Reading specs from /opt/gnu/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/specs
Configured with: ./configure --prefix=/opt/gnu --enable-languages=c,c++,objc --disable-nls --enable-shared --enable-threads=posix --with-as=/opt/gnu/bin/as --with-ld=/opt/gnu/bin/ld
Thread model: posix
gcc version 3.3.2
bash-2.05b$ uname -a
SunOS bslw0102 5.8 Generic_108528-11 sun4u unknown SUNW,Ultra-4 Solaris
bash-2.05b$ export CFLAGS="-O2 -fstrength-reduce -ffast-math -fexpensive-optimizations -s -pipe -mhard-float -mfpu -mcpu=ultrasparc -Wall -std=c99"
bash-2.05b$ tar xfz sqlite-2.8.11.tar.gz
bash-2.05b$ cd sqlite
bash-2.05b$ ./configure --prefix=/opt/gnu --with-gnu-ld --enable-tempdb-in-ram --disable-readline --disable-tcl
bash-2.05b$ make
...lots of compiler output...
In file included from src/func.c:26:
src/os.h:42:1: warning: "_FILE_OFFSET_BITS" redefined
In file included from /usr/include/iso/ctype_iso.h:30,
from /usr/include/ctype.h:18,
from src/func.c:21:
/usr/include/sys/feature_tests.h:96:1: warning: this is the location of the previous definition
...more compiler output...
bash-2.05b$
The above warning is repeated for:
In file included from src/main.c:20:
In file included from src/random.c:21:
In file included from src/tokenize.c:21:
In file included from src/vacuum.c:20:
In file included from src/vdbe.c:49:
In file included from src/vdbeaux.c:18:
|
dirty workaround for sparc-sun-solaris:
diff -Nur sqlite.orig/src/os.h sqlite/src/os.h
--- sqlite.orig/src/os.h 2004-01-11 23:56:52.000000000 +0100
+++ sqlite/src/os.h 2004-01-28 10:01:31.427287000 +0100
@@ -39,7 +39,6 @@
*/
#ifndef SQLITE_DISABLE_LFS
# define _LARGE_FILE 1
-# define _FILE_OFFSET_BITS 64
# define _LARGEFILE_SOURCE 1
#endif
2004-Feb-25 20:24:53 by anonymous:
Same problem as described in #605
Problem is fixed with [1227]
|
|
582 |
build
|
fixed
|
2004 Jan
|
anonymous
|
|
2004 Jan
|
|
4
|
3
|
no permission to execute install-sh
|
edit |
The file install-sh has permissions -rw-rw-r--. On Solaris 5.6, using tcsh, it compiles but it doesn't install. Permissions should be -rwxrwxr--. |
|
577 |
doc
|
fixed
|
2004 Jan
|
anonymous
|
|
2004 Jan
|
|
5
|
3
|
Typo on main SQLite home page
|
edit |
There is a typo on the SQLite home page http://www.hwaci.com/sw/sqlite/
In the section Building From Source it says "Tha latter method is used for all official development" when it should say "The latter method is used for all official development". |
|
576 |
code
|
fixed
|
2004 Jan
|
anonymous
|
CodeGen
|
2004 Feb
|
|
1
|
2
|
last_insert_rowid() returns wrong values in triggers on views
|
edit |
I have tracked down a what I think is a problem with the last_insert_rowid() function. I also get the same results with the sqlite_last_insert_rowid() API call.
If the last insert is done inside a trigger on a view, it does not update the last_insert_rowid() return value.
The SQL scrip in the attached file test.sql demonstrates the problem. A log of the execution of this script is also attached in the file test.log.
It looked like SQlite did the correct thing in triggers on tables, but after further examination, that is not true. It does not update the last_insert_rowid return value for any inserts inside triggers.
I think SQLite should update this variable for every insert into a real table, unless there is some subtlety I haven't considered. |
It seems to me that the the PutIntKey instruction at line 27 of the first explain output, the insert into a view, should have a p2 parameter of 1 rather than 0. This would allow this instruction to update the lastRowid variable which is returned by last_insert_rowid().
It looks like SQLite is actively avoiding updates to the lastRowid variable inside triggers.
The second explain output shows that it only updates this variable at line 20, which correpsonds to the original insert into t3. The insert into t4 caused by the after insert trigger on t3 does not update the lastRowid variable, because the p2 parameter of the PutIntKey instrunction at line 37 is 0.
A further update, upon looking into this matter further:
This problem has been reported previously under ticket #481 (I know, I should have checked for this first before openeing another ticket. I'm sorry). This behaviour was introduced by the fix to the problem reported on ticket #290.
I think both behaviors are unexpected and problematic. The behavior within INSTEAD OF triggers on views makes last_insert_rowid() useless when working with tables that have integer primary keys. The behavior with AFTER triggers on tables prior to the ticket #290 fix was also clearly broken.
I think the correct behavior in all cases can be obtained by having SQLite create a seperate context for each trigger. This would require the current value of db->lastRowid to be pushed onto the VDBE stack at the beginning of the trigger. Then allow all inserts to update db->lastRowid so that calls to last_insert_rowid() return the correct value within the trigger. And finally to restore the value of db->lastRowid after the trigger completes.
This would provide the correct behavior for AFTER triggers on tables, as well as allow the correct rowids to be obtained for inserts performed inside all triggers. It will also work with nested triggers.
The only anomally is that there is still no way to directly obtain the rowid for the principle table in a view if that table use an integer primary key. Perhaps this is not a real problem technically, since the rows in views do not have rowids (the rowid for a view is always NULL). However it is a problem when the user expects the view to have the same semantics as a table with an integer primary key (i.e. he expects to be able to do an insert into the view, and then select last_insert_rowid() to get the rowid assigned to the row(s) inserted).
At least with the proposed change the user can update a table to store the value of last_insert_rowid() from within the trigger and then select that value after the insert on the view instead of calling last_insert_rowid(). This is shown in the example below.
create table main (
id integer primary key,
a
);
create table extend (
id integer references main,
b
);
create view combined as
select
main.id as id,
main.a as a,
extend.b as b
from main join extend using(id);
create table last_insert (
id integer
);
create trigger in_combined instead of insert on combined
begin
//insert into main table
insert into main values (new.id, new.a);
//export last_insert_rowid out of trigger
update last_insert set id = last_insert_rowid();
//insert into extended data table with correct id to
// establish relation to main table
insert into extend values (last_insert_rowid(), new.b);
end;
//do test insert into combined view
insert into combined values(NULL, 1, 2);
//get id needed to re-select the last row inserted into the view
select id from last_insert;
This is still does not allow tables and views to be treated exactly the same. But it would probably be workable for most applications.
The only thing I can think of that would allow the view to behave more like a table is to allow the user to indicate which field in the view should be treated like its rowid. An insert trigger on a view could then update the db->lastRowid variable with the value of this field when the trigger is done. This would invlove substantially more complicated changes to SQLite. |
|
574 |
code
|
fixed
|
2004 Jan
|
drh
|
|
2004 Jan
|
|
1
|
1
|
ATTACH fails when invoked from sqlite_compile()
|
edit |
The following command fails when invoked using sqlite_compile().
It works fine from sqlite_exec():
ATTACH DATABASE testDB as db;
|
|
569 |
code
|
fixed
|
2004 Jan
|
dougcurrie
|
Pager
|
2004 Jan
|
dougcurrie
|
3
|
3
|
Newer Cygwin (>1.50) doesn't want __CYGWIN_USE_BIG_TYPES__
|
edit |
In response to tickets #429 #349 #213 the lines
if defined(__CYGWIN__)
define __CYGWIN_USE_BIG_TYPES__
endif
were added to os.h
With recent versions of Cygwin these lines in os.h are causing warnings during compile, and aren't adding anything useful to SQLite. So, I am removing them.
The Cygwin developers always advised against using __CYGWIN_USE_BIG_TYPES__ this way, and starting with version 1.50 of Cygwin the default is to use type long long for off_t anyway. See http://www.mail-archive.com/cygwin-apps@cygwin.com/msg06854.html |
|
568 |
code
|
fixed
|
2004 Jan
|
anonymous
|
Shell
|
2004 Feb
|
|
2
|
2
|
Shell does not handle -init option correctly
|
edit |
The SQLite shell does not handle the -init command line option correctly. Currently the filename passed as a parameter to the -init option is parsed as the database file name. This leads to a malformed database file error.
I have fixed the shell.c file by adding few small snippets of code.
The -init command is added to the set of options with parameters so that it is skipped when looking for the database file name.
The current processing of the init file clears the database filename and output file settings established earlier. These values should be saved and restored before and after the callback data is reinitialized. Actually there is no real effect on the output file since it is initially set to stdout, and then reinitialized to zero, which just happens to be the same value.
These changes can be applied to shell.c by patching with the attached diff file. |
|
567 |
code
|
fixed
|
2004 Jan
|
anonymous
|
Unknown
|
2004 Jan
|
|
3
|
3
|
Erroneous test for rowid >= (fp number) in where clause
|
edit |
This may be the same problem that was (partially) fixed under ticket #377.
sqlite> select count(*) from stages;
3
sqlite> select rowid, stnum from stages where rowid >= 1.5;--Oops
1|1
2|2
3|3
sqlite> select rowid, stnum from stages where 1.5 <= rowid;--Oops
1|1
2|2
3|3
The condition for error seems to be that the operator be <= or >=, that the rowid be on the 'greater side' of the operator, and that the other operand be floating point. |
|
565 |
code
|
fixed
|
2004 Jan
|
anonymous
|
VDBE
|
2004 Jan
|
|
2
|
3
|
sqlite: src/vdbe.c:512: sqliteVdbeExec: Assertion `p->tos<=pc' failed.
|
edit |
thats what I get:
> sqlite weblog.db
SQLite version 2.8.10
Enter ".help" for instructions
sqlite> select id from requests where 'xx'IN ( select name from requests );
sqlite: src/vdbe.c:512: sqliteVdbeExec: Assertion `p->tos<=pc' failed.
Abgebrochen
the tble was build with
CREATE TABLE requests ( id INTEGER primary key, name varchar(255));
I was unable to reproduce this from scratch with a little table.
here is a gdb backtrace:
Program received signal SIGABRT, Aborted.
0x15630cc1 in kill () from /lib/libc.so.6
(gdb) bt
#0 0x15630cc1 in kill () from /lib/libc.so.6
#1 0x15630a45 in raise () from /lib/libc.so.6
#2 0x15631fcc in abort () from /lib/libc.so.6
#3 0x15629f3b in __assert_fail () from /lib/libc.so.6
#4 0x1559d649 in sqliteVdbeExec (p=0x8077f58) at src/vdbe.c:4728
#5 0x1557bed0 in sqliteExec (pParse=0x3fffdb70) at src/build.c:97
#6 0x15590c16 in yy_reduce (yypParser=0x8077908, yyruleno=5) at parse.y:77
#7 0x15591067 in sqliteParser (yyp=0x8077908, yymajor=106, yyminor=
{z = 0x0, dyn = 0, n = 179949744}, pParse=0x0) at parse.c:3946
#8 0x15598f7c in sqliteRunParser (pParse=0x3fffdb70,
zSql=0x805d498 "select id from requests where 'xx' IN ( select name from requests );", pzErrMsg=0x3fffdc58) at src/tokenize.c:450
#9 0x1558a066 in sqliteMain (db=0x804d7d0,
zSql=0x805d498 "select id from requests where 'xx' IN ( select name from requests );", xCallback=0, pArg=0x0, pzTail=0x0, ppVm=0x0, pzErrMsg=0x3fffdc58)
at src/main.c:631
#10 0x1558a273 in sqlite_exec (db=0x804d7d0,
zSql=0x805d498 "select id from requests where 'xx' IN ( select name from requests );", xCallback=0x80494a0 <callback>, pArg=0x3fffdca0,
pzErrMsg=0x3fffdc58) at src/main.c:681
#11 0x0804b44a in process_input (p=0x3fffdca0, in=0x0) at src/shell.c:1038
---Type <return> to continue, or q <return> to quit---
#12 0x0804bca1 in main (argc=2, argv=0x3ffff214) at src/shell.c:1329
|
Temporary workaround:
select id from requests
where 'xx'IN ( select name from requests WHERE NAME NOT NULL );
^^^^^^^^^^^^^^^^^^^
The problem is fixed in CVS head. The workaround is only for those
who have not updated. |
|
564 |
code
|
fixed
|
2004 Jan
|
anonymous
|
Parser
|
2005 Jan
|
|
4
|
4
|
Inability to determine column in subquery
|
edit |
If I try and run this query, it cannot identify column B.col_2:
SELECT A.random_col, B.col_2
FROM A
, (SELECT c.col_2 FROM c, d WHERE c.id = d.id) B;
However, if I add an alias, it can:
SELECT A.random_col, B.col_2
FROM A
, (SELECT c.col_2 col_2 FROM c, d WHERE c.id = d.id) B;
Thanks,
Steve |
This is pretty much the same issue as #439, #469, #523, #269,
and so forth. |
|
561 |
code
|
fixed
|
2004 Jan
|
drh
|
Pager
|
2004 Jan
|
|
1
|
1
|
Database corruption when using Linux threads
|
edit |
Under Linux (RedHat 7.1 Kernel 2.4.7-10),
if multiple threads within
the same process each do separate sqlite_open() calls to the same
database then begin editing the database, the database can become
corrupted. The problem appears to be a bug in Linux threads, not
in SQLite. SQLite is doing everything correctly. Linux threads is
not honoring file locks.
You can see the problem with linux threads using the program
in the first attachment (locktest1.c). Details on what this
program does are available in the comments. In brief, you
can see the malfunction if you compile this program and run
it as follows:
./locktest1 ao ar bo bw bc bo bw
The following is what this test does:
- Thread A opens file "test.file"
- Thread A gets a read lock on the file.
- Thread B opens the same file
- Thread B tries to get a write lock on the file.
- Thread B closes the file
- Thread B reopens the file
- Thread B tries again to get a write lock on the file.
The attempt by thread B to get a write lock on the file in step
4 fails, as it should. But the second attempt by B to get a
write lock (step 7) succeeds. Step 7 should fail because
thread A still has a read lock.
From this test I conclude that file locking in linux threads
is badly broken. Since SQLite uses file locking to maintain
the integrity of the database, using SQLite under linux threads
can lead to database corruption.
The second attachment (locktest2.c) is the same program as
locktest1 except that it runs separate processes instead of
separate threads. Locktest2 appears to work. This leads me
to believe that the problem is in the pthreads library, not
in the linux kernel.
Advice from the community on how to deal with this problem will
be appreciated. In particular, I am looking for suggestions on
how to work around the problem and reports of wheether or not
the problem exists on other versions of linux. Please append
your analysis and/or advice to the remarks section below.
2004-Jan-11:
It has now come to light that the analysis above is wrong. The
problem is with SQLite - though it stems from a goofy API design
for posix advisory locks.
It turns out that when you close a file descriptor, all locks on
the file of that file descriptor that were created by the current
process are cleared. Even locks that had nothing to do with the
file descriptor that was closed.
So consider would what happen if you execute code like this:
db = sqlite_open("test.db", 0, 0);
sqlite_exec(db, "SELECT * FROM whatever", callback, 0, 0);
Then in the callback you do this:
db2 = sqlite_open("test.db", 0, 0);
sqlite_exec(db2, "INSERT INTO whatever VALUES(1)", 0, 0, 0);
sqlite_close(db2);
The INSERT attempt will fail because the database is locked. But
when the file descriptor closes after this failed insert attempt,
all locks on the database file will be cleared, including the
lock on the original database that is doing the SELECT. So the
next time the callback is invoked (assuming the WHATEVER table
contains two or more rows) there will be no locks, the INSERT
will succeed. This will change the database out from under the
SELECT, possibly leading to a segfault. In other scenarios, it
could lead to a corrupt database. |
- Slackware 9.0, Kernel 2.4.20 <kwel@kwel.net>
**kaw<~/c/threadlocktest>$ ./locktest1 ao ar bo bw bc bo bw
A(03440) Open rc=5
A(03440) RdLock OK type=0 whence=0 start=0 len=0 pid=0
B(03441) Open rc=6
B(03441) WrLock Err=EAGAIN type=1 whence=0 start=0 len=0 pid=0
B(03441) Close rc=0
B(03441) Open rc=6
B(03441) WrLock OK type=1 whence=0 start=0 len=0 pid=0
**kaw<~/c/threadlocktest>$ ./locktest2 ao ar bo bw bc bo bw
A(03445) Open rc=4
A(03445) RdLock OK type=0 whence=0 start=0 len=0 pid=0
B(03446) Open rc=5
B(03446) WrLock Err=EAGAIN type=1 whence=0 start=0 len=0 pid=0
B(03446) Close rc=0
B(03446) Open rc=5
B(03446) WrLock Err=EAGAIN type=1 whence=0 start=0 len=0 pid=0
Resolution:
Modified os.c so that calls to close() are embargoed until
all locks on the file have cleared. |
|
552 |
code
|
fixed
|
2004 Jan
|
drh
|
|
2004 Jan
|
|
1
|
1
|
Integer overflow results in database corruption
|
edit |
Beginning with a new database, the following SQL results in a corrupt
index, as shown by the final "integrity_check" line:
CREATE TABLE t1(a INT UNIQUE);
INSERT INTO t1 VALUES(-2147483649);
PRAGMA integrity_check;
The error does not occur if the value inserted is greater than
-2147483648. The problem is a 32-bit integer overflow.
greater. |
|
551 |
code
|
fixed
|
2004 Jan
|
anonymous
|
Unknown
|
2004 Jan
|
|
3
|
3
|
Date/Time functions: some modifiers cause loss of h:m:s
|
edit |
The modifiers 'weekday N', 'N months', and 'N years' cause loss of the time part of the datetime.
sqlite> select datetime('now');
2004-01-05 17:23:58 -- correct day and time of day
sqlite> select datetime('now', 'weekday 0');
2004-01-11 00:00:00 -- correct day, lost time of day
sqlite> select datetime('now', '1 month');
2004-02-05 00:00:00 -- correct day, lost time of day
sqlite> select datetime('now', '1 year');
2005-01-05 00:00:00 -- correct day, lost time of day
|
|
548 |
code
|
fixed
|
2004 Jan
|
anonymous
|
Parser
|
2004 Jan
|
|
3
|
3
|
SQLite will abort() when utf-8 character is invalid
|
edit |
utf-8 support in SQLite will assert()/abort()
when the utf-8 string is invalid.
This is a severe problem when SQLite is used as
PHP extension working with web server.
Here is a work-around patch,
Index: src/func.c
===================================================================
RCS file: /sqlite/sqlite/src/func.c,v
retrieving revision 1.34
diff -c -r1.34 func.c
*** src/func.c 23 Dec 2003 02:17:35 -0000 1.34
--- src/func.c 28 Dec 2003 15:07:56 -0000
***************
*** 123,134 ****
}
#ifdef SQLITE_UTF8
for(i=0; i<p1; i++){
! assert( z[i] );
if( (z[i]&0xc0)==0x80 ) p1++;
}
while( z[i] && (z[i]&0xc0)==0x80 ){ i++; p1++; }
for(; i<p1+p2; i++){
! assert( z[i] );
if( (z[i]&0xc0)==0x80 ) p2++;
}
while( z[i] && (z[i]&0xc0)==0x80 ){ i++; p2++; }
--- 123,134 ----
}
#ifdef SQLITE_UTF8
for(i=0; i<p1; i++){
! sqlite_assert( z[i] );
if( (z[i]&0xc0)==0x80 ) p1++;
}
while( z[i] && (z[i]&0xc0)==0x80 ){ i++; p1++; }
for(; i<p1+p2; i++){
! sqlite_assert( z[i] );
if( (z[i]&0xc0)==0x80 ) p2++;
}
while( z[i] && (z[i]&0xc0)==0x80 ){ i++; p2++; }
Index: src/os.h
===================================================================
RCS file: /sqlite/sqlite/src/os.h,v
retrieving revision 1.26
diff -c -r1.26 os.h
*** src/os.h 24 Dec 2003 01:41:19 -0000 1.26
--- src/os.h 28 Dec 2003 15:08:04 -0000
***************
*** 161,166 ****
--- 161,172 ----
# define SQLITE_MIN_SLEEP_MS 17
#endif
+ #ifdef ASSERT_UNSAFE
+ # define sqlite_assert
+ #else
+ # define sqlite_assert assert
+ #endif
+
int sqliteOsDelete(const char*);
int sqliteOsFileExists(const char*);
int sqliteOsFileRename(const char*, const char*);
|
|
545 |
code
|
fixed
|
2004 Jan
|
anonymous
|
BTree
|
2004 Jan
|
|
5
|
4
|
Use of uninitialized memory
|
edit |
While running "PRAGMA integriry_check"
with the following stack:
checkTreePage
fileBtreeIntegrityCheck
sqliteVdbeExec
sqliteExec
yy_reduce
sqliteParser
sqliteRunParser
sqliteMain
sqlite_exec
The following code increments a counter that was not initialized:
/* Update freespace totals.
*/
pCheck->nTreePage++; <---- BUG
pCheck->nByte += USABLE_SPACE - pPage->nFree; <--- BUG
The pCheck was allocated on stack:
char *fileBtreeIntegrityCheck(Btree *pBt, int *aRoot, int nRoot){
int i;
int nRef;
IntegrityCk sCheck;
and this specific member was not initialized.
maybe do memset to zero ? |
The IntegrityCk.nTreePage and IntegrityCheck.nByte fields were never
used for anything so it matters not that they were uninitialized.
They have now been removed from the structure and the code identified
above as a "bug" has been removed. |
|
542 |
code
|
fixed
|
2003 Dec
|
anonymous
|
Parser
|
2003 Dec
|
|
1
|
1
|
crash on date parsing
|
edit |
while running the following sql statement:
SELECT coalesce(date('2003-10-22','weekday 0'),'NULL');
I crashed with the following stack:
parseModifier
isDate
dateFunc
sqliteVdbeExec
sqliteExec
yy_reduce
sqliteParser
sqliteRunParser
sqliteMain
sqlite_exec
The reason is that the code is running on both strings for 29 characters while the parameter is much shorter.
static int parseModifier(const char *zMod, DateTime *p){
int rc = 1;
int n;
double r;
char z[30];
for(n=0; n<sizeof(z)-1; n++){ <------ the bug
z[n] = tolower(zMod[n]);
}
|
|
541 |
code
|
fixed
|
2003 Dec
|
anonymous
|
|
2003 Dec
|
drh
|
1
|
1
|
Compile error in os.c
|
edit |
Check-in [1149]
introduce a compile error on unix and mac os, by running a statement before variable declaration (during normal build). The following patch corrects the problem:
--- os.orig Wed Dec 31 16:38:24 2003
+++ os.c Wed Dec 31 16:35:05 2003
@@ -39,6 +39,7 @@
#if OS_WIN
# include <winbase.h>
+#include <memory.h>
#endif
#if OS_MAC
@@ -1441,6 +1442,8 @@
** supply a sufficiently large buffer.
*/
int sqliteOsRandomSeed(char *zBuf){
+ int pid;
+ memset(zBuf, 0, 256);
/* We have to initialize zBuf to prevent valgrind from reporting
** errors. The reports issued by valgrind are incorrect - we would
** prefer that the randomness be increased by making use of the
@@ -1453,9 +1456,7 @@
** that we always use the same random number sequence.* This makes the
** tests repeatable.
*/
- memset(zBuf, 0, 256);
#if OS_UNIX && !defined(SQLITE_TEST)
- int pid;
time((time_t*)zBuf);
pid = getpid();
memcpy(&zBuf[sizeof(time_t)], &pid, sizeof(pid));
@@ -1464,7 +1465,6 @@
GetSystemTime((LPSYSTEMTIME)zBuf);
#endif
#if OS_MAC
- int pid;
Microseconds((UnsignedWide*)zBuf);
pid = getpid();
memcpy(&zBuf[sizeof(UnsignedWide)], &pid, sizeof(pid));
Related #535 |
|
534 |
code
|
fixed
|
2003 Dec
|
anonymous
|
|
2004 Jan
|
|
2
|
2
|
possible bug in sqliteMalloc and sqliteMallocRaw
|
edit |
I think if you try to malloc 0 bytes you will get failure with the current implementations of sqliteMalloc and sqliteMallocRaw. If you turn on MEMORY_DEBUG, then you get sqliteMalloc_, and it has the following line:
if( n==0 ) return 0;
But that line is not in either sqliteMalloc and sqliteMallocRaw and so a 0-byte malloc will fail. I think this manifests itself if you try to create an in-memory database and then try to create a table in that database. A workaround appears to be to add the above line to both sqliteMalloc and sqliteMallocRaw. |
|
533 |
code
|
fixed
|
2003 Dec
|
anonymous
|
|
2003 Dec
|
|
2
|
1
|
Crash when using datetime() with a NULL value.
|
edit |
isDate in date.c appears to crash when passed a NULL value. The problem can best be seen by issuing the following SQL:
select datetime(NULL);
I think a simple check for argv being NULL in isDate should do the trick. |
|
530 |
code
|
fixed
|
2003 Dec
|
anonymous
|
Pager
|
2003 Dec
|
|
2
|
2
|
sqlite returns SQLITE_BUSY forever (linux multithreaded)
|
edit |
sqliteOsReadLock() and sqliteOsUnlock() in the OS_UNIX def
leave open the potential that a different thread will make
the fcntl() UNLOCK call from the the thread that made the fcntl() LOCK call.
[thread1] ReadLock()s with pLock->cnt=0: fcntl(LOCK); cnt++
[thread2] ReadLock()s with pLock->cnt=1: cnt++
[thread1] UnLock()s with pLock->cnt=2: cnt--
[thread2] UnLock()s with pLock->cnt=1: fcntl(UNLOCK); cnt=0
in linux thread2 can't fcntl(UNLOCK) thread1's lock
what ends up happening is: a read lock is leaked!
and any attempt to get a write lock from then on returns SQLITE_BUSY
ive been using my own fix since 2.8.4 that gets a rdlock for each call to ReadLock() and unlocks for each call to Unlock() to avoid this problem. (i dont have repro steps but each time i ran my high-load application the db would become unusable in a few minutes) |
If this is true, then Linux is does not conform to the POSIX spec.
This would technically be a bug in Linux, then, not in SQLite.
Given the widespread use of linux, I suppose I'll have to invent
some kind of work-around.
Works now on linux. Question is, did this break it for other
unix systems.
The locks should now work on both linux and POSIX systems. I say
"should" because I don't have any way to test non-linux unix systems. |
|
529 |
code
|
fixed
|
2003 Dec
|
drh
|
|
2003 Dec
|
|
1
|
1
|
An aborted update can corrupt the database
|
edit |
The following sequence of SQL statements applied against a new database
will result in a database file that is corrupt. The corruption can
be seen using the "PRAGMA integrity_check" command.
CREATE TABLE t(a UNIQUE,b);
INSERT INTO t VALUES(1,'a23456789_b23456789_c23456789_d23456789_e23456789_');
UPDATE t SET b=b||b;
UPDATE t SET b=b||b;
UPDATE t SET b=b||b;
UPDATE t SET b=b||b;
UPDATE t SET b=b||b;
INSERT INTO t VALUES(2,'x');
UPDATE t SET b=substr(b,1,500);
BEGIN;
UPDATE t SET a=CASE a WHEN 2 THEN 1 ELSE a END, b='y';
CREATE TABLE t2(x,y);
COMMIT;
The first group of statements constructs a database with a single
table holding two entries. One of the two entries uses a single
overflow page. There is a single page on the freelist.
The UPDATE statement within the transaction processes row 1 of
the table first. The long "b" column of that row is truncated,
which causes the overflow page used to hold data for the "b" column
to be moved onto the freelist. When the UPDATE statement continues
to the second row, a constraint failure occurs which causes the
statement to abort. The abort restores the content of the first
row and remove the overflow page used to store "b" from the freelist
on disk. But the overflow page is not removed from the freelist
in the in-memory cache image that SQLite maintains of parts of
the disk file. This omission - the failure to keep the in-memory
cache synchronized with the disk - is the origin of the error.
At this point, the in-memory cache has become corrupt.
No harm would come of this if the transaction
ended immediately because that would flush the cache. But since the
transaction continues and the corrupt cache continues to be used
instead of the correct data on disk, permanent database corruption
can result.
Because it is using the corrupt in-memory cache image of the
database freelist, the CREATE TABLE statement within the transaction
reuses the the overflow page from table t to be the root page of
table t2. The same page is now being used for two different things
at the same time. When the transaction commits, this corruption
is written to disk and becomes permanent. |
The problem was introduced on 2003-Jan-29 by
check-in [855]
. This occurred in between release 2.7.6 and
2.8.0 so only the 2.8.0 through 2.8.7 should be effected by
this problem. |
|
526 |
code
|
fixed
|
2003 Dec
|
anonymous
|
|
2003 Dec
|
|
1
|
1
|
Primary key not unique (database corruption?)
|
edit |
Having many problems that look like indexing issues. We are seeing a primary key that is losing uniqueness among other things.
Here is the sqlite_master table:
select * from sqlite_master;
table|version|version|3|CREATE TABLE version (version INT)
table|message_log_meta_data|message_log_meta_data|5|CREATE TABLE
message_log_meta_data (
name VARCHAR(32) PRIMARY KEY,
value VARCHAR(128)
)
index|(message_log_meta_data autoindex 1)|message_log_meta_data|4|
table|message_log|message_log|7|CREATE TABLE message_log (
id VARCHAR(32) PRIMARY KEY,
client VARCHAR(16),
start_time INT,
end_time INT,
latency INT,
time VARCHAR(32),
log_time VARCHAR(32),
msg_file VARCHAR(64),
to VARCHAR(128),
from_email VARCHAR(64),
subject VARCHAR(128),
tag VARCHAR(32),
quarantine VARCHAR(32),
virus_block VARCHAR(32),
spam_block VARCHAR(32),
spam_score FLOAT,
disconnect VARCHAR(16),
message_delivered VARCHAR(16),
error VARCHAR(128),
connect VARCHAR(64),
debug_id VARCHAR(32),
pu_quarantine VARCHAR(32),
whitelist VARCHAR(32)
)
index|(message_log autoindex 1)|message_log|6|
index|start_time|message_log|105666|CREATE INDEX start_time ON message_log (start_time)
index|to|message_log|108337|CREATE INDEX to ON message_log (to)
index|latency|message_log|112359|CREATE INDEX latency ON message_log (latency)
table|recipients|recipients|114339|CREATE TABLE recipients (
to VARCHAR(128) PRIMARY KEY,
last_message_time INT
)
index|(recipients autoindex 1)|recipients|114336|
index|recipients_to|recipients|116279|CREATE INDEX recipients_to ON recipients (to)
index|last_message_time|recipients|117212|CREATE INDEX last_message_time ON recipients (last_message_time)
Note that "id" is the primary key of the "message_log" table. However, look at the following log:
# sqlite /tmp/message.lite
SQLite version 2.8.6
Enter ".help" for instructions
sqlite> vacuum;
SQL error: column id is not unique
>>>>> How is this possible?? column "id" is a primary key..
sqlite> SELECT id FROM message_log GROUP BY id HAVING COUNT(1) > 1;
1071129925-32560-6-0
1071130020-32662-6-0
1071130053-32710-1-0
1070988099-22639-3-0
sqlite> DELETE FROM message_log WHERE id IN (SELECT id FROM message_log GROUP BY id HAVING COUNT(1) > 1);
sqlite> SELECT id FROM message_log GROUP BY id HAVING COUNT(1) > 1;
1070988099-22639-3-0
>>>>> We just deleted these!!
sqlite> SELECT id FROM message_log WHERE id ='1071130173-440-2-0' ;
1071130177-466-0-0
>>>>> Huh?
sqlite> DELETE FROM message_log WHERE id ='1071130173-440-2-0';
sqlite> SELECT id FROM message_log WHERE id ='1071130173-440-2-0' ;
1071130177-466-0-0
>>>>> Still there...
sqlite> vacuum;
sqlite> SELECT id FROM message_log WHERE id ='1071130173-440-2-0' ;
1071130173-440-2-0
>>>>> Fixed!?!
Please download the test database from:
http://205.158.110.60/sqlite |
Probably the same as ticket #529. |
|
523 |
code
|
fixed
|
2003 Dec
|
anonymous
|
Unknown
|
2005 Jan
|
|
2
|
2
|
Select table 'AS' does not work in JOIN USING clause
|
edit |
If you do a select and use the "AS 'alias'" for a table and also do a "JOIN USING <col list>", you get a sql error: no such column <tablename>.<col name>. So, if you have table User with fields a,b and table UserInfo with fields a,c, the following gives the error "User.a no such column":
SELECT U.b,I.c FROM User as U JOIN UserInfo as I USING a;
whereas, the following sql will work just fine:
SELECT User.b,UserInfo.c FROM User JOIN UserInfo USING a; |
2004-Nov-23 20:32:16 by anonymous:
SELECT U.b,I.c FROM User as U JOIN UserInfo as I ON U.a=I.a;
works. |
|
521 |
code
|
fixed
|
2003 Dec
|
anonymous
|
Unknown
|
2004 Jul
|
|
2
|
1
|
"create as select ..." does not preserve datatypes
|
edit |
Subject says it all. This problem effectively rendres "create as select" useless, because every "create as select" needs to be examined by hand for datatypes involved and replaced by "create table ..." and 'insert into ... select ...". Is it possible to preserve datatype information for selects that does not involve expressions in "select" and only select whole columns?
Here is transcript from sqlite session that shows problem:
SQLite version 2.8.6
Enter ".help" for instructions
sqlite> create table zzz (col1 text, col2 text);
sqlite> create table ttt as select * from zzz;
sqlite> .schema
CREATE TABLE ttt(col1,col2);
create table zzz (col1 text, col2 text);
Notice datatypes for "ttt" |
Fixed in version 3.0 |
|
520 |
code
|
fixed
|
2003 Dec
|
anonymous
|
Parser
|
2003 Dec
|
drh
|
2
|
2
|
tokenize bug in simultaneous threaded sqlite_open (with patch)
|
edit |
Bug with patch:
To check if the keyword hash table is already initialized, sqliteKeywordCode method checks the len of the first element...
If set, it thinks the hash is initialized... it's wrong.
The method must test the last element to be sure another process is not still generating hash values.
Here is a possible patch:
-- CUT HERE --
--- tokenize.wrong.c 2003-09-27 15:39:39.000000000 +0200
+++ tokenize.c 2003-12-10 14:39:17.000000000 +0100
@@ -155,13 +155,12 @@
int sqliteKeywordCode(const char *z, int n){
int h;
Keyword *p;
+ int aKeywordTableSz = sizeof(aKeywordTable)/sizeof(aKeywordTable[0]);
- if( aKeywordTable[0].len==0 ){
+ if( aKeywordTable[ aKeywordTableSz ].len==0 ){
/* Initialize the keyword hash table */
sqliteOsEnterMutex();
if( aKeywordTable[0].len==0 ){
int i;
- int n;
- n = sizeof(aKeywordTable)/sizeof(aKeywordTable[0]);
- for(i=0; i<n; i++){
+ for(i=0; i<aKeywordTableSz; i++){
aKeywordTable[i].len = strlen(aKeywordTable[i].zName);
h = sqliteHashNoCase(aKeywordTable[i].zName, aKeywordTable[i].len);
------------------------------------------
|
|
519 |
code
|
fixed
|
2003 Dec
|
drh
|
VDBE
|
2003 Dec
|
|
1
|
1
|
3-way join causes segfault
|
edit |
The following SQL code triggers a segfault:
CREATE TABLE counts(n INTEGER PRIMARY KEY);
INSERT INTO counts VALUES(0);
INSERT INTO counts VALUES(1);
INSERT INTO counts SELECT n+2 FROM counts;
INSERT INTO counts SELECT n+4 FROM counts;
INSERT INTO counts SELECT n+8 FROM counts;
SELECT dim1.n, dim2.n, dim3.n
FROM counts AS dim1, counts AS dim2, counts AS dim3
WHERE dim1.n<10 AND dim2.n<10 AND dim3.n<10;
|
|
515 |
code
|
fixed
|
2003 Dec
|
anonymous
|
Unknown
|
2003 Dec
|
|
4
|
3
|
VACUUM fails after dependent table DROP,CREATE sequence
|
edit |
see this test script for example:
CREATE TABLE Test (TestID int primary key);
INSERT INTO Test VALUES (NULL);
CREATE VIEW viewTest AS SELECT * FROM Test;
BEGIN;
CREATE TEMP TABLE tempTest (TestID int primary key, Test2 int NULL);
INSERT INTO tempTest SELECT TestID, 1 FROM Test;
DROP TABLE Test;
CREATE TABLE Test(TestID int primary key, Test2 int NULL);
INSERT INTO Test SELECT * FROM tempTest;
COMMIT;
VACUUM; -- this fails with message "SQL error or missing database. no such table: main.Test"
|
|
514 |
code
|
fixed
|
2003 Dec
|
anonymous
|
Unknown
|
2004 Mar
|
|
2
|
3
|
attaching a locked database causes strange errors and a crash
|
edit |
I run SQLite on Windows 2000 using the precompiled sqlite.dll.
The following problems occur at least in SQLite versions 2.8.6 and 2.8.7:
Suppose you have a database in file 'A' which is locked, e.g. because another process currently running a transaction. Now open a database file 'B' and execute the SQL query:
ATTACH DATABASE 'A' AS DB1;
The result is a (correct) "database is locked" error message.
Unfortunately any subsequent SQL query also produces this error message, regardless whether the query is perfectly in order or even syntactically wrong.
Moreover, if you have executed a certain number of statements(at least 3, it seems) after the failed ATTACH, closing database 'B' with "sqlite_close" produces a segmentation fault.
The only workaround I see is closing and re-opening the database immediately after an ATTACH command returned "database locked". |
|
505 |
doc
|
fixed
|
2003 Nov
|
anonymous
|
|
2003 Nov
|
|
5
|
3
|
Typos in SQLite Database File Format document
|
edit |
The current version of the SQLite Database File Format document contains three typos in the description of the payload field in the Btree cell structures.
Current text is: A cell can have up to 238 byte of payload space. If the payload is more than 238 bytes, then an addition 4 point page number is appended to the cell
It should be: A cell can have up to 238 bytes of payload space. If the payload is more than 238 bytes, then an additional 4 byte page number is appended to the cell |
|
504 |
code
|
fixed
|
2003 Nov
|
anonymous
|
|
2004 Feb
|
|
3
|
3
|
'INDEX_INFO' PRAGMA returns invalid data if used with non-callback API
|
edit |
'INDEX_INFO' PRAGMA returns invalid data if used with non-callback API |
Everything uses the non-callback API now. Even sqlite_exec() is
implemented using the non-callback API. And the INDEX_INFO pragma
works. So this must be fixed. |
|
502 |
doc
|
fixed
|
2003 Nov
|
anonymous
|
BTree
|
2003 Nov
|
|
5
|
3
|
Typos in Database File Format documentation
|
edit |
The current version of the SQLite Database File Format document contains two typos in the description of the Keysize field in the Btree cell structures.
The current text is:
The size of the key is a 24-bit where the upper 8 bits are taken
from by 8 and the lower 16 bits are token from bytes 4 and 5
It should be:
The size of the key is a 24-bit where the upper 8 bits are taken
from byte 8 and the lower 16 bits are taken from bytes 4 and 5 |
|
488 |
doc
|
fixed
|
2003 Nov
|
anonymous
|
|
2003 Nov
|
|
5
|
4
|
Lemon Parser Generator page is outdated
|
edit |
There are many links from different places to http://www.hwaci.com/sw/lemon/
But looks like this page is currently outdated and does not contain the latest version of Lemon. Many people choosing parser generator may find this page and think that is has the latest version available. By the way, I was one of those people :-) I considered Lemon to be used in a commercial project I currently work on. But I found a license in a parser template file quite confusing. Fortunately, I have downloaded SQLite sources a bit later and found an updated version of Lemon with much less restrictive license!
Putting a notice on that page stating that the latest Lemon version can be obtained from SQLite sources would probably help.
Thanks for making a great tool. |
|
487 |
code
|
fixed
|
2003 Nov
|
anonymous
|
|
2003 Nov
|
|
2
|
2
|
mac os x build via pear creates invalid bundle
|
edit |
If I go through the usual steps to build sqlite via pear install on mac os x 10.2.8, it ends up creating a .so that will not load via the php dl() or automatically via the php.ini. A dynamic library is created instead of a bundle.
This causes an error when you try to load the library:
cat example <<END
sh-2.05a# php sqlite.php
Warning: dl(): Unable to load dynamic library '/usr/local/lib/php/extensions/sqlite.so' - not a Mach-O MH_BUNDLE file type in /private/tmp/tmp9GcwuC/SQLite-1.0/sqlite.php on line 3
Fatal error: Call to undefined function: sqlite_libversion() in /private/tmp/tmp9GcwuC/SQLite-1.0/sqlite.php on line 6
END
There is a /usr/local/lib/php/extensions/sqlite.so file with proper permissions, it is merely linked incorrectly.
I was able to work around the problem by halting a pear install during mid build, running configure myself and relinking the binary with the correct options. Instead of -dynamiclib, use -bundle, and remove the -install_name option:
sh-2.05a# gcc -bundle -flat_namespace -undefined suppress -o .libs/sqlite.so sqlite.lo libsqlite/src/opcodes.lo libsqlite/src/parse.lo libsqlite/src/encode.lo libsqlite/src/auth.lo libsqlite/src/btree.lo libsqlite/src/build.lo libsqlite/src/delete.lo libsqlite/src/expr.lo libsqlite/src/func.lo libsqlite/src/hash.lo libsqlite/src/insert.lo libsqlite/src/main.lo libsqlite/src/os.lo libsqlite/src/pager.lo libsqlite/src/printf.lo libsqlite/src/random.lo libsqlite/src/select.lo libsqlite/src/table.lo libsqlite/src/tokenize.lo libsqlite/src/update.lo libsqlite/src/util.lo libsqlite/src/vdbe.lo libsqlite/src/attach.lo libsqlite/src/btree_rb.lo libsqlite/src/pragma.lo libsqlite/src/vacuum.lo libsqlite/src/copy.lo libsqlite/src/where.lo libsqlite/src/trigger.lo -lc
This worked for me and everything was happy once I copied it into place. As a side note, the dynamic libs are what you want to do for a library that compiled code will link against, just apparently not the mechanism php is/was set up to use (php could have used the equivalent to dlopen, but they apparently favored using bundles instead). Hope this helps someone. :)
Cheers!
Sean |
This appears to be a PHP issue, not something to do with SQLite. |
|
482 |
code
|
fixed
|
2003 Oct
|
anonymous
|
BTree
|
2003 Dec
|
|
1
|
1
|
SIGSEGV inside memRbtreeNext
|
edit |
(gdb) bt
#0 memRbtreeNext (pCur=0x835ed88, pRes=0x835c6a0) at src/btree_rb.c:1052
#1 0x41284d8e in sqliteVdbeExec (p=0x82f81d0) at src/vdbe.c:4414
#2 0x41257c3c in sqliteExec (pParse=0xbffff020) at src/build.c:95
#3 0x4126c66f in yy_reduce (yypParser=0x82f81d0, yyruleno=5) at parse.y:77
#4 0x4126c272 in sqliteParser (yyp=0x82b9e50, yymajor=107, yyminor=
{z = 0x835c6a0 " ü1\belations.origin may not be NULL", dyn = 0, n = 546637480},
pParse=0x4e206562) at parse.c:7017
#5 0x412771e9 in sqliteRunParser (pParse=0xbffff020,
zSql=0x8193fb4 "SELECT sid, weight FROM 'Recent' WHERE time < '1066861751';", pzErrMsg=0x81920ac)
at src/tokenize.c:452
#6 0x4126746a in sqliteMain (db=0x81961f8,
zSql=0x8193fb4 "SELECT sid, weight FROM 'Recent' WHERE time < '1066861751';",
xCallback=0x4e206562, pArg=0x4e206562, pzTail=0x0, ppVm=0x0, pzErrMsg=0x81920ac) at src/main.c:630
#7 0x412665ed in sqlite_exec (db=0x4e206562, zSql=0x4e206562 <Address 0x4e206562 out of bounds>,
xCallback=0x4e206562, pArg=0x4e206562, pzErrMsg=0x4e206562) at src/main.c:680
#8 0x4118b143 in SqlDb::select_query(std::string const&, int (SqlDb::*)(int, char**)) (
this=0x81920a0, query=@0xbffff160, callback=
{__pfn = 0x4118672e <ImmsDb::expire_recent_callback_1(int, char**)>, __delta = 0})
at sqldb.cc:91
Not sure what is happening here.
I am hoping that maybe you can give me some insight into what could be causing this.
The only guess that I have is that it could be caused by the way I use callbacks. I do something like:
"SELECT uid FROM <table1> WHERE <stuff>;"
and then inside the callback, I do a
"DELETE FROM <table1> WHERE uid = '<the uid that i get as a parameter>';"
In essence removing the element for which the callback is currently in progress (of course there's other processing happening as well... otherwise I could just do a delete in the first place). Is this not an acceptable practice?
Output of 'backtrace full' is available upon request. |
|
481 |
code
|
fixed
|
2003 Oct
|
anonymous
|
VDBE
|
2004 Feb
|
|
1
|
3
|
last_insert_rowid doesn't work within triggers any more
|
edit |
The fix of ticket 290 has introduced a behaviour which is, in my view,
buggy (whereas the behaviour described in ticket 290 was simply unexpected, but logical).
I use views and triggers to simulate inheritance, with an "Header" table for the parent class, and a number of other tables for the daughter classes. I have made "instead of" triggers for inserting into
views which present the whole object. These triggers use last_insert_rowid to link the "parent" part of the object and the "daughter" part.
A simplified example of what doesn't work :
With the following code :
create table test1 (oid integer primary key);
create table count (oid integer primary key, cp integer);
create view v as select * from test1;
create trigger i instead of insert on v
for each row
begin
insert into test1 values (NEW.oid);
insert into count values (NULL, last_insert_rowid());
end;
insert into v values (5);
sqlite> select * from test1;
5
sqlite> select * from count;
1|0
The value of cp is "0", while we were expecting "5".
Regards,
S. Rosmorduc |
|
480 |
code
|
fixed
|
2003 Oct
|
anonymous
|
CodeGen
|
2005 Sep
|
|
3
|
5
|
Joins with more than 32 tables are broken
|
edit |
When a query joins more than 32 queries and has a WHERE clause that refers to elements of more than 32 tables or table aliases the query returns no rows.
The TCL script below can be used to reproduce the problem.
sqlite db :memory:
# With (N == 32) the query works, with (N == 33) it is broken.
# set N 32
set N 33
# Create N tables with one row of data each
for {set ii 0} {$ii < $N} {incr ii} {
db eval "CREATE TABLE t$ii (k, v);"
db eval "INSERT INTO t$ii VALUES (1, 'val $ii');"
}
# Build a query of the form:
#
# SELECT * FROM t1, t2 .... tN WHERE
# t1.k = t2.k AND t2.k = t3.k AND ... AND t[N-1].k = tN.k;
#
set q "SELECT * FROM t0 \n"
for {set ii 1} {$ii < $N} {incr ii} {
append q ", t$ii"
append where "t$ii.k = t[expr $ii-1].k"
if {$ii != $N-1} {
append where " AND "
}
}
append q " WHERE "
append q $where
# Execute the query. It should return one row.
db eval "$q" ar {
set row {}
foreach k $ar(*) {
lappend row $ar($k)
}
puts $row
}
|
The problem is in where.c. For a query of the type described above with more than 32 tables to be joined the codegen layer generates code like this:
LOOP through t1
LOOP through t2
IF( t1.k == t2.k )
LOOP through t2
IF( t2.k == t3.k )
...
IF( t32.k == t33.k ) #should be inside the next loop
LOOP through t33
<do callback>
END LOOP
END IF
...
END IF
END LOOP
END IF
END LOOP
END LOOP
This is due to a 32-bit mask being used to track the dependencies between WHERE expressions and table scans. |
|
469 |
code
|
fixed
|
2003 Oct
|
anonymous
|
Unknown
|
2005 Jan
|
|
4
|
3
|
Qualified column name in subselect not recognized in outer select
|
edit |
"select s.sname from (select s.sname from s)" gives a "no such column" error. If the column name is not qualified (sname) or is aliased (sname x), everything is OK. Also note that "select * from (select s.sname from s)" produces the correct column name, s.sname. |
|
468 |
code
|
fixed
|
2003 Oct
|
anonymous
|
|
2003 Oct
|
|
2
|
2
|
DROP TRIGGER w/ single quotes doesn't work.
|
edit |
I think I may have found a bug in the drop trigger command. I tried to drop a trigger with single quotes around the name in case it was a key word and it errors even though it doesn't error when creating the trigger.
SQLite version 2.8.6
Enter ".help" for instructions
sqlite> create table t (a,b,c);
sqlite> create trigger 'trig' after insert on t begin update t set c=5; end;
sqlite> insert into t values (1,2,3);
sqlite> select * from t;
1|2|5
sqlite> drop trigger 'trig';
SQL error: no such trigger: trig
sqlite> .schema t
create table t (a,b,c);
create trigger 'trig' after insert on t begin update t set c=5; end;
sqlite> drop trigger 'trig';
SQL error: no such trigger: trig
|
|
461 |
code
|
fixed
|
2003 Sep
|
anonymous
|
CodeGen
|
2003 Sep
|
|
3
|
3
|
Nulls are incorrectly returned on an indexed column
|
edit |
Sqlite behaves differently with nulls depending on whether you have an index or not. Without indices, nulls are handled correctly, but with indices, they are not. I noticed the problem when doing a join, but here is a simpler example provided by DRH on the sqlite message group.
>CREATE TABLE t(x,y);
>INSERT INTO t VALUES(1,11);
>INSERT INTO t VALUES(2,NULL);
>SELECT x FROM t WHERE y=NULL;
>The above (without an index) correctly returns an empty set.
>But if you add an index:
>CREATE INDEX i1 ON t(y);
>SELECT x FROM t WHERE y=NULL;
>In this case, you get a result of "2". Which, if I understand
>NULLs correctly, is wrong.
|
|
460 |
new
|
fixed
|
2003 Sep
|
anonymous
|
VDBE
|
2003 Nov
|
|
5
|
5
|
[Patch] extending copy command for dump file of PostgerSQL pg_dump.
|
edit |
Patch file is here |
--- vdbe.c.orig Sun Sep 7 07:18:08 2003
+++ vdbe.c Wed Sep 24 15:43:37 2003
@@ -4092,6 +4092,29 @@
while( (c = p->zLine[n])!=0 ){
if( c=='\\' ){
if( p->zLine[n+1]==0 ) break;
+ else {
+ /* for using file of pg_dump by iosephATuriDOTsarangDOTnet */
+ switch(p->zLine[n+1]){
+ case 'b':
+ p->zLine[n+1] = '\b';
+ break;
+ case 'f':
+ p->zLine[n+1] = '\f';
+ break;
+ case 'n':
+ p->zLine[n+1] = '\n';
+ break;
+ case 'r':
+ p->zLine[n+1] = '\r';
+ break;
+ case 't':
+ p->zLine[n+1] = '\t';
+ break;
+ case 'v':
+ p->zLine[n+1] = '\v';
+ break;
+ }
+ }
n += 2;
}else if( c=='\n' ){
p->zLine[n] = 0;
|
|
459 |
new
|
fixed
|
2003 Sep
|
xdong
|
Unknown
|
2003 Sep
|
xdong
|
5
|
5
|
adding releasemode option to allow libtool link release
|
edit |
when you compile the sqlite by using the autoconf tools, it only produce the version control binary: libsqlite.so libsqlite.so.0 and libsqlite.so.0.0.0, and it will not work if you just want to using libsqlite.so alone. In certain case, like you jar the .so binary file and ship it with your product, you may want a stand-alone worked binary file. libtool do have an option "-release VERSION". so sqlite autoconfg should allow build to generate libsqlite-2.8.6.so instead of libsqlite.so.0.0.0 as an option. The default setting will keep sam.e |
used as:
./configure --enable-releasemode=yes |
|
458 |
new
|
fixed
|
2003 Sep
|
xdong
|
Unknown
|
2003 Sep
|
xdong
|
5
|
5
|
configure file and libtool doesnot work for cross compiling
|
edit |
This is the auto-config problem occured at cross-compile SQLite to xscale or arm target with certain tool-chain. a related work-around can be find at http://www.kecher.de/howtos/SQLite-JDBC-Howto.html
The fix will submot a modified configure file with a latest version of libtool. |
|
453 |
code
|
fixed
|
2003 Sep
|
anonymous
|
Parser
|
2003 Sep
|
|
3
|
3
|
"SELECT a, b FROM tt;-" Crashes SQLite
|
edit |
GPF on "SELECT a, b FROM tt;-"
** $Id: tokenize.c,v 1.60 2003/05/04 18:30:59 drh Exp $
ln 230:
case '-': {
if( z[1]==0 ) return -1;
if( z[1]=='-' ){
ln 430:
pParse->sLastToken.n = sqliteGetToken((unsigned char*)&zSql[i], &tokenType);
i += pParse->sLastToken.n;
** @(#) $Id: sqliteInt.h,v 1.196 2003/08/09 21:32:28 drh Exp $
ln 547:
struct Token {
const char *z; /* Text of the token. Not NULL-terminated! */
unsigned dyn : 1; /* True for malloced memory, false for static */
unsigned n : 31; /* Number of characters in this token */
};
---------------------------------
Error: unsigned n = -1
---------------------------------
My solution (not good):
/*
** Return the length of the token that begins at z[0]. Return
** 1 if the token is (or might be) incomplete. Store the token
** type in *tokenType before returning.
*/
static int sqliteGetToken(const unsigned char *z, int *tokenType){
int i;
+ *tokenType = TK_ILLEGAL;
switch( *z ){
case ' ': case '\t': case '\n': case '\f': case '\r': {
for(i=1; isspace(z[i]); i++){}
*tokenType = TK_SPACE;
return i;
}
case '-': {
- if( z[1]==0 ) return -1;
+ if( z[1]==0 ) return 1;
Now, i have errmsg: 'unrecognized token: "-"' |
|
452 |
code
|
fixed
|
2003 Sep
|
anonymous
|
TclLib
|
2003 Dec
|
|
4
|
3
|
DbMain assumes sscanf likes 0x... syntax for pointers, breaking tests
|
edit |
DbMain in src/tclsqlite.c ensures that its result always starts with 0x, which is a problem on some systems (such as Solaris) that treat everything from the x on as garbage and parse the pointer as NULL. As a result, certain tests (starting with capi2-1.1) end up segfaulting.
I ended up simply #if-ing out the relevant three lines, but a better fix would be to adopt something like the logic in makePointerStr in src/test1.c; I'd even suggest giving libtclsqlite a public C interface containing at minimum a sane pointer->string converter (and its inverse?), since I see several more hardcoded occurrences of "0x", some of which are doubly nonportable by using "%x" as the format directive and assuming that casting from pointers to ints loses no information. |
|
447 |
event
|
fixed
|
2003 Sep
|
anonymous
|
|
2003 Sep
|
|
3
|
1
|
Problems compiling on FreeBSD 4.8-STABLE
|
edit |
The generic Makefile won't too well seeing as it's not a Linux system.
bash-2.05a$ make
make: Permission denied
I can't really figure out why it says that. |
I figured it out by pure fluke :)
Use: gmake |
|
444 |
code
|
fixed
|
2003 Sep
|
anonymous
|
Shell
|
2003 Dec
|
|
3
|
4
|
free (zErrMsg) in shell.c should be sqlite_freemem(zErrMsg)
|
edit |
According to documentation on sqlite_exec:
The calling function is responsible for freeing the memory that holds the error message. Use sqlite_freemem() for this.
By the way, the reason free() does not work in Win32 if SqlLite is a DLL is:
The DLL obtains new memory calling its own implementation of "malloc" returning that pointer.
Thus, if the application which loaded the DLL calls free on that pointer, it is calling its own implementation of "free" in which, for sure, that pointer does not exist. Therefore => crash!! |
|
439 |
code
|
fixed
|
2003 Aug
|
anonymous
|
Unknown
|
2005 Jan
|
|
2
|
3
|
Query fails when run as a View
|
edit |
I have created the Microsoft Northwind sample database as a SQLite database. It has Customers, Orders and Order Details tables.
When I run the query below, it works fine. When I try to create a View with the same query, it succeeds. But when I try to select * from the View, I get the error "no such column: 'Order Details'.ProductID". The database is available at www.eztools-software.com/downloads/northwind.zip
SELECT Customers.CustomerID, Customers.CompanyName, Orders.OrderID,
'Order Details'.ProductID, 'Order Details'.Quantity
FROM Customers
INNER JOIN Orders ON Customers.CustomerID = Orders.CustomerID
INNER JOIN 'Order Details' ON Orders.OrderID = 'Order Details'.OrderID
|
2005-Jan-18 17:25:57 by drh:
Unable to reproduce - the northwind.zip database contains a
schema that does not match the query above.
This problem was likely fixed by recent check-ins [2230]
, [2231]
,
and [2232]
. |
|
435 |
code
|
fixed
|
2003 Aug
|
anonymous
|
Unknown
|
2003 Aug
|
|
3
|
3
|
backslash in Makefile hides clean target
|
edit |
at the end of the install target in the Makefile, there is an extra backslash, which continues the line, so that the clean target is not recognized. I am using HPUX 10.20 (yeah, I know its old) |
|
434 |
code
|
fixed
|
2003 Aug
|
anonymous
|
|
2003 Aug
|
|
3
|
3
|
vacuum-3.1 test fails on Win2k needs db2 close
|
edit |
When running 'make test' on Win2k with mingw/msys the test vacuum-3.1 fails with an error "cannot delete file, permission denied." This seems to be because the file is still open. I added a line to vacuum-3.1
db2 close
It seems to fix the problem, and 'make test' reports 0 errors.
do_test vacuum-3.1 {
db close
db2 close
file delete test.db
sqlite db test.db
execsql {
PRAGMA empty_result_callbacks=on;
VACUUM;
}
} {}
|
|
433 |
new
|
fixed
|
2003 Aug
|
anonymous
|
Unknown
|
2003 Dec
|
dougcurrie
|
3
|
2
|
configure needs updating for mingw/msys
|
edit |
configure produces a Makefile that is almost usable by mingw/msys on Windows. There are just two problems.
One is that it ignores the setting of EXEEXT and uses CYGWIN instead (which isn't set for msys). So this:
if test "$CYGWIN" = "yes"; then
BUILD_EXEEXT=.exe
else
BUILD_EXEEXT=""
should say:
if test "$CYGWIN" = "yes"; then
BUILD_EXEEXT=.exe
else
BUILD_EXEEXT=$EXEEXT
(I dunno why the present script uses CYGWIN for this at all since EXEEXT is there to use for this purpose; perhaps it's a legacy.)
Second, the tcl library that ships with mingw/msys is called tcl84 so this:
AC_SEARCH_LIBS(Tcl_Init, dnl
tcl8.4 tcl8.3 tcl8.2 tcl8.1 tcl8.0 tcl80 tcl,,,$otherlibs)
should say:
AC_SEARCH_LIBS(Tcl_Init, dnl
tcl8.4 tcl8.3 tcl84 tcl83 tcl,,,$otherlibs)
in configure.ac , or this:
for ac_lib in tcl8.4 tcl8.3 tcl84 tcl83 tcl; do
in configure.
I guess the right thing to do is edit configure.ac and regenerate configure, but I do not run autoconf and friends, so I've just been editing configure directly. |
I found a couple of other problems with the Makefile produced by configure on mingw/msys.
First, the shell is built without readline support since mingw has the readline libraries and headers under the /mingw directory which is not searched. This can be corrected by adding /mingw to the list of directories to search in configure.ac at line 497.
Second, 'make clean' does not delete lemon.exe which cause future makes to fail since lempar.c is not copied. This is corrected by changing Makefile.in to use the BUILD_EXEEXT and TARGET_EXEEXT macros to generate the correct target filenames in the Makefile produced by configure.
I have attached a set of diff files that can be used to patch the distributed configure.ac and Makefile.in file to correct these problems (as well as the problems noted in the original ticket).Since I don't have autoconf etc. installed, I have manually modified the configure file. I have also attached a diff file that can be used to patch the distributed configure file.
The Makefile.in.diff patch also adds a couple of new targets to the Makefile; dll and implib. 'make dll' will produce a windows dll file, and 'make implib' will make a dll import library for the Borland C++ compiler and the Microsoft VC compiler. The later won't work if you don't have the Borland or Microsoft programs on your path, but the make will succeed since the errors are ignored.
Making the windows dll requires a sqlite.def file. I have also attached a def file produced by copying the appropriate section from the distributed publish.sh script.
I hope this helps someone else. |
|
432 |
code
|
fixed
|
2003 Aug
|
drh
|
|
2003 Aug
|
|
3
|
3
|
Returns "Disk I/O Error" when the filename is an empty string
|
edit |
The shell command
sqlite ''
Gives an error as follows:
Unable to open database "": disk I/O error
The error of using an empty string as the database name should be
caught sooner and a better error message should be returned. |
|
430 |
code
|
fixed
|
2003 Aug
|
drh
|
|
2003 Aug
|
|
1
|
1
|
Dropping a trigger with the same name as a table corrupts the database
|
edit |
The following sequence of commands results in a corrupt database:
create table t1(x unique);
create trigger t1 before delete on t1 begin
select raise(abort,'cannot delete');
end;
drop table t1;
Dropping a trigger that has the same name as a table also removes
the table entry from the SQLITE_MASTER table. But it does not
actually drop the table. The table just becomes inaccessible.
After the above commands, nn assertion failure occurs if the
next command is executed:
pragma integrity_check;
|
|
429 |
code
|
fixed
|
2003 Aug
|
anonymous
|
|
2003 Aug
|
|
1
|
2
|
os.h cygwin compilation patch
|
edit |
Hi,
I needed the attached patch on cygwin perl 5.8.0/cygwin-multi-64int
to compile SQLite correctly. This holds true for perl DBD-SQLite-0.25,
DBD-SQLite-0.26 and the current sqlite cvs version.
gcc -c -I/usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/auto/DBI -DPERL_USE_SAFE_PUTENV
-fno-strict-aliasing -DUSEIMPORTLIB -O6 -DNDEBUG=1
-DSQLITE_PTR_SZ=4 -DVERSION=\"0.25\" -DXS_VERSION=\"0.25\"
"-I/usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE" os.c
In file included from /usr/include/sys/types.h:363,
from /usr/include/stdio.h:46,
from vdbe.h:22,
from sqliteInt.h:19,
from os.c:18:
/usr/include/cygwin/types.h:39: conflicting types for `off_t'
os.h:123: previous declaration of `off_t'
os.c:813: conflicting types for `sqliteOsSeek'
os.h:159: previous declaration of `sqliteOsSeek'
os.c: In function `sqliteOsSeek':
os.c:821: warning: right shift count >= width of type
os.c: At top level:
os.c:892: conflicting types for `sqliteOsTruncate'
os.h:161: previous declaration of `sqliteOsTruncate'
os.c: In function `sqliteOsTruncate':
os.c:899: warning: right shift count >= width of type
os.c: At top level:
os.c:921: conflicting types for `sqliteOsFileSize'
os.h:162: previous declaration of `sqliteOsFileSize'
os.c: In function `sqliteOsFileSize':
os.c:935: warning: left shift count >= width of type
make: *** [os.o] Error 1
/usr/include/cygwin/types.h:
#ifndef __off_t_defined
#define __off_t_defined
typedef long __off32_t;
typedef long long __off64_t;
#ifdef __CYGWIN_USE_BIG_TYPES__
typedef __off64_t off_t;
#else
typedef __off32_t off_t;
#endif
#endif /*__off_t_defined*/
sqlite patch (apply with patch -p1 < ...)
--- DBD-SQLite-0.25/os.h.orig 2003-02-17 08:40:52.000000000 +0100
+++ DBD-SQLite-0.25/os.h 2003-07-25 14:40:09.000000000 +0200
@@ -109,6 +109,9 @@
#endif
#if OS_WIN
+# ifdef __CYGWIN__
+# define __CYGWIN_USE_BIG_TYPES__
+# endif
#include <windows.h>
#include <winbase.h>
typedef struct OsFile OsFile;
@@ -119,8 +122,10 @@
# if defined(_MSC_VER) || defined(__BORLANDC__)
typedef __int64 off_t;
# else
+# ifndef _CYGWIN_TYPES_H
typedef long long off_t;
# endif
+# endif
# define SQLITE_TEMPNAME_SIZE (MAX_PATH+50)
# define SQLITE_MIN_SLEEP_MS 1
#endif
|
|
427 |
code
|
fixed
|
2003 Aug
|
anonymous
|
Unknown
|
2003 Aug
|
|
2
|
2
|
access violation on vacuum with pragma empty_result_callbacks
|
edit |
Hello,
How are you today?
The subject of my mail is...a bug report with correction
(to be validate by you of course).
In summary, access violation occurs when vacuum command is run and
pragma empty_result_callbacks is on.
The problem is easily reproducable (just enter the pragma command and
then vacuum and it crashes) and comes from the fact that the callback
is always called once due to the pragma.
When the callback is called, the third argument (argv) is null (as
defined in the documentation).
Oups! we found the problem => callback functions used in the vacuum
code don't take this possibility into account.
Here is the code (where I've already corrected the problems, just see the comments)
sqliteVacuum
...
rc = sqlite_exec(db, "SELECT type, name, sql FROM sqlite_master "
"WHERE sql NOT NULL", vacuumCallback1, &sVac, &zErrMsg);
=> if there is no database created then vacuumCallback1 will be called with argv = 0
static int vacuumCallback1(void *pArg, int argc, char **argv, char
**NotUsed) {
vacuumStruct *p = (vacuumStruct*)pArg;
/* int rc = 0; use #define instead */
int rc = SQLITE_OK;
assert( argc==3 ); /* true */
/* assert( argv[0]!=0 ); not true if empty_result_callbacks is ON *
* assert( argv[1]!=0 ); not true if empty_result_callbacks is ON *
* assert( argv[2]!=0 ); not true if empty_result_callbacks is ON */
if (argv == 0) /* take into account empty_result_callbacks */
return rc;
rc = execsql(p->pParse, p->dbNew, argv[2]);
if( rc==SQLITE_OK && strcmp(argv[0],"table")==0 ){
char *zErrMsg = 0;
p->s1.nUsed = 0;
appendText(&p->s1, "SELECT * FROM ", -1);
appendQuoted(&p->s1, argv[1]);
p->zTable = argv[1];
rc = sqlite_exec(p->dbOld, p->s1.z, vacuumCallback2, p, &zErrMsg);
if( rc && p->pParse->zErrMsg==0 ){
sqliteErrorMsg(p->pParse, "%s", zErrMsg);
}
}
return rc;
}
=> if there is at least one database created but with no row then
vacuumCallback2 is called...with argv = 0
static int vacuumCallback2(void *pArg, int argc, char **argv, char
**NotUsed) {
vacuumStruct *p = (vacuumStruct*)pArg;
/* int rc = 0; use #define instead */
int rc = SQLITE_OK;
const char *zSep = "(";
int i;
if (argv == 0) /* take into account empty_result_callbacks */
return rc;
=> and finally, when the temporary database is initialised, it receives also argv = 0
static
int sqliteInitCallback(void *pInit, int argc, char **argv, char
**azColName) {
InitData *pData = (InitData*)pInit;
Parse sParse;
int nErr = 0;
if (argv == 0) /* take into account empty_result_callbacks */
return nErr;
assert( argc==5 );
...
I've not tried to enter the vacuumCallback3 but I think it's the same problem.
So, may I ask you to have a look to the solution to implement.
I've done some changes in the code but I'm not sure if it's really correct.
Moreover, the other simpler solution would be to force the pragma
empty_result_callback to OFF at start of sqliteVacuum and reset it to
the previous value at the end of the function.
Enjoy :)
Dobedo
Waremme/Belgium
|
Apparently, I've discovered another access violation when exiting the application. I've not yet pointed out the faulty instruction.
Come to you soon. |
|
421 |
code
|
fixed
|
2003 Aug
|
anonymous
|
|
2003 Aug
|
|
3
|
3
|
bug on sqliteRealloc_
|
edit |
The variable p can be used before being initialized (but only on memory corruption).
The code to change is at line 163, file 'util.c':
150 void *sqliteRealloc_(void *oldP, int n, char *zFile, int line){
151 int *oldPi, *pi, i, k, oldN, oldK;
152 void *p;
153 if( oldP==0 ){
154 return sqliteMalloc_(n,1,zFile,line);
155 }
156 if( n==0 ){
157 sqliteFree_(oldP,zFile,line);
158 return 0;
159 }
160 oldPi = oldP;
161 oldPi -= N_GUARD+1;
162 if( oldPi[0]!=0xdead1122 ){
163*** fprintf(stderr,"Low-end memory corruption in realloc at 0x%x\n", (int)p); ***
164 return 0;
165 }
Probably a copy/paste error made on CheckIn 1067. |
|
419 |
new
|
fixed
|
2003 Jul
|
anonymous
|
|
2003 Aug
|
|
4
|
3
|
Return index name with 'uniqueness constraint failed' error message
|
edit |
I am proposing the following (simple) code changes to display the unique index name as part of the uniqueness constraint failed error message.
My proposal consists of the following code changes to insert.c:
Replace Line 820 and 821 (currently):
sqliteVdbeAddOp(v, OP_Halt, SQLITE_CONSTRAINT, onError);
sqliteVdbeChangeP3(v, -1, "uniqueness constraint failed", P3_STATIC);
be replaced with:
char *zMsg = 0;
sqliteVdbeAddOp(v, OP_Halt, SQLITE_CONSTRAINT, onError);
sqliteSetString(&zMsg, pIdx->zName, " uniqueness constraint failed", 0);
sqliteVdbeChangeP3(v, -1, zMsg, P3_DYNAMIC); |
|
416 |
code
|
fixed
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
|
1
|
1
|
An SQL DML which yields a segfault
|
edit |
1. Create the following objects:
CREATE TABLE Oid(high INTEGER,lastLow INTEGER);
INSERT INTO Oid values(0,0);
CREATE TABLE Object(id INTEGER PRIMARY KEY,type INTEGER);
CREATE TABLE Occurence(id INTEGER PRIMARY KEY, topic INTEGER, type INTEGER, ref INTEGER, value);
CREATE TABLE Relation (id INTEGER, role INTEGER, member INTEGER);
CREATE TABLE Scope(id INTEGER, topic INTEGER, member INTEGER);
CREATE VIEW Instance AS
SELECT r1.member AS instance, r2.member AS class
FROM Relation r1, Relation r2
WHERE r1.role = 110
AND r2.role = 109
AND r1.id = r2.id
;
CREATE VIEW Axis AS
SELECT r1.member AS topic, r2.member AS axi
FROM Relation r1, Relation r2, Instance i
WHERE r1.role = 1
AND r2.role = 105
AND i.class = 103
AND r1.id = r2.id
AND r1.id = i.instance
;
2. This query yields a segmentation fault:
SELECT * from Axis; |
Here is a much simpler way to generate the problem:
CREATE TABLE x(a,b);
CREATE VIEW y AS
SELECT x1.b AS p, x2.b AS q FROM x AS x1, x AS x2 WHERE x1.a=x2.a;
CREATE VIEW z AS
SELECT y1.p, y2.p FROM y AS y1, y AS y2 WHERE y1.q=y2.q;
SELECT * from z;
|
|
410 |
code
|
fixed
|
2003 Jul
|
anonymous
|
Pager
|
2003 Jul
|
|
3
|
4
|
Creation and deltions of files should fsync() directory
|
edit |
Hello,
re my post and drh's response both on 25/07/03 entitled "Deletion and recreation of journal files - database corruption"
fsync is performed on both the main file and journal file, but whenever a journal file is created or destroyed and whenever a main file is created the directory also needs to be synched to ensure data integrity. If the fsync is not done then, for example, a journal file required to recover a database could be lost when the machine recovers after a power failure. This would result in a corrupt database, and I belive this is the source of some database corruption I've seen on a Sun machine running Solaris 8 with SCSI disks and a journalling filesystem.
I suspect the directory sync will have to be executed no more often than twice per commit, and by avoiding deletion of the journal (truncate instead) sqlite might further reduce the impact of syncing the directory as it would not have changed. According to the fsync man page on linux the access time and other stat metadata is saved along with the file on fsync. It's just the directory entry which places the file in a particular location that doesn't get written, and that's how the journal file can get lost.
I don't know how this affects platforms that do not use fsync.
I noticed this problem in a scenareo where I've got transactions each of one-second duration that (almost) immediately restart whenever they commit, so it may even be possible in my case the the filesystem recovery mechanism pulled in an old journal file long since deleted if it's commit period is much longer than a second.
Benjamin. |
A call is now made to fsync() for the directory that contains the
journal filename after the journal is created. gdb was used to
confirm that the fsync() is being called and is returning successfully. |
|
408 |
code
|
fixed
|
2003 Jul
|
anonymous
|
VDBE
|
2003 Jul
|
|
1
|
1
|
toInt() reports success on overflow, causes comparisons to fail
|
edit |
The comparison operators, and maybe other things in the VDBE, use the static function toInt to convert stack entries to integers, and to determine if the entries are integers. toInt reports success for numbers that overflow an int, but would fit in a double. This causes queries to return incorrect results. For example:
create table DMData (time);
insert into DMData values (1058989418890);
insert into DMData values (1);
insert into DMData values (1050);
SELECT * FROM DMData WHERE time > 0;
1
1050
SELECT * FROM DMData WHERE time < 0;
1058989418890
In addition to fixing (or instead of using) toInt, perhaps the implementations of the comparison operators should use a conversion to double similar to what is done in OP_Add. |
|
406 |
code
|
fixed
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
|
1
|
1
|
BEGIN ON CONFLICT ROLLBACK
|
edit |
The sequence below will raise an access violation (at least on windows).
It was executed using the sqlite_get_table() interface.
PRAGMA empty_result_callbacks = ON;
BEGIN ON CONFLICT ROLLBACK;
CREATE TABLE tabx ( a INTEGER PRIMARY KEY, b, c, d );
INSERT INTO tabx VALUES ( NULL, 2, 3, 4 );
INSERT INTO tabx VALUES ( NULL, 2, 3, 4 );
INSERT INTO tabx VALUES ( NULL, 2, 3, 4 );
SELECT * FROM tabx;
-- Force rollback
INSERT INTO tabx VALUES ( 1, 2, 3, 4 )
/*
* ACCESS VIOLATION with any querie I tried
*/
SELECT * FROM sqlite_master;
This program was linked with the sqlite.dll (v2.8.5) on the downloads page with the same results (access violation), but I think this will also happen with previous versions.
The access violation is on file 'MAIN.C', line 61, function 'sqliteInitCallback' (see comment):
55: int sqliteInitCallback(void *pInit, int argc, char **argv, char **azColName){
56: InitData *pData = (InitData*)pInit;
57: Parse sParse;
58: int nErr = 0;
59:
60: assert( argc==5 );
61: if( argv[0]==0 ){ //**ACCESS VIOLATION****** argv is a NULL pointer
62: corruptSchema(pData);
63: return 1;
64: }
------------
|
I didn't emphasize that the cause is the "PRAGMA empty_result_callbacks = ON;" SQL query. It works as expected if this is off.
The title is misleading. This problem has nothing to do with
the BEGIN ON CONFLICT ROLLBACK. The trouble was that the internal
SQLite callback that handled reading the schema out of SQLITE_MASTER
could not handle a null argv value that appeared when
EMPTY_RESULT_CALLBACKS was turned on. |
|
405 |
todo
|
fixed
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
|
1
|
1
|
Missing complete unix source tarballs
|
edit |
A compelete, unix tarball is not present on the downloads page. I have a sqlite-2.8.0.tar.gz on my machine, so I know that it used to exist. Please make one available. I'm running MacOSX, so the RPMs can't be used. Thanks! |
|
401 |
code
|
fixed
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
|
2
|
3
|
Source downloads considered useless..
|
edit |
I'm an OSX user, and have previously downloaded source tarballs for sqlite 2.8.0. I'd like to be able to download 2.8.4, but you don't offer a source tarball, just a useless zip file and several rpms. Please consider packaging the source tarball again.
I'll use the cvs checkout in the meantime... |
|
400 |
code
|
fixed
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
|
3
|
4
|
shell.c, when readline() not avail, getline() conflicts with stdio's
|
edit |
I need to undefine READLINE_FLAGS in my makefile, because my system does not have readline(). This results in the following compilation error:
../src/shell.c:94: conflicting types for `getline'
<my development env directory>/include/stdio.h:435: previous declaration of `getline'
In sqlite/src/shell.c, a locally declared getline() routine is substituted for readline(). On my particular system, this causes a conflict (as seen above) with stdio.h. My solution was to simply replace all occurences of "getline" with something else like "mygetline" in this file. Not sure if others are likely to encounter this. I am compiling for ARM. But this fix will not affect systems that are currently working.
Buzz
buzzweetman@hotmail.com |
|
397 |
code
|
fixed
|
2003 Jul
|
anonymous
|
Unknown
|
2003 Jul
|
|
4
|
3
|
tests attach-5.1 and attach2-1.1 fail on w2k mingw
|
edit |
Building from CVS 17-Jul-2003 (version 2.8.4+) the 'make test' fails; this is on Win2k with Mingw.
Two edits to the tests remedy the problem.
In attach-5.1 add the line
db2 close
after the line
db close
otherwise the file delete of test2.db fails.
After attach2-1.1 add
do_test attach2-1.2 {
catchsql {
DETACH t2;
}
} {0 {}}
otherwise the file delete of test2.db fails.
-- e |
|
396 |
code
|
fixed
|
2003 Jul
|
anonymous
|
Unknown
|
2003 Jul
|
|
3
|
2
|
AGGREGATE FUNCTION WITH LIMIT
|
edit |
SELECT MAX(FIELD) FROM TABLE LIMIT 0,100
Hang SQLITE. |
This works when I try it. No database hang. If this is
still causing a problem, please provide full details and I
will look at it again.
Further correspondance with the discoverer of this problem
has enabled me to decode the cryptic error description above.
The following SQL results in an "illegal instruction" error
in the VDBE:
create table t(a integer primary key);
select max(a) from t limit 1;
|
|
394 |
code
|
fixed
|
2003 Jul
|
anonymous
|
Parser
|
2003 Jul
|
|
4
|
1
|
SELECT 1; syntax throw run-time compiler warning
|
edit |
SELECT 1 AS ItemID, 2 AS Item2ID; (no FROM clause) syntax works but throws a compiler run-time warning about the variable cont being used without being initialized (debug mode in MSVC7.1). It is defined on line 361 in sqliteWhereBegin() in where.c.
I am not sure if this syntax is intended to work with sqlite, but it is allowed in MS Sql Server, and presumably other database engines as well. I personally find it much cleaner than SELECT 1 AS ItemID, 2 AS Item2ID FROM sqlite_master LIMIT 1; or similar.
My proposal is to simply initialize this variable to 0 when defined to avoid receiving this run-time assertion.
Therefore where.c line 361 becomes:
int brk, cont = 0; /* Addresses used during code generation */
Kevin Alons |
In a SELECT with no WHERE clause, the "cont" variable is never
initialized. It is then copied into variable "brk" which is
never used. So this is not really a bug. But I'll initialize
the variable if that is what it takes to get MSVC to work. |
|
393 |
code
|
fixed
|
2003 Jul
|
anonymous
|
Unknown
|
2003 Jul
|
|
3
|
4
|
UNION and LIMIT incorrectly
|
edit |
I have two databases, both identical in structure;
main.db :-
create table dictionary (word);
insert into dictionary values ('steve');
user.db :-
create table dictionary (word);
insert into dictionary values ('dave');
I open the main database and attach the second;
attach "user.db" as user;
I then run a UNION query on both tables to see if a word exists in
either table;
select word from dictionary where word='steve'
union
select word from user.dictionary where word='steve' limit 1;
This produces 'steve'
Run it again but look for 'dave'
select word from dictionary where word='dave'
union
select word from user.dictionary where word='dave' limit 1;
This produces nothing........
Increase the limit to 2;
select word from dictionary where word='dave'
union
select word from user.dictionary where word='dave' limit 2;
And I get 'dave' |
|
387 |
code
|
fixed
|
2003 Jul
|
anonymous
|
Parser
|
2003 Jul
|
|
1
|
1
|
Parse has problems with parser names ...
|
edit |
SELECT TW_Method.primaryKey primaryKey,TW_Method.name name,TW_Method.timeStamp timeStamp,TW_Method.version version,TW_Method.userName userName,TW_Method.trace trace,TW_Method.className className,TW_Methods.packageRef packageRef,TW_Method.sourceCodeID sourceCodeID,TW_Method.protocolName protocolName,TW_Blob.blobData blobData,TW_Blob.blobType blobType FROM TW_Methods, TW_Method, TW_Blob WHERE TW_Methods.methodRef = TW_Method.primaryKey AND TW_Method.sourceCodeID = TW_Blob.primaryKey AND packageRef = 161 AND primaryKey NOT IN ( SELECT methodRef FROM TW_Methods WHERE packageRef = 159 ) : ambiguous column name: primaryKey
ambiguous column name: primaryKey
The parser has problems with the alias names ... |
No change.
It appears that Oracle, PostgreSQL, and SOLID all work the
same way. SQLite could be changed so that it would prefer a
name assigned by AS over a regular column name, but a survey
on the SQLite mailing list suggested that people do not want
this. They prefer the current behavior.
I will attach diffs against the expr.c source module that
could be used to give precedence to AS-clause names. |
|
385 |
new
|
fixed
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
|
4
|
4
|
NULL args for output variables to sqlite_step cause access violation
|
edit |
The three output arguments to the sqlite_step() function all cause an access violation if a NULL pointer is passed.
These arguments should be checked for NULL before updating the output variable (like the pzErrmsg argument to other sqlite functions). This will avoid the access violation exception, and would allow the caller to signal that they did not require that portion of the output.
This could be useful if the names have already been retrieved by the execution of another VM previously. Additional VMs could be passed NULL for the pazColnames argument and then sqlite_step would not have to build the column names array. I'm not sure how useful calling this function with a NULL value for the pN argumnet would be, but it should be allowed for consistancy (and to avoid the access violation). |
|
384 |
new
|
fixed
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
|
4
|
4
|
NULL argument for pzTail to sqlite_compile causes access violation
|
edit |
The third, pzTail argument to sqlite_compile can not be NULL. If it is, an access violation occurs.
The sqlite_compile function should check if this argument is NULL and not update the output variable if it is (in the same way as the pzErrmsg pointer is handled).
Many times the caller will be passing a single SQL statement, and does not need the tail of the statement (which is an empty string) set. This change would allow the caller to pass NULL for the third argument and avoid having to declare a dummy char pointer variable to pass to sqlite_compile(). |
|
383 |
code
|
fixed
|
2003 Jul
|
anonymous
|
Unknown
|
2003 Jul
|
|
1
|
3
|
sqlite_changes returns wrong value with non-callback API
|
edit |
The actual values returned by sqlite_changes() do not agree with the description in section 3.2 of the C/C++ API documentation at http://www.hwaci.com/sw/sqlite/c_interface.html when used with the non-callback API.
The docs say it will return the number of rows changed since the last sqlite_compile. It actually returns the number of rows changed by any unfinalized VM's and the last finalized VM.
I have attached a simple test program that demonstrates the problem. It simply executes two VMs that each insert a single row into a table. Running it with no arguments causes the first VM to be left un-finalized until the end. In the case the second call to sqlite_changes returns the incorrect value 2. Running it with any argument causes the first VM to be finalized before the second is executed. In this case the expected result is returned.
This bug causes a problem with Marco Wobben's SQLite dbExpress driver for Borlands Delphi and C++ environments. The Borland dbExpress libraries leave commands unfinalized while executing other commands, and at the same time check the number of rows affected by the commands. If the number of affected rows is more or less than expected, it throws an exception. |
Updated the documentation to be more explicit about exactly
what sqlite_changes returns.
I noticed that the revised documentation is not being distributed on the web site yet (as of 2003-07-15). Perhaps there something else you need to do to make this happen. |
|
378 |
doc
|
fixed
|
2003 Jul
|
anonymous
|
Shell
|
2003 Jul
|
|
5
|
4
|
sqlite command line utility still needs file name
|
edit |
According to the Wiki (InMemoryDatabase) the sqlite utility can now be given a file name of :memory: to create an in-memory db. That appears to work fine.
The same wiki page also indicates that if the sqlite utility is given no file name it defaults to creating an in-memory db. That does not appear to work as shown here:
~# sqlite
Usage: sqlite [OPTIONS] FILENAME [SQL]
Use the -help option for additional information
~# sqlite -version
2.8.4
~# myconfig
Linux 2.4.19; libc.so.6 2.2.5; gcc 2.95.3
|
I corrected the text on the Wiki page. |
|
377 |
code
|
fixed
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
|
1
|
3
|
Comparisons of integer primary key to float are erroneous
|
edit |
The integer-primary-key always compares < the float. This crops up in practice when you do something like
select * from tbl where key < (select avg(key) from tbl);
If avg(key) turns out to be a float, you get the whole table; if you change the comparison to >, you get nothing. (The behavior is the same with constants, but that's less likely in practice.) |
|
373 |
code
|
fixed
|
2003 Jul
|
anonymous
|
|
2003 Aug
|
|
1
|
2
|
2.8.4 Cygwin compile failure
|
edit |
Under W2k / Cygwin latest (www.cygwin.com) with gcc 3.2; 2.8.4 fails to compile. Error log says:
gcc -DOS_UNIX=0 -DOS_WIN=1 -DHAVE_USLEEP=1 -I. -I/usr/src/build/sqlite/sqlite-2.8.4/src -c -DTEMP_STORE=1 /usr/src/build/sqlite/sqlite-2.8.4/src/main.c -DDLL_EXPORT -DPIC -o .libs/main.lo
In file included from /usr/src/build/sqlite/sqlite-2.8.4/src/main.c:20:
/usr/src/build/sqlite/sqlite-2.8.4/src/os.h:91:1: warning: "OS_WIN" redefined
/usr/src/build/sqlite/sqlite-2.8.4/src/main.c:1:1: warning: this is the location of the previous definition
In file included from /usr/src/build/sqlite/sqlite-2.8.4/src/main.c:20:
/usr/src/build/sqlite/sqlite-2.8.4/src/os.h:156: parse error before "OsFile"
/u
Full log is in attachment
jari.aalto@poboxes.com |
Looks like configure is fooled.
In the makefile try:
TCC = gcc -g -O2 -DOS_UNIX=1 -DOS_WIN=0 -DHAVE_USLEEP=1 -I. -I${TOP}/src
Becuase windows cannot lock on files in os.c add:
#define fcntl(A,B,C) 0
You will still get three errors in 'make test'
bigfile-1.2...
Error: database disk image is malformed
copy-6.1...
Expected: [11 22 33 22 33 44 33 44 55 44 55 66 55 66 77 66 77 88]
Got: [11 22 33 22 33 44]
expr-6.75... Ok
skipping tests of GLOB operator: unknown encoding "iso8859-1"
3 errors out of 25586 tests
Failures on these tests: attach-5.1 bigfile-1.2 copy-6.1
but it runs. Just be aware there are no file locks, ie single user. |
|
370 |
code
|
fixed
|
2003 Jun
|
anonymous
|
|
2004 Feb
|
dougcurrie
|
2
|
3
|
make fulltest status on Cygwin, failure on 2 tests
|
edit |
'make fulltest' result:
[snip]
attach-5.1...
Error: error deleting "test2.db": permission denied
[...]
copy-6.1...
Expected: [11 22 33 22 33 44 33 44 55 44 55 66 55 66 77 66 77 88]
Got: [11 22 33 22 33 44]
[...]
2 errors out of 25972 tests
Failures on these tests: attach-5.1 copy-6.1
make: *** [fulltest] Error 1
NOTE: compiled with __CYGWIN_USE_BIG_TYPES__ (for off_t as 64 bit type). |
Re-running these tests using Cygwin and SQLite 2.8.11 confirms that all of these problems are fixed, except copy-6.1.
The issue with copy-6.1 is that Cygwin converts "\n" to "\r\n" when writing to text files. See: http://cygwin.com/faq/faq_4.html#SEC75
The result is that the file dataX.txt produced by the tcl test tile copy.tst looks like this:
Addr 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E
-------- ---- ---- ---- ---- ---- ---- ---- ---- ----------------
00000000 3131 7c32 327c 3333 0d32 327c 3333 7c34 11|22|33.22|33|4
00000010 340d 0d0a 3333 7c34 347c 3535 0d0a 3434 4...33|44|55..44
00000020 7c35 357c 3636 0d35 357c 3636 7c37 370d |55|66.55|66|77.
00000030 0d0a 3636 7c37 377c 3838 0d0a ..66|77|88..
So COPY interprets the "\r\r" as end of file.
Since this problem is not in SQLite itself, but rather in Cygwin/tcl I am considering this ticket closed.
Opening dataX.txt as
set f [open dataX.txt w]
fconfigure $f -translation binary
fixes this problem for Cygwin users; see attached diff (thanks, Ron). |
|
367 |
code
|
fixed
|
2003 Jun
|
anonymous
|
Unknown
|
2003 Jun
|
|
4
|
1
|
soundex bug
|
edit |
In func.c line 293:
sqlite_set_result_string(context, zResult, "?000", 4);
should be changed to:
sqlite_set_result_string(context, "?000", 4); |
|
365 |
code
|
fixed
|
2003 Jun
|
anonymous
|
VDBE
|
2003 Jun
|
|
3
|
4
|
Can not define SQLITE_OMIT_AUTHORIZATION
|
edit |
Problem: if one uncomments the
/*#define SQLITE_OMIT_AUTHORIZATION 1 */
in sqliteint.h then the library can not be built, generating errors
in some of the files (parser.c, delete.c and some others.) This is a bug in the definition of sqliteAuthCheck, very easy to address.
To fix it, change line 1183 of sqliteint.h from
# define sqliteAuthCheck(a,b,c,d) SQLITE_OK
to
# define sqliteAuthCheck(a,b,c,d,e) SQLITE_OK |
This appears to be a duplication of ticket #353 which has
already been fixed. |
|
364 |
code
|
fixed
|
2003 Jun
|
anonymous
|
|
2003 Jun
|
|
3
|
3
|
Assert when doing SELECT ROWID,* against a VIEW
|
edit |
When SELECTing a ROWID against a VIEW, the sqlite command-line utility asserts:
sqlite> CREATE VIEW v1 AS SELECT * FROM t1,t2 WHERE t1.a = t2.a;
sqlite> SELECT * FROM v1;
zzz|xxx|yyy|zzz|aaa|bbb
yyy|zzz|xxx|yyy|iii|jjj
sqlite> SELECT ROWID,* FROM v1;
./src/vdbe.c:4224: failed assertion `pC->pCursor!=0'
Abort
|
|
361 |
code
|
fixed
|
2003 Jun
|
anonymous
|
Unknown
|
2003 Jun
|
anonymous
|
3
|
3
|
main.c doesn't compile when SQLITE_OMIT_TRACE=1
|
edit |
There are some #ifdef missing in main.c. Also settings SQLITE_OMIT_AUTHORIZATION=1 causes some warnings about the number of arguments in sqliteAuthCheck. I think a parameter is missing in the sqliteAuthCheck definition in sqliteInt.h |
The SQLITE_OMIT_AUTHORIZATION error has already been reported
(see ticket #353) and fixed.
The SQLITE_OMIT_* macros are designed to remove extraneous features
in order to save code space. But SQLITE_OMIT_TRACE was not removing
very much code. So I have removed all SQLITE_OMIT_TRACE macros from
the code. Tracing is now always enabled. |
|
360 |
code
|
fixed
|
2003 Jun
|
anonymous
|
Unknown
|
2003 Jun
|
|
2
|
3
|
"not N between n and m" in trigger dumps core
|
edit |
create table foo (bar integer default 1 not null);
create trigger foo_insert before insert on foo for each row
begin select case when (not new.bar between 0 and 20)
then raise (rollback, 'aiieee') end; end;
insert into foo (bar) values (1);
|
|
357 |
code
|
fixed
|
2003 Jun
|
anonymous
|
Pager
|
2003 Aug
|
drh
|
4
|
3
|
Compilation errors and warnings when compiled on Open VMS
|
edit |
Problems in insert.c and func.c. One warning is an undefined variable
which may be meant to do something important. |
|
355 |
code
|
fixed
|
2003 Jun
|
anonymous
|
BTree
|
2003 Jun
|
|
4
|
3
|
Compile warning when NDEBUG is defined
|
edit |
In btree.c, allocateSpace() has an unused variable, "cnt", when NDEBUG is defined. |
|
354 |
code
|
fixed
|
2003 Jun
|
anonymous
|
Unknown
|
2003 Jul
|
|
3
|
2
|
ATTACH DATABASE call asserts in build.c in Debug Mode in MSVC7.1
|
edit |
From Version 2.8.3 to latest code, I get an ASSERT in build.c (line 1699: Expression: p == pIndex) when trying to attach a database using the following syntax:
ATTACH DATABASE 'c:\test.db' AS Attached;
If I use the debug version of the compiled dll (using MSVC) I get this error. I think the ASSERT is in error, because I can use the non-debug compiled dll with normal operation, and no side-effects. |
Even the simplest case demonstrates this behaviour for me.
I created c:\test.db with one table, using the following create statement:
CREATE TABLE Test (TestID INT PRIMARY KEY, TestString TEXT NULL);
INSERT INTO Test VALUES TestString, 'X');
I then ran the above ATTACH DATABASE statement (attaching the same db to itself), and the assertion is raised.
If I continue (ignoring the assertion), the table is attached normally and can be queried and DETACHED (with no assertion).
I get the ASSERT failure as described above. |
|
353 |
code
|
fixed
|
2003 Jun
|
anonymous
|
|
2003 Jun
|
|
4
|
3
|
Compile errors when SQLITE_OMIT_AUTHORIZATION is defined
|
edit |
When SQLITE_OMIT_AUTHORIZATION is turned on, the sqliteAuthCheck() stub macro only has 4 arguments, where the real function expects 5, causing compile errors. |
Also this flag causes a warning in trigger.c that sContext is unused because all the functions are stubbed out. Suggest this workaround:
# define sqliteAuthContextPop(a) ((void)(a))
|
|
352 |
code
|
fixed
|
2003 Jun
|
anonymous
|
Shell
|
2003 Jun
|
|
3
|
3
|
The sqlite shell ignores empty lines inside SQL strings
|
edit |
Problem:
Running the following SQL in the sqlite shell results in the empty lines disappearing:
create table foobar (x);
insert into foobar values ('This is a text with
several empty lines');
Brute force fix:
--- shell.c 19 May 2003 23:55:30 -0000 1.80
+++ shell.c 14 Jun 2003 13:13:14 -0000
@@ -1002,7 +1002,7 @@
seenInterrupt = 0;
}
if( p->echoOn ) printf("%s\n", zLine);
- if( _all_whitespace(zLine) ) continue;
+ /*if( _all_whitespace(zLine) ) continue;*/
if( zLine && zLine[0]=='.' && nSql==0 ){
int rc = do_meta_command(zLine, p);
free(zLine);
Proper fix:
Make the shell recognize when it is inside of a string which hasn't been terminated yet. |
|
351 |
code
|
fixed
|
2003 Jun
|
anonymous
|
Pager
|
2003 Jun
|
|
2
|
3
|
Journal pager playback doesn't secure exclusive access
|
edit |
The sqlitepager_get() routine opens the journal file using sqliteOsOpenReadWrite(), while the comment suggests it intends to gain exclusive access. The journal is then read and played back without obtaining exclusive access or even using a read lock. I think this could cause some very serious issues in certain conditions. |
The journal file is never open except when there is a write lock
(a.k.a an exclusive lock) on the main database file. So even though
the journal file itself is not locked, the database file is, which
prevents other threads and/or processes from accessing the the journal. |
|
350 |
code
|
fixed
|
2003 Jun
|
anonymous
|
Unknown
|
2003 Jun
|
|
2
|
3
|
LEFT JOIN works improperly on static inner queries and views
|
edit |
Lets say I have 2 tables, "Objects" and "Properties", that look like that (fictive crapy example so don't tell me my datamodel sucks hahaha!):
OBJECT_ID OBJECT_NAME
--------- -----------
1 Toto
2 Titi
3 Tutu
4 Tata
FOREING_OBJECT_ID PROPERTY_NAME PROPERTY_VALUE
----------------- ------------- --------------
1 TYPE MyClass
1 VALUE AnyValue
2 TYPE String
2 VALUE Testing
2 LENGTH 7
3 TYPE String
If I do the following SQL statament, I get the following result which is OK:
SELECT o.object_id, p.property_name, p.property_value
FROM objects AS o LEFT JOIN properties AS p
ON o.object_id = p.foreing_object_id;
OBJECT_ID PROPERTY_NAME PROPERTY_VALUE
--------- ------------- --------------
1 TYPE MyClass
1 VALUE AnyValue
2 TYPE String
2 VALUE Testing
2 LENGTH 7
3 TYPE String
4 <NULL> <NULL>
But if I do the following query, I get only the following results wich, from my point of view isn't good:
SELECT o.object_id, p.property_value
FROM objects AS o LEFT JOIN (SELECT * FROM properties WHERE property_name = 'VALUE') AS p
ON o.object_id = p.foreing_object_id;
OBJECT_ID PROPERTY_VALUE
--------- --------------
1 AnyValue
2 Testing
I would have expected to get:
OBJECT_ID PROPERTY_VALUE
--------- --------------
1 AnyValue
2 Testing
3 <NULL>
4 <NULL>
The same problem occurs if I create views out of my inner queries.
It seems to be the same problem as in #306 that should have been fixed by version 2.8.1 I believe. |
This problem is similar to #306 in that it results from the query
optimizer being overly aggressive in its attempts to optimize
LEFT OUTER JOINs. But the specific cause the problem is different. |
|
349 |
code
|
fixed
|
2003 Jun
|
anonymous
|
|
2003 Aug
|
|
3
|
2
|
Cygwin build errors
|
edit |
The build on cygwin fails.
1) The auto generated Makefile defines OS_UNIX=0, so the #ifndef on line 65 of os.h fails and the #else part on line 95 is the one processed.
Fix: Delete OS_UNIX=0 from the compiler options.
2) The cygwin system types already define off_t, but if __CYGWIN_USE_BIG_TYPES__ is not defined, off_t is a 32 bits offset.
Fix: Define __CYGWIN_USE_BIG_TYPES__ on the compiler options.
I don't know nothing of autoconf so I don't know how to fix this (but I belive it should be a quick fix). |
|
347 |
code
|
fixed
|
2003 Jun
|
anonymous
|
BTree
|
2003 Jun
|
|
4
|
3
|
Workaround for warning that print_node() in btree_rb.c is unused
|
edit |
Although this function is intentionally unused, it can cause a compiler warning. A possible workaround:
static void print_node(BtRbNode *pNode)
{
char * str = append_node(0, pNode, 0);
printf(str);
/* avoid compiler warning that function is not used */
(void)print_node;
}
|
|
346 |
code
|
fixed
|
2003 Jun
|
anonymous
|
BTree
|
2003 Jul
|
|
3
|
3
|
Problem with LIMIT 0
|
edit |
SELECT * FROM my_table LIMIT 0;
Will return all rows from my_table rather then returning nothing. |
Works as designed. A LIMIT of zero means that there is no limit.
This is documented. I'm told that other SQL database engines work
the same way.
No change.
Further investigation reveals that other SQL database engines return
zero rows on LIMIT 0. Use LIMIT -1 to turn off the limit. This
change has now been implemented. |
|
345 |
event
|
fixed
|
2003 Jun
|
anonymous
|
BTree
|
2003 Jun
|
|
4
|
4
|
repeated returns
|
edit |
Two repeated returns at function memRbtreeRollbackCkpt(), on file btree_rb.c, line 1329.
May cause some compilers problems. |
|
342 |
code
|
fixed
|
2003 Jun
|
anonymous
|
|
2003 Jun
|
|
5
|
3
|
vxprintf() makes invalid assumptions about size of pointer and long
|
edit |
On lines 392, 404, and 514 of printf.c, vxprintf() makes casts from pointers to longs. On some systems, these types are different sizes (32 and 64 bits respectively, for example), so this can cause warnings during compilation on gcc with the warning levels set high enough. |
|
341 |
code
|
fixed
|
2003 Jun
|
anonymous
|
VDBE
|
2003 Jun
|
|
4
|
3
|
vdbe.c calls access() instead of sqliteOsFileExists()
|
edit |
In sqliteVdbeMakeReady(), there is a call to access(). It is not safe to assume that access() is available on every platform, so it should use the wrapper function sqliteOsFileExists() instead:
#ifdef MEMORY_DEBUG
if( sqliteOsFileExists("vdbe_trace") ){
}
#endif
Also this block can be removed:
#ifdef MEMORY_DEBUG
extern int access(const char*,int);
#endif
|
|
340 |
code
|
fixed
|
2003 Jun
|
anonymous
|
|
2003 Jun
|
|
1
|
2
|
ATTACH database needs an authorization hook
|
edit |
When used with the PHP bindings, ATTACH database presents a security risk in that it can bypass the safe_mode settings and give access to files that are otherwise off-limits.
The only workaround for those worried by this is to use an older version of sqlite.
It would be great if you could provide me with a patch that implements an authorizer callback. I can merge this into the PHP bundled sqlite library and rest easier until the next release.
[We are planning to go "gold" with the sqlite extension in the next couple of weeks and demonstrate it at the Linux Tag conference in July] |
|
337 |
code
|
fixed
|
2003 Jun
|
anonymous
|
Unknown
|
2003 Jun
|
|
4
|
4
|
.dll produces database files claiming version 2.0.1
|
edit |
I recently downloaded and started experimenting with the precompiled .dll.
I quickly threw together a test bed in a console app. (using VC++ 6) and started playing. I noticed that when I opened a database file with notepad, that the version line appears to be an older version.
Is this truly the version of the code that is compiled in the .dll, or did you just forget to update the version string before creating the .dll.
I'd really appreciate it if you could get back to me on this.
Thanks!
-Jeff Luckett |
I'm guessing it says version "2.1" not "2.0.1". This is
by design. See section 3.1 of http://www.sqlite.org/fileformat.html. |
|
336 |
code
|
fixed
|
2003 Jun
|
anonymous
|
|
2003 Jun
|
|
4
|
2
|
Compiler warnings on SQLite 2.8.3
|
edit |
Compiler warnings of SQLite 2.8.3, on VC++ 7.1
[source file (line) : warning]
vdbe.c(2289) : warning C4244: 'initializing' : conversion from 'double' to 'int', possible loss of data
pager.c(947) : warning C4018: '>=' : signed/unsigned mismatch
os.c(1006) : warning C4101: 'tmpOsType' : unreferenced local variable
btree.c(2480) : warning C4018: '<' : signed/unsigned mismatch
insert.c(751) : warning C4700: local variable 'extra' used without having been initialized
pager.c(499) : warning C4018: '>' : signed/unsigned mismatch |
The uninitialized variable on line insert.c:751 is a real
bug that was introduced by check-in [999]
. The others are
just nuisance warnings but have been fixed nevertheless. |
|
334 |
code
|
fixed
|
2003 Jun
|
drh
|
CodeGen
|
2003 Jun
|
|
1
|
1
|
REPLACE statement corrupts indices
|
edit |
The following sequence of SQL statement will corrupt the
index used to implement the UNIQUE constraint. The result will
be that the SELECT statement at the end will return a single
row of data: a=1, b=4.
CREATE TABLE t1(a INTEGER PRIMARY KEY, b UNIQUE);
INSERT INTO t1 VALUES(1,2);
INSERT INTO t1 VALUES(2,3);
REPLACE INTO t1 VALUES(1,4);
SELECT * FROM t1 WHERE b=2;
|
This bug appears to have been here since the ON CONFLICT logic
was first added in versoin 2.3.0, nearly a year and a half. |
|
333 |
code
|
fixed
|
2003 Jun
|
anonymous
|
Unknown
|
2003 Jun
|
|
1
|
1
|
Temp Triggers cause update/delete statement failure with explicit transaction
|
edit |
If a temp update trigger containing an insert statement (which selects data from a table) is created on a non-temp table, and an update statement is executed this table within an explicit transaction, that statement will fail with the following error: "SQL error or missing database. SQL logic error or missing database"
See the small attached sample script that will demonstrate the problem.
Additionally, I have found that delete triggers have the same type of bug, if a temp delete trigger that matches the above criteria is defined, then the same error message will be generated for a delete action on the table with the same type of WHERE clause as the update examples.
TIA,
Kevin |
|
327 |
code
|
fixed
|
2003 May
|
anonymous
|
|
2003 Aug
|
|
1
|
1
|
Cygwin 1.3.22 compile failure
|
edit |
Latest CVS (co 2003-05-29) SQLite build fails under current Cygwin 1.3.22/Windows 2000, sp3. Details of the build are in the attachments |
|
323 |
code
|
fixed
|
2003 May
|
anonymous
|
CodeGen
|
2003 Jun
|
|
1
|
1
|
Assertion failed by attaching a file
|
edit |
Testing the new features of SQLite, I got an 'Assertion failed' by
merging a files, which contains the same table, with the same
UNIQUE INDEXES.
sqlite.out test.db
SQLite version 2.8.2
Enter ".help" for instructions
sqlite> create table xxx(tel integer);
sqlite> CREATE UNIQUE INDEX myindex on xxx(tel);
sqlite> exit
sqlite.out test1.db
SQLite version 2.8.2
Enter ".help" for instructions
sqlite> create table xxx(tel integer);
sqlite> CREATE UNIQUE INDEX myindex on xxx(tel);
sqlite> attach database 'test.db' as newdb;
sqlite.out: sqlite/src/build.c:1629: sqliteCreateIndex: Assertion pTab->iDb==pParse->iDb || isTemp==1' failed.
|
|
322 |
code
|
fixed
|
2003 May
|
anonymous
|
|
2003 Aug
|
|
3
|
3
|
Configure problem with ming32 on win32 (XP) and all sqlite version
|
edit |
When you launch configure script , setting for OS are OS_WIN=0 and
OS_UNIX=1. This is wrong and compilation abort on os.c. In configure i just modify before TARGET_CFLAGS="$TARGET_CFLAGS -DOS_UNIX=$OS_UNIX -DOS_WIN=$OS_WIN" case test in order to test os_type with ming32 (like for cygwin ). Moreover , as OS_* is defined , error appear
in os.h because OS_WIN and OS_UNIX are already defined. |
|
318 |
code
|
fixed
|
2003 May
|
anonymous
|
Unknown
|
2003 Jul
|
drh
|
1
|
1
|
dl-minimal.c: 128: realloc: Asseration failure...
|
edit |
369 if( rc!=SQLITE_OK ){
(gdb) n
381 sqliteRegisterBuiltinFunctions(db);
(gdb) n
382 rc = sqliteInit(db, pzErrMsg);
(gdb) n
Inconsistency detected by ld.so: dl-minimal.c: 128: realloc: Assertion `ptr == alloc_last_block' failed!
Program exited with code 0177.
I am using an FPC binding available from: http://befpc.sourceforge.net/sqlite_fpc_beos.zip
I have compiled and installed sqlite 2.8.0, the shell works perfectly, have created and used databases manually. I have not tested any C written code however, am trying to use FPC bindings...
cheers
James
PS: prologic at prologitech dot com should you need to contact me... |
This was a problem using FPC in that SQLite expects to be able to move around the buffers passed to it (So I've been told by the FPC Developers). FPC's default memory manager is slightly different so in order to remedy this you must use the C memory manager unit that comes with FPC. ie: uses cMem;
cheers
James |
|
317 |
code
|
fixed
|
2003 May
|
jplyon
|
CodeGen
|
2003 May
|
|
2
|
3
|
ATTACH fails for external database containing an index
|
edit |
Using ATTACH on an external database containing an index fails.
The problem occurs when sqliteInitOne() rebuilds the internal structures for the attached database. The original SQL statement that created the index is replayed. When it is parsed, sqliteSrcListAppend() tries to create that index for the main (0) database instead of the database being attached. After that the sqliteCreateIndex() call fails.
Note that sqliteSrcListAppend() doesn't take a Parse* argument, so we can't use context information stored in it to find the real database to use. I'm not sure whether it's better to patch the SrcList after the fact or not.
TRIGGERs and FOREIGN KEYS will probably have to be checked for the same kind of problem. |
|
316 |
code
|
fixed
|
2003 May
|
anonymous
|
Unknown
|
2003 Aug
|
|
2
|
3
|
Cygwin with gcc V2.95.3 compilation -- os.h
|
edit |
Cygwin using gcc V2.95.3 won't compile because the off_t and OS_xxx definitions are wrong. My patch to os.h below addresses this by including /usr/include/cygwin/types.h under Cygwin, using Cygwin's off_t, and by not redefining OS_WIN and OS_MAC if they are already defined during the build. These changes allow SQLite V2.8.0 to compile, along with compiling the embedded version of SQLite V2.8.0 included in the Perl DBI driver DBD::SQLite.
== Mark Leighton Fisher (mark-fisher@mindspring.com) ==
PATCH:
*** os.h.orig Mon Feb 17 03:40:51 2003
--- os.h Fri May 16 07:26:12 2003
***************
*** 18,23 ****
--- 18,32 ----
#define _SQLITE_OS_H_
/*
+ ** Handle Cygwin specially for off_t.
+ */
+ #ifdef __CYGWIN__
+ #ifndef _CYGWIN_TYPES_H
+ #include "/usr/include/cygwin/types.h"
+ #endif
+ #endif
+
+ /*
** These #defines should enable >2GB file support on Posix if the
** underlying operating system supports it. If the OS lacks
** large file support, or if the OS is windows, these should be no-ops.
***************
*** 82,90 ****
--- 91,104 ----
# define OS_UNIX 0
# endif
#else
+ #ifndef OS_MAC
# define OS_MAC 0
+ #endif
+ #ifndef OS_WIN
# define OS_WIN 0
#endif
+ #endif
+
/*
** A handle for an open file is stored in an OsFile object.
***************
*** 119,126 ****
--- 133,144 ----
# if defined(_MSC_VER) || defined(__BORLANDC__)
typedef __int64 off_t;
# else
+ # if defined(__CYGWIN__)
+ /* use from types.h */
+ # else
typedef long long off_t;
# endif
+ # endif
# define SQLITE_TEMPNAME_SIZE (MAX_PATH+50)
# define SQLITE_MIN_SLEEP_MS 1
#endif
|
|
315 |
code
|
fixed
|
2003 May
|
anonymous
|
Unknown
|
2003 May
|
|
3
|
3
|
Usage of potentially changed address
|
edit |
Hi,
When looking through the code, I noticed something strange (to me).
It is in table.c (sqlite 2.8.0) at line 172:
if( res.nAlloc>res.nData ){
char **azNew;
azNew = realloc( res.azResult, sizeof(char*)*(res.nData+1) );
if( res.azResult==0 ){
sqlite_free_table(&res.azResult[1]);
return SQLITE_NOMEM;
}
res.azResult = azNew;
}
*pazResult = &res.azResult[1];
if( pnColumn ) *pnColumn = res.nColumn;
if( pnRow ) *pnRow = res.nRow;
Why is this not (something) like this:
if( res.nAlloc>res.nData ){
char **azNew;
azNew = realloc( res.azResult, sizeof(char*)*(res.nData+1) );
if( azNew==0 ){ // changed
sqlite_free_table(&res.azResult[1]); // this is dangerous:
// after realloc this is
// freed (so undefined)
return SQLITE_NOMEM;
}
res.azResult = azNew;
res.nAlloc = res.nData+1; // added
}
*pazResult = &res.azResult[1];
if( pnColumn ) *pnColumn = res.nColumn;
if( pnRow ) *pnRow = res.nRow;
|
The call to sqlite_free_table() should be safe because according
to the realloc() documentation, if realloc() returns NULL, the
original memory allocation should be unchanged. Of course, just
because the documentation says it does not mean that the realloc()
implementation really works that way. So just to be safe, an
extra test for NULL was added inside sqlite_free_table() too. |
|
313 |
code
|
fixed
|
2003 May
|
anonymous
|
Unknown
|
2003 May
|
|
2
|
3
|
Creating a table with a specific name crashes SQLite.
|
edit |
The following statement crashes SQLite:
create table CategoryCategory ( c integer );
The following variants of that statement do not:
create table 'CategoryCategory' ( c integer );
create table CategoryCategorx ( c integer );
create table CategoryCategoryx ( c integer );
|
I too see this problem, on release builds but not debug builds, compiled with Visual Studio.NET 2003. It also occurs with the official sqlite.exe which was compiled with MinGW so it is not compiler-specific. (I hope I'm using this wiki correctly)
Wow! Good catch!
The problem was in a hash function that was suppose to always
return a non-negative number. In computing the hash, a negative
number might result but this was being dealt with by the following
line of code:
if( h<0 ) h = -h;
return h;
The above should always make h a non-negative number, right?
Well, not if the original hash is -214783648 (or 0x80000000).
For that one value for h stays negative when you takes it's
negative. To fix the problem, I changed the code to
return h & 0x7fffffff;
This is a mistake I've been making for years. It appears
throughout my code. I've got to go back and change it all.
But notice that the error only occurs in about 1 out of every
4 billion hashes. Which explains why I've never seen the
problem before now. |
|
311 |
code
|
fixed
|
2003 May
|
anonymous
|
|
2003 May
|
|
3
|
3
|
configure fails with non gcc compilers due to non escaped \n in test
|
edit |
The following is a screenshot of the make failure in SQLite 2.7.6:
configure: creating ./config.status
config.status: creating Makefile
(cd ../sqlite_source/ux/build; make)
sed -e s/--VERS--/`cat ../sqlite/VERSION`/ \
-e s/--ENCODING--/ISO8859/ \
../sqlite/src/sqlite.h.in >sqlite.h
echo '#include <stdio.h>' >temp.c
echo 'int main(){printf(' >>temp.c
echo '"#define SQLITE_PTR_SZ %d\n",sizeof(char*));' >>temp.c
echo 'exit(0);}' >>temp.c
cc -g -o temp temp.c
"temp.c", line 3: newline in string literal
"temp.c", line 4: newline in string literal
"temp.c", line 5: syntax error before or at: exit
cc: acomp failed for temp.c
*** Error code 2
make: Fatal error: Command failed for target `config.h'
The make succeeds on systems where gcc is installed. The following is the compiler version on the failing system (Solaris 2.6 with no gcc compiler):
cc -V
cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2
The symptom is reproducible on systems with more recent compilers.
The cause is the following code in the makefile.
config.h:
echo '#include <stdio.h>' >temp.c
echo 'int main(){printf(' >>temp.c
echo '"#define SQLITE_PTR_SZ %d\n",sizeof(char*));' >>temp.c
echo 'exit(0);}' >>temp.c
$(BCC) -o temp temp.c
./temp >config.h
rm -f temp.c temp
The problem is that echo statements are preprocessing the \n in the printf format string. The resulting file looks like this:
#include <stdio.h>
int main(){printf(
"#define SQLITE_PTR_SZ %d
",sizeof(char*));
exit(0);}
The gcc compiler accepts a string constant with an embedded new line, however the Sun compiler objects.
The apparent fix is escape the \n in the printf statement:
echo '"#define SQLITE_PTR_SZ %d\\n",sizeof(char*));' >>temp.c |
|
310 |
code
|
fixed
|
2003 May
|
anonymous
|
Pager
|
2003 May
|
|
3
|
3
|
win32 locking error
|
edit |
This is a rather queer problem - perhaps more windows related than SQLite:
I have a sqlite database hosted on a win98 "server", through normal windows filesharing. Only one client active at a time.
When the client is run on the "server", or from another win98 box on the network, no problems. However, when the client runs from a win2k workstation, sqlite_open fails after blocking for a while.
The problem seems to be with win32 LockFile not succeeding - I don't know whether changing share or lock modes could help this, nor whether it's a win32 problem.
I don't need a fix as I've put a linux distribution on the server, which works with both 9x and NT clients, but I thought I should report this weird behaviour. |
I did think there was any easy fix to this problem, but not so. Locking needs to be re-thought to be compatible not only between Win 2000/XP and 95/98/Me, but also between MacOS, Windows (all) and Linux/Unix if possible.
Derry Bryson |
|
309 |
code
|
fixed
|
2003 May
|
anonymous
|
Unknown
|
2003 May
|
|
5
|
5
|
Source code files are corrupted
|
edit |
I've tried to download the src.rpm and the tarball of version 2.8.0 and both seem to be corrupted. |
This is a duplicate of ticket #308. |
|
308 |
todo
|
fixed
|
2003 May
|
anonymous
|
Unknown
|
2003 May
|
|
1
|
1
|
can not unzip downloaded binary files
|
edit |
I have downloaded sqllite from the download page using ie and netscape download was successful but I can not unzip the files.
It is not possible using windows or linux tools.
what am i doing wrong. |
There is a problem on the main SQLite website. Use the
backup site until we can get the problem fixed:
|
|
306 |
code
|
fixed
|
2003 May
|
drh
|
CodeGen
|
2003 May
|
|
1
|
1
|
Left outer join fails when right table is a view of a join.
|
edit |
If you have a LEFT OUTER JOIN where the right table is a view or
subquery that is an INNER JOIN, the optimizer attempts to flatten
the subquery - which is incorrect. If the original query is
like this:
t1 LEFT OUTER JOIN (t2 JOIN t3)
The optimizer simplifies this to
(t1 LEFT OUTER JOIN t2) JOIN t3
which is not the same thing at all. |
|
305 |
code
|
fixed
|
2003 May
|
chw
|
|
2003 Dec
|
|
1
|
1
|
Problems with locale specific "," as the radix point character
|
edit |
The the locale is set so that the radix point character is ","
instead of ".", things don't work right with atof() and
printf(). The proposed solution is to use an internal
implementation of both of these functions that ignores
the locale and always uses "." as the radix point.
Note that is is not acceptable to use "," as the radix point
because that would lead to parsing ambiguities. For example:
SELECT 123,456;
If "," were the radix point, the statement above might return
either two integers or a single real number. |
It should still be possible to enter this as either of these:
SELECT '123,456'
SELECT '123','456'
depending on what one desired.
We could support this behavior by modifying the %Q printf option to add surrounding single quotes whenever there is a punctuation character, even if it wouldn't normally be necessary. |
|
302 |
code
|
fixed
|
2003 Apr
|
anonymous
|
Shell
|
2003 Apr
|
|
3
|
3
|
.sqliterc can do memory fault
|
edit |
If I put a ".timeout 100" into the ".sqliterc" configuration file sqlite exit for a memory fault.
The problem is that the .sqliterc is processed before the database is opened so a ".timeout 100" command (but so other commands) use a NULL "db" pointer.
Into "shell.c" the "do_meta_command" call the "sqlite_busy_timeout" funcion with a NULL db pointer. |
|
300 |
new
|
fixed
|
2003 Apr
|
anonymous
|
|
2005 Feb
|
|
5
|
5
|
Correlated Subqueries are not supported
|
edit |
select name, age, comp, (select Context from Tbl2 where Tbl2.GUID = A.GUID) as Des from Tbl1 as A where GUID ='-1'; |
AS works fine. The problem is that SQLite does not support
subqueries that reference their containing query. The lack
of support for this is explicited mentioned in the documentation.
See also ticket #30.
I will interpret this ticket as an enhancement request for
dynamic subqueries. |
|
299 |
new
|
fixed
|
2003 Apr
|
anonymous
|
Parser
|
2006 Aug
|
|
2
|
3
|
Cannot insert only default values.
|
edit |
If I have a table:create table foo (id integer primary key);
I cannot insert a row with the default value for column id.
In SQL there is this posibility with sometring like:
INSERT INTO foo DEFAULT VALUES;
standard syntax for this is (change to be done in parse.y ?):
INSERT INTO foo () VALUES (); |
2006-Aug-25 08:51:20 by anonymous:
if your table foo had a field 'pk integer primary key autoincrement', then there would be a workaround:
insert into foo (pk) values (NULL);
otherwise not only there would be no workaround, but any time (except possibly the first) you give the command 'insert into foo default values' you would get some 'duplicate primary key' error.
it is possible to modify parse.y and insert.c to translate the SQL92 syntax into the workaround, and to do this only in the case that the primary key is declared integer autoincrement. I will attach a patch doing exactly this.
2006-Aug-25 10:42:08 by drh:
Anonymous is mistaken. The AUTOINCREMENT keyword is not
required to get the desired behavior. The following works:
INSERT INTO foo(pk) VALUES(NULL);
The AUTOINCREMENT keyword causes the value inserted in such
cases to be unique over the entire lifetime of the table.
In other words, the value inserted has never before been used
as the primary key for that table. With AUTOINCREMENT, a
unique primary key is created, but that key might be one
that was used previously and then deleted.
2006-Aug-25 14:11:39 by anonymous:
glad to see that I was at least partially mistaken, since this means that the proposed and attached patch works in the more general case. |
|
298 |
code
|
fixed
|
2003 Apr
|
drh
|
CodeGen
|
2003 Apr
|
|
1
|
1
|
SELECT sometimes ignores constant WHERE clause
|
edit |
The following queries return 1 when they should return an empty set:
SELECT 1 WHERE abs(random())<0;
SELECT 1 WHERE NULL=5;
This only happens when the FROM clause is omitted and the WHERE clause
slips through the optimizer as a non-constant expression. |
|
297 |
code
|
fixed
|
2003 Apr
|
anonymous
|
|
2003 Apr
|
|
1
|
1
|
sqliteSortCompare crashes when sorting ints by more than one key
|
edit |
in line 836 (at the end of sqliteSortCompare) a and b are set to the next element which is set wrong if the elements don't have the same size.
example:
a: +100\000A1\000\000
b: +100.0\000A4\000\000
after cmp:
a: A1\000\000
b: 0\000A4\000\000
sqlite: ../sqlite/src/util.c:804: sqliteSortCompare: Assertion `a[0]==b[0]' failed.
this can be fixed with the following patch in util.c:
instead of :
len = strlen(&a[1]) + 2;
a += len;
b += len;
someone should write:
a += strlen(&a[1]) + 2;
b += strlen(&b[1]) + 2;
thanks for all the stuff anyway,
marcus. |
|
296 |
code
|
fixed
|
2003 Apr
|
anonymous
|
VDBE
|
2003 Apr
|
|
1
|
4
|
crash sqlite or execute via libtclsqlite
|
edit |
create table proba(num integer unique not null);
select max(num) from proba;
$ sqlite: ./src/dtree.c:1215: sqliteBtreeKey:Assertion `offset>=0' failed. |
|
295 |
code
|
fixed
|
2003 Apr
|
drh
|
CodeGen
|
2003 Apr
|
|
1
|
1
|
ATTACH does not work on a database containing triggers
|
edit |
The ATTACH command fails if the database begin attached
contains triggers. |
|
293 |
code
|
fixed
|
2003 Apr
|
anonymous
|
|
2003 Apr
|
paul
|
1
|
2
|
configure-script broken by checkin #903
|
edit |
Hate to bother you again, but the changes to the configure script concerning the in-memory btrees broke it. Problem is you are using shell variables with the name
enable_incore-db
and
enable_tempdb-in-ram
which both are not legal shell variable identifiers. I think the '-' is not allowed.
You should use '_' instead. |
|
292 |
code
|
fixed
|
2003 Apr
|
drh
|
|
2005 Jan
|
|
4
|
4
|
Multiple indices created for a UNIQUE PRIMARY KEY
|
edit |
Using "UNIQUE" and "PRIMARY KEY" on the same field of a table
definition is redundant. But it happens. Unfortunately, SQLite
creates separate indices for the UNIQUE and the PRIMARY KEY.
For that matter, if you use "UNIQUE" two or more times on the
same column of a table, it creates a separate index for each
use. Probably it should only create a single index.
Having multiple indices does not break anything - it just slows
down inserts and updates. |
You can also create a separate index on a PRIMARY KEY.
And if the PRIMARY KEY is an INTEGER, this can lead to
problems. See [946]
.
Getting SQLite to automatically recognize and ignore
redundant keys will require a database format update. |
|
291 |
code
|
fixed
|
2003 Apr
|
drh
|
|
2003 Apr
|
drh
|
1
|
1
|
autoincrement does not work with triggers
|
edit |
Consider the following SQL:
CREATE TABLE t1(a INTEGER PRIMARY KEY);
CREATE TABLE t2(b);
CREATE TRIGGER r1 AFTER INSERT ON t1 FOR EACH ROW BEGIN
INSERT INTO t2 VALUES(new.a);
END;
INSERT INTO t1 VALUES(NULL);
The insert of a NULL into the INTEGER PRIMARY KEY column causes
the NULL to be changed into the next available rowid for that
table. But within the trigger, NEW.A does not take on the
rowid value. It continues to be NULL. |
|
290 |
event
|
fixed
|
2003 Apr
|
drh
|
VDBE
|
2003 Apr
|
|
1
|
1
|
interaction of last_insert_rowid() and AFTER triggers
|
edit |
Consider the following SQL:
CREATE TABLE t1(a integer primary key);
CREATE TABLE t2(x);
CREATE TRIGGER r1 AFTER INSERT on t1 FOR EACH ROW BEGIN
INSERT INTO t2 VALUES(NEW.a+10);
END;
When a value is inserted into t1, it causes trigger r1 to fire and
insert a related value into t2. The next call to
sqlite_last_insert_rowid() will return the rowid for the insert into
table t2, not the insert into table t1.
Technically, this behavior is correct, because the last row inserted
was into table t2. But the behavior was unexpected. The user was
expecting the rowid of the row inserted into t1 because the t2
insert happens behind the scenes - out of view from the user.
I'm not sure if this is a bug or not. |
|
289 |
code
|
fixed
|
2003 Apr
|
anonymous
|
BTree
|
2003 Apr
|
|
1
|
1
|
File src/btree_rb.c is missing
|
edit |
File src/btree_rb.c is missing from CVS! |
|
288 |
code
|
fixed
|
2003 Apr
|
anonymous
|
|
2003 Apr
|
|
1
|
1
|
sqlite don't compile on SuSE 8.2 (gcc 3.3)
|
edit |
Hello,
sqlite 2.8.0 don't compile on SuSE 8.2 (gcc 3.3). The following error is shown on the console:
gcc -g -O2 -o lemon ../sqlite/tool/lemon.c
In file included from ../sqlite/tool/lemon.c:10:
/usr/lib/gcc-lib/i486-suse-linux/3.3/include/varargs.h:4:2: #error "GCC no longer implements <varargs.h>."
/usr/lib/gcc-lib/i486-suse-linux/3.3/include/varargs.h:5:2: #error "Revise your code to use <stdarg.h>."
../sqlite/tool/lemon.c:1106: error: parse error before "va_dcl"
../sqlite/tool/lemon.c:1107: error: syntax error before '{' token
../sqlite/tool/lemon.c:1116: error: parse error before "ap"
../sqlite/tool/lemon.c:1116: warning: data definition has no type or storage class
../sqlite/tool/lemon.c:1119: warning: parameter names (without types) in function declaration
../sqlite/tool/lemon.c:1119: warning: data definition has no type or storage class
../sqlite/tool/lemon.c:1120: error: parse error before "char"
../sqlite/tool/lemon.c:1121: error: parse error before "int"
../sqlite/tool/lemon.c:1122: error: conflicting types for `format'
../sqlite/tool/lemon.c:1110: error: previous declaration of `format'
../sqlite/tool/lemon.c:1122: error: parse error before "char"
../sqlite/tool/lemon.c:1129: error: initializer element is not constant
../sqlite/tool/lemon.c:1129: warning: data definition has no type or storage class
../sqlite/tool/lemon.c:1130: error: initializer element is not constant
../sqlite/tool/lemon.c:1130: warning: data definition has no type or storage class
../sqlite/tool/lemon.c:1133: warning: parameter names (without types) in function declaration
../sqlite/tool/lemon.c:1133: warning: data definition has no type or storage class
../sqlite/tool/lemon.c:1134: warning: parameter names (without types) in function declaration
../sqlite/tool/lemon.c:1134: warning: data definition has no type or storage class
../sqlite/tool/lemon.c:1135: error: initializer element is not constant
../sqlite/tool/lemon.c:1135: warning: data definition has no type or storage class
../sqlite/tool/lemon.c:1137: error: parse error before "while"
../sqlite/tool/lemon.c:1142: warning: data definition has no type or storage class
../sqlite/tool/lemon.c:1143: error: parse error before "while"
../sqlite/tool/lemon.c:1147: error: parse error before string constant
../sqlite/tool/lemon.c:1147: warning: conflicting types for built-in function `fprintf'
../sqlite/tool/lemon.c:1147: warning: data definition has no type or storage class
../sqlite/tool/lemon.c:1148: error: redefinition of `base'
../sqlite/tool/lemon.c:1142: error: `base' previously defined here
../sqlite/tool/lemon.c:1148: error: initializer element is not constant
../sqlite/tool/lemon.c:1148: warning: data definition has no type or storage class
../sqlite/tool/lemon.c:1149: error: parse error before '}' token
make: *** [lemon] Fehler 1 |
see ticket #280 |
|
284 |
code
|
fixed
|
2003 Apr
|
anonymous
|
Unknown
|
2003 Apr
|
|
2
|
1
|
"make test" --> Segmentation Fault on Solaris
|
edit |
Several test cases fail catastrophically:
* auth-1.1.1
* capi2-1.1
I've tried several environments with similar results:
Solaris 8
- Sun WorkShop C++ 5.0 + tcl8.4
- gcc 3.2.2 + tcl8.4
Solaris 9
- gcc 3.2.2 + tcl8.4
I've attached two stack dumps, both from the Sun WorkShop environment on Solaris 8.
BTW, sqlite 2.7.6 builds and passes all tests in that same environment. |
The problem appears to be in the test code, not in SQLite
itself. So you might still be able to use the library even
though some of the tests fail.
The problem seems to be in the getDbPointer() routine
near the top of the test1.c source file. I suspect it
has something to do with Sparcs using a 64-bit pointer.
Either getDbPointer() is not decoding that pointer
correctly, or the pointer is not being rendering into
a string correctly by the printf() in sqlite_test_open()
of the same file. I don't have access to a Sparc and
cannot debug this. I'd appreciate it if the reporter
would look into this using a debugger and suggest a
patch to fix it.
In tclsqlite.c there is a fragment of code that formats native pointers to string values for Tcl. The code looks like this:
sprintf(zBuf,"%p",p->db);
if(strncmp(zBuf,"0x",2)){
sprintf(zBuf,"0x%p",p->db);
}
This has the effect of forcing a 0x prefix. However, in getDbPointer() in test1.c the sscanf() uses a bare "%p". Adding the leading 0x to the PTR_FMT in test1.c resolves the problem and gets us past auth-1.1.1 and capi2-1.1
Note to self: The %p format appears to work differently on
different systems. Consider doing a run-time test to discover
the operation of %p when the test fixture is initialized and
set up the format appropriately based on the results. |
|
282 |
code
|
fixed
|
2003 Apr
|
anonymous
|
Unknown
|
2003 May
|
|
2
|
3
|
Echo "\n" on Solaris causes two linebreaks. Makefile problem.
|
edit |
Hi,
I tried compiling sqlite 2.8.0 on Solaris 2.7. There was only one glitch, namely the place where the Makefile creates the config.h file. When writing the line with #define SQLITE_PTR_SZ, the echo command includes the string "\n" in the string to be written. On Solaris /bin/sh, this causes echo to issue a linebreak instead of the intended slash-n. The workaround is to write "\\n" instead of "\n" in the makefile. Once this is done, sqlite compiles on Solaris with no problems. I use Sun Forte WS6, that is, Sun's own compilers.
The compiler does issue a number of warnings, and I could send you those in a separate ticket if you contact me and ask for it. Things like "statement not reached" and mismatch between unsigned signed versions of types in prototypes and assignments.
One way of solving the problem with echo-issuing-a-newline is to write a small script in configure.in which issues an "echo '\n'" command into an empty file and then uses wc -l to count the number of lines. On Solaris /bin/sh, this gives 2:
\u@\h:\w$echo '\n' > try.txt
\u@\h:\w$wc -l try.txt
2 try.txt
On bash, of course, it gives 1:
[upet01@upet01 sqlite]$ echo '\n' > try.txt
[upet01@upet01 sqlite]$ wc -l try.txt
1 try.txt
The point is not to assume you are running under bash, but to test for how the shell deals with newlines.
Best regards,
Ulrik Petersen |
|
281 |
code
|
fixed
|
2003 Apr
|
anonymous
|
|
2003 Apr
|
|
1
|
1
|
expression 0 = '' is true
|
edit |
Expression 0 = '' is true: run script
create table t1(i integer primary key);
create table t2(i integer);
insert into t1 values(0);
insert into t2 values(0);
select 1, i from t1 where i = '';
select 2, i from t2 where i = '';
select 3, i from t1 where 0 = '';
Output (sqlite 2.7.5):
1|0
2|0
3|0
Output (sqlite 2.8.0):
2|0
3|0
|
|
280 |
code
|
fixed
|
2003 Apr
|
anonymous
|
|
2003 Apr
|
|
2
|
2
|
Revise your code to use <stdarg.h>
|
edit |
Starting with version 3.3, GCC no longer implements <varargs.h>. Please revise your code to use <stdarg.h>.
In file included from tool/lemon.c:10:
/usr/lib/gcc-lib/i486-suse-linux/3.3/include/varargs.h:4:2: #error "GCC no longer implements <varargs.h>."
/usr/lib/gcc-lib/i486-suse-linux/3.3/include/varargs.h:5:2: #error "Revise your code to use <stdarg.h>."
tool/lemon.c:1106: error: parse error before "va_dcl"
tool/lemon.c:1107: error: syntax error before '{' token
tool/lemon.c:1116: error: parse error before "ap"
tool/lemon.c:1116: warning: data definition has no type or storage class
tool/lemon.c:1119: warning: parameter names (without types) in function declaration
tool/lemon.c:1119: warning: data definition has no type or storage class
tool/lemon.c:1120: error: parse error before "char"
tool/lemon.c:1121: error: parse error before "int"
tool/lemon.c:1122: error: conflicting types for `format'
tool/lemon.c:1110: error: previous declaration of `format'
tool/lemon.c:1122: error: parse error before "char"
tool/lemon.c:1129: error: initializer element is not constant
tool/lemon.c:1129: warning: data definition has no type or storage class
tool/lemon.c:1130: error: initializer element is not constant
tool/lemon.c:1130: warning: data definition has no type or storage class
tool/lemon.c:1133: warning: parameter names (without types) in function declaration
tool/lemon.c:1133: warning: data definition has no type or storage class
tool/lemon.c:1134: warning: parameter names (without types) in function declaration
tool/lemon.c:1134: warning: data definition has no type or storage class
tool/lemon.c:1135: error: initializer element is not constant
tool/lemon.c:1135: warning: data definition has no type or storage class
tool/lemon.c:1137: error: parse error before "while"
tool/lemon.c:1142: warning: data definition has no type or storage class
tool/lemon.c:1143: error: parse error before "while"
tool/lemon.c:1147: error: parse error before string constant
tool/lemon.c:1147: warning: conflicting types for built-in function `fprintf'
tool/lemon.c:1147: warning: data definition has no type or storage class
tool/lemon.c:1148: error: redefinition of `base'
tool/lemon.c:1142: error: `base' previously defined here
tool/lemon.c:1148: error: initializer element is not constant
tool/lemon.c:1148: warning: data definition has no type or storage class
tool/lemon.c:1149: error: parse error before '}' token
gmake: *** [lemon] Fehler 1
|
Added simple patch that fixes compile on GCC 3.3. The patch is somewhat ugly because it mixes K&R-style C with ANSI C in one source file, but I see no other way to use <stdarg.h>. |
|
277 |
code
|
fixed
|
2003 Apr
|
anonymous
|
Parser
|
2003 Apr
|
|
1
|
2
|
Multi-line comments cause syntax errors in ".read" files
|
edit |
Commenting out multiple lines of code using "/\*...\*/" in files that are .read into sqlite.exe causes a syntax error to be thrown on the closing "\*/":
SQL error: near "\*": syntax error
The syntax error is thrown at the END of the following statement. I do not know if the error is thrown if there is nothing after the commented out block.
The priority assigned is bacause this flaw makes it devilishly hard to debug code.
NOTE: the backslashes before the astrisks are to prevent the bug tracker from eating them and trying to bold the text after/between two asterisks. If there is another way to get these characters verbatim, the "Formating Hints" don't show it. |
|
276 |
new
|
fixed
|
2003 Apr
|
anonymous
|
Shell
|
2003 Apr
|
|
3
|
3
|
Proposal/Bug-Fix for TTY determination
|
edit |
one line summary:
Call to isatty() could be "cleaner", the current implemenation fails under Windows CE.
This is an enhancement but also a bug fix in relation to Windows CE. I expect to be submitting my changes against sqlite "proper" for the Windows CE / Pocket PC platform soon. The only reason I'm raising this pedantic change is to get my PocketPC port working :-)
diff winCE_sqlite_280_source/shell.c sqlite-2.8.0/sqlite/src/shell.c
1213c1213
< if( isatty( fileno( stdout ) ) ){
---
> if( isatty(0) ){
Under PocketPC we don't have console's etc. so I'm relying opon PocketConsole (and portlib) http://www.symbolictools.de/public/pocketconsole/index.htm#download to get the (shell) terminal monitor working (they are not nessacary for the sqlite library).
PocketConsole doesn't appear to use the standard integer values for stdout, etc. I'm not clear if ANSI enforce this standard or whether the constants 0,1, 2 are just a convention.
Once I made the change above everything was hunky-dorey. I can't for-see any problems under Unix/Windows but I can't test/build sqlite[.exe] to confirm/prove this :-(
Thanks,
Chris |
|
275 |
code
|
fixed
|
2003 Mar
|
anonymous
|
CodeGen
|
2003 Apr
|
|
3
|
5
|
"INSERT INTO x SELECT * FROM x" doesn't work when x is a TEMP table
|
edit |
SQLite version 2.8.0
Enter ".help" for instructions
sqlite> create temp table a(a);
sqlite> insert into a values (1);
sqlite> insert into a select * from a;
SQL error: database table is locked
On line 196 of insert.c, vdbe code already generated is searched for an OP_OpenTemp instruction. It should be OP_OpenAux. |
|
272 |
code
|
fixed
|
2003 Mar
|
anonymous
|
|
2003 May
|
|
3
|
3
|
select on view with where clause does not use index
|
edit |
I think the example output says it all (times are milliseconds):
Sql: select count(*) from tw_methodsandsourcesview
where packageRef=125
Execution time: 3863 , Result Rows: 1
Sql: select count(*) from TW_Methods, TW_Method, TW_Blob
WHERE TW_Methods.methodRef = TW_Method.primaryKey AND
TW_Method.sourceCodeID = TW_Blob.primaryKey and
packageRef=125;
Execution time: 8 , Result Rows: 1
Note that the index on TW_Methods.packageRef in this example
is a combined one
(it's created by PRIMARY KEY (packageRef, methodRef)), although
creating a separate index on packageRef alone did not improve
performance. |
Unable to reproduce. The trouble report lacks a definition for
the view that is allegedly not using indices. Views created
in several test cases do use indices.
A script to reproduce the problem is in the join-view.sql
attachment.
The problem is that subqueries (VIEWs are always treated as
subqueries during code generation) that are joins never get
folded into the parent query by the optimizer. This is a
limitation of the flattenSubquery() routine in select.c and
needs to be addressed.
drh's notes to self:
- Add an iCursor field to SrcList_item. This field holds the VDBE
cursor number used to access the corresponding table.
- Number SrcList_items as they are encountered. The numbers need
to be close to gether (due to 32-bit bitmaps in where.c) but they
need not be consecutive. Can we relax the proximity restriction
somehow?
- The Expr.iTable field is set to SrcList_item.iCursor.
- No need to pass around the "base" cursor value or store it in
Select or WhereInfo.
- Omit the OP_RenameCursor opcode and the ChangeTables() routines.
- The above simplifications allow flattenSubquery() to push a
subquery that is a join up into the parent query.
|
|
270 |
code
|
fixed
|
2003 Mar
|
anonymous
|
Unknown
|
2003 Apr
|
|
3
|
4
|
incorrect check for fcntl error code
|
edit |
Reading through the Unix locking code, s (return code
from fcntl) is being compared to EINVAL.
s = fcntl(id->fd, F_SETLK, &lock);
if( s!=0 ){
rc = (s==EINVAL) ? SQLITE_NOLFS : SQLITE_BUSY;
This is incorrect; s will only ever be 0 or -1,
and never be EINVAL (22 on most systems). I think the
code means to say
rc = (errno==EINVAL) ? SQLITE_NOLFS : SQLITE_BUSY;
|
Duplication of ticket #240. |
|
269 |
new
|
fixed
|
2003 Mar
|
anonymous
|
|
2005 Jan
|
|
3
|
3
|
table.column view columns can not be referenced in where clause
|
edit |
View columns that include the tablename in their column definition
(as in "tablename.columnname") cannot be referenced in a where clause, neither via "columnname" nor via "tablename.columnname".
It does work if you specify an alias. E.g. "tablename.columnname columname" will result in a column that may be referenced by
"columnname". "columnname.tablename" will still not work, however.
Unfortunately, I think that's even more important issue of the two.
Modification of all view definitions is not hard, just boring. But hunting down all the where clauses that may be run
against those views can be tricky ... |
The attachment says:
create table y1(a,b);
create table y2(a,b);
create view yy as select y1.a,y1.b,y2.a,y2.b from y1,y2 where y1.a=y2.a;
insert into y1 values (1,2);
insert into y2 values (1,2);
select * from yy;
select * from yy where a=1;
select * from yy where y1.a=1;
I don't think the last statement should work. My understanding
of a view is that it hides the definitions of its underlying
tables. If there are any SQL experts out there who want to
correct me, please do so.
Note that in the case above, the names of the columns in
the view are "y1.a" and "y1.b" and so forth. So the last
statement of SQL could be:
select * from yy where "y1.a"=1.
I think you are right about the last statement. I ran
an example script against Oracle and "tablename.columnname"
is not recognized either.
drop table test1;
drop table test2;
drop view testview;
create table test1(a varchar2(32), b varchar2(32));
create table test2(a varchar2(32), c varchar2(32));
create view testview as select test1.a, test1.b, test2.c
from test1, test2 where test1.a=test2.a;
insert into test1 values('a','b');
insert into test2 values('a','c');
select * from testview;
select * from testview where a='a';
select * from testview where test1.a='a';
select * from testview where testview.a='a';
The result on Oracle is that everything works but the
second-to-last ("test1.a"). For sqlite, no where clause works.
As an aside, I noticed that I don't get any type information
for selects on views (I use "pragma show_datatypes=on").
Which is kind of unfortunate, because VisualWorks standard
database interface converts select results to appropriate
smalltalk types on the fly (I am trying to port VW's
Store source-code management framework). |
|
266 |
new
|
fixed
|
2003 Mar
|
drh
|
|
2003 Apr
|
|
1
|
1
|
Make the VACUUM command work.
|
edit |
The VACUUM command used to remove free space from the database
file, back in version 1.0. Since version 2.0, VACUUM has been
a no-op. The VACUUM command should be made functional again
for version 2.0. |
|
262 |
new
|
fixed
|
2003 Mar
|
anonymous
|
Unknown
|
2003 Jun
|
|
4
|
4
|
Non Callback is Slow on scripts
|
edit |
Performance was and is great using the callback api. I could create 14 tables do 6000 inserts within a single transaction in less than 1.5 seconds.
Now I'm using the non-callback mechanism and the script needs to be run until the "Tail" of the statement to be executed is nil (or empty string!). This takes ages to finish... :( |
See remarks on ticket #261. |
|
258 |
code
|
fixed
|
2003 Feb
|
anonymous
|
Parser
|
2003 Mar
|
|
3
|
3
|
sqlite_compile doesn't work with (some?) PRAGMAs
|
edit |
It appears that sqlite_compile() returns an error when given a
pragma, e.g., "PRAGMA SHOW_DATATYPES=ON;"
It would be nice to always be able to use the no-callback API without pre-parsing the sql string. |
|
257 |
code
|
fixed
|
2003 Feb
|
anonymous
|
VDBE
|
2003 Mar
|
|
4
|
3
|
sqliteVdbeList should return SQLITE_DONE not SQLITE_OK
|
edit |
When using the no-callback API to process EXPLAIN queries, the last call of the VM returns OK not DONE.
The last line of sqliteVdbeList is:
return p->rc==SQLITE_OK ? SQLITE_OK : SQLITE_ERROR;
and it never seems to return SQLITE_DONE.
This behavior is inconsistent with normal queries, and with the documentation, and makes it difficult to make a reliable general purpose query processor with the no-callback API. |
|
256 |
code
|
fixed
|
2003 Feb
|
anonymous
|
|
2003 May
|
|
3
|
2
|
Simple Makefile error on HP/UX, may affect other UNIX systems
|
edit |
The Makefile generated for HP/UX with the native compiler fails at an early point:
echo '#include <stdio.h>' >temp.c
echo 'int main(){printf(' >>temp.c
echo '"#define SQLITE_PTR_SZ %d\n",sizeof(char*));' >>temp.c
echo 'exit(0);}' >>temp.c
$(BCC) -o temp temp.c
./temp >config.h
rm -f temp.c temp
...should be revised with another escape for the newline: \\n
Simple, but fatal mistake. (-: |
|
250 |
code
|
fixed
|
2003 Feb
|
anonymous
|
Unknown
|
2003 Mar
|
|
2
|
1
|
SQLite_Changes increments with new non-callback
|
edit |
Using the new non-callback mechanism in the DbExpress driver surfaced a bug in sqlite_changes. Documentation tells me it returns the number of rows affected in the latest SQLite_Exec call.
Since I'm using SQLite_Compile, SQLite_Step and SQLite_Finalize, the result of SQLite_Canges seems to increment every time this SQLite_Compile is used.
Could it be this doesn't reset the ChangeCount somehow?
If it is a bug, please fix and release quickly. ;) |
sqlite_changes() should return the number of changes in the
most recent sqlite_exec() call, or in all sqlite_step() calls
after the most recent sqlite_compile() call. The documentation
has been updated to reflect this and new test cases have been
added to make sure this is the way things work. |
|
249 |
code
|
fixed
|
2003 Feb
|
anonymous
|
Unknown
|
2004 Aug
|
drh
|
1
|
1
|
install
|
edit |
OS: windows 2000
It seems like there is a serious memory leak when you create a table with a primary key. This bug is only been tested on a windows 2000 machine, so I am not sure if another OS has the same problem.
How to reproduce :
sqlite *m_sqliteObj =0;
char* errorMessage = 0;
int resultCode = 0;
char *errmsg =0;
m_sqliteObj = sqlite_open("c:\\temp\\testdb.db", 0, &errorMessage);
if(errorMessage != 0){
sqlite_freemem(errorMessage);
return 1;
}
for (int x =0; x<1000; x++){
cout << x << endl;
Sleep(2) // windows, sleep in milliseconds;
resultCode = sqlite_exec(m_sqliteObj,"CREATE TABLE TEST(a integer, primary key(a));",NULL,NULL,&errmsg);
if(resultCode !=0 ){
if(errmsg != 0)sqlite_freemem(errmsg);
return 1;
}
resultCode = sqlite_exec(m_sqliteObj,"DROP TABLE TEST;",NULL,NULL,&errmsg);
if(resultCode !=0 ){
if(errmsg != 0)sqlite_freemem(errmsg);
return 1;
}
}
sqlite_close(m_sqliteObj);
return 0;
Note: When [primary key(a)] is removed, no leak occurs. Every insert into a table with a primary key defined has also a memory leak. |
The leak only occurs if the following is true.
- The PRIMARY KEY is specified as a separate clause in the CREATE TABLE
statement - not as a modifier to a the datatype of a column.
- The CREATE TABLE statement must fail or the PRIMARY KEY is a
single column of type INTEGER.
I have been unable reproduce any memory leaks associated with inserts. |
|
247 |
code
|
fixed
|
2003 Feb
|
anonymous
|
VDBE
|
2003 Feb
|
drh
|
1
|
1
|
OUTER JOIN problem
|
edit |
When the right table in a LEFT OUTER JOIN has an INTEGER PRIMARY KEY,
that key does not become NULL when no row in the right table matches
the current left table row.
Example:
CREATE TABLE t1(a,b);
INSERT INTO t1 VALUES(1,2);
INSERT INTO t1 VALUES(3,NULL);
INSERT INTO t1 VALUES(5,6);
CREATE TABLE t2(x INTEGER PRIMARY KEY,y);
INSERT INTO t2 VALUES(2,22);
INSERT INTO t2 VALUES(6,66);
SELECT t1.a, coalesce(t2.x,999) FROM t1 LEFT OUTER JOIN t2 ON (t1.b=t2.x);
The output of the above is
1|2
3|2
5|6
When it should be
1|2
3|999
5|6
|
|
246 |
event
|
fixed
|
2003 Feb
|
anonymous
|
Unknown
|
2003 Feb
|
|
2
|
3
|
View not the same as direct query
|
edit |
Something is funny with the views ... I get different results if i use the View than If I use the query directly.
CREATE TABLE Signal (
uSignalID INTEGER UNSIGNED PRIMARY KEY,
strComment VARCHAR(128),
ca4CurPinName CHAR(4),
UNIQUE(strTag, strName),
);
CREATE TABLE Pin (
ca4Name CHAR(4) NOT NULL,
strComment VARCHAR(128),
uSignalIDCache INTEGER UNSIGNED,
PRIMARY KEY(ca4Name)
);
DROP VIEW PinComment;
CREATE VIEW PinComment AS
SELECT
(CASE Signal.uSignalID IS NULL
WHEN 1 THEN Pin.strComment
ELSE Signal.strComment END) AS strComment,
Pin.ca4Name as ca4Name
FROM Pin LEFT JOIN Signal ON (Signal.ca4CurPinName=Pin.ca4Name);
SELECT
(CASE Signal.uSignalID IS NULL
WHEN 1 THEN Pin.strComment
ELSE Signal.strComment END) AS strComment,
Pin.ca4Name as ca4Name
FROM Pin LEFT JOIN Signal ON (Signal.ca4CurPinName=Pin.ca4Name)
WHERE ca4Name Like "pa3_";
pa30 pin|pa30
pa31 sig|pa31
sqlite> select * from PinComment where ca4Name Like "pa3_";
|pa30
pa31 sig|pa31
|
Unable to reproduce. The straight select and the view in the code
below produce identical output.
CREATE TABLE t1(a PRIMARY KEY,b,c);
CREATE TABLE t2(x PRIMARY KEY,b);
INSERT INTO t1 VALUES(2,'com1-1','pa31');
INSERT INTO t1 VALUES(3,'com1-2','pa32');
INSERT INTO t1 VALUES(4,'com1-2','pa99');
INSERT INTO t2 VALUES('pa30','com2-0');
INSERT INTO t2 VALUES('pa31','com2-1');
INSERT INTO t2 VALUES('pa99','com2-1');
SELECT 'A', CASE t1.a IS NULL WHEN 1 THEN t2.b ELSE t1.b END AS b, t2.x AS x
FROM t2 LEFT JOIN t1 ON (t1.c=t2.x)
WHERE x LIKE "pa3_";
CREATE VIEW v1 AS
SELECT CASE t1.a IS NULL WHEN 1 THEN t2.b ELSE t1.b END AS b, t2.x AS x
FROM t2 LEFT JOIN t1 ON (t1.c=t2.x);
SELECT 'B', * FROM v1 WHERE x LIKE "pa3_";
|
|
245 |
code
|
fixed
|
2003 Feb
|
anonymous
|
Parser
|
2003 Feb
|
|
3
|
3
|
LIMIT and OFFSET clause
|
edit |
LIMIT and OFFSET clause have two syntax
1. LIMIT integer [OFFSET integer]
2. LIMIT [offset,] rows
For example,
select * from t1 limit 50,10;
correct result: 50~59
SQLite result: 10~59 |
|
240 |
code
|
fixed
|
2003 Feb
|
anonymous
|
|
2003 Apr
|
|
5
|
4
|
fcntl return code checked instead of errno
|
edit |
When fcntl fails the return code is checked to determine whether to report SQLITE_BUSY or SQLITE_NOLFS. The return code should be used to determine whether the call succeeded or failed, but the specific error must be obtained from errno for this test to work:
if( s!=0 ){
rc = (s==EINVAL) ? SQLITE_NOLFS : SQLITE_BUSY;
should be changed to
if( s!=0 ){
rc = (errno==EINVAL) ? SQLITE_NOLFS : SQLITE_BUSY;
I only noticed this through code review as I investigated a deadlocking problem due to my own code, so I don't know of any specific problem outcome that could emerge from this problem. FYI only...
Benjamin. |
See also ticket #270. |
|
238 |
code
|
fixed
|
2003 Feb
|
drh
|
CodeGen
|
2003 Feb
|
|
1
|
1
|
Assertion failure after some incorrect SQL
|
edit |
The following series of commands causes an assertion failure.
CREATE TABLE t1 AS SELECT c2;
DROP TABLE t1;
The first command returns an error. (The FROM clause was omitted
from the SELECT statement.) But somehow, SQLite thinks table T1
was created in spite of this error. So it allows the DROP TABLE
statement to be executed which results in an error. |
The problem appears to have been introduced when support for
CREATE TABLE ... AS SELECT was first added by
check-in [377]
on 2002-Feb-18 as part of SQLite 2.3.3. |
|
237 |
code
|
fixed
|
2003 Jan
|
anonymous
|
Parser
|
2003 Jan
|
|
2
|
2
|
suspected problem in IN operator
|
edit |
IN (on the right) seems to require single-quotes, rejecting values bounded by double quotes. This will be a problem when I have to denote values that contain single-quotes, no?
This fails similarly when tried via RexxSQL.
-R. |
|
234 |
code
|
fixed
|
2003 Jan
|
anonymous
|
|
2003 Apr
|
|
4
|
4
|
Impossibility to have Comments and DOT-Commands in an SQL-File
|
edit |
This is a followup to Ticket #211, but I think, now I've found the real source of the problem.
If a comment is immediately followed by a "DOT-Command"
SQLite reports a syntax error :
Example :
create table bar (foo integer);
insert into bar values (42);
-- This is a comment
.echo off
select max(foo) from bar;
SQL error: near ".": syntax error |
|
232 |
code
|
fixed
|
2003 Jan
|
anonymous
|
Parser
|
2003 Feb
|
|
2
|
2
|
group by result is wrong
|
edit |
Select x
from T1
group by x
The result shows x's for every row in the table T1.
The result should be equal to "select distinct x from T1".
(Question if it being resolved: will you treat all nulls as a single row?) |
To answer the question: I originally coded SQLite so that NULLs
were distinct in a "SELECT DISTINCT" query. But then I noticed
that every other database engine I could find (except Ocelot)
treated NULLs as indistinct in that context. So I changed SQLite.
There is a #define in the code someplace to change it back, if
I recall. See http://www.sqlite.org/nulls.html. |
|
231 |
code
|
fixed
|
2003 Jan
|
anonymous
|
|
2003 Jan
|
|
2
|
3
|
sqlite deny acces with wrong return value
|
edit |
sqlite_exec seems to return SQLITE_ERROR instead of SQLITE_AUTH if access is denied. |
- Symbol SQLITE_AUTH isn't used in the source at all!
- Functions sqliteAuthCheck() and sqliteAuthRead() need to set the 'return' value pParse->rc = SQLITE_AUTH before incrementing the count nErr.
- These 2 functions need to make sure they aren't called for a pParse instance that already has an error value set, so they should either check pParse->rc and assert() or return or both if already non-zero.
- sqliteAuthBadReturnCode() needs to 'return' SQLITE_MISUSE in its pParse->rc member.
- sqliteAuthCheck() needs to set rc = SQLITE_DENY after the call to sqliteAuthBadReturnCode() so that the actual error code is passed to that function. |
|
227 |
code
|
fixed
|
2003 Jan
|
anonymous
|
Pager
|
2003 Jan
|
|
2
|
1
|
win32 db locked
|
edit |
in win32 - boundschecker warns about: "API failure
LockFile returned 0x00000000
LastError: The process cannot access the file because another process has locked a portion of the file."
this happens in os.c line 1020 during sqlite_open.
this happens mostly when i don't implement myself a mutex that would prevent 2 threads from accessing the db in the same time.
in the image you'll notice that this happens event though id->locked = 0
a similar problem happens in os.c line 1115. in the attached example it happened in a simple update sql command ("update ac set Mode = 4 where AC_ID = 1").
see image:
|
Unless I badly misunderstand what is being said above, the
LockFile() API is doing exactly what it is suppose to do - it
is failing if another process or thread already has the file locked.
This is how SQLite detects that another process or thread already
has the database locked.
This is a feature, not a bug. |
|
226 |
code
|
fixed
|
2003 Jan
|
anonymous
|
Unknown
|
2003 Jan
|
|
2
|
2
|
Glob doesn't work for upercase letters
|
edit |
BEGIN TRANSACTION;
create table test (id integer primary key, name varchar(10));
INSERT INTO test VALUES(1,'abcABC exapmle');
COMMIT;
sqlite> select * from test where name glob "*C*";
sqlite> select * from test where name glob "*c*";
1|abcABC exapmle
sqlite>
Looking at util.c, function sqliteGlobCompare. There are missing conversion UpperToLower in next piece of code:
}else{
while( (c2 = *zString)!=0 ){
while( c2 != 0 && c2 != c ){ c2 = *++zString; }
if( c2==0 ) return 0;
if( sqliteGlobCompare(&zPattern[1],zString) ) return 1;
sqliteNextChar(zString);
}
Possible fix:
}else{
while( (c2=UpperToLower[*zString])!=0 ){
while( c2 != 0 && c2 != c ){ c2 = UpperToLower[*++zString]; }
if( c2==0 ) return 0;
if( sqliteGlobCompare(&zPattern[1],zString) ) return 1;
sqliteNextChar(zString);
}
|
|
225 |
code
|
fixed
|
2003 Jan
|
anonymous
|
Unknown
|
2003 Jan
|
|
3
|
4
|
reading uninitialized memory
|
edit |
during sqlite_open, in random.c line 69.
sqliteOsRandomSeed(k); initializes only about 12 bytes for k[256] but then the function tries to use all 256 bytes for creating the random number. |
Hopefully, the uninitialized memory will contain random
information, since that will increase the randomness of
the starting value for the random number generator. This
is a feature, not a bug. |
|
224 |
code
|
fixed
|
2003 Jan
|
anonymous
|
Pager
|
2003 Jan
|
|
3
|
3
|
read overflows memory
|
edit |
in pager.c line 1058 - doing operation on memory that's out of bound.
upon deletion of entries from table.
(pPager->aInJournal[pgno/8] points to some random memory)
see image:
|
I modified the code to always check the memory allocation prior
to line 1058 and then reran the entire test suite. No problems
were ever detected. Until evidence to the contrary emerges, I'm
going to assume this is another bug in the boundschecker program
being used and not a problem with SQLite. |
|
223 |
code
|
fixed
|
2003 Jan
|
anonymous
|
VDBE
|
2003 Jan
|
|
3
|
3
|
using uninitialized memory's value
|
edit |
in vdbe.c line 5188 - unitialized memory's value is used. i don't know how bad this is.
as you can see - nErr's value is usueless after such an operation.
see image:
|
The bug here was that the nErr variable is never used. It has
now been removed. |
|
222 |
code
|
fixed
|
2003 Jan
|
anonymous
|
VDBE
|
2003 Jan
|
|
3
|
3
|
cleanup tries to access memory out of array bounds
|
edit |
upon db creation - in WIN32 - the cleanup tries to pop from the stack at location -1.
see image for better explanation - as you can see the p->tos == -1
|
This is a bug in the boundschecker program used, not in SQLite.
The -1 element of the array is never really accessed. We just
compute its address (which is a perfectly legal thing to do.)
But the address is never used because N is 0 and so the while
loop never executes.
Nevertheless, I have revised the code to be less confusing to
bounds checker programs. |
|
221 |
doc
|
fixed
|
2003 Jan
|
anonymous
|
|
2003 Jan
|
|
2
|
4
|
pragma show_datatypes not documented
|
edit |
N/A |
Duplicate of ticket #97. |
|
220 |
code
|
fixed
|
2003 Jan
|
anonymous
|
|
2003 Jan
|
|
4
|
3
|
AS clause disables retrieving data types
|
edit |
pragma show_datatypes=ON
select 4+5 returns 'NUMERIC'
select 4+5 as a returns NULL
same for 'TEXT'. So it seems show_datatypes doesn't work as soon as 'AS' is used. |
Same as ticket #153. |
|
218 |
new
|
fixed
|
2003 Jan
|
anonymous
|
|
2003 Jan
|
|
2
|
2
|
MacOS port for submission to CVS
|
edit |
I have modified os.h, os.c and shell.c to work under MacOS compiled with CodeWarrior (version 8). This applies to Classic and Carbon builds. For OS X (aka Darwin) use Apple's tools (gcc) and treat as Unix.
I have done a basic set of tests to verify that everything works, and everything seems to work with no problems. I have verifed all 3 builds: Classic, Carbon and Darwin. I have also checked that the files produced on the Mac are fully recognised and read by the Linux version of sqlite.
The modified files are attached. |
A couple of things I forgot to mention:
- I have put in the the option to change the temporary file name prefix. This defaults to what was there previously. See my comments in the file.
- On sqliteOsFullPathname(), Windows version, GetFullPathName() returns the number of bytes required not including the null terminator. It needs one more byte to be allocated, which I have put in.
(DRH adds: The return value of GetFullPathName() does include
space for the null-terminator according to the documentation on
microsoft's website. But allocating an extra byte won't hurt and
it will probably protect against bugs in the microsoft documentation,
so I left it in.)
|
|
215 |
new
|
fixed
|
2003 Jan
|
anonymous
|
|
2003 Feb
|
|
4
|
2
|
sqlite authorizer callback
|
edit |
New feature that adds an interface or hook for an application that
wants to control if an access to a table/row should be granted or denied.
This could be done be with following interface function as discussed on the mailing list:
int sqlite_set_authorizer(
sqlite*,
int (*xAuth)(void*, int op, const char*, const char *),
void*
);
The xAuth() function is called during the code generation phase to
check access permissions on each column accessed. The "op" argument
is one of SQLITE_READ or SQLITE_WRITE. zTable is the name of the
table and zColumn is the name of the column being accessed. The
xAuth() function should return SQLITE_OK to permit access,
SQLITE_DENY to deny access (causing sqlite_exec() to return
SQLITE_DENY without executing any part of the request) or
SQLITE_IGNORE to cause reads to yield NULL and writes to become
no-ops.
If the xAuth argument to sqlite_set_authorizer is NULL, then
authorization is disabled. |
The actual implementation ended up being somewhat more complex than
this. See the documentation for details. |
|
213 |
new
|
fixed
|
2003 Jan
|
anonymous
|
Unknown
|
2003 Aug
|
|
4
|
4
|
Cygwin port needs __CYGWIN_USE_BIG_TYPES__ defined
|
edit |
When building on the cygwin platform, an incompatible typedef of 'off_t' is made in src/os.h at line 92 (the clash is with /usr/include/cygwin/types.h at line 27. The cygwin type is to '__off32_t' which is 'long'. The sqlite type is 'long long'.
However, if __CYGWIN_USE_BIG_TYPES__ is defined upon processing of /usr/include/cygwin/types.h, the declarations match (both are 'long long').
A workaround is simply to add '#define __CYGWIN_USE_BIG_TYPES__' to either the makefile options or the top of sqliteInt.h.
Thanks |
Sorry, this is incorrect. I reran the configure script and ran make on the resulting makefile under cygwin and the build ran completely perfectly.
I have not been able to successfully make sqlite under cygwin
Same symptoms:
Environment is a fresh install of the latest cygwin:
$ uname -a
CYGWIN_NT-5.0 host040 1.3.22(0.78/3/2) 2003-03-18 09:20 i686 unknown unknown Cygwin
--Derek Lane |
|
212 |
code
|
fixed
|
2003 Jan
|
drh
|
Pager
|
2003 Jan
|
|
2
|
1
|
Corrupt database results if the very first transaction rolls back.
|
edit |
If you open a new database (initial file size of 0 bytes) and start
a transaction, and make it a big transaction so that information is
written to disk during the transaction, then if you rollback that
transaction, the rollback fails and you are left with a corrupt
database file.
This only happens if you start with an initially empty database, so
there is not any danger of losing real data. But it is annoying. |
|
211 |
new
|
fixed
|
2002 Dec
|
anonymous
|
Unknown
|
2003 Jan
|
|
4
|
4
|
How to add comments to an SQL-File
|
edit |
This is not a bug, but I was unable to find anything in the documentation ...
How can I insert a comment in an SQL-File ? Something like
-- This is a comment
Currently sqlite reacts with :
Incomplete SQL: -- This is a comment
By the way, sqlite is great ... :-) |
Comments can be entered like this:
-- a comment
or this:
/* C-like comment */
But you cannot enter a comment inside an expression:
CREATE TABLE T1(
-- comment inside argument list
datetime int);
This is the only way in which I could get parsing a comment to fail.
The page "SQL As Understood By SQLite"("lang.html") could use a short section on comments.
Jim Lyon (jplyon ta attglobal tod net)
Comments inside a table declaration work. In the "sqlite" shell,
if comments occurred at the end of a file (with no ";" following)
then an error was reported. This is fixed by check-in [838]
. |
|
210 |
code
|
fixed
|
2002 Dec
|
anonymous
|
Unknown
|
2003 Jan
|
drh
|
1
|
1
|
Segfault on OSX with Perl bindings
|
edit |
Hi,
I'm the author of the Perl bindings for SQLite (DBD::SQLite).
Since updating to 2.7.4 I'm getting strange segfaults when doing a looping bunch of inserts (in the benchmark part of the test harness - tests 500 inserts).
The relevant part of the test suite is this code:
$dbh->do("CREATE TABLE bench (id INTEGER, name CHAR(40),"
. " firstname CHAR(40), address CHAR(40),"
. " zip CHAR(10), city CHAR(40), email CHAR(40))");
my(@vals) = (0 .. 499);
my($num);
TimeMe("Testing INSERT speed ...",
"%d rows in %.1f cpu+sys seconds (%d per sec)",
sub {
($num) = splice(@vals, int(rand(@vals)), 1);
$dbh->do("INSERT INTO bench VALUES (?, 'Wiedmann', 'Jochen',"
. " 'Am Eisteich 9', '72555', 'Metzingen',"
. " 'joe\@ispsoft.de')", undef, $num);
},
500);
I've been unable to trace what's causing the segfault, so I'm hoping you might be able to help me here. Here's a backtrace of when the segfault occurs:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x002c4914 in cellSize (pBt=0x140430, pCell=0x0) at btree.c:395
395 int n = NKEY(pBt, pCell->h) + NDATA(pBt, pCell->h);
(gdb) bt
#0 0x002c4914 in cellSize (pBt=0x140430, pCell=0x0) at btree.c:395
#1 0x002caf94 in balance (pBt=0x140430, pPage=0x1cc8f0, pCur=0x1c8340) at btree.c:2294
#2 0x002cc430 in sqliteBtreeInsert (pCur=0x1c8340, pKey=0xbfffe6e4, nKey=4, pData=0x1c8370, nData=72) at btree.c:2562
#3 0x00306510 in sqliteVdbeExec (p=0x1ca880, xCallback=0x2f5e74 <sqlite_get_table_cb>, pArg=0xbfffec40, pzErrMsg=0xbfffeb84, pBusyArg=0x7530, xBusy=0x2e40e0 <sqliteDefaultBusyCallback>) at vdbe.c:3745
#4 0x002ce638 in sqliteExec (pParse=0xbfffeb70) at build.c:73
#5 0x002ea570 in yy_reduce (yypParser=0x1ca1a0, yyruleno=3) at parse.y:67
#6 0x002ed0cc in sqliteParser (yyp=0x1ca1a0, yymajor=0, yyminor={z = 0x1c823d ")", dyn = 0, n = 1}, pParse=0xbfffeb70) at parse.c:6790
#7 0x002f77ac in sqliteRunParser (pParse=0xbfffeb70, zSql=0x1c81d0 "INSERT INTO bench VALUES ('70', 'Wiedmann', 'Jochen', 'Am Eisteich 9', '72555', 'Metzingen', 'joe@ispsoft.de')", pzErrMsg=0xbfffeccc) at tokenize.c:469
#8 0x002e3d44 in sqlite_exec (db=0x1b6350, zSql=0x1c81d0 "INSERT INTO bench VALUES ('70', 'Wiedmann', 'Jochen', 'Am Eisteich 9', '72555', 'Metzingen', 'joe@ispsoft.de')", xCallback=0x2f5e74 <sqlite_get_table_cb>, pArg=0xbfffec40, pzErrMsg=0xbfffeccc) at main.c:633
#9 0x002f6314 in sqlite_get_table (db=0x1b6350, zSql=0x1c81d0 "INSERT INTO bench VALUES ('70', 'Wiedmann', 'Jochen', 'Am Eisteich 9', '72555', 'Metzingen', 'joe@ispsoft.de')", pazResult=0x1c5220, pnRow=0x1c5224, pnColumn=0x1c522c, pzErrMsg=0xbfffeccc) at table.c:150
#10 0x002d5e38 in sqlite_st_execute (sth=0x19d908, imp_sth=0x1c51b0) at dbdimp.c:302
#11 0x002c2914 in XS_DBD__SQLite__st_execute (cv=0x1b3be8) at SQLite.xsi:398
[snip]
As you can see, pCell is NULL in the call to cellSize(). Email me if you want more backtrace details.
The segfault doesn't occur on my Linux box. No idea why not - perhaps stricter type checking, perhaps different optimisations or something.
It occurred to me it might be different optimisation flags too, but turning off all optimisations didn't get rid of the bug. |
OSX is big endian. Is your Linux box little endian? -- e
Yes, it's intel. -- matt
OK, found the bug. It was my stupid. The perl bindings forgot to copy over config.h, so a config.h from somewhere else in the path got picked up, and SQLITE_PTR_SZ wasn't defined, so things broke. Thanks to drh for adding the asserts though that pointed out where the problem was! Marking bug as fixed. -- matt. |
|
208 |
code
|
fixed
|
2002 Dec
|
anonymous
|
BTree
|
2002 Dec
|
|
2
|
2
|
pager.c uninitlized local variable
|
edit |
LINE 832:
static int syncAllPages(Pager pPager){
PgHdr *pPg;
/ AOS Correction to add 0 initializer */ Pgno lastPgno = 0;
int rc = SQLITE_OK;
LINE 854:
if( lastPgno==0 || pPg->pgno!=lastPgno+1 ){
<lastPgno> used before being initialized. |
This bug was introduced by check-in [795]
.
It could (in theory) lead to database corruption, though
that is unlikely. |
|
206 |
code
|
fixed
|
2002 Dec
|
anonymous
|
Pager
|
2003 Jan
|
|
3
|
3
|
Local variable used before it is initialised
|
edit |
As reported by Visual C++
M:\Projects\sqlite\OsxBuild\tsrc\pager.c(853) : warning C4700: local variable 'lastPgno' used without having been initialized
MSVC is fussy and reports other things, which probably won't be a problem. It's probably worth checking and putting casts in if the functionality is deliberate:
M:\Projects\sqlite\OsxBuild\tsrc\os.c(562) : warning C4244: 'initializing' : conversion from '__int64 ' to 'long ', possible loss of data
M:\Projects\sqlite\OsxBuild\tsrc\os.c(563) : warning C4244: 'initializing' : conversion from '__int64 ' to 'long ', possible loss of data
M:\Projects\sqlite\OsxBuild\tsrc\os.c(604) : warning C4244: 'initializing' : conversion from '__int64 ' to 'long ', possible loss of data
M:\Projects\sqlite\OsxBuild\tsrc\os.c(605) : warning C4244: 'function' : conversion from '__int64 ' to 'long ', possible loss of data
M:\Projects\sqlite\OsxBuild\tsrc\os.c(605) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\pager.c(394) : warning C4018: '>' : signed/unsigned mismatch
M:\Projects\sqlite\OsxBuild\tsrc\pager.c(480) : warning C4244: '=' : conversion from '__int64 ' to 'int ', possible loss of data
M:\Projects\sqlite\OsxBuild\tsrc\pager.c(538) : warning C4244: '=' : conversion from '__int64 ' to 'int ', possible loss of data
M:\Projects\sqlite\OsxBuild\tsrc\pager.c(555) : warning C4244: '=' : conversion from '__int64 ' to 'int ', possible loss of data
M:\Projects\sqlite\OsxBuild\tsrc\pager.c(724) : warning C4244: '=' : conversion from '__int64 ' to 'int ', possible loss of data
M:\Projects\sqlite\OsxBuild\tsrc\pager.c(726) : warning C4244: 'return' : conversion from '__int64 ' to 'int ', possible loss of data
parse.c(6827) : warning C4761: integral size mismatch in argument; conversion supplied
parse.c(6838) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\select.c(100) : warning C4018: '==' : signed/unsigned mismatch
M:\Projects\sqlite\OsxBuild\tsrc\vdbe.c(2123) : warning C4244: 'initializing' : conversion from 'double ' to 'int ', possible loss of data
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(2385) : warning C4018: '<' : signed/unsigned mismatch
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(637) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(1841) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(1843) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(524) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(528) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(542) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(546) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(549) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(490) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(491) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(418) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(429) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(440) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(442) : warning C4761: integral size mismatch in argument; conversion supplied
M:\Projects\sqlite\OsxBuild\tsrc\btree.c(2003) : warning C4761: integral size mismatch in argument; conversion supplied |
|
202 |
code
|
fixed
|
2002 Dec
|
anonymous
|
|
2002 Dec
|
|
1
|
1
|
make test core-dumps on solaris
|
edit |
I untarred sqlite, created a sqlite-build folder, went in there, ../sqlite/configure, then make.
make test proceeded through to the misuse tests without incident, but then:
misuse-5.3... Ok
make: *** [test] Segmentation Fault (core dumped)
This is on Solaris 2.7 (ultrasparc, 32-bit OS), with TCL 8.3 installed. Compiler is GCC 3.1. |
I applied the patch from check-in [799]
onto 2.7.3 (well, got the patch from cvs in case of HTML formatting problems) and rebuilt from scratch. The full test suite runs without error now.
The test suite also runs without error in the CVS HEAD as of Dec 17, noon.
It's worth noting that I upgraded to TCL 8.4.1 while trying to isolate the bug. So, the above successful tests were run with libtcl8.4. However, misuse.test runs to completion on 8.3 as well. |
|
200 |
code
|
fixed
|
2002 Dec
|
anonymous
|
Pager
|
2002 Dec
|
|
3
|
3
|
full pathname of database not recorded, so errors when chdir used
|
edit |
When a db is opened with sqlite_open(), only the filename argument is saved, not the full pathname or current directory. If the program subsequently changes the current directory, and the argument to sqlite_open() was not a full pathname, then the journal file will be created in an arbitrary place. This leads to many potential errors, including no possibility of recovery, or runtime errors. An example Windows tcl session demonstrating one problem is below. Here the e: drive is initially empty, and then a CD-ROM is inserted. By changing to this drive as the current directory, sqlite is unable to create the journal file despite the fact that the db is on a writable drive.
14 % sqlite db test.db
0x009D7FB8
() 15 % cd a:
couldn't change working directory to "a:": file busy
() 16 % cd e:
couldn't change working directory to "e:": file busy
() 17 % cd e:
() 18 % db eval {CREATE TABLE t1(a int, b text)}
unable to open database file
() 19 % cd c:
() 20 % db eval {CREATE TABLE t1(a int, b text)}
SQL logic error or missing database
() 21 % db close
() 22 % sqlite db test.db
0x009D7FB8
() 23 % db eval {CREATE TABLE t1(a int, b text)}
() 24 % cd e:
() 25 % db eval {CREATE TABLE t2(a int, b text)}
unable to open database file
() 26 % cd c:
() 27 % db eval {select * from t1}
() 28 % db eval {CREATE TABLE t2(a int, b text)}
SQL logic error or missing database
() 29 % db eval {select * from t1}
() 30 % db eval {select * from t2}
no such table: t2
() 31 %
|
|
198 |
todo
|
fixed
|
2002 Dec
|
anonymous
|
|
2003 Jan
|
|
1
|
1
|
Descending sort order in indices
|
edit |
Wouldn't it be an idea to (bitwise) invert an index' column data if the column is to be sorted in descending order? By this you will get the right effect with a minimum of effort. |
Check-in [795]
enhances the query optimizer so that it will scan
a table or index backwards if that will help implement an
ORDER BY ... DESC clause. Is this what you are asking for? |
|
197 |
code
|
fixed
|
2002 Dec
|
anonymous
|
Unknown
|
2002 Dec
|
|
1
|
1
|
Missing .yacc & .lex file...
|
edit |
I encountered annyoing disability with sqlite (no 'LIKE') and i wanted to add it, but as sources are generated, changing them is really painfull... would you be so nice and add yaccs input files to the distribution. Anyway usefull program...
Thank you, Rok Erjavec, Slovenia |
- SQLite supports LIKE. Also NOT LIKE, GLOB, and NOT GLOB.
- The lexical analyzer is hand-coded. The source file is
tokenize.c
- The parser is generated using
Lemon, not Yacc. The
grammer is defined by the parse.y source file. The source code
and documentation for Lemon are also include in the distribution.
|
|
195 |
code
|
fixed
|
2002 Nov
|
anonymous
|
|
2002 Nov
|
|
2
|
4
|
Borland Compiler error for long long definition in os.h
|
edit |
This problem is in os.h version 1.17
The borland compiler needs to use the first definition of a 64 bit integer so if you change the following code:
# ifdef _MSC_VER
typedef __int64 off_t;
# else
typedef long long off_t;
# endif
to this:
#if defined(_MSC_VER) || defined(__BORLANDC__)
typedef __int64 off_t;
# else
typedef long long off_t;
# endif
It fixes the problem. |
|
194 |
new
|
fixed
|
2002 Nov
|
anonymous
|
BTree
|
2003 Apr
|
|
5
|
3
|
Remove warnings in btree.c
|
edit |
Please remove the annoying warnings in btree.c that appear when using the visual c++-compiler.
You just have to change two lines in btree.c...
Change line 64 to:
#define SWAB16(B,X) ((B)->needSwab? swab16((u16)(X)) : ((u16)(X)))
and line 520 to:
pFBlk->iSize = swab16((u16)(swab16(pNext->iSize)+iSize+size));
(The casts to u16 are new.)
The line numbers belong to the 2.7.3-release of sqlite - i am sure you will find these lines in your version... |
|
193 |
code
|
fixed
|
2002 Nov
|
anonymous
|
Unknown
|
2002 Dec
|
|
3
|
3
|
Incorrect creation of a VIEW when using SELECT ... LIMIT
|
edit |
First of all, I really like your efforts. SQLite is a great product and I'm very happy to be able to use it.
The bug occured when I executed the following SQL query:
CREATE VIEW top3 AS SELECT DISTINCT COUNT(*) FROM restaurants GROUP BY plaats ORDER BY COUNT(*) DESC LIMIT 3
Where the table 'restaurants' is defined as follows:
CREATE TABLE restaurants (plaats, naam, adres, postcode, toelichting, telefoonnummer)
Executing the following query on the 'top3' view...
SELECT * FROM top3
...gives the following resultset:
2
1
3
While executing...
SELECT DISTINCT COUNT(*) FROM restaurants GROUP BY plaats ORDER BY COUNT(*) DESC LIMIT 3
...gives this resultset:
15
13
7
In other words: when creating a view based on SELECT ... ORDER BY query, the ordering gets lost, which (when using a LIMIT) results in a wrong VIEW.
It is interesting to know that this only happens when creating a view. When creating a similar table, using this query...
CREATE TABLE top3 AS SELECT DISTINCT COUNT(*) FROM restaurants GROUP BY plaats ORDER BY COUNT(*) DESC LIMIT 3
...the ordering is taken into account.
If you need any more information (I will try to include the database, which actually contains the addresses of McDonald's restaurants in the Netherlands), please let me know.
Regards,
Michiel de Wit |
|
191 |
code
|
fixed
|
2002 Nov
|
anonymous
|
Unknown
|
2003 Jan
|
drh
|
1
|
1
|
Large file support does not work in Windows
|
edit |
Any database that is larger than 4GB becomes non-operational, at least for the tables that are beyond the 32-bit limit. Hint: I artifically enlarged the database by increasing the file size manually, as suggested by drh. |
Warnings in #206 may point to the cause (unwitting truncation of 64-bit integers). |
|
190 |
code
|
fixed
|
2002 Nov
|
anonymous
|
|
2002 Nov
|
|
1
|
3
|
the btree code crashes on LP64 systems
|
edit |
The uptr type is defined as an int, which breaks on systems where this
is less than a pointer (specifically I get a core dump on alpha). I know this type can be redefined, but it's usually unnecessary to use an integer type at all. As far as I can
tell this type is only used in the btree code and when hashing on
pointers. In the first case a char* would do just fine, and should
work on most systems (but probably not vector crays, but neither should the current code).
For the hash
code there is no help, but then it doesn't really use the casted
value. |
|
189 |
code
|
fixed
|
2002 Nov
|
anonymous
|
|
2002 Nov
|
|
4
|
4
|
sqlite html output format produces extra </TD>
|
edit |
$ sqlite -html foo 'select * from test;'
<TR><TD>some data</TD>
</TD></TR>
The last </TD> should not be there. |
|
187 |
code
|
fixed
|
2002 Nov
|
anonymous
|
Parser
|
2002 Dec
|
|
2
|
2
|
Having count(*) issue
|
edit |
/* FAILING QUERY */
SELECT PARTOFFT
FROM ROLE
GROUP BY PARTOFFT
HAVING COUNT(*)=2;
/* ACCEPTED QUERY */
SELECT PARTOFFT, COUNT(*)
FROM ROLE
GROUP BY PARTOFFT
HAVING COUNT(*)=2;
/* USELESS IN SUBQUERIES LIKE */
SELECT PARTOFFT, ROLE
FROM ROLES
WHERE PARTOFFT IN (
SELECT PARTOFFT
FROM ROLE
GROUP BY PARTOFFT
HAVING COUNT(*)=2); |
|
185 |
code
|
fixed
|
2002 Oct
|
anonymous
|
Unknown
|
2002 Oct
|
|
1
|
1
|
Crash when running specific SQL
|
edit |
As per https://sourceforge.net/tracker/?func=detail&atid=402788&aid=630828&group_id=31577 my user has sent me the related database as a ZIP file. I can forward that to you, just tell me how.
I don't get the same error on 2.7.1 on Linux.
The following script demonstrates the problem:
create table t1(a,b);
insert into t1 values(1,2);
select * from t1 where a in ();
select * from t1 where a in (1,2) and b in ();
Segfaults occur if the "IN" operator is used with
empty sets. |
|
179 |
code
|
fixed
|
2002 Oct
|
drh
|
|
2002 Oct
|
anonymous
|
1
|
1
|
Column names and string constants in parentheses cause errors.
|
edit |
Given a type like this:
CREATE TABLE t(x);
The following statements fail:
SELECT * FROM t WHERE (x)==('hi');
If the parentheses are removed, it works. |
|
178 |
code
|
fixed
|
2002 Oct
|
anonymous
|
Unknown
|
2002 Oct
|
|
2
|
3
|
Undefinied pointer with sqlite_get_table (empty result set)
|
edit |
if i run the following program, the pointer 'result[0]' is not defined. But it will be freed in sqlite_free_table().
The problem is, that sqlite_get_table() set nData=1, but there are no datas. |
I am not able to reproduce this problem. The code in the attachment
runs fine on my machine (RedHat 8.0) and it never tries to free
unallocated memory. result[0] is undefined, but that is because
there are no rows and no columns in the result set. But
sqlite_free_table() never tries to free result[0], so that is not
a problem, as far as I can tell. |
|
176 |
code
|
fixed
|
2002 Oct
|
mike
|
|
2002 Oct
|
drh
|
1
|
3
|
locking mechanism fails under Windows
|
edit |
There is a subtle defect in the locking mechanism used for Windows. The os.c code for windows uses LockFile() for locking, and an area of MX_LOCK_BYTES(10240) from the beginning of the file, essentially using the file itself for implementing multi-read-exclusive-write semaphores. this is a standard technique, but in all Microsoft operating systems (including DOS, and all versions of Windows), there is a caveat: When a lock is obtained in an area of a file, it exludes everybody else from reading that area. "everybody else" includes any other threads of the process that created the lock (!) Which means that, if the "real" data portion of the file is being used in this way (as semaphores), it may conflict with a legitimate attempt to read the data. This actually happened quite often in a stress test with multiple threads that I wrote. The result is that the engine gives an I/O error. This is a design bug, not a code bug. possible work-arounds are :
1. use a separate file for the locks, not the data file.
2. NEVER use the semaphore area for actual data (ie create a reserved area of MX_LOCK_BYTES in the beginning of the file). not a very good idea, but easy to implement, and would work.
3. Use the lock-beyond-eof technique. In Windows and DOS, the LockFile function will work for offsets than are beyond the physical end-of-file. this is documented. it potentially has the same problem , of course. if you lock beyond EOF, and the file has to extend , and it covers the locked area, then the write will fail (as opposed to the read failing with the current design). One way to solve this is to lock as far as possible from the eof. My technique involves locking at the 4GB limit (0xFFFFFFFF), minus the size of the semaphore area. This will of course limit the maximum size of the database, by this amount. in fact, in Windows NT/2000/XP, the Lockfile functions take 64-bit arguments, so, you could use the terrabyte area for this lock, and nobody is going to reach that limit, anyway.
so, my suggested fix is, in pseudo-code :
a. add some code to detect that you are in Win9x or NT/2000/xp
b. if in 9X, bias all your lock calls by 0xFFFFFFFFF-MX_LOCK_BYTES
c. if in winnt, bias by 0xFFFF FFFFF FFFFF FFFF - MX_LOCK_BYTES
I have already tried (c), and it does solve the problem.
PS. on the same subject: byte (0) (biased or not) of the file is used as a "sync" mutex, to ensure that no two processes are modifying the lock area at the same time. with the current design, if a conflict occurs in this lock, the locking mechanism aborts with SQLITE_BUSY. My suggestion is to make this is blocking call, and loop until a lock can be obtained. since this is a temporary lock that will always be released immediately, and since this would be the first action of the locking code, the possibility of a deadlock does not exist. this will improve the retry behavior of the engine (or the user code in case the user is handling the retries), since the sync lock by itself will not return with SQLITE_BUSY errors. SQLITE_BUSY itself should IMHO only have the semantics of "database is locked for updating", and it should not reflect the internal locking and sync mechanism, as it does now..
finally, last hint: make MX_LOCK_BYTES such that biasing is easy (65536 is a better choice, since the arithmetic is "lighter", just drop the least significant word) |
The recommended solution (3) also solved my lock problems on Win32, but I wasn't using threads at all. I had two separate processes, one inserting, and the other selecting. I would consistently see io errors from the writing process. I have no idea how the solution of locking a range beyond the file's size fixes this, but it seems to. All I did was change all the high-offset arguments (argument 3) to LockFile and UnlockFile from 0 to 1 -- I am running on Win2k so going beyond 2**32 is OK. Perhaps something in the insert code was trying to read the database in an area locked by the select before grabbing the write lock? -- e |
|
174 |
code
|
fixed
|
2002 Oct
|
anonymous
|
Unknown
|
2002 Oct
|
drh
|
1
|
3
|
inconsistent data types
|
edit |
According to the doc, a table created as CREATE TABLE XXX(a,b,c) (no data types) should create columns of NUMERIC type. when using the PRAGMA SHOW_DATATYPES, the columns are reported as NUMERIC (which is ok). however, the PRAGMA table_info shows them as TEXT, which is inconsistent with the documentation. |
|
173 |
todo
|
fixed
|
2002 Oct
|
anonymous
|
|
2002 Oct
|
drh
|
4
|
3
|
publish.sh does not build dll correctly
|
edit |
The publish.sh script does not contain an export definition for
sqlite_function_type, which results in the function not being exported from the DLL. |
|
171 |
code
|
fixed
|
2002 Oct
|
anonymous
|
|
2002 Oct
|
drh
|
1
|
3
|
incompatibility with Borland run-time library
|
edit |
The borland run-time malloc behaves differently than the Ms equivalent, and presumably than the Linux equivalent. When 0 is passed as an argument, the Borland malloc returns a nil pointer, but the Ms version returns a valid, 0-length pointer. The code in util.c contains two version of sqliteMalloc. the one used with MEMORY_DEBUG correctly works around this issue by testing for 0 and returning nil. however, the non-debug version lacks this test. It seems that some defect in the logic in some other place will attempt to Malloc 0 bytes (which IMHO it should not), and, as a result, the malloc (and all subsequent mallocs) fail.
solution: modify Sqlitemalloc thus:
void *sqliteMalloc(int n){
void *p;
if( n==0 ) return 0; <-- add this line
p = malloc(n);
if( p==0 ){
sqlite_malloc_failed++;
return 0;
}
memset(p, 0, n);
return p;
} |
|
168 |
new
|
fixed
|
2002 Oct
|
anonymous
|
Shell
|
2003 Apr
|
|
4
|
4
|
Startup file complicates dumping a database
|
edit |
The example shown for dumping a database from the command line does not work if there is a startup file, since the first line of stdout contains the "Loading resources from ..." text. An option such as
-dump that would supress this message would be useful. I had to write a shell script to rename the startup file before dumping. |
|
166 |
code
|
fixed
|
2002 Oct
|
anonymous
|
Unknown
|
2002 Oct
|
|
1
|
1
|
Left outer join doesn't seem to be working
|
edit |
The left outer join appears to be giving identical results as an inner join. I'm not getting all rows from the left table. I'm not positive that this is inherent to 2.7.2, as I've found the bug by using the shell program on a database created by zeecookbook. Zeecookbook wasn't giving me the correct values, so I downloaded the shell program for windows and ran queries of my own to see where the problem was. Example:
recipe_ingredient table that has a unit_id column, unit table with an id column that is used in the recipe_ingredient table unit_id column
If I have 5 rows in recipe_ingredient, and 2 of the rows have either a null value and/or a value that is not in the unit table, they don't appear in the results of a recipe_ingredient left outer join unit on unit_id = unit.id
I just tried the same query in mysql to verify my results, using the exact same tables and data and the results are correct in mysql, but not in sqlite. |
Here is a dump of the two tables I'm joining, as well as a sql statement to show how to reproduce:
CREATE TABLE recipe_ingredient (id INTEGER PRIMARY KEY, recipe_id,
position, quantity, unit_id, ingredient_id, is_group);
INSERT INTO recipe_ingredient VALUES(1,1,1,2,1,1,0);
INSERT INTO recipe_ingredient VALUES(2,1,2,1,2,2,1);
INSERT INTO recipe_ingredient VALUES(3,1,5,6,3,3,0);
INSERT INTO recipe_ingredient VALUES(4,1,3,'6-7',-1,4,0);
INSERT INTO recipe_ingredient VALUES(5,1,4,'6-7',-1,4,0);
INSERT INTO recipe_ingredient VALUES(6,1,6,'6-7',3,4,0);
CREATE TABLE unit (id INTEGER PRIMARY KEY, name);
INSERT INTO unit VALUES(1,'Pkg');
INSERT INTO unit VALUES(2,'cup');
INSERT INTO unit VALUES(3,'Pcs');
SELECT recipe_ingredient.id, recipe_ingredient.position, unit.name
FROM recipe_ingredient LEFT JOIN unit
ON recipe_ingredient.unit_id = unit.id;
The output of this query is:
1|1|Pkg
2|2|cup
3|5|Pcs
||
and should have been:
1|1|Pkg
2|2|cup
3|5|Pcs
4|3|
5|4|
6|6|
Hope this helps
2005-Nov-20 06:29:07 by anonymous:
I just tried the example today in sqlite3 3.1.3 and got the wrong result:
1|1|Pkg
2|2|cup
3|5|Pcs
4|3|
5|4|
6|6|Pcs
That Pcs should not be there in the last line: very scary!
2005-Nov-20 06:30:23 by anonymous:
No, I take it back: doing it by hand the Pcs looks correct. Why is the original wrong? |
|
163 |
code
|
fixed
|
2002 Oct
|
anonymous
|
Unknown
|
2002 Oct
|
|
2
|
2
|
Buggy initialization of random generator on win32
|
edit |
The function sqliteOsRandomSeed will always set the same random seed due to a wrong usage of the GetSystemTime API function on win32.
It will copy the first 4 bytes of the SYSTEMTIME structure as the random seed, but they represent the year which is the same for quite a long time.
I would suggest to use a simple time(NULL) call instead (that works on Win32 and unix):
#include <time.h>
...
int sqliteOsRandomSeed(char *zBuf){
int seed;
static int once = 1;
#ifdef SQLITE_TEST
/* When testing, always use the same random number sequence.
** This makes the tests repeatable.
*/
seed = 1;
#else
seed = time(NULL);
#endif
if( once ){
srand(seed);
once = 0;
}
return SQLITE_OK;
}
|
The call to srand() was not being used for anything and has been
removed. The real work of sqliteOsRandomSeed() is to come up with
a 256-byte seed for the RC4 pseudorandom number generator coded
in random.c. The entire SYSTEMTIME structure is being used for
this, not just the first four bytes. |
|
160 |
code
|
fixed
|
2002 Oct
|
anonymous
|
|
2005 Jan
|
|
1
|
4
|
trigger not called when user-defined function used
|
edit |
* Schema:
create table work (oid, id integer,
person, workitem, workdate, duration, description, last_change)
* Trigger definition
create trigger trig_work_insert after insert on work
begin
update work set last_change=timestamp() where id=new.id;
end;
* Custom user-defined functions from PySQLite named new_id() and timestamp()
* cursor.execute("insert into work(id) values (new_id('work'))")
==> Trigger not called
* cursor.execute("insert into work(id) values (100)")
== Trigger called |
Yep this is another bug. The problem is that the new_id() function is being evaluated twice, and is presumably returning a different value each time. The algorithm for INSERT triggers is currently:
* Build up and store a row for new.* references ( this is the first evaluation of new_id() )
* Execute BEFORE INSERT triggers.
* insert a row into the table (this is the second evaluation of new_id() )
* Do the AFTER INSERT triggers.
One could argument that this is a bug in the new_id() function since
SQL functions should not (in principle) have side-effects.
I have been giving some thought to eliminating the stack from the
VDBE and storing intermediate results in virtual registers. The
original motivation for this change would be to implement common
subexpression elimination. A common subexpression could be evaluated
once with the result stored in a virtual register, then the result
of the common subexpression could be reused multiple times. I notice
that such a change might also fix this problem since the new_id()
routine would only be evaluated once and the result pulled from a
virtual register as needed.
2005-Jan-16 19:55:21 by drh:
I think this is fixed by [2158]
. |
|
159 |
code
|
fixed
|
2002 Oct
|
anonymous
|
Unknown
|
2003 Apr
|
drh
|
2
|
2
|
Triggers don't work _at all_ in the presence autoincrement fields
|
edit |
There's this mentioned caveat in the docs for triggers:
Note that currently, triggers may behave oddly when created on
tables with INTEGER PRIMARY KEY fields. If a BEFORE trigger program
modifies the INTEGER PRIMARY KEY field of a row that will be
subsequently updated by the statement that causes the trigger to
fire, then the update may not occur. The workaround is to declare
the table with a PRIMARY KEY column instead of an INTEGER PRIMARY
KEY column.
However, I'm having a different problem:
create table work (
id integer primary key,
foo varchar(20),
last_change timestamp
);
create trigger trig_work_insert after insert on work
begin
update work set last_change=timestamp() where id=new.id;
end;
insert into work (foo) values ('bar');
timestamp() is a custom Python function that I use from PySQLite. Now
the strange thing is that the trigger is NOT called. It is called when I
change the id column to "integer". That's a new kind of bug, right? |
|
155 |
code
|
fixed
|
2002 Sep
|
anonymous
|
Unknown
|
2002 Dec
|
|
2
|
2
|
sqliteSortCompare var dir uninitialized
|
edit |
The variable dir is not initialized. There is a code path in this function that results in the use of this uninitialized variable. This results in a runtime exception under Visual Studio .NET. |
For the record, this is not a bug in SQLite but rather a bug in .NET.
Nevertheless, I have added code to work around the problem.
(2002-Dec-21) I stand corrected. This was actually an SQLite bug.
See ticket #205. |
|
153 |
code
|
fixed
|
2002 Sep
|
anonymous
|
Parser
|
2003 Jan
|
|
1
|
1
|
PRAGMA SHOW_DATATYPES bug
|
edit |
If the pragma SHOW_DATATYPES in ON and one uses a SELECT query with aliasing like "SELECT tablecol AS foo ..." the data type info is missing for the alias column. The not aliased columns show correct data type info. |
Same as ticket #220. |
|
152 |
code
|
fixed
|
2002 Sep
|
anonymous
|
Unknown
|
2002 Sep
|
|
1
|
1
|
"make test" has errors
|
edit |
I got the following errors from "make test":
temptable-6.3...
Expected: [1 {attempt to write a readonly database}]
Got: [0 {}]
temptable-6.4...
Expected: [0 {}]
Got: [1 {table t9 already exists}]
temptable-6.6...
Expected: [1 {attempt to write a readonly database}]
Got: [0 {xyzzy hello}]
temptable-6.7...
Expected: [0 {xyzzy 1 2}]
Got: [0 {xyzzy 1 2 hello 1 2}]
temptable-6.8...
Expected: [1 {no such table: t9}]
Got: [0 {xyzzy 1 2 hello 1 2}]
version-2.1...
Expected: [1 {unable to upgrade database to the version 2.6
format: attempt to write a readonly database}]
Got: [0 0x8083200]
6 errors out of 7193 tests
Failures on these tests: temptable-6.3 temptable-6.4 temptable-6.6 temptable-6.7 temptable-6.8 version-2.1
- compiler: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
- libc RPM: glibc-2.2.4-19.3
- sqlite: sqlite-2.7.1
|
This happens when you try to run the tests as root.
The test script is attempting to create a read-only database
by setting the file permissions to 444. But that doesn't
work for the superuser who can write a file regardless
of the file permissions.
Run the tests as a normal user and they will work.
The tests were modified in check-in [740]
to issue an appropriate
error message if you try to run them as root. |
|
150 |
doc
|
fixed
|
2002 Sep
|
anonymous
|
Unknown
|
2002 Sep
|
anonymous
|
2
|
2
|
Missing documentation files
|
edit |
Some of the doc files are missing. I know for sure that the quickstart.html is one. |
The file quickstart.html is generated by a TCL script named
quickstart.tcl. quickstart.tcl is located in the source
tarball (sqlite-2.7.1.tar.gz) and in the CVS repository.
The derived quickstart.html file is available on the website. |
|
147 |
code
|
fixed
|
2002 Sep
|
anonymous
|
|
2002 Sep
|
|
1
|
1
|
"INSERT into xxx SELECT yyy ORDER BY zzz LIMIT 1" ignores the limit
|
edit |
The following SQL code returns 3 rows of data where it
should only return 1 row:
create table t1(a,b,c);
create table t2(x,y,z);
insert into t1 values(1,2,3);
insert into t1 values(2,3,4);
insert into t1 values(3,4,5);
insert into t2 select * from t1 order by b desc limit 1;
select * from t2;
|
|
146 |
code
|
fixed
|
2002 Sep
|
drh
|
Pager
|
2002 Sep
|
drh
|
1
|
1
|
Disk I/O error encountered on very large transactions
|
edit |
In a very large transaction where:
- New records are inserted
- Those records are deleted creating free blocks at the
end of the file.
- Lots of update occur to so that the free blocks at the
end of the file are removed from the cache
- Additional inserts are attempted which attempt to use the
free blocks at the end of the file
Then the os.c layer will try to read a block that was never
written. The read will be short (zero bytes) which will cause
an SQLITE_IOERR. |
|
142 |
code
|
fixed
|
2002 Aug
|
anonymous
|
|
2002 Aug
|
|
1
|
1
|
Incorrect Order By when column is null
|
edit |
create table a( a id );
INSERT INTO a VALUES(3);
INSERT INTO a VALUES(1);
INSERT INTO a VALUES(2);
select * from a order by null , a;
returns 2,1,3, and it must return 1,2,3 |
A better example:
create table a ( a int , b varchar(10) );
INSERT INTO a VALUES(2,'ab');
INSERT INTO a VALUES(1,NULL);
INSERT INTO a VALUES(3,NULL);
INSERT INTO a VALUES(0,'cd');
INSERT INTO a VALUES(5,NULL);
INSERT INTO a VALUES(4,NULL);
select * from a order by b , a;
|
|
140 |
todo
|
fixed
|
2002 Aug
|
drh
|
CodeGen
|
2002 Aug
|
drh
|
4
|
4
|
Enhance INSERT ... SELECT to omit the intermediate temporary table
|
edit |
Consider the following statement.
INSERT INTO table SELECT ...
As currently implemented, statements of this form first
execute the SELECT and store the results in a temporary
table. Then the temporary table is scanned and the results
are written into the destination table. The operation would
go about twice as fast if the results of the SELECT were written
into the destination table directly, bypassing the intermediate
temporary table.
Suggested implementation strategy:
- Implement OP_Gosub and OP_Return operators in the VDBE.
(These are needed for other things anyhow.)
- Add a new destination type to the sqliteSelect() routine,
SRT_Subroutine, that invokes a subroutine to process each
row of the result set.
- Modify the sqliteInsert() procedure to code a subroutine
to do the insert and then call sqliteSelect() to code the
select using the new SRT_Subroutine target.
|
Skipping the intermediate table causes problems for
statements like this:
INSERT INTO t1 SELECT * FROM t1;
So we need to either drop this idea or fall back to the
old intermediate scheme when there is self-reference.
There might also be problems when there are insert triggers
that mess with some of the tables in the SELECT clause. |
|
138 |
code
|
fixed
|
2002 Aug
|
jadams
|
|
2002 Aug
|
|
4
|
4
|
Makefile doesn't use exec_prefix, has some install problems
|
edit |
- autoconf provides an '--exec_prefix' option, which lets you set a directory, (by default the same as '--prefix') in which to install architecture-specific executables and libraries. The Makefile.in shipped with sqlite doesn't use this, and just uses --prefix.
- the 'sqlite' target does not include a -rpath directive, which makes
installing the shlibs in a non-standard location tricky.
- the install target gets very confused if the target directories do not exist. I've added INSTALL -d directives to fix that.
unidiff: (had some extra stuff in there)
--- Makefile.in.dist Wed May 15 04:07:05 2002
+++ Makefile.in Tue Aug 20 23:47:11 2002
@@ -31,6 +31,7 @@
# Some standard variables and programs
#
prefix = @prefix@
+exec_prefix = @exec_prefix@
INSTALL = @INSTALL@
LIBTOOL = ./libtool
@@ -121,15 +122,15 @@
| awk '{print $$5,$$6}' >last_change
libsqlite.la: $(LIBOBJ)
- $(LIBTOOL) $(TCC) -o libsqlite.la $(LIBOBJ) -rpath $(prefix)/lib
+ $(LIBTOOL) $(TCC) -o libsqlite.la $(LIBOBJ) -rpath $(exec_prefix)/lib
libtclsqlite.la: tclsqlite.lo libsqlite.la
$(LIBTOOL) $(TCC) -o libtclsqlite.la tclsqlite.lo \
- libsqlite.la $(LIBTCL) -rpath $(prefix)/lib
+ libsqlite.la $(LIBTCL) -rpath $(exec_prefix)/lib
sqlite: $(TOP)/src/shell.c libsqlite.la sqlite.h
$(LIBTOOL) $(TCC) $(READLINE_FLAGS) -o sqlite $(TOP)/src/shell.c \
- libsqlite.la $(LIBREADLINE)
+ libsqlite.la $(LIBREADLINE) -rpath $(exec_prefix)/lib
# Rules to build the LEMON compiler generator
#
@@ -309,8 +310,11 @@
mv $(DOC) doc
install: sqlite libsqlite.la sqlite.h
- $(LIBTOOL) $(INSTALL) libsqlite.la $(prefix)/lib
- $(LIBTOOL) $(INSTALL) sqlite $(prefix)/bin
+ $(INSTALL) -d $(exec_prefix)/lib
+ $(LIBTOOL) $(INSTALL) libsqlite.la $(exec_prefix)/lib
+ $(INSTALL) -d $(exec_prefix)/bin
+ $(LIBTOOL) $(INSTALL) sqlite $(exec_prefix)/bin
+ $(INSTALL) -d $(prefix)/include
$(INSTALL) -m 0644 sqlite.h $(prefix)/include
clean:
|
|
137 |
code
|
fixed
|
2002 Aug
|
anonymous
|
Shell
|
2002 Aug
|
|
4
|
3
|
shell's find_home_dir() is ineffecient
|
edit |
in src/shell.c:
981 static char *find_home_dir(void){
982 char *home_dir = NULL;
983
984 #if !defined(_WIN32) && !defined(WIN32)
985 struct passwd *pwent;
986 uid_t uid = getuid();
987 while( (pwent=getpwent()) != NULL) {
988 if(pwent->pw_uid == uid) {
989 home_dir = pwent->pw_dir;
990 break;
991 }
992 }
993 #endif
If you've got a NIS server with a large passwd map, this takes a long time to complete. The getpwuid(3) function does a lookup instead of a line-by-line search.
diff -u src/shell.c.dist src/shell.c
--- src/shell.c.dist Thu Jul 25 13:30:01 2002
+++ src/shell.c Tue Aug 20 18:17:53 2002
@@ -984,11 +984,8 @@
#if !defined(_WIN32) && !defined(WIN32)
struct passwd *pwent;
uid_t uid = getuid();
- while( (pwent=getpwent()) != NULL) {
- if(pwent->pw_uid == uid) {
- home_dir = pwent->pw_dir;
- break;
- }
+ if( (pwent=getpwuid(uid)) != NULL) {
+ home_dir = pwent->pw_dir;
}
#endif
|
When I try this patch on my RedHat7.2 box, the getpwuid() function
spins. It never returns - just uses 100% of the CPU. (I didn't
let it run for more than 15 seconds. Maybe it would have finished
if I had been more patient...)
Does anybody have any suggestions on how to fix this?
Silly me. I has a "while" around getpwuid() instead of an "if".
The problem is fixed now. |
|
136 |
code
|
fixed
|
2002 Aug
|
drh
|
CodeGen
|
2002 Aug
|
drh
|
1
|
1
|
Segfault on VIEW of a subquery
|
edit |
The following SQL causes a segfault:
CREATE TABLE t1(a);
CREATE VIEW v1 AS SELECT max(cnt) FROM
(SELECT a, count(*) FROM t1 GROUP BY a);
SELECT * FROM v1;
|
|
135 |
new
|
fixed
|
2002 Aug
|
anonymous
|
|
2002 Aug
|
|
5
|
4
|
Code optimizations (to reduce compilation warnings under BC5 Windows)
|
edit |
btree.c (variable totalSize unused):
2003 MemPage *pOldCurPage; /* The cursor originally points to this page */
2004 - int totalSize; /* Total bytes for all cells */
2005 int subtotal; /* Subtotal of bytes in cells on one page */
2228 */
2229 - totalSize = 0;
2230 - for(i=0; i<nCell; i++){
2231 - totalSize += szCell[i];
2232 - }
2233 for(subtotal=k=i=0; i<nCell; i++){
where.c (variable aDirect unused):
302 int haveKey; /* True if KEY is on the stack */
303 - int aDirect[32]; /* If TRUE, then index this table using ROWID */
304 int iDirectEq[32]; /* Term of the form ROWID==X for the N-th table */
410 loopMask = 0;
411 - for(i=0; i<pTabList->nSrc && i<ARRAYSIZE(aDirect); i++){
411 + for(i=0; i<pTabList->nSrc && i<32; i++){
412 int j;
printf.c (variable zMem unused):
208 enum et_type xtype; /* Conversion paradigm */
209 - char *zMem; /* String to be freed */
210 char *zExtra; /* Extra memory used for etTCLESCAPE conversions */
552 case etSTRING:
553 - zMem = bufpt = va_arg(ap,char*);
553 + bufpt = va_arg(ap,char*);
554 if( bufpt==0 ) bufpt = "(null)";
|
|
134 |
code
|
fixed
|
2002 Aug
|
anonymous
|
Parser
|
2002 Aug
|
anonymous
|
2
|
4
|
syntax error in lemon.c on IBM AIX systems (both gcc and xlc)
|
edit |
On IBM systems, the include file <stdio.h> defines FALSE and
TRUE as 0 and 1. This generates a syntax error on line 120 of
lemon.c:
typedef enum {FALSE=0, TRUE} Boolean;
because this line is mapped into
typedef enum {0=0, 1} Boolean;
which is not legal C.
Possible work-arounds:
- explicitly define your own FALSE and TRUE as 0 and 1 then
replace "FALSE=0" with just "FALSE"
- change FALSE to False and TRUE to True
|
|
133 |
code
|
fixed
|
2002 Aug
|
anonymous
|
Unknown
|
2002 Aug
|
|
5
|
5
|
sqlite.exe crashes
|
edit |
If I manipulate a database from TCL using tclsqlite.dll and then try to use sqlite.exe on the database, I receive the following error: SQLITE.exe has generated errors and will be closed by Windows.
The database is very small (27KB) and I would be glad to send it to you if you will supply an email address.
This has happend twice, the first time I just ignored it and started over. I can also be reached at 919.997.7878 - Ron. |
This is from an older version of SQLite. The problem was fixed
by check-in [682]
. |
|
132 |
new
|
fixed
|
2002 Aug
|
anonymous
|
Unknown
|
2002 Aug
|
|
3
|
3
|
Temp file path
|
edit |
In os.c:
int sqliteOsTempFileName(char *zBuf){
#if OS_UNIX
static const char *azDirs[] = {
".",
"/tmp",
"/var/tmp",
"/usr/tmp",
};
...
The choice of the current directory "." as the first candidate where
to put the temp file is IMO very bad. In an embedded system like ours
this results in a premature compact flash consumption.
And, you know, embedded systems are the preferred targets of sqlite.
It would be far better preferible to put "." as the last resort, preferring the other three, which can be statically linked or mounted on a ram disk (as we do).
Or, even better, specify it as a compile options.
Anyway, you are doing a wonderful job! |
|
131 |
code
|
fixed
|
2002 Aug
|
drh
|
|
2002 Aug
|
drh
|
1
|
1
|
ORDER BY ignored when used with GROUP BY on an indexed column
|
edit |
Consider the following code:
CREATE TABLE t1(a,b);
INSERT INTO t1 VALUES(3,4);
INSERT INTO t1 VALUES(1,2);
INSERT INTO t1 SELECT a+4,b+4 FROM t1;
INSERT INTO t1 SELECT a,b+8 FROM t1;
SELECT a, min(b) FROM t1 GROUP BY a ORDER BY a;
CREATE INDEX i1 ON t1(a);
SELECT a, min(b) FROM t1 GROUP BY a ORDER BY a;
The first SELECT occurs before the index is created and
it sorts the result correctly. But in the second SELECT,
the output appears in a random order. The ORDER BY clause
has no effect.
This appears to only happen when a GROUP BY clause is used and
the ORDER BY clause refers to an indexed column. |
|
130 |
code
|
fixed
|
2002 Aug
|
anonymous
|
|
2002 Aug
|
|
3
|
3
|
No transactions across Linux threads seems restrictive.
|
edit |
I see that you have added an explanation that starting a transaction
in one thread and terminating it in another thread are not permitted
under LinuxThreads.
If I understand your reason for instituting this restriction, it is
to prevent someone from starting a transaction in one processes forking,
then completing it in another process.
If this is the case, then it is a pity that you put this restriction
into your threaded implementation under Linux where it apparently
works fine.
Did you implement this restriction to prevent someone
from possibly doing something stupid?
Hmmm -- I'm sure that if we think about it, you can find out
if you are really running as a thread or not, but it doesn't
seem to me to be that important.
As far as I can tell LinuxThreads are perfectly compliant
with Posix Threads. I see nothing in the standard that refers to a
process id (other than that you should be able to create at least
64 threads from a single process, which, of course, you can do).
pthreads do not contain the concept of a process id as far as I
know.
If you really want to have this restriction, fine, but if it does
no harm on Linux machines, then please provide us with a configuration
parameter for disabling it. If you have some real reason why it
won't work on Linux, then of course, you can trash this request.
PS: Is there any way to get your response by email? |
|
97 |
todo
|
fixed
|
2002 Jul
|
drh
|
|
2003 Jan
|
|
1
|
1
|
Document and test the SHOW_DATATYPES pragma
|
edit |
Add documentation and tests for the SHOW_DATATYPES pragma. |
See also ticket #221. |
|
30 |
new
|
fixed
|
2002 Apr
|
anonymous
|
|
2005 Feb
|
drh
|
2
|
4
|
Correlated subqueries are not supported
|
edit |
Bulk inserts with sub-selects do not have (useful)
e.g. Oracle semantics:
create table bar(t1,t2);
insert into bar values (1,'a');
insert into bar values (2,'b');
insert into bar values (3,'c');
create table bar2(t1,t2);
insert into bar2 values (3,'cc');
insert into bar2 values (2,'bb');
update bar set t2=(select t2 from bar2 where bar.t1=bar2.t1);
SQL error: no such column: bar.t1
Oracle will take this and give:
Ora> select * from bar;
T1 T2
----- ----
1
2 bb
3 cc
The 'a' can be retained in oracle with an extra
'where t1 in (select t1 from bar2)' |
|
29 |
new
|
fixed
|
2002 Apr
|
anonymous
|
|
2004 Jan
|
drh
|
3
|
1
|
Enhancement of column data types in views
|
edit |
PRAGMA table_info on VIEWs should return the original type
information of those columns which are taken from tables
directly, e.g.
CREATE TABLE A(id integer PRIMARY KEY, name text);
CREATE TABLE B(id integer, descr text);
CREATE VIEW C AS SELECT A1.id AS id, A1.name AS name,
B1.descr AS descr FROM A A1, B B1 WHERE A1.id = B1.id;
PRAGMA table_info(C);
The last statement should return:
0|id|integer|0| <-- currently the type is "text" for this column
1|name|text|0|
2|descr|text|0|
|
" ? " ' " |
|
2839 |
new
|
defer
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
4
|
4
|
Deleting row from sqlite_stat1 will not take effect until next connect
|
edit |
I noticed if sqlite_stat1 is purged or altered, the query plans remain the same until you disconnect and reconnect to the database. Is this by design? |
2007-Dec-13 17:54:02 by drh:
If you manually mess around with the sqlite3_stat1 table,
I don't think it is too much to ask that you restart
the connection to make those changes go into effect.
To add code for this specialized corner case seems
unwarranted. |
|
2499 |
build
|
defer
|
2007 Jul
|
anonymous
|
|
2007 Aug
|
drh
|
1
|
1
|
undefined reference to `_WinMain@16'
|
edit |
when attempting to build I get the error:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab): undefined reference to `_WinMain@16' |
2007-Jul-11 18:16:28 by anonymous:
<!-- ~/mydocs/dl/sqlite-3.4.0 --> ls
Makefile.in config.sub main.mk sqlite.pc.in
Makefile.linux-gcc configure mkdll.sh sqlite3.1
README configure.ac mkopcodec.awk sqlite3.pc.in
VERSION contrib mkopcodeh.awk src
aclocal.m4 doc mkso.sh tclinstaller.tcl
addopcodes.awk ext notes test
art install-sh publish.sh tool
config.guess ltmain.sh spec.template www
<!-- ~/mydocs/dl/sqlite-3.4.0 --> ./configure && make install
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ld used by gcc... /usr/i686-pc-cygwin/bin/ld.exe
checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes
checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for xlf... no
checking for f77... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for xlf90... no
checking for f90... no
checking for pgf90... no
checking for pghpf... no
checking for epcf90... no
checking for gfortran... no
checking for g95... no
checking for xlf95... no
checking for f95... no
checking for fort... no
checking for ifort... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for ftn... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether accepts -g... no
checking the maximum length of command line arguments... 8192
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking for correct ltmain.sh version... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC...
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/i686-pc-cygwin/bin/ld.exe
checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes
checking whether the g++ linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes
checking for g++ option to produce PIC...
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
Version set to 3.4
Release set to 3.4.0
Version number set to 3004000
checking whether to support threadsafe operation... no
checking whether to allow connections to be shared across threads... no
checking whether threads can override each others locks... no
checking whether to support shared library linked as release mode or not... no
checking whether to use an in-ram database for temporary tables... no
checking if executables have the .exe suffix... unknown
checking host system type... (cached) i686-pc-cygwin
checking for Tcl configuration... found /usr/lib/tclConfig.sh
checking for existence of /usr/lib/tclConfig.sh... loading
checking for library containing tgetent... -ltermcap
checking for readline in -lreadline... no
checking readline.h usability... no
checking readline.h presence... no
checking for readline.h... no
checking for /usr/include/readline.h... no
checking for /usr/include/readline/readline.h... no
checking for /usr/local/include/readline.h... no
checking for /usr/local/include/readline/readline.h... no
checking for /usr/local/readline/include/readline.h... no
checking for /usr/local/readline/include/readline/readline.h... no
checking for /usr/contrib/include/readline.h... no
checking for /usr/contrib/include/readline/readline.h... no
checking for /mingw/include/readline.h... no
checking for /mingw/include/readline/readline.h... no
checking for library containing fdatasync... none required
checking for usleep... yes
checking for fdatasync... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating sqlite3.pc
gcc -g -O2 -o lemon.exe ./tool/lemon.c
cp ./tool/lempar.c .
cp ./src/parse.y .
./lemon.exe parse.y
mv parse.h parse.h.temp
awk -f ./addopcodes.awk parse.h.temp >parse.h
cat parse.h ./src/vdbe.c | gawk -f ./mkopcodeh.awk >opcodes.h
sort -n -b -k 3 opcodes.h | gawk -f ./mkopcodec.awk >opcodes.c
gcc -g -O2 -o mkkeywordhash.exe ./tool/mkkeywordhash.c
./mkkeywordhash.exe >keywordhash.h
sed -e s/--VERS--/3.4.0/ ./src/sqlite.h.in | \
sed -e s/--VERSION-NUMBER--/3004000/ >sqlite3.h
rm -rf tsrc
mkdir -p tsrc
cp ./src/alter.c ./src/analyze.c ./src/attach.c ./src/auth.c ./src/btree.c ./src/btree.h ./src/build.c ./src/callback.c ./src/complete.c ./src/date.c ./src/delete.c ./src/expr.c ./src/func.c ./src/hash.c ./src/hash.h ./src/insert.c ./src/legacy.c ./src/loadext.c ./src/main.c ./src/malloc.c ./src/os.c ./src/os_unix.c ./src/os_win.c ./src/os_os2.c ./src/pager.c ./src/pager.h ./src/parse.y ./src/pragma.c ./src/prepare.c ./src/printf.c ./src/random.c ./src/select.c ./src/shell.c ./src/sqlite.h.in ./src/sqliteInt.h ./src/table.c ./src/tclsqlite.c ./src/tokenize.c ./src/trigger.c ./src/utf.c ./src/update.c ./src/util.c ./src/vacuum.c ./src/vdbe.c ./src/vdbe.h ./src/vdbeapi.c ./src/vdbeaux.c ./src/vdbeblob.c ./src/vdbefifo.c ./src/vdbemem.c ./src/vdbeInt.h ./src/vtab.c ./src/where.c ./ext/fts1/fts1.c ./ext/fts1/fts1.h ./ext/fts1/fts1_hash.c ./ext/fts1/fts1_hash.h ./ext/fts1/fts1_porter.c ./ext/fts1/fts1_tokenizer.h ./ext/fts1/fts1_tokenizer1.c sqlite3.h ./src/btree.h ./src/btreeInt.h ./src/hash.h ./src/limits.h opcodes.h ./src/os.h ./src/os_common.h ./src/sqlite3ext.h ./src/sqliteInt.h ./src/vdbe.h parse.h ./ext/fts1/fts1.h ./ext/fts1/fts1_hash.h ./ext/fts1/fts1_tokenizer.h ./src/vdbeInt.h tsrc
cp: warning: source file `./src/btree.h' specified more than once
cp: warning: source file `./src/hash.h' specified more than once
cp: warning: source file `./src/sqliteInt.h' specified more than once
cp: warning: source file `./src/vdbe.h' specified more than once
cp: warning: source file `./ext/fts1/fts1.h' specified more than once
cp: warning: source file `./ext/fts1/fts1_hash.h' specified more than once
cp: warning: source file `./ext/fts1/fts1_tokenizer.h' specified more than once
cp: warning: source file `./src/vdbeInt.h' specified more than once
rm tsrc/sqlite.h.in tsrc/parse.y
cp parse.c opcodes.c keywordhash.h tsrc
tclsh ./tool/mksqlite3c.tcl
cc sqlite3.c -o sqlite3
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab): undefined reference to `_WinMain@16'
collect2: ld returned 1 exit status
make: *** [sqlite3] Error 1
<!-- ~/mydocs/dl/sqlite-3.4.0 -->
2007-Jul-11 18:17:17 by anonymous:
when initially filing this bug, i was told to not paste large screen dumps.
i was also promised that i would be able to add an attachment later. however, that option was not given, so I have attached a screen transcript.
2007-Jul-11 18:18:33 by anonymous:
my email is metaperl at gmail.com
2007-Jul-11 18:38:53 by drh:
The [Attach] link in the upper-left is what you use to add
attachments.
The sqlite3.c source file is a library, not a program. If
you want to compile a command-line shell, add the "shell.c"
source file:
cc -o sqlite3 sqlite3.c shell.c
2007-Jul-23 20:35:06 by anonymous:
I believe this bug report should be reopened because this error comes when you try to configure and compile USING THE DEFAULTS.
When you try to do a standard configure and make, it should either try to compile shell.c as is needed or not compile sqlite.c. It shouldn't put in a command that fails the compile by default.
Sorry to bother you about this, but I don't see how this isn't a bug or at least a glitch. It's a problem in the configuration and makefile system.
2007-Aug-15 03:26:05 by anonymous:
Compile and link passed by following patch (at least for me).
diff -ru sqlite-3.4.2/Makefile.in sqlite-3.4.2-new/Makefile.in
--- sqlite-3.4.2/Makefile.in 2007-08-15 10:37:18.921875000 +0900
+++ sqlite-3.4.2-new/Makefile.in 2007-08-15 10:36:08.750000000 +0900
@@ -681,7 +681,7 @@
mkdir -p doc
mv $(DOC) doc
-install: sqlite3 libsqlite3.la sqlite3.h ${HAVE_TCL:1=tcl_install}
+install: sqlite3$(TEXE) libsqlite3.la sqlite3.h ${HAVE_TCL:1=tcl_install}
$(INSTALL) -d $(DESTDIR)$(libdir)
$(LTINSTALL) libsqlite3.la $(DESTDIR)$(libdir)
$(INSTALL) -d $(DESTDIR)$(exec_prefix)/bin
2007-Aug-22 12:33:17 by anonymous:
Why is this bug closes and marked "not a bug"? sqlite fails on make install on Cygwin (as in untar/configure/make/make install), which is clearly a bug. The "fix" posted above does not work, make install fails instantly with
tclsh ../sqlite-3.4.2-n/tclinstaller.tcl 3.4
can't read "env(DESTDIR)": no such variable
while executing
"set LIBDIR $env(DESTDIR)$env(TCLLIBDIR)"
(file "../sqlite-3.4.2-n/tclinstaller.tcl" line 11)
make: *** [tcl_install] Error 1
2007-Aug-22 12:53:45 by drh:
I misread the problem.
Cygwin is not a supported platform. So in that sense, this is
not clearly a bug in SQLite. This is an imcompatibility with
Cygwin.
We will take the problem under advisement, but since Cygwin
is not officially support and because we have many much more
serious problems to work on, progress on this is likely to
be slow. You can expedite a fix by posting a patch. |
|
2227 |
new
|
defer
|
2007 Feb
|
scouten
|
|
2007 Apr
|
|
5
|
4
|
Feature request: CHECKPOINT command
|
edit |
We'd like to maintain exclusive access to the database over time. DRH proposed a CHECKPOINT, which would commit the changes made so far, but not end the transaction. |
2007-Feb-12 22:46:56 by scouten:
As we've thought about this more, we think it would be more elegantly implemented as an open_exclusive command using "real" transactions during the execution stream instead of keeping our transactions open indefinitely.
2007-Feb-13 01:26:01 by drh:
I do not understand the above comment. More explanation would be
appreciated.
2007-Feb-15 20:13:07 by anonymous:
The goal of any of these changes it to prevent sqlite from dumping it's page cache at the end of a transaction. In situations where exclusive access to a sqlite3 database is guaranteed or desired, the overhead of flushing and reloading the cache is unnecessary.
Current and suggested workarounds involve keeping a transaction open. The suggested CHECKPOINT fix would allow the sqlite user to keep a transaction open indefinitely and get the benefits of a transaction by issuing a CHECKPOINT where a COMMIT would have previously been issued.
Modifying sqlite's transaction paradigm to keep the page cache around indefinitely would take advantage of a side effect of the transaction to solve this issue. Scouten suggests a more declarative way of accomplishing this, by adding a sqlite3_open_exclusive function that did the same thing as sqlite3_open, but informed the pager layer not to flush it's cache at the end of a transaction.
2007-Mar-07 17:48:17 by anonymous:
CHECKPOINT (as I understand it) would not just be useful to avoid flushing the page cache; it would be useful in cases where a process is running a long, involved update operation, that can be restarted from some internal points but one would prefer to avoid it, and if another process comes in and modifies things it would have to be restarted. The behavior of flushing out the current journal but not dropping the lock is thus desired for operation semantics, not just efficiency. One example of such an operation is monotone netsync (currently we use drop-and-retake, and hope no other user comes in).
2007-Mar-29 21:36:38 by drh:
As of earlier this week, there is a new feature in SQLite that
will give you something like CHECKPOINT functionality. If you
run this macro:
PRAGMA locking_mode=EXCLUSIVE;
Then locks will increase but will not be released. So as soon
thereafter that you get an exclusive lock on the database, you
will hold that lock until you either run
PRAGMA locking_mode=NORMAL;
Or until you close the database connection. While in exclusive
access mode like this, you can do as many COMMITs as you want,
and be assured that no other process will be able to jump in
and modify the database. The page cache is not flushed. And
the rollback journal file is truncated but not deleted.
We might in the future add a command:
COMMIT AND BEGIN
That will commit a transaction then immediately start a new
transaction without dropping locks even while not in exclusive
access mode. COMMIT AND BEGIN is closer to the concept of
CHECKPOINT. But for now, exclusive access mode will probably
suffice for most peoples needs.
2007-Apr-10 23:27:58 by rdc:
The SQL:1999 standard uses a feature called CHAINED TRANSACTIONS for this. Basically each COMMIT or ROLLBACK statement can optionally be followed by a chain clause which performs the operation and immediately starts another transaction.
COMMIT [AND [NO] CHAIN]
ROLLBACK [AND [NO] CHAIN]
The optional NO clause does the same thing as a normal commit with no chain clause. |
|
1685 |
code
|
defer
|
2006 Feb
|
anonymous
|
|
2006 Feb
|
|
1
|
1
|
Stall on multithread application.
|
edit |
SQLite used in multithread application that collects statistical data for production machines and then resend the data to the main SQL server.
One of the threads reads the data from the machine and writes it to the local database. The second thread from time to time checks the local database and if records exists, read them, send data to the main SQL server and then deletes the records from the local DB.
After a few days of working ( 7 in the last stall ) in random moment, the database stalls and the first thread cant write anymore.
If you have ideas what I have to check to determine where exactly the problem is, let me know. |
2006-Feb-21 23:51:13 by anonymous:
It is probably a bug in your code. Please provide an actual program that reproduces the bug. Otherwise no one will take this bug report seriously. At the very least get a thread stack dump of each thread via pstack, or by attaching gdb to the stalled process at runtime.
2006-Feb-27 23:46:56 by drh:
Unable to reproduce. |
|
1527 |
code
|
defer
|
2005 Nov
|
anonymous
|
|
2005 Nov
|
|
1
|
1
|
DROP TABLE returns "database disk image is malformed" error
|
edit |
I run simple test where I insert 10.000-100000 row of data into "CREATE TABLE teibeli( pk INT, val TEXT, val2 TEXT, val3 TEXT);" table. When I try to drop this table after, then I get "database disk image is malformed" SQLite error. After debugging I noticed this code in btree.c, function static int clearDatabasePage():
if( pgno>sqlite3pager_pagecount(pBt->pPager) ){
return SQLITE_CORRUPT_BKPT;
}
that returns the error. I don't know do I understand right this situation, but I figured out also that the root page of this table has the link to the page that does not exist physically in the database file. This is the code from the same function in btree.c:
if( !pPage->leaf ){
rc = clearDatabasePage(pBt, get4byte(&pPage->aData[8]), pPage->pParent, 1);
if( rc ) goto cleardatabasepage_out;
}
where get4byte(&pPage->aData[8]) returns the number of page that is bigger then the size of the database file. |
2005-Nov-18 13:09:36 by drh:
Unable to reproduce.
Perhaps it would help to supply us with a script that fails and
perhaps identify the operating system you are using.
2005-Nov-22 08:39:38 by anonymous:
My test is a simple loop where some number of data rows inserted into just created table (existing in just created database file). The amount of pages the data is occupied have to exceed the MAX_PAGES number defined as 2000 by default. In my settings I use SQLITE_DEFAULT_PAGE_SIZE = 512 and SQLITE_MAX_PAGE_SIZE = 1024 bytes. Therefore the amount of data is more than 1MB in this case. When I try to drop this full table after, I get an SQLite error: "database disk image is malformed"!
2005-Nov-22 12:23:13 by drh:
Please attach your test program.
2005-Dec-01 05:55:31 by anonymous:
The problem is identified. My version of seek() moves file pointer to the end of the database file if the page number to write has bigger number than the size of the database file. So pages with a big numbers are appended to the end of the database file. Therefore some pages are overwritten by other pages. Do you have any suggestions to solve this problem?
P.S. I solved this by adding missing number of bytes before writing pages with big numbers. But this way reduces write performance.
2005-Dec-01 13:19:12 by drh:
What OS is it that will not let you seek past the end of a file??? |
|
1072 |
code
|
defer
|
2005 Jan
|
anonymous
|
|
2005 Jan
|
|
3
|
3
|
Non-standard behaviour for date/time functions in SELECT
|
edit |
The following SELECT statement returns non-standard results for the date/time component, namely, a list of rows where the timestamp changes to reflect the advance of the system clock:
SELECT datetime('now'),* FROM someTableWithManyRows;
This is incorrect. What should be returned is a result set where all timestamp values are the same, ie. the date/time should be captured just once and then applied to all rows returned by the statement.
Both DB2 and Oracle exhibit the correct behaviour. |
2005-Jan-13 11:50:04 by drh:
This is unlikely to change anytime soon. Suggested workaround:
SELECT (SELECT datetime('now')), * FROM tableWithManyRows;
|
|
1007 |
code
|
defer
|
2004 Nov
|
anonymous
|
|
2004 Nov
|
|
3
|
2
|
SQLite ignores SQLITE_CORRUPT error and continues executing SQL query
|
edit |
After performing SELECT on corrupted database, I have received "garbage" instead of data.
All consequent queries resulted in access violation.
After conducted a little research, I have found a few problems.
1. The initPage function does detect invalid page caption and returns SQLITE_CORRUPT. However, this error is ignored by sqliteVdbeCursorMoveto, which never checks the returned value when executing the following code:
sqliteBtreeMoveto(p->pCursor, (char*)&p->movetoTarget, sizeof(int), &res);
2. The sqliteVdbeCursorMoveto(pC) error code is also not checked when processing the OP_Recno opcode (vdbe.c).
3. Although the initPage function returns error, it still manages to initialize pPage->pParent with non-zero value, and thus in all consequent initPage calls for this page, SQLITE_CORRUPT was not returned, so the page was treated as successfully initialized.
I tried to solve these problems this way:
1. vbdeaux.c - sqliteVdbeCursorMoveto function
sqliteBtreeMoveto(p->pCursor, (char*)&p->movetoTarget, sizeof(int), &res);
changed to:
int rc;
rc = sqliteBtreeMoveto(p->pCursor, (char*)&p->movetoTarget, sizeof(int), &res);
if (rc != SQLITE_OK)
{
return rc;
}
2. vbde.c (OP_Recno processing):
sqliteVdbeCursorMoveto(pC);
changed to:
rc = sqliteVdbeCursorMoveto(pC);
if (rc != SQLITE_OK)
{
goto abort_due_to_error;
}
3. btree.c - initPage function
page_format_error:
return SQLITE_CORRUPT;
changed to:
page_format_error:
if( pPage->pParent ){
sqlitepager_unref(pPage->pParent);
pPage->pParent = 0;
}
return SQLITE_CORRUPT;
Please let me know what you think.
Thanks! |
|
86 |
new
|
defer
|
2002 Jun
|
anonymous
|
|
2002 Jun
|
|
5
|
2
|
Add SAFEARRAY support for WIN32 clients of SQLite.DLL.
|
edit |
I have developed a new function called 'sqlite_get_table_com'
The source for this is located here
http://www.ag-software.com/sqlite/sqlite_com.c
and
http://www.ag-software.com/sqlite/sqlite_com.h
This function should only be for win32 compiles.
The problem is that the .NET framwork and VB6 do not support char arrays. The .NET framework does to a certain point but you need to know the bounds of the array before you can access the array.
So to get arround this problem, I have developed a function that calls sqlite_get_table to get the information out of sqlite and then converts this information into a 2 dim SAFEARRAY of objects.
Including this function in sqlite would mean that the .NET framework would be able to use SQLite natively.
Using this function I have almost completed a fully functional .NET data provider. Using this data provider .NET programmers can bind SQLite databases to any and all controls in the .NET framework , just as if they were using MS SQL Server.
This would open SQLite up to many many more people. |
Am am unable to get mingw to compile this code. |
|
81 |
code
|
defer
|
2002 Jun
|
|
|
2002 Jun
|
|
4
|
3
|
Single process on NFS
|
edit |
Howdy,
In the FAQ you mention:
"The locking mechanism used to control simultaneous access might not work correctly if the database file is kept on an NFS filesystem. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time."
So I understand the NFS limitations. Unfortunately, even with a single process on NFS I cannot seem to create a database file. Using the sqlite command line tool, if I try to add a table I receive: "SQL error: database is locked".
I'm running Mandrake Linux 8.1 with kernel 2.4.8-34. I don't actually plan to run against NFS as such, but my development space is NFS mounted and it's causing a little grief.
Thought I'd report it just in case it is actually a bug. Thanks,
Matt Sheats
sheats@los-alamos.net |
This is a bug, but the bug is in NFS, not in SQLite. There are
no plans to work around the NFS bug at this time. |
|
74 |
new
|
defer
|
2002 Jun
|
anonymous
|
|
2004 Nov
|
|
4
|
2
|
2.5 database file still says "SQLite 2.1 database"
|
edit |
After creating a database with the RPM version 2.5.0 of SQLite,
I noticed that the first line in the (binary) database file says:
** This file contains an SQLite 2.1 database **
Not a big deal, but someone may be looking for this... |
SQLite 2.5 is backwards compatible with SQLite 2.1 databases.
If this were changed, it would break the backwards compatiblity.
Maybe we can do something to keep the version number up to
date when we go to version 3.0. |
|
56 |
event
|
defer
|
2002 Jun
|
anonymous
|
|
2002 Jun
|
|
1
|
1
|
'Permission Denied' while trying to use SQLITE in a Familiar iPAQ
|
edit |
I am new on Linux and I desperately need a SQL engine to work with some databases on my iPAQ. So, I installed SQLITE and it always goes wrong when I try to use it.
I type:
#sqlite
or
#sqlite test
and...
Permission Denied
Maybe it is something about permissions under Linux. But the only user my iPAQ has is root, I installed it under root and always try to use it as root. Please help me!
Thanks a lot,
Joao |
|
38 |
code
|
defer
|
2002 May
|
danielk1977
|
CodeGen
|
2002 May
|
|
3
|
5
|
Count-changes broken for: DELETE FROM <table-name> (no WHERE clause)
|
edit |
When executing:
DELETE FROM <table-name>;
The "count-changes" functionality doesn't work. A workaround is to use:
DELETE FROM <table-name> WHERE 1; |
This situation, and the reason for it, is already described in
the documentaion of the sqlite_change() API function. |
|
2910 |
new
|
closed
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
1
|
2
|
Number of rows in result set - new API
|
edit |
Performance problem to retrieve number of records in result set after executed any query using prepare/step is evident. On DB around 200MB using one table with 15.000 records having around 10 fieds, among it's one blob field with data less than 10KB in each record, executed query with 'where' clausule using prepare/step (have no blob field listed) last around 30s to only count records in result set. SQLIte3_Get_Table need only 3s to returning all data as well. I I'm aware that many asserts may slow down the whole process dramatically, however not 10 times.
Since there is no an API to retrieve number of records in result set and as prepare/step is far to slow, suggestion is to create one API, with maximum optimization for the purpose. |
2008-Jan-31 02:00:07 by anonymous:
To discover the number of rows, the VDBE engine should iterate over every record of the result. This is the same as calling sqlite_step() until EOF.
But you can't do that, because after each sqlite_step(), you lost in memory data fields fetched for each row, so the way is counting rows after iteration.
Also, tickets should be used for reporting bugs only.
2008-Jan-31 04:24:29 by danielk1977:
Internally, sqlite3_get_table() uses sqlite3_exec() which uses
sqlite3_prepare()/step()/finalize(). So you should look for another
reason why get_table() is 10 times faster than prepare()/step()/finalize().
You could also try a "SELECT count(*) ..." query to determine the
expected size of a result set.
As the above poster points out, there is no way to efficiently add
this capability to SQLite (at least, no more efficiently than evaluating
a count(*) query before the "real" query).
Dan.
2008-Jan-31 08:19:05 by anonymous:
Anonymous: As allowed during ticket adding, I propose new feature.
Dan: Since this feature should speed-up performance of a SQLite wrapper, "SELECT count(*) ..." is a real problem (require careful parsing to redesine gived query). "SELECT count(*) ..." itself is reasonably fast.
2008-Jan-31 08:54:56 by anonymous:
In addition to upper. "SELECT count(*)..." exactly last around 3s, Get_Table last as well around 3s, prepare/step/finalyze to only count numbers of records last 30s. This clearly indicate radically performance lost in prepare/step/finalyze. |
|
2906 |
code
|
closed
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
anonymous
|
2
|
2
|
Error in MSVC v.6.0 (optimization: Maximize Speed mode)
|
edit |
Hello, I am Vyacheslav Pindura (Kiev, Ukraine).
I will detect error in MSVC v.6.0 (optimization: Maximize Speed mode).
Look accessPayload() function in amalgamation project (the same in btree.c in separeted project).
This is fragment from sqlite.cod (listing generated by MSVC compiler). Look my comment "//SLA: ..."
<<<<<< BEGIN LISTING
; COMDAT _accessPayload
_TEXT SEGMENT
_pCur$ = 8
_offset$ = 12
_amt$ = 16
_pBuf$ = 20
_skipKey$ = 24
_eOp$ = 28
_nKey$ = -12
_iIdx$ = -8
_pPage$ = -4
_pBt$ = -4
_ovflSize$62039 = 24
_nextPage$62040 = 12
_pDbPage$62056 = -12
_accessPayload PROC NEAR ; COMDAT
; 29385: ){
00000 83 ec 0c sub esp, 12 ; 0000000cH
00003 53 push ebx
00004 55 push ebp
00005 56 push esi
; 29386: unsigned char *aPayload;
; 29387: int rc = SQLITE_OK;
; 29388: u32 nKey;
; 29389: int iIdx = 0;
; 29390: MemPage *pPage = pCur->pPage; /* Btree page of current cursor entry */
00006 8b 74 24 1c mov esi, DWORD PTR _pCur$[esp+20]
0000a 57 push edi
0000b 33 db xor ebx, ebx
0000d 8b 7e 1c mov edi, DWORD PTR [esi+28]
; 29391: BtShared *pBt; /* Btree this cursor belongs to */
; 29392:
; 29393: assert( pPage );
; 29394: assert( pCur->eState==CURSOR_VALID );
; 29395: assert( pCur->idx>=0 && pCur->idx<pPage->nCell );
; 29396: assert( offset>=0 );
; 29397: assert( cursorHoldsMutex(pCur) );
; 29398:
; 29399: getCellInfo(pCur);
00010 56 push esi
00011 89 5c 24 18 mov DWORD PTR _iIdx$[esp+32], ebx
00015 89 7c 24 1c mov DWORD PTR _pPage$[esp+32], edi
00019 e8 00 00 00 00 call _getCellInfo
; 29400: aPayload = pCur->info.pCell + pCur->info.nHeader;
0001e 8b 4e 24 mov ecx, DWORD PTR [esi+36]
; 29401: nKey = (pPage->intKey ? 0 : pCur->info.nKey);
00021 8a 47 03 mov al, BYTE PTR [edi+3]
00024 33 ed xor ebp, ebp
00026 83 c4 04 add esp, 4
00029 66 8b 6e 38 mov bp, WORD PTR [esi+56]
0002d 03 e9 add ebp, ecx
0002f 84 c0 test al, al
00031 74 08 je SHORT $L80642
00033 33 c0 xor eax, eax
00035 89 44 24 10 mov DWORD PTR _nKey$[esp+28], eax
00039 eb 0a jmp SHORT $L80643
$L80642:
0003b 8b 4e 2c mov ecx, DWORD PTR [esi+44]
0003e 8b 4e 28 mov ecx, DWORD PTR [esi+40]
00041 89 4c 24 10 mov DWORD PTR _nKey$[esp+28], ecx
$L80643:
; 29402:
; 29403: if( skipKey ){
00045 8b 4c 24 30 mov ecx, DWORD PTR _skipKey$[esp+24] //SLA: ecx:=skipKey
; 29404: offset += nKey;
00049 8b 7c 24 24 mov edi, DWORD PTR _offset$[esp+24] //SLA: edi:=offset
0004d 3b cb cmp ecx, ebx
0004f 74 02 je SHORT $L62032
00051 03 f9 add edi, ecx //SLA: offset += skipKey !!!
$L62032:
; 29405: }
; 29406: if( offset+amt > nKey+pCur->info.nData ){
00053 8b 54 24 28 mov edx, DWORD PTR _amt$[esp+24]
00057 8b 46 30 mov eax, DWORD PTR [esi+48]
0005a 03 44 24 10 add eax, DWORD PTR _nKey$[esp+28]
0005e 8d 0c 17 lea ecx, DWORD PTR [edi+edx] //SLA: edi have (offset+skipKey) !!!
00061 3b c8 cmp ecx, eax
00063 76 0d jbe SHORT $L62033
00065 5f pop edi
00066 5e pop esi
00067 5d pop ebp
; 29407: /* Trying to read or write past the end of the data is an error */
; 29408: return SQLITE_ERROR;
00068 b8 01 00 00 00 mov eax, 1
0006d 5b pop ebx
; 29510: }
<<<<<<< END LISTING
So, optimization imposible !!!
We need disable optimization in MSVC project :(
Best regards,
Vyacheslav. |
2008-Jan-27 12:51:32 by drh:
See also ticket #2657. There have been other reports of problems
with MSCV 6.0 and SQLite, some of which result in an "Internal
Compiler Error" and others which just cause incorrect code to be
generated.
At this point we recommend that you not use MSVC 6.0 to build
SQLite or any other project for that matter. If you must use MSVC 6.0,
at least disable optimization.
To be fair to MSVC, other compilers also have bugs.
Ticket #2469 is an example of an optimizer bug in GCC which
has since been fixed.
Thank you for reporting this problem. But this really is a bug in
MSVC, not in SQLite, so there is nothing that we can do about it. |
|
2900 |
code
|
closed
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
3
|
4
|
Can't ESCAPE in GLOB
|
edit |
If you apply an ESCAPE clause to the GLOB operator, you get the message:
SQL error: wrong number of arguments to function glob()
You can reproduce this on Mac OS X 10.5 with the following:
$ sqlite3 test.db
SQLite version 3.4.0
Enter ".help" for instructions
sqlite> create table Identifiers ( ident text );
sqlite> insert into Identifiers values ( "foo?" );
sqlite> insert into Identifiers values ( "foo" );
sqlite> insert into Identifiers values ( "foo_" );
sqlite> select * from Identifiers where ident like "foo\_" escape "\";
foo_
sqlite> select * from Identifiers where ident glob "foo\?" escape "?";
SQL error: wrong number of arguments to function glob()
I believe that this is because sqlite3RegisterLikeFunctions (in "func.c") registers the "like" function with either 2 or 3 arguments, but only registers the "glob" function with 2 arguments. |
2008-Jan-22 13:04:28 by drh:
Escape characters in a GLOB as you would in a shell glob, which is
to put them inside of a [...]. Example:
select * from identifiers where ident glob 'foo[?]';
Note also the use of single-quotes instead of double-quotes
around the string literal. SQL requires single-quotes. |
|
2896 |
code
|
closed
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
1
|
1
|
FTS3 misses document, but finds non-matching ones instead
|
edit |
The following script presents a severe bug in FTS3 where it does not find a document even though it is in the index. Instead it finds other documents which do not match the search criteria.
The log below was generated by the original SQLite3.exe 3.5.4 downloaded from the web-site. It shows that the entry 'A-123' is present in the table but is not matched by the query. It also demonstrates that non-matching entries are found instead.
DROP TABLE IF EXISTS fts3;
CREATE VIRTUAL TABLE fts3 using fts3 (a);
INSERT INTO fts3 VALUES ('A-123');
SELECT * FROM fts3;
A-123
SELECT * FROM fts3 WHERE fts3 MATCH 'A-123';
INSERT INTO fts3 VALUES ('A-12');
SELECT * FROM fts3 WHERE fts3 MATCH 'A-123';
A-12
INSERT INTO fts3 VALUES ('A-1');
SELECT * FROM fts3 WHERE fts3 MATCH 'A-123';
A-12
A-1
Here is the SQL only (without output, for easy reproduction):
DROP TABLE IF EXISTS fts3;
CREATE VIRTUAL TABLE fts3 using fts3 (a);
INSERT INTO fts3 VALUES ('A-123');
SELECT * FROM fts3;
SELECT * FROM fts3 WHERE fts3 MATCH 'A-123';
INSERT INTO fts3 VALUES ('A-12');
SELECT * FROM fts3 WHERE fts3 MATCH 'A-123';
INSERT INTO fts3 VALUES ('A-1');
SELECT * FROM fts3 WHERE fts3 MATCH 'A-123';
|
2008-Jan-17 19:36:18 by anonymous:
Sorry, I must have been dreaming: This is of course not a bug but the expected behavior. The '-' character is supposed to exclude the word following it.
My sincere apologies if this has caused doubt or uncertainties to anyone! |
|
2895 |
build
|
closed
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
3
|
1
|
Please describe how to run an indvidual test out of the test suite
|
edit |
Please describe how to run an individual test out of the test suite? Thanks.
For example, how to run the test incrvacuum-ioerr-1.31.4 |
2008-Jan-17 17:14:12 by drh:
Tickets are for reporting bugs, not asking questions about how
to compile or operate SQLite. For questions of that nature, please
post comments on the SQLite mailing list. See
http://www.sqlite.org/support.html.
PS: You cannot run individual tests. You have to run
an entire script. |
|
2891 |
code
|
closed
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
2
|
3
|
col with "NOT NULL", no default: works on table create, not col add
|
edit |
- WORKS:
CREATE TABLE my_table ("my_column" integer NOT NULL);
- GIVES ERROR:
ALTER TABLE my_table ADD "my_other_column" integer NOT NULL;
(2) gives the error: "SQL error: Cannot add a NOT NULL column with default value NULL"
This is inconsistent, either both cases should work, or both should give an error. |
2008-Jan-15 19:59:03 by anonymous:
This is default in all SQL database managers.
If a column can't have a default NULL value, how it will be added to a table with existing rows ?
How that columns will have the default column value is there´s no default and has the NOT NULL constraint ?
2008-Jan-16 00:15:50 by drh:
Anonymous poster above is correct. This is not a bug. |
|
2890 |
build
|
closed
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
1
|
1
|
Assistance request fixing six 3.5.4 i/o test failures
|
edit |
Failures include exclusive-ioerr-2.280.4 exclusive-ioerr-2.281.4 exclusive-ioerr-2.282.4 incrvacuum-ioerr-1.31.4 io-4.1 io-4.2.3
Please let me know how to run individual tests, so I can debug these and submit fix suggestions.
Thanks. |
2008-Jan-15 21:50:52 by drh:
These errors do not appear when the tests are run
individually. They are only reproducible when you
run the complete test suite.
2008-Jan-16 03:15:50 by anonymous:
Please give an example of how to run one individual test.
Thanks. |
|
2889 |
build
|
closed
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
3
|
2
|
Cannot disable TCL
|
edit |
Slackware 12
TCL/TK is not installed, as I don't need it, and don't really want to install it
Sequence of commands to reproduce :
tar -xzvf sqlite-3.5.4.tar.gz
cd sqlite-3.5.4
mkdir bld
cd bld
../configure --disable-tcl --without-tcl
make
The last command dies with
rm tsrc/sqlite.h.in tsrc/parse.y
cp parse.c opcodes.c keywordhash.h tsrc
tclsh ../tool/mksqlite3c.tcl
make: tclsh: Command not found
make: *** [sqlite3.c] Error 127
root@slack12:~/install/sqlite-3.5.4/bld# ls ..
Thanks in advance
Roman |
Same as #2845, #2346, #2871. |
|
2888 |
code
|
closed
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
3
|
4
|
statement not commited
|
edit |
code:
#include <stdio.h>
#include "sqlite3.h"
int main() {
sqlite3 *db;
sqlite3_stmt *stmt;
sqlite3_open("test.db", &db);
sqlite3_prepare(db, "SELECT 1", -1, &stmt, NULL);
sqlite3_step(stmt);
sqlite3_exec(db, "CREATE TABLE t(a INT)", NULL, NULL, NULL);
printf("%s\n", sqlite3_errmsg(db));
return -1;
}
CREATE TABLE isn't commited. There is no BEGIN, CREATE TABLE doesn't return an error, so I think table should be created. |
2008-Jan-15 12:28:21 by drh:
The pending SELECT statement must complete before a COMMIT
will occur. See the documentation. |
|
2887 |
code
|
closed
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
anonymous
|
5
|
5
|
|| not outputing correctly with empty fields
|
edit |
While using || to concatenate fields for output, the rows with a NULL field are not printed.
Example:
-all rows:
sqlite> select vend_city,vend_state,vend_zip from vendors;
vend_city vend_state vend_zip
---------- ---------- ----------
Bear Town MI 44444
Anytown OH 44333
Dollsville CA 99999
New York NY 11111
London N16 6PS
Paris 45678
-Using ||, the 2 last rows with NULL states do not show on the output:
sqlite> select vend_city ||','|| vend_state ||','|| vend_zip from vendors;
vend_city ||','|| vend_state ||','|| vend_zip
Bear Town,MI,44444
Anytown,OH,44333
Dollsville,CA,99999
New York,NY,11111 |
2008-Jan-15 12:30:30 by drh:
The expression
NULL || <expr>
evaluates to NULL, regardless of the value of <expr>.
This is in accordance with the SQL standard.
Use the coalesce() or ifnull() functions to work around
this. |
|
2876 |
build
|
closed
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
1
|
1
|
3.5.4 fails to build on OpenBSD...
|
edit |
$ ./configure --prefix=/home/achowe/Projects/org/sqlite --disable-tcl --enable-threadsafe
$ make
...
rm tsrc/sqlite.h.in tsrc/parse.y
cp parse.c opcodes.c keywordhash.h tsrc
tclsh ./tool/mksqlite3c.tcl
tclsh: not found
*** Error code 1
There appears to be a TCL dependency even though I've specified --disable-tcl. Stock OpenBSD does not supply TCL and I have no desire to install it. |
Duplicate of ticket #2845. |
|
2871 |
build
|
closed
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
3
|
3
|
SQLite 3.5.4 build process does not listen to --disable-tcl
|
edit |
I build sqlite without TCL support, with an incantation along the lines of:
../sqlite-3.5.4/configure --disable-tcl; make .
This works fine in 3.5.3 but 3.5.4 fails late in the compilation, looking for tclsh : tclsh ../sqlite-3.5.4/tool/mksqlite3c.tcl is the command it's trying to run.
I'm building on Solaris 10u4 and the full incantation for configure is as follows (most of this is for readline): ../sqlite-3.5.4/configure --prefix=/home/tfb/packages/sqlite-3.5.4 --enable-static=no --with-readline-lib="-L/opt/sfw/lib -R/opt/sfw/lib -lreadline -lcurses" --with-readline-inc=-I/opt/sfw/include --disable-tcl . I use gmake (which is GNU make, in /usr/sfw/bin= on Solaris 10) to compile.
This is not urgent for me - I will just stick with 3.5.3 for now - but it would be nice to avoid mandatory dependence on TCL I think.
Thanks
--tim |
Duplicate of ticket #2845 |
|
2870 |
code
|
closed
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
danielk1977
|
5
|
5
|
Comment error
|
edit |
In the #4666 checkin comment is:
+** Change the value of the P3 operand for a specific instruction.
+*/
+void sqlite3VdbeChangeP5(Vdbe *p, int addr, u8 val){
but should be: .... P5 .... operand
|
Thanks. |
|
2868 |
code
|
closed
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
1
|
1
|
Encryption user can't link latest SQLite
|
edit |
I have licensed the encryption package and have it working with an earlier version of SQLite. I downloaded the current stable release, copied it over the previous version and compiled it. It compiled fine, but now the pager has unresolved externals, it seems many of the function names have changed.
Please advise.
Thanks
Tim |
2008-Jan-03 14:00:20 by drh:
The license is perpetual with unlimited free updates. You just
have to send us private email and we will send you back the
latest code. |
|
2862 |
warn
|
closed
|
2007 Dec
|
anonymous
|
|
2008 Jan
|
|
4
|
3
|
Small warning fix
|
edit |
Hi, There is a harmless warning in btree.c about szNext being used uninitialized, with a comment in the code saying that adding an extra initialization to silence it would slow it down.
But I've done it another way which will probably make a tiny speed-up instead (only when failing some step though, I think)
Diff:
http://megasource.no-ip.org/PTstuff/btree.c.morefix
http://megasource.no-ip.org/PTstuff/btree.c.fix (the original fix, just to silence the warning) |
2008-Jan-01 06:19:11 by danielk1977:
Thanks. |
|
2861 |
doc
|
closed
|
2007 Dec
|
anonymous
|
|
2008 Jan
|
|
1
|
1
|
How do I connect to Crystal Reports - I am using vs2003 & the Finisar
|
edit |
Not sure of the right venue for this question. My apologies if this is not the right place. I am developing a simple accounting application for a non-profit organisation. I am using vs2003 and programming in c#. To date I have used Access (Jet) database files and the Crystal Report Generator built in to VS2003. I thought SQLite would be a better choice than the Access database - simple to change my c# code using the Finisar data provider, but I am at a loss to see how I can use this provider in Crystal. Is there any way to get this provider onto the list of ADO DB providers in Crystal - or any other approach I could use. If I cannot use Crystal is there an alternative for producing reports which can link to SQLite. Any help much appreciated. Roger Lovelock |
2007-Dec-29 13:58:55 by anonymous:
Not a bug. Better ask this on the mailing list.
To subscribe to the list, send a message to:
<sqlite-users-subscribe@sqlite.org>
For help and a description of available commands, send a message to:
<sqlite-users-help@sqlite.org>
2008-Jan-01 06:07:34 by danielk1977:
This question would have a good chance of success if put to the mailing list. Suggest trying it there. |
|
2858 |
build
|
closed
|
2007 Dec
|
anonymous
|
|
2008 Jan
|
danielk1977
|
3
|
3
|
amalgamated sqlite3.c requires sqlite3ext.h
|
edit |
Staring with SQLite 3.5.3, the "amalgamted" source file sqlite3.c requires sqlite3ext.h to compile. This is because sqlite3.c attempts to effectively include sqlite3ext.h instead of simply copying/pasting its contents:
$ grep sqlite3ext.h sqlite3.c
#define SQLITE_CORE 1 /* Disable the API redefinition in sqlite3ext.h /
/************** Include sqlite3ext.h in the middle of loadext.c **************/
/************** Begin file sqlite3ext.h **************************************/
** @(#) $Id: sqlite3ext.h,v 1.17 2007/08/31 16:11:36 drh Exp $
/************** End of sqlite3ext.h ******************************************/
#include "sqlite3ext.h"
/************** Include sqlite3ext.h in the middle of fts3_tokenizer.c *******/
/************** Begin file sqlite3ext.h **************************************/
** @(#) $Id: sqlite3ext.h,v 1.17 2007/08/31 16:11:36 drh Exp $
/************** Include sqlite3.h in the middle of sqlite3ext.h **************/
/************** Continuing where we left off in sqlite3ext.h *****************/
/************** End of sqlite3ext.h ******************************************/
Compare to earlier versions such as SQLite 3.5.2:
#define SQLITE_CORE 1 /* Disable the API redefinition in sqlite3ext.h /
/************** Include sqlite3ext.h in the middle of loadext.c **************/
/************** Begin file sqlite3ext.h **************************************/
** @(#) $Id: sqlite3ext.h,v 1.17 2007/08/31 16:11:36 drh Exp $
/************** End of sqlite3ext.h ******************************************/
|
If you look at it in context you can see that sqlite3ext.h will never be #included since SQLITE_CORE is defined.
#ifndef SQLITE_CORE
#include "sqlite3ext.h"
SQLITE_EXTENSION_INIT1
#endif
2007-Dec-29 10:16:59 by anonymous:
And yet SQLite 3.5.2 doesn't build here, maybe because SQLITE_CORE is not defined here. Where and how should SQLITE_CORE be defined?
2007-Dec-29 10:24:58 by anonymous:
We compile SQLite with SQLITE_OMIT_LOAD_EXTENSION defined.
2007-Dec-30 13:10:01 by anonymous:
OK, I now understand the problem much better. Below is a short explanation. My apologies for the initial bug report, it was a bit misleading and not detailed enough.
You've added fts3.c to the amalgamated source file of SQLite, starting with version 3.5.3.
Now "sqlite3ext.h" is needed by two of the amalgamated files:
- loadext.c: It includes "sqlite3ext.h" and
SQLITE_CORE must be defined first.
- fts3.c: It includes "sqlite3ext.h" and I think
SQLITE_CORE must be defined first since the FTS3 module is being built into the core of SQLite and not as an extension.
There are actually many issues:
- I think the amalgamated source file should never include "sqlite3ext.h". Instead its should copy/paste its contents when needed. This is done for loadext.c but not for fts3.c, resulting in the following error when building sqlite3.c without "sqlite3ext.h":
sqlite3.c:80297:26: error: sqlite3ext.h: No such file or directory
sqlite3.c:80335: error: expected ',', ';', 'asm' or '__attribute__' before 'static'
sqlite3.c:86299: error: expected ';', ',' or ')' before '*' token
I solved this by making sure SQLITE_CORE is defined when processing the contents of fts3.c, whether SQLITE_OMIT_LOAD_EXTENSION is defined or not, by moving:
#ifndef SQLITE_OMIT_LOAD_EXTENSION
after the block starting with:
#define SQLITE_CORE 1 /* Disable the API redefinition in sqlite3ext.h */
/************** Include sqlite3ext.h in the middle of loadext.c **************/
- The FTS3 module in the amalgamated source file is built into the resulting library when
SQLITE_CORE is not defined, whether SQLITE_ENABLE_FTS3 is defined or not:
#if !defined(SQLITE_CORE) || defined(SQLITE_ENABLE_FTS3)
#if defined(SQLITE_ENABLE_FTS3) && !defined(SQLITE_CORE)
# define SQLITE_CORE 1
#endif
[...]
I'm not sure that's on purpose. Do you want the FTS3 module always built into the resulting SQLite library? If so, I think it would be more readable not to trigger this by defining SQLITE_CORE . Or at the very least it could be triggered by defining SQLITE_ENABLE_FTS3 if SQLITE_CORE is defined in a single place - not all over the FTS3 source files.
Is there any chance this ticket is opened again? Should I open a new ticket instead ?
2007-Dec-30 17:17:07 by anonymous:
SQLITE_CORE is defined previously in sqlite3.c. You can define it yourself on the commandline if you like.
What compiler are you using? Will it #include a file even when it is not wanted, as in:
#if 0
#include "foo.h"
#endif
or
#ifdef SOME_UNDEFINED_MACRO
#include "bar.h"
#endif
2007-Dec-30 17:53:42 by anonymous:
I can recreate your problem. If I use http://sqlite.org/sqlite-amalgamation-3_5_4.zip, unzip it, delete sqlite3ext.h and grab shell.c from CVS:
$ gcc -I. -DSQLITE_OMIT_LOAD_EXTENSION shell.c sqlite3.c -o shell -lpthread
sqlite3.c:81710:26: error: sqlite3ext.h: No such file or directory
sqlite3.c:81748: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘static’
sqlite3.c:87815: error: expected ‘;’, ‘,’ or ‘)’ before ‘*’ token
You must use both -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_CORE on the compile line:
gcc -I. -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_CORE shell.c sqlite3.c -o shell -lpthread
That's a bug. The workaround is simple, though - always compile with -DSQLITE_CORE
As you've found out, if you choose to build with FTS3 support you do not have to #define SQLITE_CORE on the compile line, as it defines it for you:
gcc -I. -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_ENABLE_FTS3 shell.c sqlite3.c -o shell -lpthread
2007-Dec-30 17:55:25 by anonymous:
I'm using GCC, Visual Studio, Intel C++, HP ANSI C/aC++, SGI MIPSpro, Sun Studio, IBM XL C and other compilers. They will certainly not #include a file even when it is not wanted.
How is your remark related to the use case exposed above?
2007-Dec-30 18:08:50 by anonymous:
Ignore the #include thing - it was just an idea.
The sqlite bug is explained in detail in the 2007-Dec-30 17:53:42 comment.
2007-Dec-30 18:09:36 by anonymous:
Indeed, SQLITE_CORE is usually defined by the loadext.c source code. Unfortunately this will not happen if SQLITE_OMIT_LOAD_EXTENSION is defined.
The fts3.c source code in the amalgamated source file needs to be compiled with SQLITE_CORE if we want it:
- not to include "sqlite3ext.h",
- and not to build the FTS3 module unless
SQLITE_OMIT_LOAD_EXTENSION is defined.
So yes, the solution is to define SQLITE_CORE when building the amalgamated source file:
- either from the command line, in which case this requirement needs to be documented,
- or within the amalgamated source file itself, in which case
#define SQLITE_CORE 1
should be added before any reference to _sqlite3ext.h".
2008-Jan-01 05:51:17 by danielk1977:
Thanks. |
|
2855 |
code
|
closed
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
drh
|
2
|
3
|
Get an error "11:database disk image is malformed" during queries
|
edit |
I don't know what has happened to my database and when. I followed every new sqlite version as soon as it got released. So now I am with version 3.5.4 (WinXP) and my database has grown up to a size of about 1.74 GB. It contains only three tables and neither views nor triggers.
When I run a query on all records of one table I got the a.m. error message and no results. I was able to query all details by RowID up to and above a small range of only 105 records (out of 345767
). No problem below and none above. Then I renamed the table, created another table and "insert into .. select from .." one into the other in two steps. ("where RowID between .. and .. or RowID between .. and .." popped up the error message again but running two queries one after the other worked fine.
That's my workaround.
It is a pitty that I cannot send you an example but I do not know how to shrink the database to only remain with the route cause of trouble. I dropped the other two tables and deleted all records before and after the malformed part but now I cannot vacuum without getting again that message.
- How may I got this malformed records into my database? How to avoid repetition?
- How can I eliminate a malformed part out of the database without having to recreate almost everything from scrap?
As soon as the malformed records are touched every command stops.
Isn't there a possibility to put such records into quarantine ?! This would really help to isolate problems and would hopefully give me a chance to send you the damaged records for your analysis to find out what may have happened. The isolation of records may be related to "check integrity" of the database. Another good idea may be to give sqlite.exe a chance to extract isolated part under quaratine from one into another database. - I keep my damaged database for such a case for a while, expecting such a command with the next release. |
2007-Dec-21 12:52:51 by drh:
Information on how to corrupt an SQLite database file can be found
at
To restore data as much as you can from a corrupt
database file, do this:
sqlite3 corrupt.db .dump | sqlite3 restored.db
This ticket reads more like a support request than a bug
report. Or perhaps it is a feature request - requesting that
corruption be "quarantined". Quarantining bad records
merely masks errors and gives no new capabilities so that
is not something we are interested in doing. For technical support see
2007-Dec-21 13:06:46 by anonymous:
Thank you for your quick response and hints about more info on causes for db corruptions.
However, "sqlite3.exe corrupt.db .dump | sqlite3 restored.db"
did not work because of the malformed records, which interrupted the process after a while of work. - For me it would be enough if "delete from tbl where RowID between nn and mm" would work without failing because of using the malformed space. This would be good for healing a db file if the problem could be isolated like in my case.
Sorry, if dealing with such problems isn't the right place here. (By the way: the first 5 fields of that table are forming the primary index; there are no other indexes on that table.)
I wish you a merry christmas and a happy and successfull new year.
2007-Dec-21 13:08:59 by drh:
The ".dump" command attempts to work around corruption. If you have some
kind of corruption that it is unable to work-around, then append an example
database to this ticket and we will reopen the ticket and work on the problem.
Without having access to a database that demonstrates the problem, I am afraid
there is not much we can do.
2007-Dec-21 14:03:59 by anonymous:
Well. Didn't know about .dump is working around corruption and tried to do this with my database where I eliminated good content around the malformed records. Your recommendation worked without raising the aborting error message. It will not solve the appearance but is a great help to heal the database for continued work. Thank you for this additional information! |
|
2854 |
code
|
closed
|
2007 Dec
|
danielk1977
|
|
2007 Dec
|
danielk1977
|
1
|
1
|
BEGIN EXCLUSIVE does not prevent other shared-cache users from reading
|
edit |
Subject says it all. Executing a "BEGIN EXCLUSIVE" does not prevent other shared cache users from reading the database. |
2007-Dec-20 17:53:32 by danielk1977:
The attached test file demonstrates the problem.
2007-Dec-20 19:28:29 by anonymous:
Could this cause unexpected deadlocks? |
|
2848 |
code
|
closed
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
4
|
4
|
windows CRLF is incorrectly handled by .dump
|
edit |
If I insert a string containing standard windows CRLF (0x0D, 0x0A) into the table, and then try to .dump the table, instead of original CRLF, I get a 'CRCRLF' (0x0D, 0x0D, 0x0A). It is probably not helpful to mention that the column does not use any special collation and that the database is in UTF-8 mode. I am on windows xp, and use original build of sqlite3.exe 3.5.4.
I am sorry if this problem already has its own ticket, or if I missed some configuration in sqlite3/dump, but I could not find any such. |
2007-Dec-17 14:06:58 by anonymous:
I can't reproduce this on MS Windows Vista with SQLite v3.5.4.
Snippet from .dump output:
sqlite3 test.db3 .dump | od --address-radix=x --format=x1a
000060 0d 0a 49 4e 53 45 52 54 20 49 4e 54 4f 20 22 74
cr nl I N S E R T sp I N T O sp " t
000070 65 73 74 31 22 20 56 41 4c 55 45 53 28 31 2c 27
e s t 1 " sp V A L U E S ( 1 , '
000080 61 6c 0d 0a 70 68 61 27 29 3b 0d 0a 43 4f 4d 4d
a l cr nl p h a ' ) ; cr nl C O M M
000090 49 54 3b 0d 0a
I T ; cr nl
Perhaps the extra control character was accidently loaded into the database?
2007-Dec-17 15:18:53 by drh:
Unable to reproduce on WinXP.
2007-Dec-17 22:12:27 by anonymous:
Thanks for fast response. The extra 0x0D was surely not in the database. I reviewed my situation over and it looks like a windows shell (cmd.exe) is adding the extra 0x0D as I was redirecting stdout from dump like this:
cmd /c sqlite3 test.db3 .dump > test.txt
Sorry to blame you. |
|
2837 |
code
|
closed
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
2
|
2
|
can't build testfixture in latest CVS
|
edit |
./configure && make clean && make testfixture
gcc -g -O2 -I. -I./src -DNDEBUG -I/usr/include/tcl8.4.13 -DSQLITE_THREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -c ./src/alter.c -o alter.o
./src/alter.c: In function ‘renameTableFunc’:
./src/alter.c:77: error: ‘TK_SPACE’ undeclared (first use in this function)
./src/alter.c:77: error: (Each undeclared identifier is reported only once
./src/alter.c:77: error: for each function it appears in.)
./src/alter.c: In function ‘renameTriggerFunc’:
./src/alter.c:135: error: ‘TK_SPACE’ undeclared (first use in this function)
make: *** [alter.lo] Error 1
|
2007-Dec-13 13:22:42 by drh:
Works for me.
Try running configure in a directory separate from the source
tree:
../sqlite/configure; make testfixture
2007-Dec-13 16:16:04 by anonymous:
When I "cvs up -A; cvs diff" the sources show no changes at all. So I tried the following:
make clean
make distclean
./configure --disable-shared
make test
But I get the same errors.
So I run the old tree and the new tree's alter.c through gcc -E and here's the difference:
--- ../../sqlite/alter.old 2007-12-13 11:04:15.000000000 -0500
+++ alter.new 2007-12-13 11:04:25.000000000 -0500
@@ -599,7 +599,7 @@
HashElem *sqlite3HashFindElem(const Hash*, const void *pKey, int nKey);
void sqlite3HashClear(Hash*);
# 154 "./src/sqliteInt.h" 2
-# 1 "./src/parse.h" 1
+# 1 "./parse.h" 1
# 155 "./src/sqliteInt.h" 2
# 1 "/usr/include/stdio.h" 1 3 4
# 28 "/usr/include/stdio.h" 3 4
@@ -3532,7 +3532,7 @@
do {
zCsr += len;
len = sqlite3GetToken(zCsr, &token);
- } while( token==TK_SPACE );
+ } while( token==145 );
((void) (0));
} while( token!=19 && token!=115 );
@@ -3582,7 +3582,7 @@
do {
zCsr += len;
len = sqlite3GetToken(zCsr, &token);
- }while( token==TK_SPACE );
+ }while( token==145 );
((void) (0));
# 147 "./src/alter.c"
dist++;
So somehow an old parse.h got copied to to src/ which was the cause of the problem.
If I remove src/parse.h as is well and "make test" now builds.
Documented in this ticket in case someone else happens to have the same problem in the future.
2007-Dec-13 16:18:16 by anonymous:
I must have been testing lemon on src/parse.y some time in the past to cause this problem. |
|
2836 |
build
|
closed
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
1
|
1
|
Undefined symbol 'OP_StackDepth'
|
edit |
There is a error on current cvs version(12/12/07)
with "Undefined symbol 'OP_StackDepth'" message.
opcodes.h and opcodes.c havn't 'OP_StackDepth' definition currently.
Sorry for my short English. |
2007-Dec-13 07:41:07 by danielk1977:
opcodes.c and opcodes.h are auto-generated files (generated based on vdbe.c). Likely your copies have not been regenerated since yesterdays modifications.
Try running "make clean" before rebuilding. If that fails, manually remove opcodes.c and opcodes.h from your build directory. |
|
2834 |
event
|
closed
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
2
|
1
|
Is Version 3.1.3 not compatible with 3.5.3 ?
|
edit |
I created this table "CREATE TABLE CALCULATION (sceneid INTEGER, calcid INTEGER, data BLOB, timestamp INTEGER, PRIMARY KEY (sceneid, calcid))" with the sqlite version 3.1.3. And now I have updated to version 3.5.3 and it is not possible to read the data from table CALCULATION. But if I create the table only with one primary key (Primary key (sceneid)), than it is possible to read the data. Is it a bug in version 3.5.3 oder in 3.1.3? How can I read the data with a double primary key? |
2007-Dec-11 18:43:51 by drh:
All versions of SQLite are compatible back through version 3.0.0.
If you think otherwise, please provide details and we will
investigate.
I generate a database using your schema and SQLite version
3.1.3 and it works just fine with SQLite version 3.5.3.
Unable to recreate the problem... |
|
2830 |
code
|
closed
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
5
|
5
|
tkt2822.test refers to tkt2820 ?
|
edit |
typo?
sqlite/test/tkt2822.test -> 1.1
do_test tkt2820-1.1 {
do_test tkt2820-1.3 {
do_test tkt2820-1.3 {
|
Thanks. |
|
2828 |
code
|
closed
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
1
|
2
|
SQLITE_OMIT_SUBQUERY compile error: sqlite3CodeSubselect() missing.
|
edit |
The new sqlite3FindInIndex() calls sqlite3CodeSubselect(), but this is kept out if SQLITE_OMIT_SUBQUERY is defined.
As it stands now, SQLite does not compiled with SQLITE_OMIT_SUBQUERY defined. |
|
2824 |
code
|
closed
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
1
|
1
|
enable shared cache problem
|
edit |
System info:
-Celeron M.
-Windows Xp.
-Single process.
-No thread.
Code:
int WINAPI WinMain(HINSTANCE h1, HINSTANCE h2, LPSTR lpCMD, int nSCMD) {
sqlite3* db;
sqlite3_stmt * stm;
sqlite3_enable_shared_cache(1);
sqlite3_open("db", &db);
sqlite3_prepare_v2(db, "ATTACH DATABASE db2 AS d", 24, &stm, 0);
sqlite3_step(stm);
}
The problem:
the sqlite3_step(stm) execute for an infinite time.
MA |
2007-Dec-06 07:56:12 by danielk1977:
I just tried the following program with the cvs version:
#include "sqlite3.h"
int main (int argc, char **argv){
sqlite3* db;
sqlite3_stmt *stm;
sqlite3_enable_shared_cache(1);
sqlite3_open("db", &db);
sqlite3_prepare_v2(db, "ATTACH DATABASE db2 AS d", 24, &stm, 0);
sqlite3_step(stm);
return 0;
}
And the sqlite3_step() did not block for any amount of time. Can you confirm
that the code above produces the bug in your environment?
Thanks.
2007-Dec-07 13:59:02 by anonymous:
I have ran more test but the problem is never arised. I think it was generated from code or configuration properties from my system, outside sqlite.
MA |
|
2823 |
code
|
closed
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
1
|
1
|
query not return values
|
edit |
I have a database with this description:
CREATE TABLE [coletores] (
[coletor] INTEGER NOT NULL ON CONFLICT ABORT PRIMARY KEY,
[senha] NVARCHAR2(20) NOT NULL ON CONFLICT ABORT);
CREATE UNIQUE INDEX [SenhaUnica] ON [coletores] ([senha]);
and contain this data:
coletor | senha
1 43043553
When i run the query:
"select coletor, senha from coletores where senha = '43043553'"
query not return values. |
Works when I try it.
Perhaps you have some whitespace on one side of the
'43043553' value in the database. Whitespace is
significant to SQLite. |
|
2819 |
code
|
closed
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
2
|
1
|
Blocking and crashing
|
edit |
First it was blocking when using perl lib DBI, i tried to update the packages and finally reinstall them and now i get this:
mush@server:~$ /usr/bin/sqlite3 ./Bureau/lexfix/lexFix/test.dat
SQLite version 3.3.10
Enter ".help" for instructions
sqlite> .schema
/usr/bin/sqlite3: symbol lookup error: /usr/bin/sqlite3: undefined symbol: sqlite3_enable_load_extension
mush@server:~$ /usr/bin/sqlite3 ./Bureau/lexfix/lexFix/test.dat
/usr/bin/sqlite3: symbol lookup error: /usr/bin/sqlite3: undefined symbol: sqlite3_enable_load_extension
|
I think this is a support request, not a bug report.
Please take your comments to the SQLite mailing list. |
|
2818 |
code
|
closed
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
2
|
4
|
Comparison of 8 bytes integer numbers is truncated
|
edit |
sqlite> select -9223372036854775808>=-9223372036854775808;
1
sqlite> select -9223372036854775809>=-9223372036854775808;
1
sqlite> select -9223372036854875808>=-9223372036854775808;
0 |
sqlite> select -9223372036854775808>=-9223372036854775808;
1
This is the correct answer.
sqlite> select -9223372036854775809>=-9223372036854775808;
1
-9223372036854775809 is not an 8-byte integer. The smallest
possible 8-byte integer is -9223372036854775808. The -9..809
value is a 64-bit IEEE floating point number:
-9.22337203685488e+18.
In order to perform the comparison, SQLite converts
the number on the right to floating point value. Due to the
limited precision of floating point numbers, both values are
the same and so the values compare equal to one another.
Hence the result shown above is correct.
sqlite> select -9223372036854875808>=-9223372036854775808;
0
This is the correct answer.
No bugs seen here. |
|
2817 |
code
|
closed
|
2007 Dec
|
danielk1977
|
|
2007 Dec
|
danielk1977
|
1
|
1
|
Temp-tables with the same name as database tables can cause corruption
|
edit |
Suspect a problem in the CREATE INDEX statement here:
CREATE TEMP TABLE abc(a, b, c);
CREATE TABLE main.abc(a, b, c);
CREATE INDEX main.abc_i ON abc(a, b, c);
The attached script demonstrates the problem. |
|
2816 |
code
|
closed
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
drh
|
4
|
3
|
.timer missing from CLI
|
edit |
.timer not valid for 3.5.2/3.5.3 |
It works when I try it.
2007-Dec-04 14:48:14 by anonymous:
No .timer support on Windows.
2007-Dec-04 15:31:30 by drh:
That is correct - there is no timer support on windows.
But on the other hand, we never claimed there was. The
".timer" command does not show up in the help menu on
windows. |
|
2812 |
new
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Dec
|
|
3
|
4
|
SQLITE_SECURE_DELETE overwrites with 0, but should use random data
|
edit |
Hello Dr. Hipp,
SQLITE_SECURE_DELETE overwrites with 0, but should use random data.
I'm not an expert in this area, but it also sounds like secure delete should involve random data then writing to disk several times in a row.
For the firefox bug that relates to this, please see https://bugzilla.mozilla.org/show_bug.cgi?id=405925
Thanks,
-Seth |
2007-Nov-29 18:40:32 by anonymous:
This is a questionable enhancement to security because you cannot ensure where the disk controller will actually write the data on the media. The old fragment may exist elsewhere on the disk. Flash memory cards try to even out where blocks are written to on the media because of the finite number of writes allowed, for example.
It's better to encrypt the whole database file.
2007-Nov-29 21:19:34 by anonymous:
dr. hipp writes:
I don't think writing random bits or writing multiple times
will help any. There are too many layers (operating system,
file system, disk driver, and disk controller) in between
SQLite and the oxide for SQLite to really have much control
over what is truly stored on media. SQLite might write the
same page multiple times, for example, but the OS would
likely coalese the writes into a single write. Perhaps we
could force multiple writes using fsync() but that would be
a huge performance penalty. And even if we did, just
because we write to the same offset in some file does not
mean that the information is written to the same place on
mass storage. Some filesystems (YAFFS) intentionally spread
the writes around to different places for the purpose of
wear leveling. And even if the operating system doesn't do
this, then on-drive disk controller might.
What problem, exactly, are you trying to solve? The existing
SQLITE_SECURE_DELETE is adequate to prevent casual snooping.
It is not, as you observe, adequate to prevent snooping from
major governments. Against a determined adversary, the only
sure defense is to physically shred the disk platter.
2007-Nov-29 21:20:33 by anonymous:
in https://bugzilla.mozilla.org/show_bug.cgi?id=405925#c4, jesse writes:
I don't think it's worth the effort and perf hit to attempt to protect Firefox profile data from forensic data recovery. It's really hard to get right, especially at the app level, and we don't want to give users a false sense of security by trying.
Any given data is likely to appear in many physical locations on the disk due to swapping, journaling, automated backups, and continuous defragmentation [1]
.
When you try to overwrite part of a file, you find yourself fighting against optimizations in operating systems and in disks themselves [2]
. Data also appears in RAM, which can survive power cycling [2]
and is even harder to control.
Zeroing sounds reasonable; it will protect against casual snooping, and depending on the file system, might protect against forensic software. But I don't think we should go beyond zeroing (e.g. multiple overwrites) in an attempt to defeat forensic analysis of the physical hard drive and RAM.
Extremely paranoid users can use operating system features to encrypt an entire hard drive or automatically do multiple overwrites every time data on disk as it is changed.
[1]
http://en.wikipedia.org/wiki/Disk_wipe
[2]
http://en.wikipedia.org/wiki/Data_remanence
2007-Nov-29 21:21:02 by anonymous:
based on these responses, this seems like a "wontfix"
thanks,
-Seth |
|
2804 |
code
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Dec
|
|
1
|
1
|
PRAGMA legacy_file_format=OFF setting lost with VACUUM
|
edit |
It seems that the PRAGMA legacy_file_format=OFF and the ability
to use DESC indexes is lost after two VACUUMs and reconnects.
$ rm -f foo.db
$ ./sqlite3-3.5.3.bin foo.db
SQLite version 3.5.3
Enter ".help" for instructions
sqlite> PRAGMA legacy_file_format;
1
sqlite> PRAGMA legacy_file_format=OFF;
sqlite> PRAGMA legacy_file_format;
0
sqlite> CREATE TABLE abc(a,b,c);
sqlite> CREATE INDEX abc_i on abc(b desc, c asc, a desc);
sqlite> explain query plan select * from abc order by b desc, c asc, a desc;
0|0|TABLE abc WITH INDEX abc_i ORDER BY
sqlite> vacuum;
sqlite> .q
In the next connection we see that the legacy file format reverted
back to 1, but the DESC index is still picked up...
$ ./sqlite3-3.5.3.bin foo.db
SQLite version 3.5.3
Enter ".help" for instructions
sqlite> PRAGMA legacy_file_format;
1
sqlite> explain query plan select * from abc order by b desc, c asc, a desc;
0|0|TABLE abc WITH INDEX abc_i ORDER BY
sqlite> vacuum;
sqlite> .q
But if connected to another time, the DESC index is not picked up...
$ ./sqlite3-3.5.3.bin foo.db
SQLite version 3.5.3
Enter ".help" for instructions
sqlite> PRAGMA legacy_file_format;
1
sqlite> explain query plan select * from abc order by b desc, c asc, a desc;
0|0|TABLE abc
|
Actually, this works correctly, though the documentation could be clearer.
The legacy_file_format pragma does not tell you the file format of the current
database. Rather, it tells you what file format will be used when creating
new databases (for example, using ATTACH). The behavior shown above is
correct. There is no pragma to tell you what the file format of the current
database is.
The documentation has been clarified. Two new test cases have been inserted
into the test suite to verify that the operation is correct. |
|
2802 |
code
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Dec
|
|
1
|
1
|
SELECT UNION and EXCEPT seem to have a memory allocation bug
|
edit |
It seems that SELECT UNION and EXCEPT operators work wrong. It looks like memory access overflow or integer overflow.
Well, I have a large text file 'text2.text' (~1.5mg), which contains:
20091208
20216510
20149599
20250484
20211910
20199980
........
20183528
20151994
20179184
20077607
182500 lines in total. The meaning of these numbers is a date in YYYYMMDD format. Numbers are random and unsorted at all.
The next file is 'test1.text' is the same as 'test2.text' but without the last 1000 lines. The 'diff' between these files shows the difference in last 1000 lines.
Than I execute script:
@echo off
if exist test.db del test.db
rem
rem Load data into table 'a'
rem It prints 181500
sqlite3 test.db "create table a (i1 text)"
sqlite3 test.db ".import test1.text a"
sqlite3 test.db "select count(*) from a"
rem
rem Load data into table 'b'
rem It prints 182500
sqlite3 test.db "create table b (i1 text)"
sqlite3 test.db ".import test2.text b"
sqlite3 test.db "select count(*) from b"
rem
rem PROBLEM IS HERE
rem Now I am trying to merge the tables 'a' and 'b' via UNION.
rem It should print '182500' but it prints '16384' !!!
sqlite3 test.db "create table c (i1 text)"
sqlite3 test.db "insert into c select * from b union select * from a"
sqlite3 test.db "select count(*) from c"
rem
rem Just a check that EXCEPT also has the same bug.
rem It should print 1000, but it prints '0' !!!
sqlite3 test.db "select count(*) from (select * from c except select * from b)"
I suggest that UNION and EXCEPT has some kind of memory overflow. And also it depends on how strong the numbers in the source text file are shuffled and how wide is the range of the numbers.
I can attach my files 'test1.text' and 'test2.text' if needed.
My system: CPU Intel Core 2 Duo, 1.06GHz, 2GB RAM.
Operating system: Windows XP SP2 (Version 5.1.2600) |
2007-Nov-27 23:45:42 by drh:
UNION and EXCEPT both imply DISTINCT. Since you are dealing with dates,
it seems unlikely that you really have 182500 distinct dates. That would
span 500 years and your sample data seems to all be from the early part
of the 21st century. 16384 distinct dates would span 44 years, which
seems more reasonable, given your sample data. The fact that the number
is a power of two probably results from a poor-quality PRNG used to
generate the same data.
You can use UNION ALL to to get the union of two tables without the
implied DISTINCT. There is no way to omit the implied DISTINCT from
EXCEPT. You will probably need to refactor your query to use the NOT IN
operator.
2007-Dec-05 20:10:08 by anonymous:
Actually, in the real data, when I've got this situation on EXCEPT and UNION, there are some extra fields in the database. Except 'date', there were text fields: 'amount', 'owner', 'descr', 'labels' (it's personal cash accouting database). When the test data was generatated, all fields could have duplicate values, but 'amount' field was generated like:
$amount = sprintf( "%d.%02d", rand( 1, 10000 ), rand( 0, 99 ) );
so, it can take 9999999 possible values, which is more than 16384 for sure.
And the behaviour of the EXCEPT was completely the same as I've described the the original message of this bug report. That's why I've decided that the key of the problem is just in the amount of data, not in values, and I've reduced the database structure for the bug report to make it more clear (I left only one field 'date'), but the 'bug' (I mean this strange behaviour of the EXCEPT and UNION) still happens in the reduced database structure (with only one field 'date'). So DISTINCT function will not merge all values of 'amount' field into 16384 unique values.
What do you think? |
|
2798 |
build
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
3
|
4
|
Wrong nm used when cross-compiling
|
edit |
When cross-compiling, the build platforms nm is used, instead of the one for the target platform.
I included a patch for Makefile.in and configure.ac to start using the detected nm instead of the hardcoded 'nm'. |
2007-Nov-27 14:53:06 by drh:
The configure script is a mess and I am disinclined to
make it a bigger mess by trying to fix cross-compilation.
A better approch to cross-compiling is to use the
amalgamation. Build the amalgamation using:
make sqlite3.c
Then compile sqlite3.c for your target system using
whatever cross-compiler you want. |
|
2790 |
code
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
danielk1977
|
2
|
2
|
sqlite3_compile returns NULL for empty statements
|
edit |
There was apparently a backwards-incompatible behaviour change in 3.5 and later versions.
sqlite3_compile() for an empty statement, like "" now returns a NULL pointer for the statement, but the function returns SQLITE_OK. In my applications I always assumed that if sqlite3_compile() returns SQLITE_OK, then there will be a valid statement.
Now if you sqlite3_step() on the NULL pointer, you get a segfault. |
This has been fixed so that passing a NULL pointer to sqlite3_step() returns SQLITE_MISUSE, as it did for earlier versions. Strictly speaking, applications are not supposed to pass NULL to sqlite3_step().
See also #2773. |
|
2782 |
code
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
1
|
1
|
bind_text(...) into transaction
|
edit |
In Transaction i insert some values, using sqlite3_bind_text(...)
The first row has undef value(some times it's empty), but other rows have normal values. |
2007-Nov-21 13:50:25 by drh:
If you can describe some kind of problem with SQLite, we will
be happy to look into the matter. Your description above
sounds like a bug in your own code though. What about this
problem makes you think it is a bug in SQLite? |
|
2779 |
code
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
2
|
2
|
Performance optimizations
|
edit |
Performance optimizations
)) PRAGMA: Does anyone have experience and good results optimizing sqlite performance using PRAGMA's?
)) Other techniques: Any success stories on sqlite optimization methods of any type would be appreciated.
Here is a list of the PRAGMA's and example use from the sqlite documentation:
PRAGMA auto_vacuum;
PRAGMA auto_vacuum = 0 | none | 1 | full | 2 | incremental;
PRAGMA cache_size;
PRAGMA cache_size = Number-of-pages;
PRAGMA case_sensitive_like;
PRAGMA case_sensitive_like = 0 | 1;
PRAGMA count_changes;
PRAGMA count_changes = 0 | 1;
PRAGMA default_cache_size;
PRAGMA default_cache_size = Number-of-pages;
PRAGMA default_synchronous;
PRAGMA empty_result_callbacks;
PRAGMA empty_result_callbacks = 0 | 1;
PRAGMA encoding;
PRAGMA encoding = "UTF-8";
PRAGMA encoding = "UTF-16";
PRAGMA encoding = "UTF-16le";
PRAGMA encoding = "UTF-16be";
PRAGMA full_column_names;
PRAGMA full_column_names = 0 | 1;
PRAGMA fullfsync
PRAGMA fullfsync = 0 | 1;
PRAGMA incremental_vacuum(N);
PRAGMA legacy_file_format;
PRAGMA legacy_file_format = ON | OFF
PRAGMA locking_mode;
PRAGMA locking_mode = NORMAL | EXCLUSIVE
PRAGMA main.locking_mode=EXCLUSIVE;
PRAGMA page_size;
PRAGMA page_size = bytes;
PRAGMA max_page_count;
PRAGMA max_page_count = N;
PRAGMA read_uncommitted;
PRAGMA read_uncommitted = 0 | 1;
PRAGMA short_column_names;
PRAGMA short_column_names = 0 | 1;
PRAGMA synchronous;
PRAGMA synchronous = FULL; (2)
PRAGMA synchronous = NORMAL; (1)
PRAGMA synchronous = OFF; (0)
PRAGMA temp_store;
PRAGMA temp_store = DEFAULT; (0)
PRAGMA temp_store = FILE; (1)
PRAGMA temp_store = MEMORY; (2)
PRAGMA temp_store_directory;
PRAGMA temp_store_directory = 'directory-name'; |
This is not a bug report. Ask any questions on the mailing list. |
|
2778 |
code
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
adixon
|
1
|
1
|
Error 0
|
edit |
CREATE PROCEDURE Driver_Daily_Activity
{
@comp_code varchar(8),
@begin_date datetime,
@end_date datetime,
@emp_short_name varchar(8),
@emp_id int,
@driver_time_in output,
@driver_time_out output,
@driver_beaktime_in output,
@driver_beaktime_out output,
@driver_lunchtime_in output,
@driver_lunchtime_out output,
@total_break_time output
}
AS
select @driver_time_in =driver_datetime_in,@driver_time_out =driver_datetime_out from driver_daily_log with (nolock) where company_code=@comp_code and emp_id=@emp_id and driver_datetime_in >=@begin_date
and driver_datetime_out<@end_date and driver_datetime_out is not null
select @driver_breaktime_in=substring((CAST(break_time_in AS varchar(20))),12,8) ,@driver_breaktime_out=substring((CAST(break_time_out AS varchar(20))),12,8) from driver_daily_break_log with (nolock) where company_code=@comp_code and emp_id=@emp_id and driver_status='OB'.
select @driver_lunchtime_in=substring((CAST(break_time_in AS varchar(20))),12,8) ,@driver_lunchtime_out=substring((CAST(break_time_out AS varchar(20))),12,8) from driver_daily_break_log with (nolock) where company_code=@comp_code and emp_id=@emp_id and driver_status='OL'.
select @total_break_time =sum(total_break_time) from driver_daily_break_log with (nolock) where company_code=@comp_code and emp_id=@emp_id.
This procedure is giving me the following error :
SQL State 42000: Error 0 : Syntax error or access violation |
SQL identifiers may not contain the "@" character. |
|
2777 |
code
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
shess
|
1
|
1
|
FTS[23] compile bug
|
edit |
You need to #include "sqlite3.h" to pick up the sqlite3_malloc() declaration:
./ext/fts3/fts3_hash.c: In function "fts3HashMalloc":
./ext/fts3/fts3_hash.c:38: warning: initialization makes pointer from integer without a cast
Also, can you move the following:
#ifndef SQLITE_ENABLE_BROKEN_FTS2
#error fts2 has a design flaw and has been deprecated.
#endif
to be after this line:
#if !defined(SQLITE_CORE) || defined(SQLITE_ENABLE_FTS2)
in fts2.c?
That way you can build fts3 while having fts2 objects in the Makefile without defining -DSQLITE_ENABLE_BROKEN_FTS2 for an fts3-only build. |
2007-Nov-23 18:21:04 by anonymous:
This error still exists in FTS2 and FTS3:
./ext/fts3/fts3_hash.c: In function "fts3HashMalloc":
./ext/fts3/fts3_hash.c:38: warning: initialization makes pointer from integer without a cast
On some 64-bit systems this will cause FTS to crash because an int is smaller than a pointer.
Nevermind - it was fixed. |
|
2775 |
code
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
danielk1977
|
3
|
4
|
Low-memory SEGV from sqlite3CodeRowTrigger()
|
edit |
I have hit a low memory segment violation in sqlite3CodeRowTrigger() after /* code the WHEN clause */.
sqlite3CodeRowTrigger() calls sqlite3ExprDup() which fails to deep copy the string p->pRight->token.z (and therefore everything thereafter).
sqlite3CodeRowTrigger() continues to call sqlite3ExprResolveNames()
sqlite3ExprResolveNames() calls walkExprTree() for the expression, which recursively calls walkExprTree() for pExpr->pRight which in turn calls nameResolverStep() which then tries to dereference pExpr->token.z[0] (for case TK_STRING) generating the SEGV.
The solution appears to be checking for allocation failures before calling nameResolverStep(), using the same early exit as when this fails. ie replacing:
if( sqlite3ExprResolveNames(&sNC, whenExpr) ){
with:
if( pParse->db->mallocFailed ||
sqlite3ExprResolveNames(&sNC, whenExpr) ){
|
2007-Nov-16 14:36:10 by anonymous:
This change will also prevent an assertion if the previous allocation is the first to fail, or a SEGV if the following one is the first.
Thanks. |
|
2773 |
code
|
closed
|
2007 Nov
|
danielk1977
|
|
2007 Nov
|
|
2
|
1
|
sqlite crashes in sqlite3_step when compiled with SQLITE_THREADS=1
|
edit |
When running the self-test of pysqlite2 [1]
, it crashes.
This only happens when sqlite3 is compiled with the --enable-threads option, but not with --disable-threads.
#0 0xbb987124 in sqlite3_step () from /usr/pkg/lib/libsqlite3.so.0
#1 0xbb9a7307 in _sqlite_step_with_busyhandler ()
from /usr/pkg/lib/python2.4/site-packages/pysqlite2/_sqlite.so
#2 0xbb9a437b in pysqlite_cursor_executescript ()
from /usr/pkg/lib/python2.4/site-packages/pysqlite2/_sqlite.so
#3 0xbbb45baa in PyCFunction_Call () from /usr/pkg/lib/libpython2.4.so.1.0
The reason for the crash is that v->db is NULL. In the non-threaded case, it all works.
[1]
<http://initd.org/pub/software/pysqlite/releases/2.3/2.3.5/pysqlite-2.3.5.tar.gz> |
Python is incorrectly passing NULL to sqlite3_step(). SQLite tests for this and returns SQLITE_MISUSE, but strictly speaking the behaviour in this case is unspecified.
Have changed things so that SQLITE_MISUSE is returned whether the build is threadsafe or not. But this should also be fixed in Python.
2007-Nov-23 13:24:36 by anonymous:
This is now also fixed in pysqlite. |
|
2772 |
code
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
danielk1977
|
3
|
3
|
Low memory assert in analyze
|
edit |
Function sqlite3Analyze() in analyze.c includes the following two lines:
...
z = sqlite3NameFromToken(db, pName1);
pTab = sqlite3LocateTable(pParse, z, 0);
...
In a low memory situation z can be returned as NULL.
sqlite3LocateTable() calls sqlite3FindTable() which promptly asserts on:
assert( zName!=0 );
I expect the solution is to conditionalise some of the code in sqlite3Analyze():
...
z = sqlite3NameFromToken(db, pName1);
if (z){
pTab = sqlite3LocateTable(pParse, z, 0);
sqlite3_free(z);
if( pTab ){
analyzeTable(pParse, pTab);
}
}
...
|
Thanks for the report. |
|
2769 |
new
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
danielk1977
|
3
|
3
|
Enable access to the sql string used to prepare a statement
|
edit |
If would be nice if it was possible to get access to the sql string used to prepare a sqlite3_stmt*, if it was prepared using sqlite3_prepare_v2. In code terms this would probably mean a public wrapper around sqlite3VdbeGetSql. Possible uses are error messages and statement cache. |
|
2768 |
code
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
danielk1977
|
3
|
3
|
asserts in wrong order
|
edit |
If pC is not set, produce a nice assert error message instead of a segfault:
diff -u -3 -p -r1.653 vdbe.c
--- src/vdbe.c 23 Oct 2007 15:39:45 -0000 1.653
+++ src/vdbe.c 11 Nov 2007 19:38:11 -0000
@@ -2005,10 +2005,10 @@ case OP_Column: {
** which is the number of records.
*/
pC = p->apCsr[p1];
+ assert( pC!=0 );
#ifndef SQLITE_OMIT_VIRTUALTABLE
assert( pC->pVtabCursor==0 );
#endif
- assert( pC!=0 );
if( pC->pCursor!=0 ){
/* The record is stored in a B-Tree */
rc = sqlite3VdbeCursorMoveto(pC);
|
Ok. Thanks. |
|
2765 |
code
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
1
|
3
|
bad rollback if temporary table created during transaction
|
edit |
Hi,
trying to resolve a test failure in an application using pysqlite2 (2.3.5) / sqlite 3.42 for its test suite, I've been able to produce a minimal script which shows that the problem is actually in sqlite... I don't think it comes from the python wrapper (if you think it is tell me and I'll redirect it to the appropriate tracker).
Anyway here is the script :
import pysqlite2.dbapi2 as sqlite
cnx = sqlite.connect('testdb')
cursor = cnx.cursor()
cursor.execute('SELECT eid from Trinfo')
nb = len(cursor.fetchall())
cursor.execute("INSERT INTO Trinfo ( from_state, to_state, wf_info_for, eid, creation_date, modification_date ) VALUES ( 734, 735, 5, 758, 1, 1)")
# comment this line and the final assertion is ok
cursor.execute("CREATE TEMPORARY TABLE T58d712f777a7170cb8ce7d94cef119ce (C0 integer,C1 timestamp);")
# get the same result with or without dropping the temp table
#cursor.execute('DROP TABLE T58d712f777a7170cb8ce7d94cef119ce')
cnx.rollback()
cursor.execute('SELECT eid from Trinfo')
nb3 = len(cursor.fetchall())
assert nb3 == nb # FAIL
Notice that if you don't create the temporary table, everything run fine, else the insertion is not actually rollbacked. |
2007-Nov-09 00:23:38 by drh:
I tested using the following TCL script:
file delete -force test.db test.db-journal
sqlite3 db test.db
db eval {
CREATE TABLE t1(a,b,c);
INSERT INTO t1 VALUES(1,2,3);
INSERT INTO t1 VALUES(4,5,6);
INSERT INTO t1 SELECT a*2, b*2, c*2 FROM t1;
INSERT INTO t1 SELECT a*4, b*4, c*4 FROM t1;
INSERT INTO t1 SELECT a*8, b*8, c*8 FROM t1;
}
puts "begin=[md5 [db eval {SELECT * FROM t1}]]"
db eval {BEGIN}
db eval {INSERT INTO t1 VALUES('hello','out','there');}
db eval {CREATE TEMPORARY TABLE T58d712f777(C0 integer,C1 timestamp)}
puts " mid=[md5 [db eval {SELECT * FROM t1}]]"
db eval {ROLLBACK}
puts " end=[md5 [db eval {SELECT * FROM t1}]]"
The results are:
begin=c17bc52be49269f8f2cd3a4df3caee6e
mid=f86cc8ad5b925962323edc041bfaa09d
end=c17bc52be49269f8f2cd3a4df3caee6e
Begin and end are equal so it appears to work using the
TCL interface. I also observe that there are countless
tests in the SQLite test suite that verify that this
sort of thing works correctly.
Perhaps this is something to do with python after all.
2007-Nov-11 20:48:52 by anonymous:
See: http://www.initd.org/pub/software/pysqlite/doc/usage-guide.html#controlling-transactions |
|
2764 |
todo
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
2
|
2
|
Since I installed Leopard I keep getting sqlite3 data bases in trash
|
edit |
Every night I seem to have a bunch of database folders in my trash with sqlite doc inside. I can't seem to delete them all even after quitting my applications.
(I realize this is a developer's page, but this is a real annoyance and I have no idea what to do about it!)
Thanks,
Liz |
2007-Nov-08 02:50:51 by drh:
I am told by engineers at Apple that this is an issue with
Leopard and that it has nothing to do with SQLite. Apple
is working on the problem and will fix it. |
|
2759 |
code
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
danielk1977
|
1
|
2
|
crash due to 'select * from virtualTable where x is null'
|
edit |
For virtual table T1:
select * from t1 where y is NULL;
causes:
1301 assert( pTerm->eOperator & (WO_EQ|WO_LT|WO_LE|WO_GT|WO_GE|WO_MATCH) );
(gdb) bt
#0 0x005e17a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x006217d5 in raise () from /lib/tls/libc.so.6
#2 0x00623149 in abort () from /lib/tls/libc.so.6
#3 0x0061adb1 in __assert_fail () from /lib/tls/libc.so.6
#4 0x00849534 in bestVirtualIndex (pParse=0xbfe2d750, pWC=0xbfe2d1d0,
pSrc=0x9a23d2c, notReady=18446744073709551615, pOrderBy=0x0,
orderByUsable=1, ppIdxInfo=0x9a372bc)
at ../../../../Source/sqlite-3.5.1-hp/src/where.c:1301
#5 0x0084a989 in sqlite3WhereBegin (pParse=0xbfe2d750, pTabList=0x9a23d28,
pWhere=0x9a28ed8, ppOrderBy=0xbfe2d59c)
at ../../../../Source/sqlite-3.5.1-hp/src/where.c:2074
#6 0x0082c6c6 in sqlite3Select (pParse=0xbfe2d750, p=0x9a28f28, eDest=4,
iParm=0, pParent=0x0, parentTab=0, pParentAgg=0x0, aff=0x0)
at ../../../../Source/sqlite-3.5.1-hp/src/select.c:3118
#7 0x0081f16c in yy_reduce (yypParser=0x9a33aa8, yyruleno=104) at parse.y:368
#8 0x00820f65 in sqlite3Parser (yyp=0x9a33aa8, yymajor=1, yyminor=
{z = 0x9a2e120 ";", dyn = 0, n = 1}, pParse=0xbfe2d750) at parse.c:3419
#9 0x0082e877 in sqlite3RunParser (pParse=0xbfe2d750,
zSql=0x9a2e100 "select * from t1 where y is NULL;", pzErrMsg=0xbfe2d74c)
at ../../../../Source/sqlite-3.5.1-hp/src/tokenize.c:449
#10 0x008246a0 in sqlite3Prepare (db=0x9920010,
zSql=0x9a2e100 "select * from t1 where y is NULL;", nBytes=-1,
saveSqlFlag=0, ppStmt=0xbfe2d8e0, pzTail=0xbfe2d8e4)
at ../../../../Source/sqlite-3.5.1-hp/src/prepare.c:525
#11 0x00824a2c in sqlite3LockAndPrepare (db=0x9920010,
zSql=0x9a2e100 "select * from t1 where y is NULL;", nBytes=-1,
saveSqlFlag=0, ppStmt=0xbfe2d8e0, pzTail=0xbfe2d8e4)
at ../../../../Source/sqlite-3.5.1-hp/src/prepare.c:604
#12 0x00824bf9 in sqlite3_prepare (db=0x9920010,
zSql=0x9a2e100 "select * from t1 where y is NULL;", nBytes=-1,
ppStmt=0xbfe2d8e0, pzTail=0xbfe2d8e4)
at ../../../../Source/sqlite-3.5.1-hp/src/prepare.c:658
#13 0x0084d862 in sqlite3_exec (db=0x9920010,
zSql=0x9a2e100 "select * from t1 where y is NULL;",
xCallback=0x8049b23 <callback>, pArg=0xbfe2da20, pzErrMsg=0xbfe2d9ac)
at ../../../../Source/sqlite-3.5.1-hp/src/legacy.c:56
#14 0x0804d2e9 in process_input (p=0xbfe2da20, in=0x0)
at ../../../../Source/sqlite-3.5.1-hp/src/shell.c:1663
#15 0x0804de80 in main (argc=5, argv=0xbfe2efd4)
at ../../../../Source/sqlite-3.5.1-hp/src/shell.c:2001
Fails to accommodate WO_ISNULL flag. |
2007-Nov-05 05:13:22 by danielk1977:
Thanks for the report. |
|
2758 |
code
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Dec
|
|
1
|
1
|
Why this?
|
edit |
sqlite3* s1;
sqlite3* s2;
sqlite3_stmt* stm;
sqlite3_open("db", &s1);
sqlite3_open("db", &s2);
sqlite3_prepare_v2(s2, "SELECT * FROM sqlite_master", 27,&stm, NULL);
sqlite3_step(stm);
sqlite3_finalize(stm);
sqlite3_prepare_v2(s1, "CREATE TABLE C (c1)", 19, &stm, NULL);
sqlite3_step(stm);
sqlite3_finalize(stm);
sqlite3_prepare_v2(s2, "SELECT * FROM C", 15, &stm, NULL);
Last row return ERROR n.17 SQLITE_SCHEMA, But All previous statements are finalized. |
2007-Nov-05 05:17:04 by danielk1977:
It's not obvious.
Which call is returning SQLITE_SCHEMA? sqite3_prepare_v2() or sqlite3_step()?
Are any other processes accessing the same database?
Which version of SQLite are you using?
Can you post a complete program that demonstrates this?
2007-Nov-05 16:00:54 by anonymous:
I can reproduce the original poster's findings.
For me, the final sqlite3_prepare_v2() returns 17 (SQLITE_SCHEMA). Up to this everything works as documented.
I run the posted code unchanged in a single process on Windows XP as main(). The database file does not exist prior to execution.
2007-Dec-13 19:50:15 by rdc:
This was closed as "can not reproduce", but I think the reported behavior is exactly as expected from SQLite.
This program opens two connections to the database file. Runs a query in one which causes SQLite to read the schema. It then adds a table using the second connection. This changes the schema. Finally it tries to execute a query that references the new table using the first connection. This generates an error.
I was informed by DanK on the mailing list that this is the normal behavior of SQLite. I thought that the new prepare_v2 API was supposed check if the schema cache was stale, and reload it before generating a schema error, but he said it didn't. Apparently the poster thinks this behavior is strange as well.
I think this should be reopened, or re-closed as "works as designed". It should be reproducible (I suspect the test was done using a single connection) and maybe shouldn't have been closed the way it was. |
|
2757 |
doc
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
1
|
1
|
Special characters handling in SQLite Like Query
|
edit |
If I have data as follows, they wont show up when I try to search for them.
[[[ ]]]
`~!@#$%^&*
()_+|{}:<>?
-=\[];',./
@@@ %%%
### ^^^
___---
Ho_mer
`~!@#$%^&*()_+|`{}:<>?-=\[];,./
_Storage-Room
@ # $
_ - +
% ^ &
asdf_qwerty
As all the data contains special charcters ,I am replacing them with
SearchS = Trim(SearchS)
SearchS = Replace(SearchS, "'", "''")
SearchS = Replace(SearchS, "[", "[[]")
SearchS = Replace(SearchS, "%", "[%]")
SearchS = Replace(SearchS, "^", "[^]")
SearchS = Replace(SearchS, "#", "[#]")
SearchS = Replace(SearchS, "_", "[_]")
My SQL Query looks like this
select * from table_name where name LIKE '%" & SearchS & "%'
eg . If I am trying to search for '%%%' my query will be
select * from table_name where name LIKE '% [%][%][%]%'
Which is returning zero results.
so how should I replace special characters for SQlite.
Thanks |
2007-Nov-03 00:11:35 by drh:
The description appears to be a question on the proper way to use SQL, not a bug
report. Please use tickets for reporting bugs only. For help with using SQLite,
send a message the the SQLite mailing list. |
|
2752 |
code
|
closed
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
5
|
5
|
redundant assignment?
|
edit |
In unixLock()
struct lockInfo *pLock = pFile->pLock;
and later in the function
pLock = pFile->pLock;
|
2007-Nov-01 05:56:16 by danielk1977:
The second assignment is required as the value of
pFile->pLock might be changed within the call to
transferOwnership() above the second assignment.
In non-threadsafe builds (where transferOwnership
is a no-op) it is redundant, but it's not hurting
anybody. |
|
2751 |
build
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Nov
|
|
2
|
3
|
Regression - Solaris/sparc throws BUS ERROR on count()/sum()/etc.
|
edit |
A regression has crept into sqlite 3.5 (both 3.5.0 and 3.5.1) running on Solaris/sparc when built with GCC (both 3.4.2 and 4.2.2 tested) which leads to a BUS ERROR when simple count()/sum() queries are run. A workaround is to build with Solaris CC.
Example session:
# ./sqlite3
SQLite version 3.5.1
Enter ".help" for instructions
sqlite> create table foo(a);
sqlite> insert into foo values(1);
sqlite> select count(a) from foo;
Bus error (core dumped)
|
2007-Oct-31 18:19:12 by danielk1977:
Can you check that applying this clears the problem? Thanks.
diff -u -r1.110 vdbeapi.c
--- src/vdbeapi.c 17 Oct 2007 01:44:21 -0000 1.110
+++ src/vdbeapi.c 31 Oct 2007 18:15:44 -0000
@@ -446,7 +446,7 @@
pMem->flags = MEM_Agg;
pMem->xDel = sqlite3_free;
pMem->u.pDef = p->pFunc;
- if( nByte<=NBFS ){
+ if( nByte<=NBFS && 0 ){
pMem->z = pMem->zShort;
memset(pMem->z, 0, nByte);
}else{
2007-Nov-02 09:06:57 by anonymous:
I can confirm that your patch prevents the crash. Thank you.
2007-Nov-05 05:51:35 by anonymous:
Do you attribute this error to be a compiler bug or a problem in SQLite?
2007-Nov-05 06:20:42 by danielk1977:
Sorry, I missed your post on November 2.
I think it's an alignment problem. Without the patch, sqlite3_aggregate_context() is
returning a pointer to a pre-allocated buffer. The problem is (I suspect) that the start
of this buffer is not aligned to an 8-byte boundary as required by your architecture.
So I figure an SQLite bug, not a compiler problem.
Will fix shortly.
2007-Nov-05 14:41:25 by anonymous:
Perhaps zShort should be moved after a double in the struct for alignment?
diff -u -3 -p -r1.130 vdbeInt.h
--- src/vdbeInt.h 28 Aug 2007 23:28:08 -0000 1.130
+++ src/vdbeInt.h 5 Nov 2007 14:39:04 -0000
@@ -123,6 +123,7 @@ struct Mem {
FuncDef *pDef; /* Used only when flags==MEM_Agg */
} u;
double r; /* Real value */
+ char zShort[NBFS]; /* Space for short strings */
sqlite3 *db; /* The associated database connection */
char *z; /* String or BLOB value */
int n; /* Number of characters in string value, including '\0' */
@@ -130,7 +131,6 @@ struct Mem {
u8 type; /* One of SQLITE_NULL, SQLITE_TEXT, SQLITE_INTEGER, etc */
u8 enc; /* SQLITE_UTF8, SQLITE_UTF16BE, SQLITE_UTF16LE */
void (*xDel)(void *); /* If not null, call this function to delete Mem.z */
- char zShort[NBFS]; /* Space for short strings */
};
typedef struct Mem Mem;
|
|
2750 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
2
|
1
|
for the new.somefield value returns the old value of it
|
edit |
For the update trigger on a table containing n columns when retrieving the new value of filed the value of which was not changed at update (so the new value is null)it returns its old value. |
2007-Oct-31 18:21:32 by danielk1977:
That's how it's documented to work. |
|
2747 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Nov
|
maria.khomenko
|
1
|
1
|
How to use Composite Key in Sqlite
|
edit |
How to use Composite Key in Sqlite |
Tickets are for reporting bugs. Please ask general questions
such as this on the SQLite mailing list.
2007-Nov-01 11:34:53 by anonymous:
but kindly Maria Give me the Way how can i use
2007-Nov-02 07:15:59 by anonymous:
How and where Can i do that
2007-Nov-02 07:18:06 by anonymous:
If you have some Articles regarding that mail me at
rizwan_aman007@yahoo.co.in
2007-Nov-05 05:39:22 by anonymous:
I did't get any resolution. plz help me
2007-Nov-08 12:07:18 by anonymous:
` |
|
2746 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
PRIMARY KEY does not treat NULL as unique
|
edit |
The below inserts 2 records. One record would be expected.
CREATE TABLE test(Colour VARCHAR COLLATE NOCASE,SubType VARCHAR COLLATE NOCASE,weight DOUBLE, PRIMARY KEY (Colour,SubType));
BEGIN TRANSACTION;
INSERT OR REPLACE INTO test VALUES('red', NULL, 100);
INSERT OR REPLACE INTO test VALUES('red', NULL, 100);
COMMIT
I understand that the NULL behaviour is hazy but this seems to not agree with the doc where it says: "nulls are distinct in a UNIQUE column". |
2007-Oct-28 23:35:17 by drh:
"nulls are distinct" means that every NULL is considered to be different from
every other NULL. Hence, if two rows contain only NULL values, they are
considered UNIQUE because they are not equal to one another. |
|
2745 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
shazow
|
1
|
1
|
Sharing File between two processes
|
edit |
Sharing File between two processes |
|
2744 |
code
|
closed
|
2007 Oct
|
drh
|
|
2007 Nov
|
danielk1977
|
1
|
1
|
Cannot quote collating sequence name
|
edit |
The following statement gives an error:
CREATE TABLE demo(x TEXT COLLATE "binary");
It is using the quote characters as part of the name. The quotes
ought to be removed before searching for the collating sequence. |
|
2743 |
doc
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
Comparison of SQLite against McObject Fusion
|
edit |
Can you please provide a comparison of SQLite against McObhect Fusion. Thanks. |
2007-Oct-24 11:07:16 by drh:
I've never heard of McObject Fusion before. |
|
2742 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
codeInteger and codeReal
|
edit |
In the latest CVS I noticed that codeInteger and codeReal ignores the argument `n'.
static void codeReal(Vdbe *v, const char *z, int n, int negateFlag){
assert( z || v==0 || sqlite3VdbeDb(v)->mallocFailed );
if( z ){
double value;
char *zV;
sqlite3AtoF(z, &value); //***** can this accidentally go beyond n bytes?
if( negateFlag ) value = -value;
zV = dup8bytes(v, (char*)&value);
sqlite3VdbeOp3(v, OP_Real, 0, 0, zV, P3_REAL);
}
}
I was under the impression that both sqlite3AtoF and sqlite3Atoi64 required null terminated strings. Is `z' guaranteed to be null terminated in all cases? Could a random byte follow the number string buffer that happens to be a digit and cause the parsed number to be incorrect?
So at best you could drop the 'n' arg from codeReal and codeInteger, at worst, you'd have to take n bytes into consideration for the sqlite3Ato* functions or less desirable - allocate a buffer and copy the string to it and nil terminate it prior to calling the sqlite3Ato* functions. |
2007-Oct-23 19:23:24 by anonymous:
You forgot to assert z[n] is not '.', 'e', and 'E' for codeReal.
I'm not comfortable with this not-a-valid-number-character assumption, but am too lazy to look for a counter example that might break it.
If you're confident that the z[n] byte always exists and reading that byte in sqlite3Ato* will not segfault or cause valgrind to complain, why not do this instead:
char zn = z[n];
z[n] = 0;
... do sqlite3Ato* stuff
z[n] = zn;
It's fast, guaranteed to be safe and is more resiliant in the face of future possibly incompatible code changes in the parser.
2007-Oct-23 19:26:05 by anonymous:
As you well know, the assert only works in debug mode, not in production. The debug runs pad memory allocations at the end with a byte or two, do they not?
2007-Oct-23 19:52:10 by anonymous:
The saving/restoring z[n] hack above won't work if the original parse string on which the tokens are based is stored in read-only memory or if the original string is being parsed simultaneously in 2 or more threads. But if the original parse string is guaranteed to be copied before parsing begins, then sure, it could work.
2007-Oct-23 21:15:15 by drh:
The code is correct as written. If you think otherwise, show
me a counter-example.
Could the code benefit from be refactored to be cleaner. Probably
so. But that would require hundreds of lines of carefully
optimized code to be redesigned and rewritten. I have more
important fish to fry right now and so I am not going to waste
several days modifying code that works. It is what it is.
Either show me a case where it fails or else learn to
live with it. |
|
2735 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
nmadhav
|
3
|
1
|
Error : Unrecognized Token
|
edit |
Hi,
I am trying to Create a table in the sqlite DB.
The table name is 9I0_STATIC_101607 and I get an error
Unrecognized token : 9I0_STATIC_101607
But if I create a table with name STATIC_9I0_101607, my code works fine.
It is something to do with the table name starting with number.
Is there any kind of restriction with table name starting with a digit??
Thanks for your help.
Regards,
Mayura. |
2007-Oct-17 17:07:43 by drh:
This is not a bug report. This is a support request.
Please see
http://www.sqlite.org/support.html
for information on how to receive support for SQLite.
Please use these ticketing system to report bugs only.
Thanks. |
|
2734 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
3
|
1
|
2 bug under the wince
|
edit |
the test version is 3.5.1 thank you!
1. in os_win.c line:1165
/*
samsting_xie change the last line: zFilename to zName.
the zFilename is not declared, so i change it to zName,
maybe it's write error? the old last line is:
&& !winceCreateLock(zFilename, pFile)
*/
2. in os_win.c line:1341
return SQLITE_OK;
/*
samsting_xie add the last line: return SQLITE_OK;
if OS_WINCE defined 1, then this function is not return value.
it's maybe return a unknown value.
*/
|
Duplicate. See, for example, #2718, #2711, #2710, #2702, #2700, #2683. |
|
2731 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
sqlite3ExprCode TK_UMINUS inefficient with large negative floats
|
edit |
The follow change in expr.c makes my program (which deals with large negative floating point numbers) run 14 times faster.
14 seconds originally to just 1 second after this patch.
Assuming the fix is correct, can you please apply it? make test runs with 0 errors with this.
Thanks.
Index: src/expr.c
===================================================================
RCS file: /sqlite/sqlite/src/expr.c,v
retrieving revision 1.313
diff -u -3 -p -r1.313 expr.c
--- src/expr.c 18 Sep 2007 15:55:07 -0000 1.313
+++ src/expr.c 16 Oct 2007 23:54:17 -0000
@@ -1879,7 +1879,10 @@ void sqlite3ExprCode(Parse *pParse, Expr
assert( pLeft );
if( pLeft->op==TK_FLOAT || pLeft->op==TK_INTEGER ){
Token *p = &pLeft->token;
- char *z = sqlite3MPrintf(pParse->db, "-%.*s", p->n, p->z);
+ char *z = sqlite3_malloc(p->n+2);
+ z[0] = '-';
+ memcpy(z+1, p->z, p->n);
+ z[p->n+1] = 0;
if( pLeft->op==TK_FLOAT ){
sqlite3VdbeOp3(v, OP_Real, 0, 0, z, p->n+1);
}else{
|
2007-Oct-17 01:34:39 by drh:
FWIW, the patch is not correct. It does not work if sqlite3_malloc
fails and returns a NULL pointer. But it isn't too hard to fix.
I'm curious, though, what kind of program you are running where
this makes a 14x speed improvement. One wonders if you couldn't
do 100x faster using sqlite3_bind_double() instead. We could go
through and make patches like this one all over the place, in order
to make this or that special case run a little faster. But that
would make the library footprint larger. The sqlite3MPrintf()
call in this context is there for reasons of space efficiency,
not CPU time. Some years ago, we when through this huge effort
to reduce the footprint of the library by replacing
the expanded string construction code like you are inserting with
instances of sqlite3MPrintf(). I am reluctant to undo that effort
for a single special case that could probably be handled more
efficiently using sqlite3_bind_double().
2007-Oct-17 02:21:17 by anonymous:
I have a script to generate ASCII SQL statements which I use in conjunction with the sqlite3 shell and MySQL to populate huge tables.
I use the multi-insert patch on the mailing list for tables that hold millions of rows of negative numbers, with anywhere from 3 to 20 columns.
http://www.mail-archive.com/sqlite-users%40sqlite.org/msg28337.html
INSERT INTO BIGTABLE VALUES
(-334712687065.09, -334712687065.12, -334712687065.13),
(-334712687065.09, -334712687065.12, -334712687065.13),
... 10 thousand rows ...
(-334712687065.09, -334712687065.12, -334712687065.13),
(-334712687065.09, -334712687065.12, -334712687065.13);
With the mulit-insert patch and the patch in this ticket, it is 25% faster for inserting than using the equivalent INSERT commands within a transaction:
BEGIN
INSERT INTO BIGTABLE VALUES(-334712687065.09, -334712687065.12, -334712687065.13);
... 10 thousand rows ...
INSERT INTO BIGTABLE VALUES(-334712687065.09, -334712687065.12, -334712687065.13);
COMMIT;
I have to have no more than 10,000 rows per insert because it blows the stack due to sqlite3Select -> multiSelect recursion. I had to bump a few other sqliteLimits as well to get more than a few thousand rows at a time.
I suppose the replacement of the sqlite3MPrintf could be useful in other scenarios as well.
2007-Oct-17 02:27:30 by anonymous:
The bind double approach is not 100X faster, by the way. It's only around 1.3X faster than the individual ASCII inserts in my tests. But it doesn't matter for my purposes, because it's not MySQL compatible anyway.
2007-Oct-17 03:04:11 by anonymous:
If the string were not pre-prepended with a '-' char, but instead parsed into a double, and the double simply negated it would be much faster and avoid a needless memory allocation/deallocation. To facilitate this, OP_Real would have to be changed or a new OP code created to accommodate an 8 byte double argument - possibly via straddling P1 and P2.
2007-Oct-23 16:00:39 by anonymous:
Fixed by Check-in [4507]
|
|
2730 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
anonymous
|
3
|
2
|
Can't compile for WindowsCE
|
edit |
There is a compilation bug in os_win.c line 1165 (then compile for WindowsCE)
"sqlite3.5_\os_win.c(1165) : error C2065: 'zFilename' : undeclared identifier"
the code
#if OS_WINCE
if( (flags & (SQLITE_OPEN_READWRITE|SQLITE_OPEN_MAIN_DB)) ==
(SQLITE_OPEN_READWRITE|SQLITE_OPEN_MAIN_DB)
&& !winceCreateLock(zFilename, pFile)
seems to be
#if OS_WINCE
if( (flags & (SQLITE_OPEN_READWRITE|SQLITE_OPEN_MAIN_DB)) ==
(SQLITE_OPEN_READWRITE|SQLITE_OPEN_MAIN_DB)
&& !winceCreateLock(zName, pFile)
Best regards, Yuri Noyanov |
Duplicate of #2648, #2700, #2702, and #2718. |
|
2726 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
4
|
3
|
solaris 10 compilation B_FALSE, B_TRUE clash from sys/types.h
|
edit |
% make
386-pc-solaris2.10-gcc -O3 -pipe -o lemon ./tool/lemon.c
./tool/lemon.c:111: error: redeclaration of enumerator ‘B_FALSE’
/usr/include/sys/types.h:176: error: previous definition of ‘B_FALSE’ was here
./tool/lemon.c:111: error: redeclaration of enumerator ‘B_TRUE’
/usr/include/sys/types.h:176: error: previous definition of ‘B_TRUE’ was here
make: *** [lemon] Error 1
% sed -e 176\!d /usr/include/sys/types.h{linebreak}
typedef enum { B_FALSE, B_TRUE } boolean_t;
% sed -e 111\!d tool/lemon.c
typedef enum {B_FALSE=0, B_TRUE} Boolean;
even when the enum is only set when it is not yet defined, I guess this results in conflicts in the code because Boolean may not equal boolean_t.
I suggest to rename B_FALSE and B_TRUE to something which makes it unique for the sqlite case. |
Duplicate of #2583 |
|
2724 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Dec
|
drh
|
2
|
2
|
Load Ext api missing error_toobig function.
|
edit |
Function call for sqlite3_error_toobig is not in the sqlite3Ext.h
void (result_error_toobig)(sqlite3_context);
#define sqlite3_result_error_toobig sqlite3_api->result_error_toobig
Without these, externally loadded libs that would like to use
error_toobig will not load into sqlite |
2007-Dec-13 18:51:28 by drh:
See ticket #2610. |
|
2723 |
new
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
anonymous
|
5
|
4
|
After execution of SQL, the Data Returned should display the col.name
|
edit |
Hi!
After executing a SQL command, the program shows the results as a table with columns. The first row ist allways grey but empty.
Couldn't the program display the selected entities (or their declared AS-alias) as column headers in the result table?
Yours sincerely
M. Heinrich, München |
2007-Oct-12 18:19:38 by drh:
Do you mean in the CLI? Just type
.header on
And the headers will appear. |
|
2720 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
WinCE - Can't write
|
edit |
Application which was working correctly with one of the last sqlite 3.3.16 fails on 3.5.1 to write anything to the database - no create tables and no inserts if the db existed beforehand. It seems to happen always, with either UTF-8 or UTF-16 encoding. |
2007-Oct-11 07:26:49 by anonymous:
I meant, "...one of the last 3.3.x (I think 3.3.16)..."
2007-Oct-11 12:20:13 by drh:
The developers have no ability to compile or run on winCE, much
less any ability to debug on winCE. All winCE support is community
provided.
There have been many patches to the winCE code since 3.5.1 was
released. The writer of this ticket previously reported two
other problems that have already been fixed. Several other
problems have also been fixed since 3.5.1. We are guessing
that this "Can't write" problem will probably go away if the
writer will simply get the latest code out of CVS. If not,
then there is nothing really we can do about it unless we have
patches to fix the problem. |
|
2719 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
3
|
1
|
WinCE winFullPathName doesn't return a value
|
edit |
#if OS_WINCE
/* WinCE has no concept of a relative pathname, or so I am told. */
sqlite3_snprintf(pVfs->mxPathname, zFull, "%s", zRelative);<br>
#endif |
Duplicate of #2702 |
|
2718 |
build
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
2
|
1
|
WinCE compile error
|
edit |
On function winOpen
#if OS_WINCE
if( (flags & (SQLITE_OPEN_READWRITE|SQLITE_OPEN_MAIN_DB)) ==
(SQLITE_OPEN_READWRITE|SQLITE_OPEN_MAIN_DB)
&& !winceCreateLock(zFilename, pFile)
){
CloseHandle(h);
free(zConverted);
return SQLITE_CANTOPEN;
}
if( dwFlagsAndAttributes & FILE_FLAG_DELETE_ON_CLOSE ){
pFile->zDeleteOnClose = zConverted;
}else
#endif
That zFilename of the winceCreateLock call doesn't exist. I guess it should be zName instead |
Duplicate of #2700 |
|
2717 |
doc
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Dec
|
anonymous
|
5
|
5
|
Document clarification around SQLITE_OMIT_MEMORY_ALLOCATION
|
edit |
In the " Moving From SQLite 3.4.2 to 3.5.0" document, section 3.0 it states that "These routines are provided for use by the application. SQLite never invokes them itself. So if the application is providing its own memory allocation subsystem, it can omit these interfaces if desired."
This doesn't seem to be correct unless SQLITE_OMIT_LOAD_EXTENSION is defined. If this value is not defined, then the function pointers are assigned in a structure (sqlite3_apis). As stated, they are not used by SQLite proper, but must be defined. In this case, I am unable to link without either defining the functions or building with SQLITE_OMIT_LOAD_EXTENSION defined. |
2007-Oct-11 19:45:36 by anonymous:
It appears that the sqlite3_memory_used() function is required in sqlite3_soft_heap_limit() so my previous comments were not entirely correct. I'm still having a link problem even with the define.
2007-Dec-13 18:48:21 by drh:
SQLITE_OMIT_MEMORY_ALLOCATION is no longer supported. |
|
2712 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
5
|
4
|
Expose a function to change the journal filename location
|
edit |
Being able to change the pager journal filename using a nice function ie: sqlite3PagerSetJournal
it maybe the following prototype:
int sqlite3PagerSetJournal(sqlite3* db, const char *zJournal);
It is intended to maximize disk IOs by splitting IO concerning the journal and the IO concerning the main DB storage.
Typically we dedicate a specific disk channel for the journal, which may be a RAM disk like iRAM from Gigabyte, or a SATA2 disk with 16MB cache dedicated, or using a RAID controller with 256MB RAM with Backup Unit.
The main DB storage resides on a different channel on SAS disks configured as RAID10.
Separating journal and main data file is typically a feature available in common SQL servers : MySQL, MSSQL, ... |
2007-Oct-09 15:38:50 by drh:
Changing the name of the rollback journal and especially moving
it to a different volume can lead to database corruption following
a power failure. See http://www.sqlite.org/ac/atomiccommit.html
for additional information. |
|
2709 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
2
|
3
|
Some SQLITE_OMIT_* keys break the sqlite3.c amalgamation compilation
|
edit |
I found that SQLITE_OMIT_TRIGGER, SQLITE_OMIT_REINDEX and SQLITE_OMIT_ALTERTABLE keys break the compilation, when defined.
Following patch solved this problem for me.
sqlite-amalgamation-3_5_1.define.patch
--- ./sqlite3.c.orig Wed Oct 3 18:08:44 2007
+++ ./sqlite3.c Tue Oct 9 14:52:09 2007
@@ -53246,6 +53266,7 @@
/* Run the BEFORE and INSTEAD OF triggers, if there are any
*/
endOfLoop = sqlite3VdbeMakeLabel(v);
+#ifndef SQLITE_OMIT_TRIGGER
if( triggers_exist & TRIGGER_BEFORE ){
/* build the NEW.* reference row. Note that if there is an INTEGER
@@ -53309,6 +53330,7 @@
goto insert_cleanup;
}
}
+#endif
/* If any triggers exists, the opening of tables and indices is deferred
** until now.
@@ -62064,6 +62086,7 @@
sqlite3VdbeAddOp(v, OP_MemInt, 0, memCnt);
}
+#ifndef SQLITE_OMIT_TRIGGER
if( triggers_exist ){
/* Create pseudo-tables for NEW and OLD
*/
@@ -62129,6 +62152,7 @@
goto update_cleanup;
}
}
+#endif
if( !isView && !IsVirtual(pTab) ){
/*
@@ -67517,10 +67541,12 @@
case 214:
{sqlite3IdListDelete((yypminor->yy432));}
break;
+#ifndef SQLITE_OMIT_TRIGGER
case 231:
case 236:
{sqlite3DeleteTriggerStep((yypminor->yy243));}
break;
+#endif
case 233:
{sqlite3IdListDelete((yypminor->yy370).b);}
break;
@@ -68378,11 +68404,13 @@
sqlite3DropTable(pParse, yymsp[0].minor.yy373, 0, yymsp[-1].minor.yy46);
}
break;
+#ifndef SQLITE_OMIT_VIEW
case 102:
{
sqlite3CreateView(pParse, &yymsp[-7].minor.yy0, &yymsp[-3].minor.yy410, &yymsp[-2].minor.yy410, yymsp[0].minor.yy219, yymsp[-6].minor.yy46, yymsp[-4].minor.yy46);
}
break;
+#endif
case 103:
{
sqlite3DropTable(pParse, yymsp[0].minor.yy373, 1, yymsp[-1].minor.yy46);
@@ -68921,6 +68949,7 @@
case 250:
{sqlite3Pragma(pParse,&yymsp[-1].minor.yy410,&yymsp[0].minor.yy410,0,0);}
break;
+#ifndef SQLITE_OMIT_TRIGGER
case 258:
{
Token all;
@@ -68935,6 +68964,7 @@
yygotominor.yy410 = (yymsp[-6].minor.yy410.n==0?yymsp[-7].minor.yy410:yymsp[-6].minor.yy410);
}
break;
+#endif
case 260:
case 263:
{ yygotominor.yy46 = TK_BEFORE; }
@@ -68972,6 +69002,7 @@
case 272:
{ yygotominor.yy243 = 0; }
break;
+#ifndef SQLITE_OMIT_TRIGGER
case 273:
{ yygotominor.yy243 = sqlite3TriggerUpdateStep(pParse->db, &yymsp[-3].minor.yy410, yymsp[-1].minor.yy174, yymsp[0].minor.yy172, yymsp[-4].minor.yy46); }
break;
@@ -68987,6 +69018,7 @@
case 277:
{yygotominor.yy243 = sqlite3TriggerSelectStep(pParse->db, yymsp[0].minor.yy219); }
break;
+#endif
case 278:
{
yygotominor.yy172 = sqlite3PExpr(pParse, TK_RAISE, 0, 0, 0);
@@ -69011,11 +69043,13 @@
case 282:
{yygotominor.yy46 = OE_Fail;}
break;
+#ifndef SQLITE_OMIT_TRIGGER
case 283:
{
sqlite3DropTrigger(pParse,yymsp[0].minor.yy373,yymsp[-1].minor.yy46);
}
break;
+#endif
case 284:
{
sqlite3Attach(pParse, yymsp[-3].minor.yy172, yymsp[-1].minor.yy172, yymsp[0].minor.yy386);
@@ -69032,19 +69066,22 @@
case 287:
{ yygotominor.yy386 = yymsp[0].minor.yy172; }
break;
+#ifndef SQLITE_OMIT_REINDEX
case 290:
{sqlite3Reindex(pParse, 0, 0);}
break;
case 291:
{sqlite3Reindex(pParse, &yymsp[-1].minor.yy410, &yymsp[0].minor.yy410);}
break;
+#endif
case 292:
{sqlite3Analyze(pParse, 0, 0);}
break;
case 293:
{sqlite3Analyze(pParse, &yymsp[-1].minor.yy410, &yymsp[0].minor.yy410);}
break;
- case 294:
+#ifndef SQLITE_OMIT_ALTERTABLE
+ case 294:
{
sqlite3AlterRenameTable(pParse,yymsp[-3].minor.yy373,&yymsp[0].minor.yy410);
}
@@ -69059,6 +69096,7 @@
sqlite3AlterBeginAddColumn(pParse, yymsp[0].minor.yy373);
}
break;
+#endif
case 299:
{sqlite3VtabFinishParse(pParse,0);}
break;
Thank you! |
2007-Oct-09 13:22:03 by anonymous:
This is because parse.c has to be regenerated from parse.y. Then, with an altered Makefile with the appropriate options, you have to run "make clean && make sqlite3.c".
Could Lemon be altered to emit the %if/%ifndef/%else/%endif's as their C preprocessor equivalents instead of just not generating the if'd out parse code? This way the amalgamation could work with all OMITs.
2007-Oct-09 15:13:49 by drh:
Changing Lemon to generate "universal" code that works with any
combination of OMIT macros is not practical. Any change to
the grammer rules typically results in massiver reorganization
of the parser tables.
If you want to use OMIT macros, then you need to compile from
the canonical source code - not the amalgamation.
2007-Oct-10 15:30:31 by anonymous:
I had a issue like that in previous sqlite 3.1x versions, which I want to omit alter table statement but need to generate a parser from lemon, but makefile did not supported it. there´s a way to configure --d(omit something) to omit some features of sqlite ? I know there are few on it, but not all are supported on sqlite configure script |
|
2707 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
appledev
|
1
|
3
|
SQLite on Mac OS X seems to have a 4GB database limit
|
edit |
This is on Mac OX 10.4 using Apple's Core Data:
I run into a strange error, always when I try to save a managed- object-context and the file-size is already at the 4GB limit:
An error saving the context: NSError "An error occurred while saving." Domain=NSCocoaError Domain Code=134030 UserInfo={NSUnderlyingException = disk I/O error; } |
2007-Oct-09 05:12:47 by anonymous:
Why do you think it is SQLite error ??
2007-Oct-09 06:52:50 by danielk1977:
What kind of file system are you using for the database?
I used the attached script to create a 5.5 GB database on HFS+, then checked it using the integrity check and everything seemed Ok.
If it's not a simple file-system limitation, is is possible for you to post some code that demonstrates the issue? Thanks.
2007-Oct-12 18:46:31 by drh:
Unable to reproduce. Submitter does not respond. |
|
2706 |
warn
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
danielk1977
|
4
|
4
|
make test aborts when built with SQLITE_OMIT_ATTACH
|
edit |
testfixture aborts during make test when it is compiled with -DSQLITE_OMIT_ATTACH=1
attach-4.5...
Error: no such table: db2.t3
./testfixture: near "DETACH": syntax error
while executing
"db eval {
DETACH db2;
}"
("uplevel" body line 1)
invoked from within
"uplevel [list $db eval $sql]"
(procedure "execsql" line 3)
invoked from within
"execsql {
DETACH db2;
}"
(file "./test/attach.test" line 505)
invoked from within
"source $testfile"
("foreach" body line 5)
invoked from within
"foreach testfile [lsort -dictionary [glob $testdir/*.test]] {
set tail [file tail $testfile]
if {[lsearch -exact $EXCLUDE $tail]>=0} continue
if..."
(file "./test/quick.test" line 93)
make: *** [test] Error 1
|
|
2695 |
new
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
drh
|
3
|
3
|
sqlite3 CLI unresolved externals with SQLITE_OMIT_GET_TABLE
|
edit |
sqlite3_free_table and sqlite3_get_table are unresolved if sqlite3 is compiled with -DSQLITE_OMIT_GET_TABLE=1
Required fix below.
Index: src/shell.c
===================================================================
RCS file: /sqlite/sqlite/src/shell.c,v
retrieving revision 1.167
diff -u -3 -p -r1.167 shell.c
--- src/shell.c 7 Sep 2007 01:12:32 -0000 1.167
+++ src/shell.c 5 Oct 2007 06:19:58 -0000
@@ -1458,6 +1458,7 @@ static int do_meta_command(char *zLine,
fprintf(p->out,"\n");
}else
+#ifndef SQLITE_OMIT_GET_TABLE
if( c=='t' && n>1 && strncmp(azArg[0], "tables", n)==0 ){
char **azResult;
int nRow, rc;
@@ -1514,6 +1515,7 @@ static int do_meta_command(char *zLine,
}
sqlite3_free_table(azResult);
}else
+#endif
if( c=='t' && n>1 && strncmp(azArg[0], "timeout", n)==0 && nArg>=2 ){
open_db(p);
|
2007-Oct-05 14:34:39 by drh:
I would imagine that there are many SQLITE_OMIT_... macros that
will break the CLI. The CLI is a separate program which is
distinct from the SQLite library and is not expected to work
with every possible configuration of the SQLite library.
So this really should be a feature request and not a bug report.
My dilemma now is whether to accept or reject this feature request.
The changes are relatively minor. But on the other hand, the
requested feature is very obscure. Why is it that you want to
have a CLI that omits the sqlite3_get_table() API? As I sit here
pondering, I cannot think of a single reason why anybody would want
to do such a thing, and so for that reason I am rejecting this
feature request. If somebody (the original poster or anybody else)
can give me a legitimate reason for wanting to build the CLI without
the sqlite3_get_table() interface, I will reconsider the rejection.
2007-Oct-05 15:49:01 by anonymous:
Why? To test all the OMIT macros on a representative program already in the source tree. I found other OMIT compile problems outside of shell.c when performing this exercise. I'll file a seperate ticket SQLITE_OMIT_FLOATING_POINT.
No one is saying anyone would #define this particular OMIT. It is just there for completeness. It gives programmers confidence in using the sqlite library without investing too much time in it. For that matter, it would be nice to test an OMIT-filled sqlite3 library against the exactly same configured corresponding sqlite3 shell.
Also, you define it if you
wanted to build a minimalistic shell for a severely memory-constrained embedded device. Truth be told, the .table command is a nice but rarely used
command whose info can be gleaned with a simple query on sqlite_master
anyway.
2007-Oct-05 16:08:23 by anonymous:
By the way, only a couple of other OMITs broke shell.c:
SQLITE_OMIT_COMPLETE
SQLITE_OMIT_DISKIO
You did a better job than you realized. ;-)
2007-Oct-05 16:26:04 by anonymous:
Was able to successfully compile/link/run shell.c with:
THREADSAFE=0
SQLITE_OMIT_ALTERTABLE
SQLITE_OMIT_ANALYZE
SQLITE_OMIT_ATTACH
SQLITE_OMIT_AUTHORIZATION
SQLITE_OMIT_AUTOINCREMENT
SQLITE_OMIT_AUTOVACUUM
SQLITE_OMIT_BETWEEN_OPTIMIZATION
SQLITE_OMIT_BLOB_LITERAL
SQLITE_OMIT_CAST
SQLITE_OMIT_CHECK
SQLITE_OMIT_COMPOUND_SELECT
SQLITE_OMIT_CONFLICT_CLAUSE
SQLITE_OMIT_DATETIME_FUNCS
SQLITE_OMIT_EXPLAIN
SQLITE_OMIT_FLAG_PRAGMAS
SQLITE_OMIT_FLOATING_POINT (see Ticket #2696)
SQLITE_OMIT_FOREIGN_KEY
SQLITE_OMIT_GET_TABLE (with above patch)
SQLITE_OMIT_GLOBALRECOVER
SQLITE_OMIT_INCRBLOB
SQLITE_OMIT_INTEGRITY_CHECK
SQLITE_OMIT_LIKE_OPTIMIZATION
SQLITE_OMIT_LOAD_EXTENSION
SQLITE_OMIT_MEMORYDB
SQLITE_OMIT_OR_OPTIMIZATION
SQLITE_OMIT_PAGER_PRAGMAS
SQLITE_OMIT_PROGRESS_CALLBACK
SQLITE_OMIT_QUICKBALANCE
SQLITE_OMIT_REINDEX
SQLITE_OMIT_SCHEMA_PRAGMAS
SQLITE_OMIT_SCHEMA_VERSION_PRAGMAS
SQLITE_OMIT_SHARED_CACHE
SQLITE_OMIT_SUBQUERY
SQLITE_OMIT_TCL_VARIABLE
SQLITE_OMIT_TEMPDB
SQLITE_OMIT_TRACE
SQLITE_OMIT_TRIGGER
SQLITE_OMIT_UTF16
SQLITE_OMIT_VACUUM
SQLITE_OMIT_VIEW
SQLITE_OMIT_VIRTUALTABLE
SQLITE_OMIT_XFER_OPT
2007-Oct-05 16:28:11 by drh:
If you are building a minimalist shell, you should start from
scratch and not try to use shell.c. There is a lot of cruft
in shell.c (above and beyond ".table") that a minimalist shell
does not want. So this is not a valid reason for wanting
shell.c to support SQLITE_OMIT_GET_TABLE.
Likewise, there a lot of ways to test to make sure SQLite
work with SQLITE_OMIT_GET_TABLE without compiling shell.c.
I remain unconvinced. Feature request still rejected.
2007-Oct-05 16:33:33 by anonymous:
Wow, you won't check in an trivially obvious perfectly harmless 2 line patch despite a half dozen reasons why it's useful.
A lot of people use shell.c for testing and in production - probably more people use the CLI than do the Tcl API. |
|
2692 |
build
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
COmpilation of Sqlite amalgamation v3.4.2. failed
|
edit |
Version 3.4.2 (amalgamation) could not be compiled under MS DevStudio 6
the compilation errors are:
sqlite3.c(6187) : error C2133: 'sqlite3UpperToLower' : unknown size
sqlite3.c(9310) : error C2133: 'sqlite3OpcodeNames' : unknown size
sqlite3.c(47159) : error C2133: 'sqlite3IsIdChar' : unknown size |
2007-Oct-04 18:19:44 by drh:
Duplicate of #2574. |
|
2691 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
SQLITE_OMIT_AUTHORIZATION compilation error
|
edit |
sqlite3.Int.h does not compile with SQLITE_OMIT_AUTHORIZATION.
Rationale: sqlite3Int.h, line 1768:
# define sqlite3AuthRead(a,b,c)
is missing a 4th parameter like this:
# define sqlite3AuthRead(a,b,c,d)
|
thanks. |
|
2690 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
3
|
4
|
"PRAGMA synchronous = OFF;" is more dangerous than documented
|
edit |
The "PRAGMA synchronous = OFF;" is much more dangerous than implied in the documentation (at http://www.sqlite.org/pragma.html).
On our embedded system written data may remain in a middleware buffer (without being passed to the OS) until a subsequent read, write, seek or close call occurs.
In particular, the last write to the database file may remain buffered semi-locally for quite a while after the lock is released. This will inevitably cause problems if the database is read through a different handle meanwhile - even by the same thread!
I have seen this occur (fairly regularly), when a subsequent SELECT returns SQLITE_CORRUPT.
Four pages are read through another handle before the error is raised.
The write didn't complete until the file was closed as part of the application shutdown more than 10 seconds later.
It might reasonably be argued that our middleware is broken in this case, but I'm sure that there are other systems with similar problems.
The problem is still present in version 3.4.1 where the sqlite3OsSync call at pager.c:3954 should not be conditional on !pPager->noSync.
Another solution may be to change the documentation to highlight this risk. |
2007-Oct-04 14:26:18 by drh:
From the description, this seems definitely to be a bug in your
alternative OS interface, not in the delivered SQLite code.
Perhaps you should modify your middleware so that it flushes
pending writes prior to unlocking. |
|
2689 |
build
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
3
|
4
|
make test fails in 3.5.1 - unresolved externals in testfixture
|
edit |
tar zxvf sqlite......
cd sqlite-3.5.1
mkdir bld
cd bld
../configure
make
make test
./libtool --mode=link gcc -g -O2 -I. -I../src -DNDEBUG -I/System/Library/Frameworks/Tcl.framework/Versions/8.4/Headers -DSQLITE_THREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DTCLSH=1 -DSQLITE_TEST=1 -DSQLITE_CRASH_TEST=1 \
-DSQLITE_NO_SYNC=1 -DTEMP_STORE=1 \
-o testfixture ../src/attach.c ../src/btree.c ../src/build.c ../src/date.c ../src/expr.c ../src/func.c ../src/insert.c ../src/malloc.c ../src/os.c ../src/os_os2.c ../src/os_unix.c ../src/os_win.c ../src/pager.c ../src/pragma.c ../src/prepare.c ../src/printf.c ../src/select.c ../src/test1.c ../src/test2.c ../src/test3.c ../src/test4.c ../src/test5.c ../src/test6.c ../src/test7.c ../src/test8.c ../src/test9.c ../src/test_autoext.c ../src/test_async.c ../src/test_btree.c ../src/test_config.c ../src/test_hexio.c ../src/test_malloc.c ../src/test_md5.c ../src/test_schema.c ../src/test_server.c ../src/test_tclvar.c ../src/tokenize.c ../src/utf.c ../src/util.c ../src/vdbe.c ../src/vdbeapi.c ../src/vdbeaux.c ../src/vdbemem.c ../src/where.c parse.c ../src/tclsqlite.c \
libsqlite3.la -framework Tcl -lpthread -framework CoreFoundation
gcc -g -O2 -I. -I../src -DNDEBUG -I/System/Library/Frameworks/Tcl.framework/Versions/8.4/Headers -DSQLITE_THREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DTCLSH=1 -DSQLITE_TEST=1 -DSQLITE_CRASH_TEST=1 -DSQLITE_NO_SYNC=1 -DTEMP_STORE=1 -o .libs/testfixture ../src/attach.c ../src/btree.c ../src/build.c ../src/date.c ../src/expr.c ../src/func.c ../src/insert.c ../src/malloc.c ../src/os.c ../src/os_os2.c ../src/os_unix.c ../src/os_win.c ../src/pager.c ../src/pragma.c ../src/prepare.c ../src/printf.c ../src/select.c ../src/test1.c ../src/test2.c ../src/test3.c ../src/test4.c ../src/test5.c ../src/test6.c ../src/test7.c ../src/test8.c ../src/test9.c ../src/test_autoext.c ../src/test_async.c ../src/test_btree.c ../src/test_config.c ../src/test_hexio.c ../src/test_malloc.c ../src/test_md5.c ../src/test_schema.c ../src/test_server.c ../src/test_tclvar.c ../src/tokenize.c ../src/utf.c ../src/util.c ../src/vdbe.c ../src/vdbeapi.c ../src/vdbeaux.c ../src/vdbemem.c ../src/where.c parse.c ../src/tclsqlite.c -framework Tcl -framework CoreFoundation ./.libs/libsqlite3.dylib -lpthread
/usr/bin/ld: Undefined symbols:
_Sqlitetest7_Init
_SqlitetestOnefile_Init
_SqlitetestThread_Init
collect2: ld returned 1 exit status
make: *** [testfixture] Error 1 |
2007-Oct-04 11:21:47 by anonymous:
This is mac os x
2007-Oct-04 15:40:13 by anonymous:
Same unresolved externals for testfixture on Linux.
Fix below. Do a "make distclean" and re-run configure/make test.
Index: Makefile.in
===================================================================
RCS file: /sqlite/sqlite/Makefile.in,v
retrieving revision 1.183
diff -u -3 -p -r1.183 Makefile.in
--- Makefile.in 3 Sep 2007 22:15:45 -0000 1.183
+++ Makefile.in 4 Oct 2007 15:37:57 -0000
@@ -212,6 +212,8 @@ SRC += \
# Source code to the test files.
#
TESTSRC = \
+ $(TOP)/src/test_onefile.c \
+ $(TOP)/src/test_thread.c \
$(TOP)/src/attach.c \
$(TOP)/src/btree.c \
$(TOP)/src/build.c \
Index: src/test7.c
===================================================================
RCS file: /sqlite/sqlite/src/test7.c,v
retrieving revision 1.9
diff -u -3 -p -r1.9 test7.c
--- src/test7.c 12 Sep 2007 17:01:45 -0000 1.9
+++ src/test7.c 4 Oct 2007 15:37:57 -0000
@@ -21,8 +21,8 @@
** This test only works on UNIX with a SQLITE_THREADSAFE build that includes
** the SQLITE_SERVER option.
*/
-#if defined(SQLITE_SERVER) && !defined(SQLITE_OMIT_SHARED_CACHE)
-#if defined(OS_UNIX) && OS_UNIX && SQLITE_THREADSAFE
+#if defined(SQLITE_SERVER) && !defined(SQLITE_OMIT_SHARED_CACHE) && \
+ defined(OS_UNIX) && OS_UNIX && SQLITE_THREADSAFE
#include <stdlib.h>
#include <string.h>
@@ -720,5 +720,4 @@ int Sqlitetest7_Init(Tcl_Interp *interp)
}
#else
int Sqlitetest7_Init(Tcl_Interp *interp){ return TCL_OK; }
-#endif /* OS_UNIX */
#endif
2007-Oct-04 15:43:15 by anonymous:
Output of make test after patch:
0 errors out of 31801 tests
All memory allocations freed - no leaks
Maximum memory usage: 14160983 bytes
2007-Oct-04 19:09:05 by anonymous:
I am the original reporter - that fix worked for me, thanks.
My results (OS X)
0 errors out of 31207 tests
All memory allocations freed - no leaks
Maximum memory usage: 14161431 bytes
|
|
2688 |
build
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
3
|
1
|
SQLITE_OMIT_AUTHORIZATION build failure
|
edit |
Version 3.5.1 does not compile when specifying -DSQLITE_OMIT_AUTHORIZATION.
The problem lies on line 6872 (of the amalgamation):
# define sqlite3AuthRead(a,b,c)
should be:
# define sqlite3AuthRead(a,b,c,d)
|
thanks. |
|
2682 |
code
|
closed
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
SQLite Text Problem
|
edit |
I am using SQLite 3 as backend database in my asp application. I am using SQLite3 ODBC driver (latest version).
Table Design
CREATE TABLE log
( id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
from_value TEXT NULL,
to_value TEXT NULL
);
INSERT 10 RECORDS IN TO DATABASE
Const adOpenStatic = 3
Const adLockOptimistic = 3
Dim SQLString ,objConnection
Dim fromVal,toval
Set objConnection = CreateObject("ADODB.Connection") for a = 1 to 10
objConnection.Open "DSN=Test;uid=;pwd=;"
fromVal = "FROM Value : "& a
toVal = "To Value : "& a
SQLString = "INSERT INTO log(from_value, to_value) VALUES ('"& fromVal & "' ,'"&toVal& "')"
objConnection.Execute SQLString
objConnection.Close
next
Access records in the log table
Dim LogRs,SQLStmt
SQLStmt = "SELECT * FROM log "
LogRs.ActiveConnection = "DSN=Test;uid=;pwd=;"
LogRs.Source= SQLStmt
LogRs.CursorType = 3'ADOPENSTATIC
LogRs.CursorLocation = 2 'ADUSESERVER
LogRs.LockType = 3 'ADLOCKOPTIMISTIC
LogRs.Open()
RecordCount = LogRs.RecordCount
If I use datatype of from_value/to_value as TEXT ,I get RecordCount as zero which is wrong.
If I use datatype of from_value/to_value as Varchar(1600) ,I get RecordCount as 10 which is correct.
If I use datatype of from_value/to_value as Varchar(1600) and tried to put more than 1600 charcters in it ,SQLite stores data in DB. While retrieving the data I get the error Arguments are of the wrong type,are out of acceptable range,or are in conflict with one another.
I enabled ODBC trace log ,but its empty after running my application.So I am not sure where it is ODBC problem or SQLite ODBC driver error?
If I open table (database) in SQLite Studio I could see data without any error.
If I use MS Access with same table design and same code, I dont get any error . The code works fine as expected . |
2007-Oct-01 22:04:18 by drh:
There are multiple ODBC drivers for SQLite, none of which are
support by this site.
Your problem appears to be in the ODBC driver.
If you find evidence to the contrary, please reopen this
ticket. |
|
2679 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Oct
|
|
2
|
3
|
locking errors lead to disk i/o failure with bulk operations on winxp
|
edit |
First got lost cursor and disk i/o errors with bulk imports to sqlite database using sqliteodbc driver with OpenOffice under win xp sp 2. Then used sqlite3.exe to reproduce and found:
if sqlite database is on an ext2 volume accessed through ext2ifs driver, and I .read a sql command file with 348 times INSERT INTO ... VALUES('...','...'); to a table with two text columns, after some (hundred or more) rows without error I receive the following error:
SQL error near line xxx: disk I/O error for all following lines; likewise, when I replace the INSERT by DELETE FROM ... WHERE col='...', I will receive the same error after some ten lines. The database cannot be accessed any more as long as the sqlite3 executable is running; closing and restarting it restores access (same with odbc driver - no access unless connection closed and reopened). I can omit these errors by surrounding the statements with a BEGIN TRANSACTION / COMMIT clause (not available with OOo and the odbc driver, unfortunately). Likewise, when the sqlite database is on a ntfs volume, the error is gone.
I first thought there might be an error with the ext2 ifs driver, but I use it heavily for all kinds of data without problems so far. Then I took a closer look at the sqlite3 executable by monitoring its activity using sysinternals' procmon. And this revealed that there were no failing reads or writes as the error message would suggest, but I noticed RANGE NOT LOCKED results with UnlockFileSingle operations (corresponding to UnlockFileEx calls in the source) when the error surfaces. Examing the sequence of LockFile and UnlockFileSingle on locations 1gb (1), 1gb+1 (1) and 1gb+2 (510) I found that sqlite3 indeed tried to unlock locations already unlocked previously - the reported errors (and the file locking implementation in the ext2 driver) were correct. It seems that sqlite looses track with its locks after multiple lock/unlock sequences.
I append the procmon log of locking activities of the sqlite3 executable during 'mass' inserts in csv format. |
2007-Sep-28 23:22:07 by anonymous:
Could you clarify a few things?
How many SQLite processes are there in your scenario?
What is the actual schema and SQL statements issued by each process?
2007-Sep-29 18:25:50 by anonymous:
could be a ext2fs ifs driver issue. did you tested id in NTFS / FAT32 filesystems ?
2007-Sep-29 23:32:09 by anonymous:
ok, first to clarify:
there is a single sqlite3 process, absolutly no concurrency; and a simple table used, like
CREATE TABLE "WhoIsWho" ("Nummer" varchar(50) NOT NULL, "Teilnehmer" varchar(50), PRIMARY KEY ("Nummer"));
then I feed a text file with 348 statements like
INSERT INTO WhoIsWho VALUES('01805312111','conrad electronic hotline');
with different values to a sqlite3-executable, either by issuing a .read statement at the sqlite3 prompt or using input redirection on the commandline. likewise, with full table to delete the entries I use a file with statements like
DELETE FROM WhoIsWho WHERE Nummer=='01805220111';
this should make the setup clear - but what do you mean with schema?
and about ext2ifs issue and testing on ntfs: see above ;-) and read on
but now: I digged a lot deeper in this issue:
first of all, there is a big difference in the sequence of operations as seen by procmon between ext2 and ntfs. on ntfs, there are 2 (!) "CloseFile C:\" between all other operations, and a lot of additional "CloseFile <current dir>"; this way each INSERT operation takes much longer, 142 +/- 23 ms on ntfs vs. 43 +/- 12 ms on ext2 on my system.
every INSERT line is handled similar: first a check for a left over journal file, then writes to the journal, then writes to the database, then mark the journal for deletion and close it
on the first failing INSERT the check for a left over journal finds it still there - although marked for deletion. the first time this happens the time between the last Close and the new CreateFile is very short, 4 ms in my case, so the journal is not yet deleted. now sqlite issues 2 identical successive QueryStandardInformationFile calls on the journal file, the result is
AllocationSize: 49'152, EndOfFile: 6'184, NumberOfLinks: 1, DeletePending: True, Directory: False
ignoring the DeletePending: True result sqlite takes it for a valid journal file and does a rollback assuming the last operation had failed - this I consider a bug: a file marked for deletion has to be looked at as not valid any more.
after rollback it marks the file again for deletion, and then creates it new with OverwriteIf flag set without checking if deletion actually occured in this case. then it restarts the current INSERT again, this time succeeding - but the next INSERT cycle will rollback this line also. prior to restarting file locks are released, but this time sqlite has lost record of which locks have been set: it releases 2 locks that are not locked, resulting in the errors reported above. this I consider the second bug. Besides, I feel the locking during rollback is not what it should be: it is done with locks at 1gb and at 1gb+1 released, and the lock on 1gb+2 is released and set to exclusive state without any of the 1gb and 1gb+1 locks protecting it. I think there is a UnlockFileSingle to 1gb+1 where a LockFile at 1gb should have been.
why it works with ntfs and not with ext2: i think this is a question of timing and those massive "CloseFile C:\" inserted in case of ntfs. they appear like a q&d workaround for similar issues on ntfs.
2007-Sep-30 00:13:23 by anonymous:
Interesting. You seem to have uncovered a race condition in the Windows version of SQLite.
Just for the heck of it, what happens if you change the os_win.c code to Sleep(1000) after every single CloseFile() call?
2007-Sep-30 00:22:31 by anonymous:
Also, can you increase MX_DELETION_ATTEMPTS from 3 to 30, and Sleep(100) to Sleep(1000) and see what happens?
#define MX_DELETION_ATTEMPTS 3
static int winDelete(
sqlite3_vfs *pVfs, /* Not used on win32 */
const char *zFilename, /* Name of file to delete */
int syncDir /* Not used on win32 */
){
int cnt = 0;
int rc;
void *zConverted = convertUtf8Filename(zFilename);
if( zConverted==0 ){
return SQLITE_NOMEM;
}
SimulateIOError(return SQLITE_IOERR_DELETE);
if( isNT() ){
do{
rc = DeleteFileW(zConverted);
}while( rc==0 && GetFileAttributesW(zConverted)!=0xffffffff
&& cnt++ < MX_DELETION_ATTEMPTS && (Sleep(100), 1) );
}else{
#if OS_WINCE
return SQLITE_NOMEM;
#else
do{
rc = DeleteFileA(zConverted);
}while( rc==0 && GetFileAttributesA(zConverted)!=0xffffffff
&& cnt++ < MX_DELETION_ATTEMPTS && (Sleep(100), 1) );
#endif
}
free(zConverted);
OSTRACE2("DELETE \"%s\"\n", zFilename);
return rc!=0 ? SQLITE_OK : SQLITE_IOERR;
}
2007-Sep-30 12:35:32 by anonymous:
Hmm, I think your suggestions point to the wrong place. If there were multiple attempts to delete the file, I would have seen them in the ProcMon log. But this is not the case. The DeleteFileW succeeds immediately (rc!=0), so the rest of the while clause is never executed. But, as the documentation says, a successful DeleteFile call does not mean the file is deleted, it only means the file has been marked for deletion, and the OS is free to schedule the actual deletion anytime after the CloseFile call.
We should look at the code that checks for a left over journal file. This code already reads the file attributes, so it should be easy to check for the DeletePending flag: if it is set it should treat the journal file as if it were already deleted.
Nevertheless, there is a fault in the fs driver or the OS: the MS documentation says that a CreateFile call on a file marked for deletion fails with ERROR_ACCESS_DENIED - but in this case it succeeds!
The second error - loosing track of locks during rollback - still has to be addressed.
2007-Sep-30 15:59:26 by anonymous:
What happens when you insert the Sleep calls after CloseFile?
2007-Oct-01 12:47:25 by anonymous:
If I would place a Sleep(1000) after every CloseFile (I didn't) then the errror would shurely vanish - and my 348 inserts would last 6 minutes! That's not the way to go. I suggested to look for the code to check for the journal file still there, but I see this has already been accounted for in the code to exclusively open a file on windows, here:
/*
...
** Sometimes if we have just deleted a prior journal file, windows
** will fail to open a new one because there is a "pending delete".
** To work around this bug, we pause for 100 milliseconds and attempt
** a second open after the first one fails. The whole operation only
** fails if both open attempts are unsuccessful.
*/
int sqlite3WinOpenExclusive(const char *zFilename, OsFile **pId, int delFlag){
...
do{
h = CreateFileW((WCHAR*)zConverted,
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
CREATE_ALWAYS,
fileflags,
NULL
);
}while( h==INVALID_HANDLE_VALUE && cnt++ < 2 && (Sleep(100), 1) );
...
}
This requires the CreateFileW call to fail and return an invalid handle - which is what Microsoft specifies for a file marked for deletion but what the file system driver does not acknowledge: it allows the file marked for deletion to be successfully opened.
So it's again the ext2ifs driver developer's turn: I have already contacted him ...
2007-Oct-01 14:46:18 by anonymous:
Adding the Sleep would simply confirm your theory. No one is suggesting it be added permanently.
2007-Oct-07 23:21:26 by anonymous:
I finally tracked down also the unlock errors: they are there by design. When a hot journal is found, the immediate rollback is purposely only with an EXCLUSIVE lock, but without a RESERVED or PENDING lock. Nevertheless, the unlock code assumes that whenever there is an EXCLUSIVE lock, then there might also be a RESERVED and a PENDING lock, and both are unlocked too. That's nothing to bother with, as it only provokes error returns from the OS, the handling itself is correct. See:
static int winUnlock(OsFile *id, int locktype){
...
if( type>=RESERVED_LOCK ){
UnlockFile(pFile->h, RESERVED_BYTE, 0, 1, 0);
}
...
if( type>=PENDING_LOCK ){
UnlockFile(pFile->h, PENDING_BYTE, 0, 1, 0);
}
...
}
2007-Oct-12 18:50:28 by drh:
Summary:
This turns out to be a bug in the ext2 driver for winNT,
not in SQLite.
The locking problem is not a real issue.
2007-Oct-14 16:27:15 by anonymous:
Just to approve: the ext2ifs driver developer sent me a patched driver that returns a "DELETE PENDING" error when a journal file already marked for deletion tried to be opened, and with it the errors are gone. I suppose the corrected driver will soon be general available. |
|
2676 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
1
|
1
|
TEMP_STORE does not appear to be set by the compile time switch
|
edit |
The compile time switch -DTEMP_STORE=2 does not appear to change TEMP_STORE.
When a database is created after compiling the library I tried to view temp_store by using PRAGMA temp_store which returns the value 0. If this is true that would force all temp storage to a file. I want temp storage to be in memory. |
It's more complex than that. See the table at:
http://www.sqlite.org/pragma.html#pragma_temp_store
|
|
2675 |
new
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
1
|
1
|
TEMP_STORE does not appear to be set by the compile time switch
|
edit |
The compile time switch -DTEMP_STORE=2 does not appear to change TEMP_STORE.
When a database is created after compiling the library I tried to view temp_store by using PRAGMA temp_store which returns the value 0. If this is true that would force all temp storage to a file. I want temp storage to be in memory. |
See #2676 |
|
2670 |
doc
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Oct
|
|
5
|
4
|
Document for EXPLAIN doesn't mention using EXPLAIN QUERY PLAN
|
edit |
I was looking for documentation for determining what indicies a select statement uses. I found "EXPLAIN" in the documentation, but couldn't figure anything out from the output. Eventually I found "EXPLAIN QUERY PLAN" on the idxchk wiki page. |
2007-Oct-01 13:37:02 by drh:
EXPLAIN QUERY PLAN is unsupported. If we document it we will have to
support it forever. That is something we do not want to do. |
|
2669 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
anonymous
|
2
|
3
|
INSERT of Large REAL value fails with Floating Point Exception
|
edit |
When inserting a large number as a REAL value, a Floating Point Invalid Operation exception is thrown. This occurs in the "sqlite3VdbeIntegerAffinity" function in the "vdbemem.c" source, on the line "pMem->i = pMem->r". This exception is only thrown when the value in pMem->r is outside the range of a signed I64 value.
The following is a work-around that seems to suppress the exception and produce no adverse affects on the content of the database:
/*
** @date Added 9/26/07 - ESK -- Include needed for the _I64_MIN and _I64_MAX defines
*/
#include <limits.h>
/*
** The MEM structure is already a MEM_Real. Try to also make it a
** MEM_Int if we can.
*/
void sqlite3VdbeIntegerAffinity(Mem *pMem){
assert( pMem->flags & MEM_Real );
/*
** @date 9/26/07 - ESK -- Added conditional to check for a double value that is
** outside the range of the __int64 value (when the value is out of the range it
** throws a invalid floating point operation exception).
*/
if (( pMem->r > _I64_MAX ) || ( pMem->r < _I64_MIN )){
pMem->i = 0;
}else{
pMem->i = pMem->r;
}
if( ((double)pMem->i)==pMem->r ){
pMem->flags |= MEM_Int;
}
}
At the time of the exception, pMem->r is equal to 3.8E+49. The library was compiled under Borland C++ Builder 5 on the Windows Platform (2k and XP).
This issue has only occurred for us when pulling data out of a database (that originally accepted the real value that was inserted) and inserting the data into another database. The problem occurs when calling sqlite3_step with a sqlite3_stmt struct, after binding the REAL value to the structure.
I'm not sure if this floating point exception will present in any other location, since this is the only location we've seen it in so far.
This issue may or may not be related to Ticket #2586. |
2007-Sep-26 15:10:55 by anonymous:
Please provide a few line standalone SQL example with schema that reproduces what you're seeing.
2007-Sep-26 15:26:59 by anonymous:
To be more specific, please provide a few line standalone SQL example with schema that reproduces what you're seeing using the sqlite3 commandline shell program.
http://www.sqlite.org/sqlite-3_5_0.zip
2007-Sep-26 23:34:56 by anonymous:
We cannot replicate the issue using the sqlite3.exe utility. However the following code sample does demonstrate how to reproduce the exception (the exception occurs within the call to sqlite3_step):
#include "sqlite3.h"
int main(int argc, char* argv[])
{
sqlite3 *pDB;
int ret;
char *errmsg = NULL;
sqlite3_stmt *pStmt;
ret = sqlite3_open ("database.db", &pDB);
ret = sqlite3_exec (pDB, "CREATE TABLE POS_NUMERIC (MAIN_ID INTEGER, NUMERIC_VALUE REAL )", 0, 0, &errmsg);
if ( errmsg ){
free (errmsg);
}
ret = sqlite3_prepare (pDB, "INSERT INTO POS_NUMERIC (MAIN_ID, NUMERIC_VALUE) VALUES (?, ?)", -1, &pStmt, 0);
sqlite3_bind_text (pStmt, 1, "1234", strlen ("1234"), SQLITE_TRANSIENT);
sqlite3_bind_text (pStmt, 2, "3.8E49", strlen ("3.8E49"), SQLITE_TRANSIENT);
ret = sqlite3_step (pStmt);
sqlite3_finalize (pStmt);
pStmt = NULL;
ret = sqlite3_close (pDB);
return 0;
}
2007-Sep-27 01:07:15 by anonymous:
Your program works fine here with gcc, and the database has the correct values.
What compile flags did you use for Borland C++?
Can you run this program?
#include <stdio.h>
#include <stdlib.h>
#include "sqlite3.h"
void p(char* z) {
puts(z);
sqlite3_free(z);
}
int main() {
sqlite_int64 i;
double r = atof("3.8E49");
printf("sizeof(sqlite_int64) = %d\n", sizeof(sqlite_int64));
p(sqlite3_mprintf("r = %f", r));
i = r;
if ((double)i == r)
puts("can fit into sqlite_int64");
else
puts("can not fit into sqlite_int64");
return 0;
}
It should produce:
sizeof(sqlite_int64) = 8
r = 38000000000000000000000000000000000000000000000000.000000
can not fit into sqlite_int64
2007-Sep-27 01:14:21 by anonymous:
It's a Borland bug. You have to set the FPU control word as follows to avoid these floating point exceptions.
_control87(MCW_EM, MCW_EM);
See:
http://www.virtualdub.org/blog/pivot/entry.php?id=53
http://homepages.borland.com/ccalvert/TechPapers/FloatingPoint.html |
|
2668 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Oct
|
|
3
|
4
|
Build failure due to syntax error under Cygwin
|
edit |
Missing semi-colon at end of line.
The patch below fixes it.
--- os_win.c.orig 2007-09-25 16:55:35.053064600 -0400
+++ os_win.c 2007-09-25 16:52:46.146226100 -0400
@@ -1326,7 +1326,7 @@
#if defined(__CYGWIN__)
cygwin_conv_to_full_win32_path(zRelative, zFull);
- return SQLITE_OK
+ return SQLITE_OK;
#endif
#if OS_WINCE
|
2007-Sep-25 21:22:40 by anonymous:
4th time this was reported. Cygwin appears to be a popular platform.
Duplicate of #2642 |
|
2667 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
no such function: hex no such function: regexp
|
edit |
I am using SQLite 3 with pysqlite. I have few triggers that uses regexp and hex functions. on linux it worked fine. Once I switch to Windows I am getting no such functions errors. |
2007-Oct-01 13:35:49 by drh:
The regexp function is not supported by SQLite. hex() is supported
but we are unable to find anything wrong with it. |
|
2665 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
3
|
1
|
Dissapearing exclusive lock when DB is copied...
|
edit |
In our application, we occasionally need to make copies of a running database. To insure consistancy, the program does something like this (in python):
# we're about to lock the db
dbcursor.execute('begin exclusive')
# the db is now locked
shutil.copy('database.db','other-name.db')
# WHOAH, what happened to our lock on database.db??????
the comments indicate the locking status at each time. I've got a workaround, which amounts to:
# we're about to lock the db
dbcursor.execute('begin exclusive')
# the db is now locked
os.system('cp database.db other-name.db')
# database.db is still locked, but other-name.db is not locked
which is more or less what I'd expect.
Is this copying of databases totally evil? Why does a copy made by a process that has an exclusive lock on the origin of the copy destroy the exclusive lock? Why doesn't a copy by a different process destroy it? |
2007-Sep-25 18:30:59 by anonymous:
The problem is
shutil.copy('database.db','other-name.db')
must be unlocking the file or doing something altogether wrong.
Run strace/truss to confirm.
2007-Sep-25 18:32:06 by drh:
On unix, when you close a file, all locks on that file held by the same
process are cleared - even locks that were created by separate
file descriptors. You are probably closing the file at the conclusion
of your copy, which is clearing the locks.
This "feature" of unix is brought to you by The Open Group.
After a while, you learn to clearly see the differences between
those parts of unix that were designed by Thompson and Richie and
those parts developed by committee. Would that there was more
of the former and less of the latter...
2007-Sep-25 18:52:38 by anonymous:
How can we get the UNIX file descriptor for the sqlite3* connection from the sqlite3 API so that we do not have to reopen and ultimately close the file, thus clearing the locks?
2007-Sep-25 19:12:05 by anonymous:
I've run strace, and the results are exactly what you'd expect; the shutil.copy() command opens the FD for creating. opens the destination
FD, and writes out a copy.
Also; the bug dissapears if you replace the shutil.copy() with
something like:
os.system('python -e "shutil.copy(...."')
so it's not the mechanics of shutil.copy, but instead is because of the same processness of doing the copy. Sorry for not including that earlier!
2007-Sep-26 12:09:00 by anonymous:
Maybe you could consider introducing new API - sqlite3_backup(sqlite3*, const char*), or new SQL command BACKUP(FileName) which would backup main database to specified file using (exclusive?) lock.
I don't see far to SQLite internals, but I hope this change could also provide functionality for saving in-memory databases to disk. |
|
2663 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Oct
|
|
3
|
3
|
Adding a column with default value not reflected in view
|
edit |
When adding a column to a table using alter table any default value for the column is not returned by a select using a view even if the view is recreated.
Adding a single integer column to a table with a default value of 0. Any existing record correctly appears to have a value of 0 for the new column. However, if this table is used in a view, then the column appears to be NULL (the view has a select a.*, b.x from a, b where a.i = b.i; definition and we add a column to a). So, I then dropped the view and re-created it again because the schema of a has changed. However, the new column still appears to be NULL in the view whereas 0 is correctly displayed when a select from the table is done.
This error occurs using sqlite3 and no code of ours. |
2007-Sep-24 14:40:49 by anonymous:
# sqlite3 f.db
sqlite> create table a (a int);
sqlite> create table b (b int);
sqlite> create view ab as select a.*, b.* from a,b where a.a = b.b;
sqlite> insert into a values (1);
sqlite> insert into a values (2);
sqlite> insert into a values (3);
sqlite> insert into b values (2);
sqlite> select * from ab;
2|2
sqlite> alter table a add column c int default 0;
sqlite> select * from a;
1|0
2|0
3|0
sqlite> select * from ab;
2|
sqlite> drop view ab;
sqlite> create view ab as select a.*, b.* from a,b where a.a = b.b;
sqlite> select * from ab;
2||2
sqlite>
2007-Sep-24 14:43:26 by anonymous:
Sorry, that should have read (and I also see that this is 3.3.5)
$ sqlite3 f.db
SQLite version 3.3.5
Enter ".help" for instructions
sqlite> create table a (a int);
sqlite> create table b (b int);
sqlite> create view ab as select a.*, b.* from a,b where a.a = b.b;
sqlite> insert into a values (1);
sqlite> insert into a values (2);
sqlite> insert into a values (3);
sqlite> insert into b values (2);
sqlite> select * from ab;
2|2
sqlite> alter table a add column c int default 0;
sqlite> select * from a;
1|0
2|0
3|0
sqlite> select * from ab;
2|
sqlite> drop view ab;
sqlite> create view ab as select a.*, b.* from a,b where a.a = b.b;
sqlite> select * from ab;
2||2
sqlite>
2007-Oct-01 13:14:13 by drh:
Unable to reproduce in 3.5.0. This problem appears to have
been fixed already.
2007-Oct-22 09:58:35 by anonymous:
FYI: This problem was not present in 3.4.1 either |
|
2662 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
1
|
1
|
Serious Performance Degradation from 3.3.4 to 3.3.5 & latest versions
|
edit |
Starting from 3.3.5, SQLite suffers a serious performance degradation for the following schema and query. 3.3.4 returnes results immedialtely, all later versions take considerable time (multiple seconds) to execute the query. The database is about 6 MB in size.
Schema:
CREATE TABLE MTV20030105AdLink (AdvertisementID Numeric,
AdRelationShipID Numeric,
AgencyID Numeric,
AdvertiserID Numeric,
ProductID Numeric);
CREATE TABLE MTV20030105AdType (ADTypeID Numeric,
AdTypeName char(50));
CREATE TABLE MTV20030105Adjacency (AdInstID Numeric,
ProductID Numeric);
CREATE TABLE MTV20030105Advertiser (AdvertiserID Numeric,
AdvertiserName char(50));
CREATE TABLE MTV20030105Agency (AgencyID Numeric,
AgencyName char(50));
CREATE TABLE MTV20030105Products (ProductID Numeric,
ProductName char(50));
CREATE TABLE MTV20030105Programs (ProgramID Numeric,
ProgramName char(50));
CREATE TABLE MTV20030105Spots (AdInstID Numeric,
AdvertisementID Numeric,
KeyNumber char(15),
StationID Numeric,
SpotDateTime DateTime,
Duration Numeric,
BreakNumber Numeric,
NumAdsInBreak Numeric,
PositionInBreak Numeric,
PromoBefore Numeric,
PromoAfter Numeric,
AdTypeID Numeric,
CommentID Numeric,
ProgramID Numeric,
MarketInd Numeric);
CREATE TABLE MTV20030105Stations (StationID Numeric,
NetworkID Numeric,
NetworkName char(50),
CallSign char(50),
LeadMarketInd Numeric);
CREATE INDEX MTV20030105AdLink_i1 ON MTV20030105AdLink(ProductID);
CREATE INDEX MTV20030105Spots_i1 ON MTV20030105Spots (AdvertisementID);
Query:
select SpotDateTime,NetworkName,CallSign,KeyNumber,Duration,ProgramName
from MTV20030105Spots,MTV20030105Stations,MTV20030105Programs
where MTV20030105Spots.AdvertisementID
in (select AdvertisementID from MTV20030105AdLink where productid=90887)
and MTV20030105Stations.StationID=MTV20030105Spots.StationID
and MTV20030105Programs.ProgramID=MTV20030105Spots.ProgramID;
"ANALYZE;" was not executed with any version of SQLite, and running it does not speed up the query with recent versions.
I can provide the test database if required, just let me know. |
2007-Sep-24 14:49:29 by anonymous:
This is not a bug. This question belongs on the mailing list.
If you run "EXPLAIN QUERY PLAN" on your SELECT you can see that your schema is not optimal, and results in full table scans for stations and programs:
0|1|TABLE MTV20030105Stations
1|2|TABLE MTV20030105Programs
2|0|TABLE MTV20030105Spots WITH INDEX MTV20030105Spots_i1
0|0|TABLE MTV20030105AdLink WITH INDEX MTV20030105AdLink_i1
If you change your schema as follows, it will use the indexes effectively:
CREATE TABLE MTV20030105AdLink (AdvertisementID Numeric,
AdRelationShipID Numeric,
AgencyID Numeric,
AdvertiserID Numeric,
ProductID Numeric);
CREATE TABLE MTV20030105AdType (ADTypeID INTEGER PRIMARY KEY,
AdTypeName char(50));
CREATE TABLE MTV20030105Adjacency (AdInstID INTEGER PRIMARY KEY,
ProductID Numeric);
CREATE TABLE MTV20030105Advertiser (AdvertiserID INTEGER PRIMARY KEY,
AdvertiserName char(50));
CREATE TABLE MTV20030105Agency (AgencyID INTEGER PRIMARY KEY,
AgencyName char(50));
CREATE TABLE MTV20030105Products (ProductID INTEGER PRIMARY KEY,
ProductName char(50));
CREATE TABLE MTV20030105Programs (ProgramID INTEGER PRIMARY KEY,
ProgramName char(50));
CREATE TABLE MTV20030105Spots (AdInstID Numeric,
AdvertisementID Numeric,
KeyNumber char(15),
StationID Numeric,
SpotDateTime DateTime,
Duration Numeric,
BreakNumber Numeric,
NumAdsInBreak Numeric,
PositionInBreak Numeric,
PromoBefore Numeric,
PromoAfter Numeric,
AdTypeID Numeric,
CommentID Numeric,
ProgramID Numeric,
MarketInd Numeric);
-- assumes that StationID is a unique identifier
CREATE TABLE MTV20030105Stations (StationID INTEGER PRIMARY KEY,
NetworkID Numeric,
NetworkName char(50),
CallSign char(50),
LeadMarketInd Numeric);
CREATE INDEX MTV20030105AdLink_i1 ON MTV20030105AdLink(ProductID);
CREATE INDEX MTV20030105Spots_i1 ON MTV20030105Spots (AdvertisementID);
explain query plan
select SpotDateTime,NetworkName,CallSign,KeyNumber,Duration,ProgramName
from MTV20030105Spots,MTV20030105Stations,MTV20030105Programs
where MTV20030105Spots.AdvertisementID
in (select AdvertisementID from MTV20030105AdLink where productid=90887)
and MTV20030105Stations.StationID=MTV20030105Spots.StationID
and MTV20030105Programs.ProgramID=MTV20030105Spots.ProgramID;
0|0|TABLE MTV20030105Spots WITH INDEX MTV20030105Spots_i1
1|1|TABLE MTV20030105Stations USING PRIMARY KEY
2|2|TABLE MTV20030105Programs USING PRIMARY KEY
0|0|TABLE MTV20030105AdLink WITH INDEX MTV20030105AdLink_i1
2007-Sep-24 15:12:03 by anonymous:
This query is faster:
explain query plan
select SpotDateTime,NetworkName,CallSign,KeyNumber,Duration,ProgramName
from (select AdvertisementID from MTV20030105AdLink where productid=90887) ads,
MTV20030105Spots,
MTV20030105Stations,
MTV20030105Programs
where MTV20030105Spots.AdvertisementID = ads.AdvertisementID
and MTV20030105Stations.StationID=MTV20030105Spots.StationID
and MTV20030105Programs.ProgramID=MTV20030105Spots.ProgramID;
0|0|TABLE MTV20030105AdLink WITH INDEX MTV20030105AdLink_i1
1|1|TABLE MTV20030105Spots WITH INDEX MTV20030105Spots_i1
2|2|TABLE MTV20030105Stations USING PRIMARY KEY
3|3|TABLE MTV20030105Programs USING PRIMARY KEY
2007-Sep-24 15:45:58 by anonymous:
Point well taken ;-)
For completeness, here is the query plan produced by SQLite 3.3.4:
0|0|TABLE MTV20030105Spots WITH INDEX MTV20030105Spots_i1
1|1|TABLE MTV20030105Stations
2|2|TABLE MTV20030105Programs
0|0|TABLE MTV20030105AdLink WITH INDEX MTV20030105AdLink_i1
The table scan order is different which results in much faster execution times.
If anyone knows if this change was intentional in later versions, I'd be glad to read about it on the mailing list.
Also, out of plain curiosity: While I realize that the presented DB schema is not defined adequately, would anyone still consider that the new scan order behavior breaks backwards compatibility? For very large tables, the query becomes unusable after 3.3.4.
Meet you at the mailing list ...
2007-Sep-24 18:18:28 by anonymous:
The table/index scan order has changed many times from release to release, and has never been guaranteed. When the query optimizer was first introduced many queries relying on the join order specified in the FROM clause were slower and had to be reworked. Your previous defined schema was just lucky in this regard. If you have proper indexing you would not have had this performance degradation. For that matter, it would not hurt if you used ANALYZE as well. |
|
2661 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
2
|
3
|
Single line, multi inserts
|
edit |
Using a wrapper for the DLL in Delphi, when doing single SQL statements, each row being inserted is successfully inserted as it should be.
When doing multiple inserts in one call though, only the first insert seems to be processed.
When using SQLITE3.EXE and I do the multi insert on one line, the transaction adds two rows to the DB.
In detail;
insert into tblfiles ([Name], fkid) values ('.bash_history',1); insert into tblfiles ([Name], fkid) values ('.rnd',1);
When I run this via SqlDB.ExecSQL in Delphi, only .bash_history shows up in tblfiles. When I run that statement in SQLITE3.EXE, both show up. The wrapper directly calls the DLL.
I'm pounding the DB pretty hard with a bulk inserts (45,000 inserts easy). One at a time takes a VERY long time. |
Apparantly it was the wrapper that was causing the issue. Found another one and multi-inserts work just fine. |
|
2660 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
4
|
4
|
Spelling error in comment for SQLITE_CONSTRAINT
|
edit |
"constraint" is mispelled as "contraint" once in sqlite3.h and once in sqliteInt.h.
In sqlite3.h
#define SQLITE_CONSTRAINT 19 /* Abort due to contraint violation */
In sqliteInt.h
/*
** SQLite supports many different ways to resolve a contraint
** error. ROLLBACK processing means that a constraint violation
|
Thanks. |
|
2657 |
build
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Oct
|
anonymous
|
1
|
1
|
fail to compile
|
edit |
I fail to compile.
It is a "win32 static library" project.
I simply create an empty project with "not using MFC" option and then add all files included in "sqlite-source-3_5_0.zip" into the project.
Debug configuration is fine, but I cannot compile release.
Information:
...sqlite-source-3_5_0\btree.c(3111) : fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'F:\9782\vc98\p2\src\P2\regasg.c', line 646)
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
Error executing cl.exe. |
2007-Sep-21 00:05:42 by anonymous:
I have the same problem. I am using the preprocessed source code in sqlite-source-3_5_0.zip with Visual Studio 6.0 SP6. Compiler version:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
The offending line of btree.c is line 3111, which looks fairly innocent to me:
pCur->aOverflow[iIdx] = nextPage;
After investigating, it looks like this error is only emitted when global optimizations (/Og) are enabled, which is one of the switches set by optimizing for maximum speed.
As a workaround, you can insert the line
#pragma optimize("g", off)
before line 3026 and the line
#pragma optimize( "", on)
after line 3156, which are the beginning and ending of the function
static int accessPayload(BtCursor,int,int,unsigned char,int,int)
This will disable global optimizations for the function, but leave them enabled for the rest of the file.
MSDN has more information about error C1001, but it is not quite the same as what the VS6 docs say:
This error is most often generated [due to] ... Failure of the code generator to find a way to generate correct code for a construct. This is most often caused by the interaction of an expression and an optimization option. The optimization has generated a tree which the compiler does not know how to handle. Such a problem can often be fixed by removing one or more optimization options when compiling the particular function containing the line indicated in the error message.
2007-Oct-12 18:53:47 by drh:
In other words, there is a bug in MSVC++ that prevents it
from correctly compiling SQLite.
Shouldn't this be a problem reported to Microsoft?
What exactly can we (the SQLite developers) do about this?
Is there some simple code change that we can make to work
around the bug in MSVC++? |
|
2656 |
doc
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Oct
|
|
2
|
1
|
missing documentation: END TRANSACTION
|
edit |
The documentation lists END [TRANSACTION] as a legal command, but does not describe it. It should be documented that is is the same as COMMIT [TRANSACTION].
Reference: http://www.mail-archive.com/sqlite-users@sqlite.org/msg03000.html |
2007-Oct-01 13:32:34 by drh:
The END TRANSACTION syntax works but it is unsupported.
If I document it that means I will have to begin supporting
it, which is something I do not want to do.
2007-Oct-01 17:41:52 by anonymous:
The END DOCUMENTATION syntax is documented - but it is not described what it does.
While this might be intentional, I know about a novice user who was confused if he had to call END DOCUMENTATION after either COMMIT or ROLLBACK.
If you decide not to document END DOCUMENTATION, you might want to think about not documenting it at all, in other words, remove the syntax declaration.
2007-Oct-01 17:46:07 by drh:
OK. We have added documentation for END TRANSACTION.
2007-Oct-02 06:30:17 by anonymous:
Thanks! |
|
2655 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
2
|
3
|
Reuse prepared statement after locked(5) gives called out of seq(21)
|
edit |
Reusing a prepared statement after locked(5) error gives library routine called out of sequence(21)
Create a test db:
sqlite3 test.db
CREATE TABLE test (id INTEGER PRIMARY KEY AUTOINCREMENT, val INTEGER);
go
Lock db by running a statement in a transaction:
begin transaction
go
delete from test where id = 99
go
Try to run a prepared statement on the table via Perl DBI will give database is locked(5) at the first try. On following tries library routine called out of sequence(21) will be returned.
Only works if statement handle is undef:ed and prepared again.
If this is a problem in the SQLite DBD or in the SQLite library I don't know.
Environment:
FreeBSD 6.1
Perl 5.8.8
DBI 1.50
SQLite DBD 1.13
SQLite 3.4.2
Test script:
#!/usr/local/bin/perl
use DBI;
my $dbh = DBI->connect("dbi:SQLite:dbname=test.db","","",{RaiseError => 0}) or die "Couldn't open dbfile.";
$dbh->func(1000, 'busy_timeout');
my $sql = "DELETE FROM test WHERE id = ?";
my $sth = $dbh->prepare($sql);
die "Couldn't prepare" unless defined $sth;
my $ret;
while(! defined $ret){
sleep 1;
print "Execute sth\n";
$ret = $sth->execute(452);
print "ERROR: " . $sth->err . $sth->errstr . "\n" if $ret;
$sth->finish;
}
if($ret){
print "Failure\n";
}
else{
print "Success\n";
}
DBI->trace(5) is attached. |
2007-Sep-19 11:47:29 by drh:
You appear to be calling sqlite3_finalize() (I'm guessing that
is what the "finish" method does) on the statement after the
error. sqlite3_finalize() is the destructor for a statement.
Then you try to use the object after it has been destroyed.
Most systems would segfault under those circumstances. SQLite
is nice and gives you an SQLITE_MISUSE error.
2007-Sep-19 14:33:56 by anonymous:
How is the library supposed to be used in order to reuse the already prepared statement?
(According to perldoc DBI->finish is supposed to finish collection of data from an execution. It is not supposed to be destructive on the statement handle. So I guess that is a misuse of the library from SQLite DBD.)
If I leave out DBI->finish I get the same error.
I added the trace when not running finish. |
|
2654 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Oct
|
jadams
|
1
|
1
|
sqlite3_prepare return 1(fail)
|
edit |
result = sqlite3_exec( db, "create table MyTable_1sadsd ( ID integer primary key autoincrement, name nvarchar(32),comp nvarchar(32), file_content blob )",NULL, NULL, errmsg );//ok
result=sqlite3_prepare(db,"insert into MyTable_1sadsd ( name,comp,file_content ) values ( 'aaaa','aaaaaa1',? )",-1,&stat,&zLeftover );//fail
//the result==1 so fail;
//but
result = sqlite3_exec( db, "create table MyTable( ID integer primary key autoincrement, name nvarchar(32),comp nvarchar(32), file_content blob )",NULL, NULL, errmsg );//ok
result=sqlite3_prepare(db,"insert into MyTable ( name,comp,file_content ) values ( 'aaaa','aaaaaa1',? )",-1,&stat,&zLeftover );//ok
//is ok ,because MyTable is shorter than MyTable_1sadsd ;
//why ? tks
|
It's not clear from the report. There's nothing wrong with the SQL or th e C code shown. Maybe some other process is changing the schema or locking the dataabase or something. If you can post a complete program that demonstrates the problem, we will be able to help you. |
|
2650 |
build
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
1
|
1
|
lack ; in os_win.c:1329
|
edit |
Hi,
I want just to inform you that it misses one; in the file os_win.c (line 1329).
in winFullPathname,
#if defined(__CYGWIN__)
cygwin_conv_to_full_win32_path(zRelative, zFull);
return SQLITE_OK <--- lack ';'
#endif
Regards
YoCarBo |
Duplicate of #2642 and #2647 |
|
2647 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
1
|
1
|
sqlite-3.5.0 Cygwin: Compilation fails on src/os_win.c - ';' missing
|
edit |
There is a ';' symbol missing on line 1329 in file os_win.c (winFullPathname function) after return statement:
#if defined(__CYGWIN__)
cygwin_conv_to_full_win32_path(zRelative, zFull);
return SQLITE_OK
#endif
|
Duplicate of Ticket #2642 |
|
2646 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
a.rottmann
|
4
|
1
|
sqlite3_get_table loses one table row
|
edit |
sqlite3_get_table seems to loose one row.
this patch fixes the problem for me. If it is wrong, please fix the bug in a right way.
--- sqlite-3.4.2/src/table.c 2007-06-12 15:18:01.000000000 +0300
+++ sqlite-3.4.2-x/src/table.c 2007-09-14 13:55:32.000000000 +0300
@@ -77,6 +77,7 @@ static int sqlite3_get_table_cb(void *pA
}
p->azResult[p->nData++] = z;
}
+ p->nRow++;
}else if( p->nColumn!=nCol ){
sqlite3SetString(&p->zErrMsg,
"sqlite3_get_table() called with two or more incompatible
queries",
|
Can you take a look at the documentation here and confirm that you are interpreting it correctly?
http://www.sqlite.org/capi3ref.html#sqlite3_free_table
In particular, this bit:
"Notice that there is an extra row of data containing the column headers. But the *nrow return value is still 3. *ncolumn is set to 2. In general, the number of values inserted into azResult will be ((*nrow) + 1)*(*ncolumn)."
The code looks like it matches this description to me. If you find that it does not, please re-open this ticket. Thanks. |
|
2644 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
1
|
1
|
sqlite
|
edit |
Will you tell me why sqlite program is running on my laptop computer? Is it part of another program. Your answer and time is really appreciated. Thank you. |
2007-Sep-13 18:00:08 by drh:
SQLite is used by Mcaffee Anti-virus, AOL Mail, Skype, Adobe Lightroom,
and countless other programs, most of which we are completely unaware
of.
This website is for reporting bugs against SQLite, not for getting
help with figuring out what it is or why it is running on your
computer. Please use the SQLite mailing list for such help. |
|
2642 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
5
|
5
|
CYGWIN compile error due to missing semicolon
|
edit |
Missing semi-colon near line 1329 of os_win.c after SQLITE_OK.
#if defined(__CYGWIN__)
cygwin_conv_to_full_win32_path(zRelative, zFull);
return SQLITE_OK
#endif
|
Thanks. |
|
2641 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
2
|
3
|
sqlite - Ticket #2638 continued as it was arbitrarily closed unsolved
|
edit |
to continue the thread from 2638. I tried as a blob and it was identical behaviour, this was not a workaround.
behaviour is different in different versions for test or blobs.
used to work, is now broken |
Indeed, the behaviour has changed. SQLite is now less tolerant of non utf-8 encoded strings being handled as text. It is very likely that that is the reason your shiftjis data is being mangled. It should not of happened if the data was being treated as a blob.
Suggest going to the mailing-list for clarification. There are many clever people there who understand this kind of issue. If it does turn out to be a bug, we can reopen this ticket. |
|
2639 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Oct
|
|
1
|
2
|
Russian charset
|
edit |
At implementation of query, Russian charset is inserted like a "􏻂􏻮􏻫" |
2007-Sep-12 02:29:24 by drh:
I do not understand the complaint.
But a good guess is that you are trying to use a codepage of
some kind in a TEXT entry. SQLite understands only Unicode -
either UTF8 or UTF16. Translate all of your strings into
one of these encodings first, before inserting them into the
database, if you want them to be compared correctly.
If you do not want to use unicode, insert your data as BLOBs
instead of a strings. |
|
2638 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
2
|
3
|
selects on japanese text okay in 3.3.5 bad in later versions
|
edit |
I have a database that was created in version 3.3.5 that contains japanese shift-jis text fields (a kanji lookup db). It works fine with the 3.3.5 dll. When I put the 3.4.2 or alpha 3.5 dll in a select of a japanese character does not match characters in the DB correctly, instead of returning 300 or so matching entries it returns 2000 non matching ones. I have a workaround in the sense that I can keep the current 3.3.5 dll in the app and it works but I'd like to move forward to new versions soon.
It's a database of japanese characters with japanese pronounciation and english meanings. format is code page 932. User puts a character in and it matches to a character in the system. replacing the dll and putting the same character in exactly (ie, paste current clipboard in both cases to be sure input codex is the same) and results are completely different. |
2007-Sep-12 01:09:08 by drh:
SQLite uses Unicode, either UTF8 or UTF16. You can put in string
that are not well-formed UTF8 or UTF16 and sometimes it might work.
But later versions have become noticably less tolerate of illformed
UTF8. This is due to security concerns. See, for example,
ticket #2029.
If you want to store strings of codepage 932, I suggest you
store them as BLOBs and not as text strings. |
|
2637 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
1
|
1
|
Segfault in pthread_getspecific ()
|
edit |
Hi,
I am trying to run Trac 0.11-dev with Apache 2.2.3-3.2ubuntu0.1/mod_python and libsqlite3 3.4.2. Accessing Trac over Apache causes segfault in libsqlite3. This has something to do with threading (models), I assume. I am not sure if this is an configuration issue, but I couldn't find any help after hard googling.
I tried also libqlite 3.3.x with the same result. I marked the bug with severity 1, since there is no known workaround AFAIK.
I compiled libsqlite3 to get the symbolic traceback:
#0 0xb7c521fa in pthread_getspecific () from /lib/tls/i686/cmov/libpthread.so.0
#1 0xb7d07f01 in sqlite3Insert (pParse=0x0, pTabList=0xb7d39bc8, pList=0xbfe16c98, pSelect=0xb7cebe8c,
pColumn=0xb7cdf298, onError=1) at ./src/insert.c:1564
#2 0xb7d1e40e in sqlite3_get_table_cb (pArg=0xb7cdf298, nCol=1, argv=0xa582000, colv=0xb7d39bc8)
at ./src/table.c:107
#3 0xb7cebe8c in sqlite3AuthRead (pParse=0xb7cebe8c, pExpr=0xbfe16c98, pTabList=0xb7d39bc8)
at ./src/auth.c:118
#4 0xb7cebf18 in sqlite3AuthRead (pParse=0xb7d39bc8, pExpr=0xa582000, pTabList=0x1) at ./src/auth.c:140
#5 0xb7d118b6 in sqlite3Parser (yyp=0xa6ff558, yymajor=<value optimized out>, yyminor=
{z = 0xffffffff <Address 0xffffffff out of bounds>, dyn = 0, n = 0}, pParse=0xbfe16e34)
at parse.y:468
#6 0xb7d11fc1 in sqlite3Parser (yyp=0xa6ff558, yymajor=<value optimized out>, yyminor=
{z = 0xffffffff <Address 0xffffffff out of bounds>, dyn = 0, n = 1609611034}, pParse=0xbfe16e38)
at parse.y:651
#7 0xb7d2f625 in getMask (pMaskSet=0x1, iCursor=1) at ./src/where.c:289
#8 0xb7d12243 in sqlite3Parser (yyp=0xbfe16ef8, yymajor=<value optimized out>, yyminor=
{z = 0xbfe16f08 "\222\023ӷ\232cӷ\200dӷ", dyn = 0, n = 0}, pParse=0x0) at parse.y:706
#9 0xb7d12347 in sqlite3Parser (yyp=0xb7cdffdc, yymajor=<value optimized out>, yyminor=
{z = 0xbfe1734c "X�o\n", dyn = 0, n = 0}, pParse=0xbfe16f78) at parse.y:735
#10 0xb7d1279c in sqlite3Parser (yyp=0xa6ff558, yymajor=<value optimized out>, yyminor=
{z = 0xa43a300 "system", dyn = 0, n = 86104312}, pParse=0xb7d39bc8) at parse.y:768
#11 0xb7d1288f in sqlite3Parser (yyp=0xbfe1734c, yymajor=<value optimized out>, yyminor=
{z = 0xa760dc8 "�>u\no", dyn = 0, n = 86104336}, pParse=0xbfe17048) at parse.y:812
#12 0xb7cf46da in sqlite3BtreeClose (p=0x0) at ./src/btree.c:1236
#13 0xb7d16c56 in base_vprintf (xRealloc=0, useInternal=-1210868792,
zInitBuf=0x1 <Address 0x1 out of bounds>, nInitBuf=-1211228996, zFormat=0xa760dc8 "�>u\no",
ap=0xb7d36480 "CREATE TABLE sqlite_master(\n type text,\n name text,\n tbl_name text,\n rootpage integer,\n sql text\n)") at ./src/printf.c:785
#14 0xb7d173ce in base_vprintf (xRealloc=0xbfe16f28, useInternal=-1210882944,
zInitBuf=<value optimized out>, nInitBuf=-1075743924, zFormat=<value optimized out>,
---Type <return> to continue, or q <return> to quit---
ap=0xe9e1744a <Address 0xe9e1744a out of bounds>) at ./src/printf.c:589
#15 0xb7d179d6 in base_vprintf (xRealloc=0xbfe17038, useInternal=0, zInitBuf=<value optimized out>,
nInitBuf=-1075743924, zFormat=<value optimized out>, ap=0xbfe17090 "\030r��") at ./src/printf.c:548
#16 0xb7d0d75d in pager_playback (pPager=0x68, isHot=16777221) at ./src/pager.c:1474
#17 0xb7d1b000 in prepSelectStmt (pParse=0x5cc2c, p=0xb7cdd000) at ./src/select.c:1368
#18 0xb7d1191f in sqlite3Parser (yyp=0xa6ff558, yymajor=<value optimized out>, yyminor=
{z = 0xffffffff <Address 0xffffffff out of bounds>, dyn = 0, n = 0}, pParse=0xa73708c) at parse.y:480
#19 0xb7d11fc1 in sqlite3Parser (yyp=0xa6ff558, yymajor=<value optimized out>, yyminor=
{z = 0xffffffff <Address 0xffffffff out of bounds>, dyn = 0, n = 87668806}, pParse=0xbfe17488)
at parse.y:651
#20 0xb6810cef in statement_create () from /usr/lib/python2.5/site-packages/pysqlite2/_sqlite.so
#21 0xb680c7ad in connection_call () from /usr/lib/python2.5/site-packages/pysqlite2/_sqlite.so
#22 0xb7547987 in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#23 0xb7547c03 in ?? () from /usr/lib/libpython2.5.so.1.0
#24 0x0a681a70 in ?? ()
#25 0x0a4154ec in ?? ()
#26 0x00000000 in ?? ()
|
2007-Sep-11 14:47:34 by anonymous:
Also, Trac works fine if started using tracd standalone daemon tool
2007-Sep-11 14:47:34 by anonymous:
Could you try sqlite 3.5? The threading code has been completely redone.
2007-Sep-11 14:57:17 by anonymous:
No dice. libsqlite 3.5.0:
#0 0xb7c521fa in pthread_getspecific () from /lib/tls/i686/cmov/libpthread.so.0
#1 0xb7d07f01 in sqlite3Insert (pParse=0x0, pTabList=0xb7d39bc8, pList=0xbfe16c98, pSelect=0xb7cebe8c,
pColumn=0xb7cdf298, onError=1) at ./src/insert.c:1465
#2 0xb7d1e40e in sqlite3Select (pParse=0xb7cdf298, p=0x1, eDest=171204008, iParm=-1210868792,
pParent=0x0, parentTab=0, pParentAgg=0xbfe16ca8, aff=0xb7cebf18 "�\205�\017\225�\017���\215�&")
at ./src/select.c:2915
#3 0xb7cebe8c in attachFunc (context=0x0, argc=0, argv=0x0) at ./src/attach.c:82
#4 0xb7cebf18 in attachFunc (context=0x0, argc=-1211232372, argv=0x1) at ./src/attach.c:114
#5 0xb7d118b6 in sqlite3PagerWrite (pDbPage=0xa8fa470) at ./src/pager.c:4156
#6 0xb7d11fc1 in sqlite3PagerOpen (pVfs=0xa8fa470, ppPager=0xb7d36480,
zFilename=0xffffffff <Address 0xffffffff out of bounds>, nExtra=-1075745228, flags=-1075745224,
vfsFlags=1) at ./src/pager.c:2110
#7 0xb7d2f625 in sqlite3VdbeHalt (p=0xa8fa470) at ./src/vdbeaux.c:1142
#8 0xb7d12243 in yy_find_shift_action (pParser=0x0, iLookAhead=1 '\001') at parse.c:1442
#9 0xb7d12347 in yy_destructor (yymajor=<value optimized out>, yypminor=0x1) at parse.c:1337
#10 0xb7d1279c in sqlite3Parser (yyp=0xa8fa470, yymajor=<value optimized out>, yyminor=
{z = 0xa8fec48 "system", dyn = 0, n = 86973048}, pParse=0xb7d39bc8) at parse.c:3268
#11 0xb7d1288f in sqlite3Parser (yyp=0xbfe1734c, yymajor=-1075744936, yyminor=
{z = 0xa906428 "�l\212\no", dyn = 0, n = 86973072}, pParse=0xbfe17048) at parse.c:3477
#12 0xb7cf46da in ?? () at ./src/btree.c:2498 from /usr/lib/libsqlite3.so.0
#13 0xbfe1734c in ?? ()
#14 0xb7d39bc8 in ?? () from /usr/lib/libsqlite3.so.0
#15 0x0a906428 in ?? ()
#16 0x0a5e3520 in ?? ()
#17 0xbfe17048 in ?? ()
#18 0xb7f18300 in ?? () from /lib/ld-linux.so.2
#19 0xb7d16c56 in sqlite3Pragma (pParse=0xbfe1734c, pId1=0xa8fec48, pId2=0x0, pValue=0xb757a700,
minusFlag=173792084) at ./src/pragma.c:601
2007-Sep-11 14:58:54 by anonymous:
Just a shot in the dark - do you have the correct system header files for your version of GLIBC?
2007-Sep-11 15:02:42 by anonymous:
sqlite 3.5 does not call pthread_getspecific
2007-Sep-11 15:59:51 by anonymous:
After a little fight, I rollbacked everything on my system to older versions. I'll see whether this problem reappears when Trac 0.11 is released. Meanwhile you can close the ticket, since I cannot provide anymore further info.
It must be some sort of configuration issue. Glibc headers might be a good guess. Maybe the latest 3.5.0 was not installed correctly.
2007-Sep-11 16:17:03 by drh:
Anonymous users can close tickets in CVSTrac. You could have
closed this ticket yourself. |
|
2636 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
1
|
1
|
Bug in sqlite3_prepare_v2
|
edit |
If we prepare two statements using sqlite3_prepare_v2, lets say
DELETE FROM table WHERE ID = ?;
and
UPDATE table SET ID = ID - ? WHERE ID > ?;
at the same time, bind values to it
Then execute each of the statements, they get executed, but the changes to the database from the second (UPDATE) statement does not show up in the database. |
2007-Sep-11 07:21:12 by danielk1977:
Can you post a short program to demonstrate the problem? From the report, I'm not sure exactly how to reproduce it.
2007-Sep-12: by drh:
Unable to reproduce and original submitter is not responding. |
|
2635 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
3
|
2
|
problem with calculation of juliand date
|
edit |
in the calculation of the function computeYMD (in date.c) the date corresponding of the julian day 77528 is 29 february 300 (which should not exist) instead of 1 march 300, as matter of fact the next day is 2 march 300.
This problem is present every 400 years backward.
Thanks. |
2007-Sep-08 21:46:10 by drh:
The date and time functions in SQLite render all dates according
to the gregorian calendar. This is by design. |
|
2630 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Oct
|
a.rottmann
|
2
|
2
|
sqlite3PagerOpen set a wrong temp file name in pPager->zFilename
|
edit |
in pager.c line 1783
1783 rc = sqlite3PagerOpentemp(&fd);
1784 sqlite3OsTempFileName(zTemp);
1785 zFilename = zTemp;
1786 zFullPathname = sqlite3OsFullPathname(zFilename);
1787 if( rc==SQLITE_OK ){
1788 tempFile = 1;
.
.
.
1823 memcpy(pPager->zFilename, zFullPathname, nameLen+1);
function sqlite3PagerOpentemp on line 1783 open the fd using e new temp file name
but the the function on 1784 get another temp file name and
assign it to pPager->zFilename on line 1823
I compile sqlite on POCKETPC and temp file were not delete automatically by the OS
so I have uncommented the code that delete temp file in function sqlite3PagerClose
/* Temp files are automatically deleted by the OS*/
if( pPager->tempFile ){
sqlite3OsDelete(pPager->zFilename);
}
but the sqlite3OsDelete(pPager->zFilename); use the wrong temp file name.
I have change the previous code with this one.
1783 // rc = sqlite3PagerOpentemp(&fd);
1784 sqlite3OsTempFileName(zTemp);
1785 zFilename = zTemp;
1786 zFullPathname = sqlite3OsFullPathname(zFilename);
1787 do{
1788 cnt--;
1789 rc = sqlite3OsOpenExclusive(zFullPathname, &fd, 1);
1790 assert( rc!=SQLITE_OK || fd );
1791 }while( cnt>0 && rc!=SQLITE_OK && rc!=SQLITE_NOMEM );
1792
1793 if( rc==SQLITE_OK ){
1794 tempFile = 1;
1795 }
and all is fine.
I hope this is useful.
thanks.
by.
|
2007-Sep-06 23:25:20 by drh:
The code in question was restructured and rewritten for
SQLite version 3.5.0.
But looking into this did bring to my attention a bug in the
implementation of 3.5.0, for which I am grateful. |
|
2626 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
1
|
1
|
The Amalgamation compile error
|
edit |
when i compile The Amalgamation 3.4.2 with visual studio 2003 in window, i encounted 3 errors :
'sqlite3IsIdChar':unknown size
'sqlite3OpcodeNames':unkown size
'sqlite3UpperToLower':unkown size
i think it is caused by following source code in sqlite3.c:
#ifndef SQLITE_PRIVATE
# define SQLITE_PRIVATE static
#endif
it should be:
#ifndef SQLITE_PRIVATE
# define SQLITE_PRIVATE
#endif
is that right? |
It looks like vs2003 doesn't like this kind of forward decl:
static int aArray[];
...
static int aArray[] = {1, 2, 3};
But is fine with this:
int aArray[];
...
int aArray[] = {1, 2, 3};
By defining SQLITE_PRIVATE as an empty string, you are avoiding
constructs like the first block above. It's not ideal, but not
harmful either.
2007-Sep-06 13:11:51 by anonymous:
This is fixed in 3.5. |
|
2625 |
build
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
2
|
2
|
http://www.sqlite.org/cvstrac/wiki?p=HowToCompileWithVsNet has problem
|
edit |
when i compile 3.4.2 with visual studio 2003 in windows, i do as http://www.sqlite.org/cvstrac/wiki?p=HowToCompileWithVsNet told me to.
but step 8 "Add all the .c and .h files that you unzipped, except for: tclsqlite.c and shell.c.Note: You may add tclsqlite.c and shell.c, but then you have to define the preprocessor-symbol NO_TCL:" won't work. i suggest to modify it to be "Add all the .c and .h files that you unzipped, except for: tclsqlite.c shell.c and icu.c. Note: You may add tclsqlite.c and shell.c, but then you have to define the preprocessor-symbol NO_TCL, you may add icu.c, but then you have to define the preprocessor-symbol SQLITE_CORE".
why not supply a .sln file? this will save many people's time.
thank you. |
2007-Sep-06 07:04:34 by danielk1977:
What you suggest sounds like an improvement. I'd add the text in
myself, but I don't have visual studio, so I can't test it.
But the wiki pages are all user editable, so feel free to modify
it yourself by clicking the "Edit" link found at the top right-hand
side of the page.
If you have a *.sln file that you can attach to the page, even better. |
|
2620 |
doc
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
5
|
5
|
doc note needed for sqlite3_memory_alarm()
|
edit |
In the docs for sqlite3_memory_alarm() it is probably worth noting that the registered callback xCallback may be invoked from any thread where sqlite3_malloc may be invoked and the user must take appropriate measures in writing their callback. |
2007-Sep-04 03:32:19 by drh:
The docs already say:
"Application programs should not attempt to use sqlite3_memory_alarm()....
This interface is exposed only so that applications can
provide their own alternative implementation...."
Isn't that enough?
2007-Sep-04 04:03:54 by anonymous:
Connection locks may be held. Things could potentially deadlock if you don't know what you're doing. I thought an explicit mention would make this clear, but perhaps you're right. Feel free to close this ticket. |
|
2618 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
linus
|
4
|
1
|
Dabase is Locked
|
edit |
I have copied my executables and binaries to my target with Sqlite Database. But When i try to access the Database I get, Error:Database is Locked and memory fault occurs. |
2007-Sep-04 03:13:48 by drh:
SQLite version 2.8.0 dates back to February of 2003.
We might consider doing a patch on a branch of version 2.8.17
if someone happens to find a very serious bug and explains
the bug clearly. This ticket does neither. Please take
further discussion to the mailing list.
Tnx. |
|
2617 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
drh
|
2
|
3
|
Check in #4357 may lead to bugs in SMP aware systems in windows vfs
|
edit |
Hi
The method for generating temporary file names in windows vfs driver may cause problems when running on SMP systems, because they could 'collide' on sqliteRandomness() call.
A safer and proper fix for this is to use GetTempFileName () windows API (http://msdn2.microsoft.com/en-us/library/aa364991.aspx) and set flags to generate a unique file name. It ensures no-other call could get the same file name. |
2007-Sep-03 21:28:15 by drh:
The chances of a name collision are vanishingly small, so small that
the problem can be ignored.
2007-Sep-05 14:49:46 by anonymous:
Yes. You are correct on this, could never happen, but still exists.
Also, after examined the Randomness code for Win32 VFS driver, I found this:
static int winRandomness(sqlite3_vfs *pVfs, int nBuf, char *zBuf){
int n = 0;
if( sizeof(LPSYSTEMTIME)<=nBuf-n ){
SYSTEMTIME x;
GetSystemTime(&x);
memcpy(&zBuf[n], &x, sizeof(x));
n += sizeof(x);
}
if( sizeof(DWORD)<=nBuf-n ){
DWORD pid = GetCurrentProcessId();
memcpy(&zBuf[n], &pid, sizeof(pid));
n += sizeof(pid);
}
if( sizeof(DWORD)<=nBuf-n ){
DWORD cnt = GetTickCount();
memcpy(&zBuf[n], &cnt, sizeof(cnt));
n += sizeof(cnt);
}
if( sizeof(LARGE_INTEGER)<=nBuf-n ){
LARGE_INTEGER i;
QueryPerformanceCounter(&i);
memcpy(&zBuf[n], &i, sizeof(i));
n += sizeof(i);
}
return n;
}
The code could run into a buffer underrun because you check for sizeof(LPSYSTEMTIME) (which is equal to sizeof(void *), because LPSYSTEMTIME is typedef'ed as SYSTEMTIME *, so a underrun could
happen here. Also, LPSYSTEMTIME suffer from timer granularity of
the kernel, which could be, in some systems, up to 130ms.
A better implementation for this routine could be:
static int winRandomness(sqlite3_vfs *pVfs, int nBuf, char *zBuf){
int n = 0;
if( sizeof(DWORD)<=nBuf-n ){
DWORD cnt = GetTickCount(); // Ticks from system startup
memcpy(&zBuf[n], &cnt, sizeof(cnt));
n += sizeof(cnt);
}
if( sizeof(LARGE_INTEGER)<=nBuf-n ){
LARGE_INTEGER i;
QueryPerformanceCounter(&i); // High-resolution TSC counter
memcpy(&zBuf[n], &i, sizeof(i));
n += sizeof(i);
}
if( sizeof(DWORD)<=nBuf-n ){
DWORD pid = GetCurrentThreadId(); // Current thread id
memcpy(&zBuf[n], &pid, sizeof(pid));
n += sizeof(pid);
}
if( sizeof(DWORD)<=nBuf-n ){
DWORD pid = GetCurrentProcessId(); // Current process id
memcpy(&zBuf[n], &pid, sizeof(pid));
n += sizeof(pid);
}
if( sizeof(SYSTEMTIME)<=nBuf-n ){
SYSTEMTIME x;
GetSystemTime(&x); // System date/time
memcpy(&zBuf[n], &x, sizeof(x));
n += sizeof(x);
}
return n;
}
This code will fill, with less chance of collision, the 20 byte randomness key used to generate the temporary file name, and also
will generate more efficiently random numbers, because it includes
the thread id on it, which will help in SMP systems, because they cannot get to be the same at same time.
There is a chance this could be fixed (SYSTEMTIME issue) and include
in pre-3.5.0 code ? |
|
2614 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
1
|
1
|
Custom VFS still calls default xRandomness
|
edit |
If a default VFS is registered, any custom VFS's xRandomness callback is never invoked. The only reference to the xRandomness call is hard coded in random.c, line 65: sqlite3OsRandomness(sqlite3_vfs_find(0), 256, k); This makes it impossible to implement custom random seeds for any VFS other than the default. |
Correct. This fact has now been made explicit in the documentation. |
|
2609 |
code
|
closed
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
1
|
1
|
Is non-thread safe binaries dangerous for multi-threaded app design ?
|
edit |
Can accessing two threads ( one is the main app one ) to one connection silently corrupt in-memory data so that next commit to write the wrong ones to the disk, for the non-threadsafe binaries ? |
2007-Sep-01 20:45:04 by anonymous:
Forgot to mention:
only the main app thread writes ( calls COMMIT), the other thread only scrolls & reads the data.
2007-Sep-01 20:57:07 by anonymous:
You have to compile sqlite with -DTHREADSAFE=1 if you are to use it in multiple threads in the same program.
This question really belongs on the mailing list, not the bug ticket system.
2007-Sep-01 22:13:40 by anonymous:
Then this issue should be noted on the top of official site, and there should also be thread-safe binaries in the download area. |
|
2605 |
build
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
1
|
3
|
Amalgamated version 3.4.2 doesn't compile (VC++6)
|
edit |
In a project that already used versions 3.3.x through 3.3.17 (successfully) in "amalgamated" source, I substituted sqlite3.c and sqlite3.h from version 3.4.2, but I yield three compilation errors:
Compiling...
sqlite3.c
c:\lavoro\nonclassificato\resanddev\hcsprog\sqlite\sqlite3.c(6187) : error C2133: 'sqlite3UpperToLower' : unknown size
c:\lavoro\nonclassificato\resanddev\hcsprog\sqlite\sqlite3.c(9310) : error C2133: 'sqlite3OpcodeNames' : unknown size
c:\lavoro\nonclassificato\resanddev\hcsprog\sqlite\sqlite3.c(47159) : error C2133: 'sqlite3IsIdChar' : unknown size
Error executing cl.exe.
They all are related to array declaration missing size in brackets. |
Duplicate of ticket #2574. Already fixed. |
|
2603 |
new
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Oct
|
|
1
|
3
|
B-tree and B+tree allow bidirectional cursor but VDBE does not.
|
edit |
B-tree and B+tree allow bidirectional cursor but VDBE does not.
We would very much like to have this capability and our fallback is to
work with the btree api directly.
the closest opcodes are:
rewind p1 p2 p3
p1 is
p2 is line number if rowcount=p1
and
step
What we would like to see is something like
rstep p1
p1= signed integer for direction of relative motion
repos p1 p2
p1=unsigned integer representing low-order 32 bits of 64 bit integer
p2=unsigned integer representing hi-order 32 bits of 64 bit integer
If this is doable in your opinion then we would be willing to look at
implementing it and contributing it to the project. |
2007-Oct-12 18:58:46 by drh:
I'm not really sure what the description above is saying, but
my best guess is that it is a request for logic to do
a ScrollingCursor. Please see the wiki page for how to
accomplish ScrollingCursor in SQLite. |
|
2601 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
Problem with opening database with Unicode filename
|
edit |
Problem with opening database with Unicode filename - it doesn't open the database with Unicode filename or path. |
The description contains insufficient information for us to act
on the problem. |
|
2596 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
2
|
2
|
wrong specifier for extern char arrays
|
edit |
In 3.4.2 (compared to 3.4.1) the forward declarations of char arrays sqlite3UpperToLower, sqlite3OpcodeNames and sqlite3IsIdChar are labeled with SQLITE_PRIVATE instead of previous extern. This causes problem with amalgamated file - the compiler (Visual C++ 9.0 beta 2) fails to compile it.
Putting extern instead of SQLITE_PRIVATE had fixed the problem. |
Compile with -DSQLITE_PRIVATE=extern or compile a file like this:
/* foo.c */
#define SQLITE_PRIVATE extern
#include "sqlite3.c"
|
|
2594 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
5
|
4
|
ability to replace allocator
|
edit |
In order to use my own allocator for the SQLite I reimplemented routines sqlite3GenericMalloc, sqlite3GenericRealloc and sqlite3GenericOsFree.
SQLite, however, needs some modification to use these functions:
(1) The original functions need to be commented out. (2) Functions sqlite3OsMalloc, sqlite3OsRealloc and sqlite3OsFree (in amalgamated code) use specifier SQLITE_PRIVATE (static) and this needs to be removed too.
Perhaps the SQLite code may employ macro SQLITE_I_HAVE_MY_OWN_ALLOCATOR or so to do this all w/o need to touch the code.
The change of allocator worked well for me (I use Doug Lea's dlmalloc). |
2007-Aug-29 22:34:36 by drh:
Please check the mailing list archives. This is a planned
feature for version 3.5.0.
2007-Aug-29 22:56:18 by anonymous:
What does OBE stand for?
2007-Aug-29 23:45:10 by drh:
Overcome by events.
Normally that means that a ticket is no longer relevant because
things have changed since the ticket was written. That does not
apply here, exactly, but it was (in my opinion) the best available
option for Resolution. |
|
2593 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
1
|
1
|
btshared unlock bug
|
edit |
You have want to avoid a race condition by zeroing p->locked within the mutex. Otherwise another thread may acquire the lock, set locked to 1 (while still holding the mutex) and then this thread outside the mutex will unintentionally clear it.
@@ -191,6 +193,7 @@
p->wantToLock--;
if( p->wantToLock==0 ){
+ p->locked = 0;
sqlite3_mutex_leave(p->pBt->mutex);
- p->locked = 0;
}
}
}
Haven't looked at the code, there may be other occurances of this. |
2007-Aug-28 17:57:26 by drh:
The p->locked variable is protected by a separate
mutex, specifically the mutex at p->pSqlite->mutex.
The database handle, the thing that sqlite3_open()
returns, is at p->pSqlite. Each such handle has
its own mutex. Associated with each database handle
is one or more Btree structures, one for each open
database. There are typically two of these, one
for the main database and another for the TEMP database.
New Btree structures are added for each ATTACH. Each
Btree is tied to a single database handle so it is
protected by the same mutex as the database handle.
"p" is a pointer to a Btree in this instance.
The guts of a database are contained in a Btshared
structure. Btree points to Btshared. But if shared
cache is enabled, two or more Btree structures from
different database handles might point to the same
Btshared. So Btshared needs its own mutex.
This new mutex covers only the Btshared. The Btree
structure is covered by the original database handle
mutex.
See also #2578 |
|
2592 |
warn
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
1
|
1
|
The Entry C:\Windows\Temp\sqlite_z6onAYdsVGqLG3Q is Invalid
|
edit |
Everytime I reboot and check disk I get " The Entry C:\Windows\Temp\sqlite_z6onAYdsVGqLG3Q is Invalid I believe this has something to do with skype and all messengers rebooting my PC everytime I try to enable voice Thank you |
This is a question for a skype group. |
|
2590 |
todo
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
danielk1977
|
2
|
2
|
return value of strftime('%s', 'now') being determined as 'text'
|
edit |
Hello.
SELECT typeof(strftime('%s', 'now'));
results 'text'. Is this correct? As strftime('%s', 'now') returns number of seconds since Unix epoch started.
Greatings. |
In my opinion it is correct. strftime returns a formatted string.
If for some reason you want the type of the expression to be an
integer you could do:
SELECT CAST(strftime('%s', 'now') AS INTEGER);
|
|
2589 |
doc
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
danielk1977
|
4
|
4
|
s/effected/affected/ in PRAGMA locking_mode
|
edit |
In the last sentence of the documentation for PRAGMA locking_mode, "effected" should be "affected". |
thanks. |
|
2586 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
3
|
3
|
INSERT of large number fails on Windows
|
edit |
When using the windows version of the sqlite3.dll, trying to insert a number larger then what fits in a 64 bits int (so larger then: 9223372036854775807) will give a "Invalid floating point operation" exception.
The following code will reproduce this:
create table t(a float);
insert into t values(2.49190E+26);
The command-line tool does not have this problem however.
The exception seems to be thrown at this line:
pMem->u.i = pMem->r;
in the "sqlite3VdbeIntegerAffinity" function in vdbemem.c
At least, that is what Visual Studio 8 says. |
2007-Aug-24 13:19:25 by anonymous:
You've changed the floating point accuracy to single precision, probably because you're writing 3D software. Google for "controlfp".
http://msdn2.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx |
|
2585 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Oct
|
anonymous
|
1
|
1
|
Error Function GetAtomNameA
|
edit |
The Procedure entry point GetAtomNameA could not be located in the dynamic link library sqlite3.dll
Using CodeBlock |
2007-Oct-05 15:11:29 by drh:
Nothing in SQLite invokes GetAtomNameA(). This must be a problem
with some other library. |
|
2584 |
new
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
1
|
2
|
On Windows function sqlite3WinSleep needs to dispatch messages
|
edit |
When sqlite is busy, it spins in the loop, re-trying call every 100 ms. On Windows if the caller thread runs a message loop (for example a GUI application of COM call from an appartment), the message loop stops and the application hangs. As a workaround, sqlite function sqlite3WinSleep needs to call PeekMessage with subsequent calls TranslateMessage/DispatchMessage to continue message processing
as following:
/*
** Sleep for a little while. Return the amount of time slept.
*/
int sqlite3WinSleep(int ms)
{
//----------------------------------------------------------------{linebreak}
//The fix starts
MSG msg;
while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage (&msg);
if (msg.message == WM_QUIT) //Note - need to handle WM_QUIT,posted by PostQuitMessage
break;
}
//The fix ends
//-----------------------------------------------------------------{linebreak}
Sleep(ms);
return ms;
}
|
2007-Aug-23 16:08:43 by drh:
Processing GUI events is not the business of a database
engine. If you need to process GUI events while waiting
on a lock, then use the sqlite3_busy_handler() API to
register your own busy handler (perhaps using the code
shown in the patch) instead of using the built-in
sqlite3_busy_timeout().
2007-Aug-23 17:54:06 by anonymous:
You should wrap in a thread your db calls if you wan't to process using GetMessage() calls |
|
2581 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
1
|
1
|
./configure && make broken: new source files: mem[12].c, mutex.c, etc
|
edit |
Please apply the diff given by this command to Makefile.in:
cvs diff -D'2007-08-14' main.mk
|
2007-Aug-21 20:31:44 by drh:
We are in the middle of a major reimplementation of large sections
of SQLite. We could fix the makefile, but the build still wouldn't
work. So what's the point, really. I promise to fix the makefile
before the next release.... |
|
2578 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
1
|
1
|
sqlite3BtreeEnter, sqlite3BtreeLeave threading issues
|
edit |
p->wantToLock++ is not an atomic operation and must be done within a mutex lock, otherwise its result is undefined. Same goes for "variable--". You need an architecture-specific operations to do that safely between threads. See http://www.mozilla.org/projects/nspr/reference/html/pratom.html and http://lxr.mozilla.org/nspr/source/nsprpub/pr/include/pratom.h#60 for an example.
void sqlite3BtreeEnter(Btree *p){
Btree *pLater;
/* Some basic sanity checking on the Btree. The list of Btrees
** connected by pNext and pPrev should be in sorted order by
** Btree.pBt value. All elements of the list should belong to
** the same connection. Only shared Btrees are on the list. */
assert( p->pNext==0 || p->pNext->pBt>p->pBt );
assert( p->pPrev==0 || p->pPrev->pBtpBt );
assert( p->pNext==0 || p->pNext->pSqlite==p->pSqlite );
assert( p->pPrev==0 || p->pPrev->pSqlite==p->pSqlite );
assert( p->sharable || (p->pNext==0 && p->pPrev==0) );
/* Check for locking consistency */
assert( !p->locked || p->wantToLock>0 );
assert( p->sharable || p->wantToLock==0 );
if( !p->sharable ) return;
p->wantToLock++;
if( p->locked ) return;
/* In most cases, we should be able to acquire the lock we
** want without having to go throught the ascending lock
** procedure that follows. Just be sure not to block.
*/
if( sqlite3_mutex_try(p->pBt->mutex)==SQLITE_OK ){
p->locked = 1;
return;
}
This needs fixing:
Index: src/btree.c
===================================================================
RCS file: /sqlite/sqlite/src/btree.c,v
retrieving revision 1.401
diff -u -3 -p -r1.401 btree.c
--- src/btree.c 17 Aug 2007 16:50:38 -0000 1.401
+++ src/btree.c 17 Aug 2007 20:42:49 -0000
@@ -1403,8 +1403,8 @@ void sqlite3BtreeEnter(Btree *p){
assert( pLater->pNext==0 || pLater->pNext->pBt>pLater->pBt );
assert( !pLater->locked || pLater->wantToLock>0 );
if( pLater->locked ){
- sqlite3_mutex_leave(pLater->pBt->mutex);
pLater->locked = 0;
+ sqlite3_mutex_leave(pLater->pBt->mutex);
}
}
sqlite3_mutex_enter(p->pBt->mutex);
@@ -1427,8 +1427,8 @@ void sqlite3BtreeLeave(Btree *p){
p->wantToLock--;
if( p->wantToLock==0 ){
assert( p->locked );
- sqlite3_mutex_leave(p->pBt->mutex);
p->locked = 0;
+ sqlite3_mutex_leave(p->pBt->mutex);
}
}
}
Otherwise there would be corruption if there was a context switch just after sqlite3_mutex_leave to "if( p->locked ) return;" in sqlite3BtreeEnter() in another thread.
You might want to replace the u8's below with int's if you intend to read or write to them outside of a mutex:
struct Btree {
sqlite3 *pSqlite; /* The database connection holding this btree */
BtShared *pBt; /* Sharable content of this btree */
u8 inTrans; /* TRANS_NONE, TRANS_READ or TRANS_WRITE */
u8 sharable; /* True if we can share pBt with other pSqlite */
u8 locked; /* True if pSqlite currently has pBt locked */
int wantToLock; /* Number of nested calls to sqlite3BtreeEnter() */
Btree *pNext; /* List of Btrees with the same pSqlite value */
Btree *pPrev; /* Back pointer of the same list */
};
Reading from and writing to a non-machine word (i.e., not an int) variable outside of a mutex is not atomic or threadsafe. MIPS, for example, can only manipulate 32 bit values at a time and must use bit operations and shifting to get at individual characters. If you read a char value at the wrong time it may contain 0, 255 or some other value. |
2007-Aug-17 21:32:11 by anonymous:
These 3 values will likely be stored in the same 32 bit integer:
u8 inTrans; /* TRANS_NONE, TRANS_READ or TRANS_WRITE */
u8 sharable; /* True if we can share pBt with other pSqlite */
u8 locked; /* True if pSqlite currently has pBt locked */
Writing to any one of them outside of a mutex in a multithreaded situation can scramble the others' values.
2007-Aug-20 00:49:28 by drh:
Not a bug.
The Btree.wantToLock values are accessed under the sqlite3.pMutex
lock - or at least they will be once we get the new threading
implementation half way completed.
2007-Aug-20 05:17:47 by anonymous:
Helgrind is useful to find these sorts of multi-thread race conditions, as well as mutex deadlocks.
http://valgrind.org/docs/manual/hg-manual.html |
|
2577 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
5
|
5
|
Initilizing pointers to 0 instead of NULL.
|
edit |
Is it better to change all initilizations an comparisions of pointers
to NULL instead of 0 ? It is only cosmetic change but the code is then
more readable.
Bartosz
|
2007-Aug-17 18:15:16 by anonymous:
Why the ticket was rejected ?
If we have eg.:
....
*pId = 0;
..
what is *pId ?
Integer value or pointer to pointer ?
I know that name suggest that it is one level pointer
but why we can not make reading easier ?
Bartosz.
2007-Aug-17 19:48:01 by anonymous:
Changing 0 to NULL adds no value to the code. 0 is one character. NULL is four characters. Both are valid, but 0 is consistent and predictable on all platforms. NULL requires an #include to work, 0 does not. |
|
2576 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
1
|
1
|
Check-in [4239] mutex race conditions
|
edit |
Nevermind. I missed seeing SQLITE_MUTEX_STATIC_MASTER. |
|
2575 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
1
|
1
|
sqlite3_mutex_enter missing return
|
edit |
I know this is experimental #if'd out code, but nonetheless, sqlite3_mutex_enter is missing a return for the final else clause. |
|
2572 |
warn
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
1
|
1
|
Sqlitw error unrecognize token
|
edit |
Sqlite error unrecognize token |
The "is human" test needs to be improved.
2007-Aug-14 21:20:44 by anonymous:
wa? |
|
2571 |
todo
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
1
|
1
|
SQLite opening in Access
|
edit |
I am trying to open SQLite database through ODBC connections in Microsoft Access 2000. Some tables in Database have Primary key defined .
Steps followed:-
System DSN TestSQLite is created using Data sources(ODBC) 1)Open Blank access database named db1.mdb 2)Click on FIle->Get External data->Link tables 3)Select - ODBC databases in Files of type in Link Dialog 4)Select Machine data source TestSQLite=20 5)Select All Tables and click Ok 6)If table does not have Primary key ,getting dialog to select unique record identifier.
7)if Primary key is defined in table ,getting error Reserved error
(-7748) There is no msg for this error .
=20
I can open tables which does not have Primary Key and cannot use MSAccess to open SQLite database through ODBC (if the SQLite database has primary key defined) .
Thanks for your help. |
2007-Aug-13 21:23:54 by anonymous:
Install this sqlite odbc driver.
http://www.ch-werner.de/sqliteodbc/ |
|
2569 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
3
|
2
|
Executing a statement causes an AccessViolation Exception
|
edit |
Executing follwowing statement causes an AccessViolation Exception:
select being.bid, bname, bvalue, bsyncstatus, bvalid from being
where being.bid in (
select bid from searchidx_Campaign
where
(
campaign_status_id = 2 or campaign_status_id = 3
)
and id in (select campaign_id from searchidx_CampaignUserStatus
where user_id = 'b37dd383-3c82-4fe1-9285-d4c2bd6e4ca3'
and locked = 0))
I tracked the problem down to the 'campaign_status_id = 2 or campaign_status_id = 3' part of the statement. if an 'and' instead of the 'or' is used the Exception doesn't occur ('campaign_status_id = 2 AND campaign_status_id = 3').
It also doesn't matter if there is data in any of the used tables. The exception raises also with empty tables.
Used configuration:
Windows XP Professional SP2 -> all MS updates installed
.NET Framework 2.0 (2.0.50727.832) using c# |
2007-Aug-13 10:17:56 by anonymous:
It would be easier to reproduce if you provided the schema for the tables you use.
2007-Aug-13 14:59:11 by drh:
I created a schema that allowed the SQL statement to
compile and then ran the SQL on version 3.3.4 without
any problems.
Unable to reproduce. |
|
2564 |
event
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
anonymous
|
4
|
4
|
in C:\windows\temp are 50 files like sqlite_fMyj88gwaTTNgUF and 0 kb
|
edit |
in C:\windows\temp are 50 files like sqlite_fMyj88gwaTTNgUF and 0 kb
every day are more files , which program use these files
i cannot delete them with windows, clean up service
i deleted them in safe mode
they keep coming back and adding more files
i use windows xp home edition
and mcafee told me, it was not mcafee but a windows program
thank you for your time
jessica |
2007-Aug-10 12:18:32 by anonymous:
http://www.sqlite.org/cvstrac/wiki?p=McafeeProblem |
|
2563 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
1
|
1
|
sqlite3_column_database_name16() is broken
|
edit |
sqlite3_column_database_name16() does not work at all.
However I form my query, regardless of how many fields and in what order are returned in result, it always returns NULL for every single column. I'm using this code and it never returned anything but NULL:
if ( pStatement)
{
UINT32 cols = sqlite3_column_count( pStatement);
for ( UINT16 currCol = 0; !isDatabaseNameRetrieved && ( currCol < cols ); ++currCol )
{
const WCHAR *databaseName = static_cast<const WCHAR*>( sqlite3_column_database_name16( pStatement, currCol ) );
if ( databaseName && *databaseName )
{
*dbName = databaseName;
isDatabaseNameRetrieved = true;
}
}
}
When I stepped through the code I noticed that MEM_Null flag check in sqlite3ValueText() always fails (flag is always set):
static const void *sqlite3ValueText(sqlite3_value* pVal, u8 enc){
if( !pVal ) return 0;
assert( (enc&3)==(enc&~SQLITE_UTF16_ALIGNED) );
if( pVal->flags&MEM_Null ){ //<--- THIS CHECK IS ALWAYS TRUE
return 0;
}
|
2007-Aug-11 16:07:41 by drh:
The 35 separate test cases in capi3.test and capi3c.test that
call this routine all seem to function correction and return
non-NULL results.
Unable to reproduce.
2007-Aug-14 20:54:58 by anonymous:
Hmmm. It NEVER worked for me. If I have just main database opened it will return "main" but as soon as I attach another one it starts returning consistently returning NULL. I had the same problem with 3.3.17 and 3.4.0. |
|
2562 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
2
|
3
|
Multithreaded transactions deadlock (Windows)
|
edit |
Two threads connected to the same database/table and use transactions:
1. 1st thread: open db3-file
2. 2nd thread: open the same (second connection handle)
3. 1st thread: begin transaction
4. 1st thread: run multiple 'insert' statement
5. 2nd thread: begin transaction (successful return from call)
6. 2nd thread: want to 'insert' but blocked (as expected), start waiting on busy flag
7. 1st thread: last 'insert' was successfull
8. 1st thread: want to 'end' transaction, but blocked (sqlite3_step returns infinite SQLITE_BUSY, WHY?!)
9. 2nd thread: still blocked on first insert attempt
10. So, both threads can't continue execution.
Workaround: remove 'begin' and 'end' SQL statements from the code - and this works OK, but too slow. |
2007-Aug-10 04:13:37 by anonymous:
You might try BEGIN EXCLUSIVE. You lose parallelism, but it won't deadlock, and the code is simpler.
See also:
http://www.sqlite.org/capi3ref.html#sqlite3_busy_handler
"If SQLite determines that invoking the busy handler could result in a deadlock, it will return SQLITE_BUSY instead. Consider a scenario where one process is holding a read lock that it is trying to promote to a reserved lock and a second process is holding a reserved lock that it is trying to promote to an exclusive lock. The first process cannot proceed because it is blocked by the second and the second process cannot proceed because it is blocked by the first. If both processes invoke the busy handlers, neither will make any progress. Therefore, SQLite returns SQLITE_BUSY for the first process, hoping that this will induce the first process to release its read lock and allow the second process to proceed."
2007-Aug-10 11:36:32 by anonymous:
Yes, with 'begin exclusive' it works. |
|
2557 |
build
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
3
|
3
|
make test errors on Rhel4 x86_64
|
edit |
Hello there,
While building sqlite 3.4.1 rpms for Rhel4 on i386 and x86_64, I came across some inconsistent behaviour with "make test".
On Rhel4.5 i386, "make test" works fine.
However, on Rhel4.5 x86_64, "make test" has two errors which terminate the rpm build process.
rpmbuild -bb --with tcl sqlite.spec 2>&1 | tee build.log
.
.
printf-7.5... Ok
printf-8.1...
Error: integer value too large to represent
printf-8.2...
Error: integer value too large to represent
printf-8.3... Ok
.
.
Thread-specific data deallocated properly
2 errors out of 29903 tests
Failures on these tests: printf-8.1 printf-8.2
make: *** [test] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.97578 (%check)
My current workaround is to apply a patch which is only applied on x86_64 hardware. Again, thanks for your time and great software. |
2007-Aug-07 17:17:39 by drh:
Neither test is particularly important and both failures problem
result from bugs in either TCL or somewhere else in RH, not in
the SQLite core.
If you want me to look into this, please consider publishing your
patch. I have no way to reproduce the problem otherwise. |
|
2553 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
3
|
3
|
AUTOINCREMENT not working when primary key has multiple columns
|
edit |
There is one thing which I really miss in SQLite from mySQL, and that is that AUTOINCREMENT-ing does not work when the primary key has multiple columns. AUTO_INCREMENT-ing should work when the last column of the PRIMARY KEY is of type INTEGER. It should work as described in the second example here:
http://dev.mysql.com/doc/refman/5.0/en/example-auto-increment.html
In essence, the final column of the primary key gets a value of 1 greater than the largest value in that column where all the other values of the primary key's columns match those of the newly entered row.
Why is the useful? As an example, consider that bug reports are being made. The reports are updated. It would make sense for each update to be incrementally numbered within the particular bug that it belongs to.
Thanks for considering this,
Csaba Gabor from Vienna |
2007-Aug-05 17:38:39 by drh:
AUTOINCREMENT in SQLite works as it is documented to work
in SQLite. SQLite is not MySQL. |
|
2552 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
1
|
3
|
sqlite3_column_double causes invalid floating point operation
|
edit |
We have a table that has values inserted by a Delphi database provider. Using one tool, we can see values in the column as:
0
NULL
0.0
When using a different tool, or our .NET provider, conversion errors are generated. The conversion errors occur on the row that is stored as 0.0. The call stack seems to indicate that sqlite3_column_double is having a problem dealing with the value stored as 0.0.
Some of my report is based on third party information and I haven't personally confirmed all details. Let me know if you have further questions. |
2007-Aug-03 16:37:35 by anonymous:
It's likely a bug in the sqlite wrapper library you are using.
Post a small standalone C program that only calls the sqlite3 API directly to demonstrate the issue and re-open this ticket.
2007-Aug-03 20:19:20 by anonymous:
When viewing the data in the sqlite command line utility, it comes across as NaN. It appears that the problem is somehow on the input side. What's not clear is if the NaN was created before being bound to the database or if the NaN value was assigned by the database. |
|
2551 |
code
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
3
|
3
|
sqlite3 shell gets into bad state with unexpected input
|
edit |
The sqlite3 shell can get into a state that you cannot recover from without aborting the process. This happens fairly often on platforms without readline support.
- build sqlite3 without readline support.
- run sqlite3 in an xterm (or KDE konsole, probably other terminal programs)
- at the prompt, press cursor up (probably other 'illegal' characters would suffice as well).
- hit return
Nothing you do at this point will work except for Ctrl-\ to kill the process.
SQLite version 3.4.1
Enter ".help" for instructions
sqlite> ^[[A
...> .q
...> ;
...> select 1;
...> .q
...> .h
...> ;
...> ;
|
2007-Aug-03 15:00:30 by anonymous:
Try CTRL+D, worked for me.
2007-Aug-03 21:19:31 by drh:
The "[A" is the beginning of a quoted identifier. The
shell continues to issue the continuation prompt because
it is waiting on the "]" to terminate the identifier.
Your workaround is to type "];".
Works as designed. |
|
2549 |
build
|
closed
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
1
|
3
|
3.4.1 fails to upgrade from 3.3.1.7 on freeBSD
|
edit |
I use DesktopBSD (freebsd), and I was running the regular software upgrade using the Package Manager. This is the result:
./.libs/libsqlite3.so: undefined reference to `sqlite3Fts2InitHashTable'
gmake: *** [sqlite3] Error 1
*** Error code 2
Stop in /usr/ports/databases/sqlite3.
*** Error code 1
Stop in /usr/ports/databases/sqlite3.
** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade.64421.1 env DIALOG=/usr/local/bin/kdialog-ports-wrapper UPGRADE_TOOL=portupgrade UPGRADE_PORT=sqlite3-3.3.17 UPGRADE_PORT_VER=3.3.17 make
** Fix the problem and try again.
Regards,
Arthur |
This is a bug for the FreeBSD ports maintainers. |
|
2542 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
2
|
1
|
select 3/2 * avg(x) gives wrong result
|
edit |
Try this. It gives 2 but obviously the answer is 3 since the
average of 1,2,3 is 2 and multiplying that by 3/2 gives 3.
C:\tmp2>sqlite3
SQLite version 3.4.0
Enter ".help" for instructions
sqlite>
sqlite> create table tab (x num);
sqlite> insert into tab values (1);
sqlite> insert into tab values (2);
sqlite> insert into tab values (3);
sqlite> select * from tab;
1
2
3
sqlite> select sqlite_version(*);
3.4.0
sqlite>
sqlite> select 3/2 * avg(x) from tab;
2.0
|
2007-Jul-30 04:10:09 by anonymous:
Sorry, please ignore this one. I just released its doing
integer arithmetic. |
|
2541 |
doc
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
danielk1977
|
4
|
4
|
ALTER TABLE <foo> RENAME TO <bar> doesn't update (all) trigger schema
|
edit |
(This might be by design, I didn't see anything in the notes to this effect though).
ALTER TABLE <foo> RENAME TO <bar> doesn't update trigger schema correctly, for example:
sqlite> .sc
CREATE TABLE t1 ( c1 );
CREATE TABLE t2 ( c1 );
CREATE TRIGGER trg_1 after INSERT ON t1 begin insert into t2 select c1 from t1 where rowid=new.rowid ; end;
then
sqlite> alter table t1 rename to table1;
sqlite> .sc
[...]
CREATE TRIGGER trg_1 after INSERT ON 'table1' begin insert into t2 select c1 from t1 where rowid=new.rowid ; end;
So you can get errors like:
sqlite> insert into t1(c1) values('one');
SQL error: no such table: t1
|
2007-Jul-28 01:00:05 by anonymous:
That's not easy to fix. SQLite stores triggers, views, etc as strings in sqlite_master - not in its tokenized form.
You basically have to drop the trigger and recreate it.
2007-Jul-28 01:31:35 by anonymous:
I think you meant to write the following command after the table name was changed:
sqlite> insert into table1 values('one');
SQL error: no such table: main.t1
2007-Jul-30 02:52:13 by danielk1977:
You need to edit (i.e. drop and recreate) views and statements
executed by triggers externally. See the third paragraph here
("If the table being renamed..."):
http://www.sqlite.org/lang_altertable.html
|
|
2538 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
1
|
calling sqlite3_interrupt() randomly leaves db->ul.isInterrupted = 1
|
edit |
Using a sequence as follows, all invoked with sqlite3_exec():
BEGIN;
... long running script with many UPDATE/INSERT statements (with triggers firing, etc)...
sqlite3_interrupt() is called
Often (always?) the next sqlite3_exec call will also return SQLITE_INTERRUPT instead of SQLITE_OK. Apparently there is at least one point in sqlite execution that can be interrupted with sqlite3_interrupt() where db->ul.isInterrupted is not reset to 0, so the next sqlite3_exec() call also to returns SQLITE_INTERRUPT.
Since the documentation states that calling sqlite3_interrupt() will rollback any EXPLICIT transactions (why specifically EXPLICIT ?? - I would assume auto [IMPLICIT] transactions would obviously also rollback with a sqlite3_interrupt call), any subsequent action done on the sqlite instance should be SQLITE_OK (or the error specific to that action since the previous call has been fully aborted).
This behavior is definitely different than 3.2.8 (the version I am attempting to upgrade from), which works as expected. |
After much additional testing, I have concluded that this may actually have been due to my error (sqlite3_interrupt() being called again) and not due to sqlite. Sorry for the wasted bandwidth. Please consider the issue closed. |
|
2537 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
4
|
4
|
sqlite3_column_type() function problem.
|
edit |
Hi,
-I prepare a sql query statement ex: Select * from Table1.
-I want read some metadata from all fields of the result-set before fetch the first row with the function sqlite3_step(...).
-sqlite3_column_name(...), sqlite3_column_origin_name(...), sqlite3_column_table_name(...) are all Ok but sqlite3_column_type(...) returns for all columns -> 5 (NULL). After the first sqlite3_step(...) the type is correct for all columns. |
2007-Jul-25 23:07:25 by drh:
The type can vary from one row to the next.
Works as designed. |
|
2536 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Aug
|
|
2
|
3
|
Possible non-ID index corruption when max_page_count exceeded
|
edit |
Using 3.4.0 or 3.4.1 compiled for windows with -DMULTITHREAD, i seem to have a problem where sqlite3_step() will return SQLITE_ROW even when there are, in fact, no rows that meet the WHERE clause criteria. I'm currently attempting a reversion to 3.3.17 to see how it behaved.
create table file_data
( rod blob not null primary key /* always 20 bytes long based on a collision-resistant hash function */
, file_size integer not null
, compression_method integer not null
, the_data blob not null
);
sqlite3_prepare(..., "select file_size, compression_method from file_data where rod = ?");
sqlite3_reset(statement);
sqlite3_bind_blob(...,0, ptr, len);
sqlite3_step(...)
sqlite3_step returned SQLITE_ROW, which was my indication that the result set would be non-empty. So I construct a query_result(statement, bool at_end=false), and then execute
sqlite3_get_int64(..., first_column, null=-1)
and I get back -1. Before I was passing in null=-1 I was passing in =0, which was a permissible value for file_size.
** keep in mind that my exact sqlite3_api calls might be slightly different, since I have a C++ framework that isolates me from having to continually remember the same API calls. Suffice it to say this code worked (so far as I knew) under 3.3.17.
--andy
On further research, it appears to be related to max_page_count being exceeded during insertion of a row, leaving behind a primary key reference in the (primary key) index on the BLOB instead of being cleaned up during rollback. |
2007-Jul-25 17:38:38 by drh:
Unable to reproduce.
I am unable to make a lot of sense of the description above.
I have tried various tests setting a low max_page_count and
inserting BLOB-keyed entries into a table until the number
of pages overflow, then run sqlite3_step to see what happens.
Everything works correctly. I tried lots of different
combinations but never could get a failure.
2007-Jul-25 19:17:19 by anonymous:
MULTITHREAD is the wrong macro, but sqlite compilation defaults to threadsafe anyway.
How many threads are you running when this thing happens and what's your relationship of sqlite connections to threads? |
|
2534 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
danielk1977
|
2
|
3
|
sqlite3_set_auxdata may cause memory to be leaked
|
edit |
The routine sqlite3_set_auxdata() may cause memory allocated by the caller to be leaked.
Specifically, if the routine fails to allocate memory for its internal array of struct AuxData then the new argument data will not be stored. If the caller included an xDelete callback, this callback will not be stored or called in this circumstance.
Given that sqlite3_set_auxdata() does not return an indicator of success or failure, if the routine fails and a xDelete callback has been supplied then the callback routine should be executed before returning to the caller. |
Makes sense to me. |
|
2532 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
3
|
4
|
Endless loop in Parser?
|
edit |
After pasting the statement:
"
create trigger brandattribute_adtr after delete on brand_attribute for each row
begin
delete from customattributetype where customattributetype.customattributetype_id == old.customattributetype_id
end;
"
the Sqlite command prompt remains in ...> level. I don't know any solution to solve it except typing <Ctrl>-C.
It seems to be an endless loop in the parser. |
You need a semi-colon after the DELETE statement. Before "end;". |
|
2531 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
a.rottmann
|
1
|
1
|
Can't find head files in icu.c
|
edit |
/* Include ICU headers */
#include <unicode/utypes.h>
#include <unicode/uregex.h>
#include <unicode/ustring.h>
#include <unicode/ucol.h>
where can I find them?
thanks. |
2007-Jul-25 05:14:37 by danielk1977:
They are part of the ICU library distribution. You need ICU
installed to build the sqlite ICU extension.
http://icu-project.org/
|
|
2529 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
anonymous
|
1
|
1
|
Bug in sqlite3_prepare_v2( ) function
|
edit |
In Win 32 console All queries are working which include
"SELECT * FROM A WHERE col1 NOT IN ( -1, 6);"
"SELECT * FROM A WHERE col2 IN ( 0, 1, 2, 3 );"
where A is the table name, col1 is the column label, table values are entered correctly ( checked and verified )
These queries are working perfectly in sqlite3 command prompt and Win32 VC++ console
But are not working on Qualcomm chipsets, with REX OS
The position where it is returning error is
sqlite3_prepare_v2( ) |
2007-Jul-24 10:20:40 by drh:
OK, Vineethev, let's think this through. You admit that
everything is working prefectly on Win32 using the
sqlite3 command prompt and Win32 VC++ console. You
are reporting against SQLite version 3.3.13 which has
been used by thousands of thousands of people on diverse
systems without problems.
You further observe that the queries do not work
on Qualcomm chipsets on the REX operating system
(which is an OS I have never before heard of and
is certainly not directly supported by the SQLite
core team.)
In other words, everything appears to be working fine
everywhere except on Qualcomm chips and REX OS?
So what is it that make you think this is a bug
in SQLite in the sqlite3_prepare_v2() function and
not a bug in either the Qualcomm chips or REX OS or
your proprietary port of SQLite to that platform?
I am not making fun of you or dismissing your complaint.
My question is serious. Why do you think this is a bug
in SQLite and not someplace else? Think carefully about
that question and answer it as fully and carefully as you can.
Because unless you answer that question, there is very little that
I or anyone else can do to help you. |
|
2527 |
doc
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
4
|
2
|
sqlite3_create_module() API documentation missing
|
edit |
Documentation for sqlite3_create_module() is missing on page C/C++ API Reference. The same goes for new sqlite3_create_module_v2(). |
2007-Jul-24 10:06:33 by drh:
This is because the whole virtual table mechanism is still
considered highly experimental and subject to change. By
writing up an interface in the C-API documentation, we promise
to support it from now on. No such promises are made with
virtual tables. |
|
2519 |
new
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
Page cache and schema should be shared between all connections/threads
|
edit |
The current shared cache scheme is too restrictive to use easily in a multi-threaded application. The page cache should be shared between all connections/threads, as the database file itself is a global resource. If the schema is changed in one thread connection, all other thread connections should pick up the change automatically. Mutexes should be used for coordination as appropriate.
Advantages of thread-agnostic shared cache/schema approach:
- reduced memory use due to cache sharing in a multi-threaded/multi-connection program
- simpler usage model for multiple connections so that the programmer need not be concerned with what thread created the connection, or using starting a dummy transaction with an insert into a dummy table in order to keep the cache between transactions
- eliminate the schema/thread/connection mismatch problem #2486
- fewer system resources - use just a single file descriptor for multiple connections to the same database file, since it is a global resource. This would avoid file descriptor problems related to the Linux 2.4 kernel.
- improved concurrency for connections in multiple threads
|
2007-Jul-26 18:39:20 by anonymous:
the database file is a global resource, the sqlite handle is not.
imagine if you start a transaction in a thread then another thread start another transaction... if you use two sqlite handles, this is ok, because you can lock a file handle for the transactions.
since sqlite doesn't provide nested transactions, you should avoid thinking a sqlite handle object is a global resource. this is explicit well documented.
2007-Jul-26 19:49:57 by anonymous:
That's the problem with the current implementation. There is no need for multiple file descriptors to the same database file, since it is a global resource. There should be only a single file handle shared between all threads and connections. Access to this common file handle should be coordinated via proper mutexes between threads.
2007-Jul-26 20:11:09 by anonymous:
right again, neither ADO / SQL Server provider in ADO / Microsoft world suport a shared handle (connection object) properly. nobody implements this just because tx control should be done by program, not by database layer driver.
2007-Jul-26 20:19:24 by anonymous:
Whether there is 1 connection or 50 connections to the same database, the database file page cache, a global resource, must be the same in all cases. Don't confuse the page cache with a journal file.
2007-Jul-26 20:45:01 by anonymous:
suppose you have a main program and a shared library. the two linked static against a sqlite amalgamation, with different versions (e.g. 3.3.14 main program and 3.4.1 shared library).
if the pager cache internal structures changed against versions (which could happen), sqlite is going to be crazy and doing worst.
also, not all os platforms works like other in memory management.
they could have different memory virtual address (in windows, dll memory is protected from program memory if it uses the malloc allocator, with globalalloc things performs differently). since sqlite is multi-platform, it's not cool to put a per-platform feature.
a 'possible' (?) workaround is to use a per-process shared memory to implement this, but not all os'es sqlite compile and run may support it to implement this design.
2007-Jul-26 20:53:27 by anonymous:
The proposed in-process shared database page cache has nothing to do with virtual shared memory or shared libraries.
If the in-memory database change counter matches that of the locked database file, we can assume that the in-memory database page cache is current - regardless of whatever sqlite3 connection or thread we're on.
2007-Aug-10 20:33:49 by anonymous:
using the same file descriptor should not work.
locking engine in sqlite is file-locked base.
testing in a process within various threads if
you could lock a region of the file will not
work if sqlite is changed this way.
again, not usual and you should realize you can
use various sqlite versions inside the same program
using amalgamations.
2007-Aug-10 21:25:12 by anonymous:
Of course using a single file descriptor would work. There is only 1 underlying database file - why on earth do you need more than 1 descriptor to access it? That's what mutexes are for. Regarding putting multiple sqlite3 engines in the same binary, no one has ever done this before, as it was not even possible until 2 days ago (Ticket #2554). But if you wanted to support the old style multi-descriptor file locking, it could be done with an appropriate compile flag -DOMIT_SINGLE_FILE_DESCRIPTOR like every other feature in sqlite.
2007-Aug-10 23:36:34 by anonymous:
you didn't get the issue.
suppose (in my case), I have two DLL´s (shared libraries) that are linked statically against sqlite.
if I build a updated DLL with different versions of SQLite, e.g., 3.2.5 (on old dll´s) and 3.4.1 (on the updated dll), sqlite in-memory structures would not be the same layout (new fields, features, etc).
this is very dangerous in my point of view. I preffer paying the penalty reading from disk and keep things going smoothly.
2007-Aug-11 00:46:16 by anonymous:
Okay, keep it running smoothly.
2007-Oct-04 01:02:32 by anonymous:
Must manually enable shared cache via:
http://www.sqlite.org/capi3ref.html#sqlite3_enable_shared_cache |
|
2516 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
3
|
3
|
REGRESSION:sqlite3_prepare ignores nBytes parameter
|
edit |
Bug described as in Ticket #1554 reappeared in recent versions of sqlite (tested debian 3.3.8, and 3.4.0 built from release tarball).
Code snippet :
int rc = sqlite3_prepare( sqlite_
, "insert into JOB_TODO values (24, 1, 4, 'C', 'p', NULL, NULL, 'respawn', '/usr/bin/moma/mbx_selection 2 /tmp/select_pipe_ED2 300 600 \0', NULL, NULL );"
, 151, &stmt, NULL ) ;
Fails with error
unrecognized token: "'/usr/bin/moma/mbx_selection 2 /tmp/select_pipe_ED2 300 600 "
Looking at the code, we can find the related [3040]
CVS commit in prepare.c (as described in ticket #1554), but the bug still occurs |
2007-Jul-19 11:11:36 by anonymous:
sqlite_prepare_v2 has the same problem
2007-Jul-19 12:12:54 by drh:
The nBytes parameter is working fine. The problem is that SQLite
does not accept strings that contain embedded \0 characters. And
this is not going to change.
If you want to insert a string that contains an embedded \0,
use ? for the string in sqlite3_prepare() then bind the
string using
sqlite3_bind_text(). |
|
2515 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
1
|
Entered to ASCII zeros as a text string was return a single zero.
|
edit |
I have created a Schema that defines all but one column as a string. When I insert data that is defined as '00', '06', '05', etc. I receive no error for the insertion. But, when I retrieve the data it returns the data with the preceeding zero removed. This should not occur when the data is defined as a string and not defined to be of a numeric type.
This does not occur for any other type string data. |
2007-Jul-18 21:47:55 by drh:
Here's what I get:
CREATE TABLE t1(x TEXT);
INSERT INTO t1 VALUES('00');
SELECT * FROM t1;
00
Unable to reproduce the problem. |
|
2513 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
2
|
Internal compiler error tclsqlite.c
|
edit |
Using make with Windows XP with MSYS and MinGW 3.4.5 after
./configure --with-tcl=C:/dev/Tcl/lib
produces this error
./src/tclsqlite.c: In function 'Sqlite3_Init':
./src/tclsqlite.c:2421: internal compiler error: in rest_of_handle_final, at toplev.c:2067
Robert Wishlaw |
2007-Jul-17 20:30:28 by drh:
Seem like an "internal compiler error" is the type of thing you
should report to the compiler vendor, not to the makers of the
code you are trying to compile.... |
|
2505 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
1
|
does not return error when use sqlite_open to open an non-sqlite db
|
edit |
I use sqlite_open api to open an non sqlite database, for example an exe file.The result of sqlite_open is not an error code but sqlite_ok. |
Sqlite does not actually read the database file until the
first SQL query is executed. So the sqlite3_open succeeds
but the first call to sqlite3_prepare_v2() or sqlite3_exec()
will return an error. |
|
2504 |
build
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
1
|
sqlite 3.4.0 fails to build FreeBSD 6.2 64-bit system
|
edit |
Attached is the configure and make output. As this is a FreeBSD 6.2 AMD 64-bit box, several "warning: cast from pointer to integer of different size" in func.c, table.c, and vdbemem.c concern me as potential bugs. Added to the fact the the undefined reference to __isnanl.
The warnings also appear in 3.3.17 version of SQLite, which I hadn't noticed before, but the there was no undefined reference preventing the build. |
2007-Jul-13 17:13:47 by anonymous:
submitter: anthony howe, achowe@snert.com
2007-Jul-13 17:34:33 by drh:
Already fixed by check-in [4103]
. |
|
2501 |
build
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
2
|
3
|
limits.h confilct with visual studio limits.h
|
edit |
When I include sqlite3.h in my code, and provide the sqlite headers folder to complier include path, limits.h is picked up from sqlite headers even when it must be picked from vc/include, so I get errors compiling other files that we compiling fine.
Current workaround is I provide the parent folder of sqlite headers as include path for compiler and instead of #include "sqlite3.h", I do a #include "sqlite-3.4.0/sqlite3.h" |
2007-Jul-12 20:39:41 by drh:
See tickets #2428 and #2495. |
|
2500 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
2
|
4
|
Possible memory leak on avr32 arch
|
edit |
I am using sqlite in a C written application running on an embedded device based on an avr32 (the 32AP7000) from atmel.
It seams that executing some insertion cause a memory leak.
The simpliest leaking code is something like this :
(The complete code include error check, error messages freeing, and non-infinite loop.)
int main(int ac, char **av)
{
sqlite3 *db;
char *zErrMsg = 0;
sqlite3_open(DB_PATH, &db))
while (42)
sqlite3_exec(db, "INSERT INTO high (io1) VALUES (1);"
NULL, NULL, &zErrMsg));
sqlite3_close(db);
return 0;
}
I've tested with both sqlite3.4.0 and 3.3.6-94 binaries.
Based on the tests i have done the amount of memory leaking depends on the number of row in the table and the size of the sql statement
It also seems that a 'SELECT' sql statement does not leak at all.
It also appear that some of the leaking memory is never returned to the system.
I suppose that the problem is somewhere between the sqlite memory management system and the device's one.
I still can not tell for sure if the problem lie on the sqlite or the board but i have successfuly ported some heavy memory consumer without experiencing such problems.
Maybe the software shiped with my board don't have default behavior for some memory managment tasks and cause sqlite not to act as it should ?
I am actually working on getting some more informations on how and where it leak. (porting valgrind, dmalloc or something) So i will try to provide some more information as soon as i can. |
Maybe you can look at the contents of zErrMsg first?
2007-Jul-13 08:16:37 by anonymous:
I've already checked zErrMsg and freed it if necessary.
2007-Jul-13 08:57:59 by anonymous:
Sorry i didn't understand i am focussed on "where is my memory" :).
If you meens to check what error happen, then i don't get any errors everything goes fine and return is SQLITE_OK. The comportement is good exept that the data segment of a program doing multiple inertions keep growing.
2007-Jul-13 13:37:06 by anonymous:
Some fresh news.
First the memory leaked seems to be correctly freed when the process done, it was my misunderstanding.
Next doing a quick wrapper around sqlite3GenericFree and sqlite3GenericMalloc i found something interristing :
Each time i am doing an insert some of the memory allocated wont be freed untill calling sqlite3_close, which cause the process to grow.
Since the sqlite malloc mecanism is pretty dark to me i still don't understand how such a behavior happen.
2007-Jul-16 13:50:17 by danielk1977:
Because sqlite3_close() does free the possibly leaked allocations,
we can probably assume this is just the pager cache growing
normally. See the documentation for the "cache_size" pragma
for details. |
|
2497 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
4
|
2
|
sqlite3_errcode does not return the proper error code
|
edit |
sqlite3_errcode does not return the same result as the last api call when using a progress handler that aborts the connection. sqlite3_step returns SQLITE_ABORT, but sqlite3_errcode is returning SQLITE_ERROR.
A test case can be found here:
https://bugzilla.mozilla.org/attachment.cgi?id=271753
Downstream bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=387609
-sdwilsh |
2007-Jul-11 06:37:52 by danielk1977:
When it comes to setting the database error code, sqlite3_step()
behaving the same way regardless of whether sqlite3_prepare() or
sqlite3_prepare_v2() is used to prepare the query.
So when an error is returned from sqlite3_step() on a statement
prepared with _v2(), the "real" error code is returned but the
database error code is being set to SQLITE_ERROR. I'm thinking
we should change to set the database error code and message
to the "real" error code in this case.
Also, note that this test-case is incompatible with version 3.4.0.
In prior versions, if the progress-handler returns non-zero,
the statement is halted and SQLITE_ABORT is returned. In 3.4.0,
this error code is now SQLITE_INTERRUPT.
2007-Jul-12 16:35:37 by anonymous:
Thanks for the heads up.
-sdwilsh |
|
2495 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
4
|
4
|
standard C library Naming conflict - limits.h
|
edit |
"limits.h"
You should really avoid using filenames conflicting with the standard C library. It took me a few minutes to figure out why my code was not compiling. Then I realized that <limits.h> was resolving to the SQLITE header.
Best Wishes,
-David Delaune
Software Engineer
Marine Technologies, LLC |
oops, I just found this issue was corrected in ticket 2428. Closing the ticket.
-David Delaune |
|
2494 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
1
|
DRow["ID"] = reader.GetString(reader.GetOrdinal("ID")); fails
|
edit |
DRow["ID"] = reader.GetString(reader.GetOrdinal("ID"));
This fails under Vista Ultimate, succeeds under XP Pro. It is Sqlite 3.1, will upgrading help?
Thanks! Jim |
Please post your question to the author of the sqlite wrapper for whatever language you're using. |
|
2493 |
build
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
2
|
3
|
Fails to build under GCC-4.1.3 on FreeBSD-6.2
|
edit |
OS: FreeBSD-6.2
When using the build-in gcc 3.4.6 [FreeBSD] 20060305, sqlite3, version 3.3.17 builds fine.
However, when using gcc 4.1.3 20070618, sqlite3 version 3.3.17 fails to build.
A copy of the failed build attempt is attached. |
2007-Jul-09 13:23:38 by anonymous:
===> Applying FreeBSD patches for sqlite3-3.3.17
Your SQLite sources have apparently been modified for FreeBSD.
This is a question for the BSD port system maintainers or simply google "unable to infer tagged configuration" where you will find many workarounds for your operating system.
libtool: link: unable to infer tagged configuration
libtool: link: specify a tag with `--tag'
gmake: *** [libsqlite3.la] Error 1
*** Error code 2
Stop in /usr/ports/databases/sqlite3.
2007-Jul-21 19:58:11 by anonymous:
This is a libtool bug that happens when the C compiler you're using is not named 'gcc'.
As a workaround in your case:
CC=/usr/local/bin/gcc41 ./configure
make
Above command assumes bash shell.
Use appropriate construct for other shells. |
|
2492 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
4
|
4
|
Incorrect protoype for function sqlite3_result_zeroblob
|
edit |
Line 1859 in sqlite3.h and line 1882 in sqlite3.c
void sqlite3_result_zeroblob(sqlite3_context*, int n);
should read
void sqlite3_result_zeroblob(sqlite3_context*, int); |
|
2490 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
Latest cvs 3.4.0 seg fault
|
edit |
This problem is the same with 3.3.1.13, Fedora's 3.4.0 and the
debug version I just built.
Using latest Fedora and perl modules:
net1#r mx
mxaddrs ...
perl : 5.8.8
DBI : 1.58
DBD::SQLite : 1.13
SQLite::DBMS: 3.4.0.1
Code is simple db create and inserts. Problem only occurs when
a DBI sth->prepare() is used with multiple execute inserts of
duplicate data. Instead of returning an error seg fault occurs.
If required I can try and put together a small code sample. |
2007-Jul-07 06:25:54 by anonymous:
Why do you think its pure SQLite problem ?
2007-Jul-07 11:46:55 by drh:
To amplify the remark by anonymous above: what makes you
think this is a problem with SQLite and not a problem with
perl or the DBD::SQLite module? We have run literally millions
of test cases through the core SQLite without hitting any
segfaults, yet you say that a simple test case is sufficient
to cause the problem. That would seem to implicate DBD::SQLite
rather than the SQLite core, would it not? Please tell us why
you think this is an SQLite problem. And please also provide
us with a reproducible test case, keeping in mind that the
core SQLite developers do not normally have DBD::SQLite installed.
2007-Aug-10 15:18:32 by anonymous:
This is a DBD::SQLite bug. See
http://rt.cpan.org/Public/Bug/Display.html?id=28757
for a test case and a patch.
Mike |
|
2489 |
build
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
1
|
Latest cvs 3.4.0 make test fails related to TCL
|
edit |
Here's how I'm building.
I've tried --disable-tcl and --enable-tcl with no joy.
I'm using latest Fedora 7 with tcl-8.4.13 installed.
mkdir -p /build/work/sqlite-3.4.0.1
cd /build/work/sqlite-3.4.0.1
unset CDPATH
export CFLAGS='-pipe -O3 -g'
make distclean
cvs -d :pserver:anonymous@www.sqlite.org:/sqlite -r update .
./configure --prefix=/usr/local/pkgs/sqlite-3.4.0.1 --disable-tcl
make
groupadd vuser || /bin/true
useradd -M -g vuser -d /vhost/davidfavor.com/users/david -s /bin/zsh david || /bin/true
useradd -M -g vuser -d /vhost/livefeast.com/users/yemiah -s /bin/zsh yemiah || /bin/true
chown david:vuser -R .
su -c "make test" david
/build/work/sqlite-3.4.0.1/./src/tclsqlite.c:2416: undefined reference to `Tcl_CreateObjCommand'
/build/work/sqlite-3.4.0.1/./src/tclsqlite.c:2417: undefined reference to `Tcl_PkgProvide'
/build/work/sqlite-3.4.0.1/./src/tclsqlite.c:2418: undefined reference to `Tcl_CreateObjCommand'
... hundreds of errors deleted ...
|
"make test" requires Tcl to function.
Post the result of "grep -i tcl config.log" after you run ./configure with no arguments. The key to it working is finding tclConfig.sh
configure:19220: checking for Tcl configuration
configure:19302: result: found /usr/lib/tclConfig.sh
configure:19305: checking for existence of /usr/lib/tclConfig.sh
ac_cv_c_tclconfig=/usr/lib
HAVE_TCL='1'
TCL_BIN_DIR='/usr/lib'
TCL_INCLUDE_SPEC='-I/usr/include/tcl8.4.13'
TCL_LIBS='-ldl -lpthread -lieee -lm'
TCL_LIB_FILE='libtcl8.4.so'
TCL_LIB_FLAG='-ltcl8.4'
TCL_LIB_SPEC='-L/usr/lib -ltcl8.4'
TCL_SRC_DIR='/usr/include/tcl8.4.13'
TCL_STUB_LIB_FILE='libtclstub8.4.a'
TCL_STUB_LIB_FLAG='-ltclstub8.4'
TCL_STUB_LIB_SPEC='-L/usr/lib -ltclstub8.4'
TCL_VERSION='8.4'
2007-Jul-07 03:49:21 by anonymous:
Ah I see now. I'm using a 64 bit machine so tcl lives in the 64 bit
directory hierarchy.
Here's how I got most of the tests to run:
export CFLAGS='-pipe -O3 -g -DSQLITE_DISABLE_DIRSYNC=1 -Wall'
make distclean
cvs -d :pserver:anonymous@www.sqlite.org:/sqlite -r update .
./configure --prefix=/usr/local/pkgs/sqlite-3.4.0.1 --enable-tcl --with-tcl=/usr/lib64
This ticket can close. I'll do some further testing and open another
ticket about the single thread test that fails.
2007-Jul-07 11:43:05 by drh:
Please note that this is an open ticketing system. Anybody
can close a ticket. You do not need to ask me or Dan to do it. |
|
2486 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Sep
|
|
2
|
3
|
pragma index_list does not detect index created on 2nd connection
|
edit |
Open two connections to the same database. On the first connection, create a table "test" and an index on that table. On the second, run "pragma index_list( test )".
Expected result: pragma detects the previously-created index.
Actual result: no index is detected.
Test case to follow. |
2007-Jul-05 20:02:25 by anonymous:
#include "sqlite3.h"
#include <boost/test/auto_unit_test.hpp>
extern "C" int IsIndexCreatedCallback( void* p, int, char**, char** )
{
*(bool*)p = true;
return 0;
}
BOOST_AUTO_TEST_CASE( SQLiteTest )
{
sqlite3* sqlite1;
int result = sqlite3_open( "test", &sqlite1 );
sqlite3* sqlite2;
result = sqlite3_open( "test", &sqlite2 );
result = sqlite3_exec( sqlite1, "create table test ( id integer )", 0, 0, 0 );
bool exists = false;
result = sqlite3_exec( sqlite2, "pragma index_list( test )", IsIndexCreatedCallback, &exists, 0 );
BOOST_CHECK( !exists );
result = sqlite3_exec( sqlite1, "create index ix on test ( id )", 0, 0, 0 );
exists = false;
result = sqlite3_exec( sqlite2, "pragma index_list( test )", IsIndexCreatedCallback, &exists, 0 );
BOOST_CHECK( exists );
}
2007-Jul-05 20:18:10 by anonymous:
Can reproduce with 3.4.0 using two sqlite3 processes.
I found that if you execute "select * from sqlite_master" from the second sqlite3 commandline shell, then pragma index_list on the 2nd connection will correctly show the indexes for some reason.
2007-Jul-05 21:12:32 by drh:
The first connection does not know that an index has been
created on the second connection until it attempts to
access the database.
2007-Jul-05 21:17:36 by anonymous:
Same problem with connection 1 executing ALTER TABLE ADD COLUMN and connection 2 executing PRAGMA table_info(table-name). I suspect the following PRAGMAs must always read() the database's file change counter and if it changed then reset the cached schema before proceeding:
PRAGMA foreign_key_list(table-name);
PRAGMA index_info(index-name);
PRAGMA index_list(table-name);
PRAGMA table_info(table-name);
2007-Jul-05 21:37:12 by anonymous:
Does the comment on 2007-Jul-05 21:12:32 imply this behavior is by design?
2007-Jul-06 11:31:55 by drh:
Yes.
2007-Jul-06 15:38:07 by anonymous:
That's understandable. This ticket can be fixed with documentation. Can you recommend the most efficient/quickest way to force SQLite to reload the schema in memory from a library user's point of view?
SELECT 0 from _dummy_table_
SELECT 0 from sqlite_master where 1=0
?
2007-Jul-06 15:41:37 by anonymous:
Would a new pragma for this purpose be out of the question?
PRAGMA force_schema_reload;
2007-Jul-06 16:57:56 by anonymous:
I can appreciate seperate processes' in-memory schema not being automatically updated when another process changes the schema or adds a new index. But it does not make sense that another connection in the same process is not flagged to automatically update their in-memory schema prior to executing one of these PRAGMAs being issued. It's just a matter of checking an integer change counter in memory for each connection on the same database.
2007-Jul-06 18:22:18 by anonymous:
SELECT 0 from sqlite_master where 1=0 doesn't work. SELECT 0 from sqlite_master does.
Can you elaborate on the reason for this design decision?
2007-Jul-06 18:55:04 by anonymous:
I was just looking for the fastest executing SELECT statement I could find that would force a reload of all schema from the file. Perhaps something like this?
select null from sqlite_master limit 1
I'm pretty sure trying to query a non-existant table also has the side-effect of reloading the entire schema.
-- force a re-load, and ignore the error
SELECT a from _non_existant_table_
I just don't know which one's faster. It would be better to have a standard way of doing this.
2007-Jul-11 21:08:14 by anonymous:
Doing a select against a non-existent table will fail without reloading the schema. At least in my independent discovery of this problem that didn't resolve things...
2007-Jul-20 06:25:14 by anonymous:
Would a schema change (add index) in one connection affect the other connection as it goes to insert into the table without knowing that the index has been added? And result in incomplete index contents?
2007-Jul-26 18:42:06 by anonymous:
the greatest way to solve this is reloading the db metadata when you issue a pragma command, like pragma index_list or other.
i thought this will be great.
also, database header has a version to detect SQLITE_SCHEMA changes. why pragma commands doesn't honor this ?
2007-Aug-22 19:09:28 by anonymous:
related ticket: #2519
2007-Sep-04 20:10:24 by anonymous:
Fixed in 3.5.0 (*)
#include "sqlite3.h"
#include <stdio.h>
#include <assert.h>
#include <unistd.h>
int mycb(void* p, int nCol, char** azVals, char** azCols) {
int i;
*(int*)p = 1;
printf("mycb: ");
for (i = 0; i < nCol; i++) {
printf("%s = %s, ", azCols[i], azVals[i]);
}
printf("\n");
return 0;
}
int main() {
const char* dbname = "schemachange.db";
sqlite3* sqlite1;
sqlite3* sqlite2;
int exists;
int result;
sqlite3_enable_shared_cache(1); /***** line necessary for it to work ****/
unlink(dbname);
result = sqlite3_open(dbname, &sqlite1);
assert(result == SQLITE_OK);
result = sqlite3_open(dbname, &sqlite2);
assert(result == SQLITE_OK);
result = sqlite3_exec(sqlite1, "create table t(id integer)", 0, 0, 0);
assert(result == SQLITE_OK);
exists = 0;
result = sqlite3_exec(sqlite2, "pragma index_list(t)", mycb, &exists, 0);
assert(result == SQLITE_OK);
result = sqlite3_exec(sqlite1, "create index ix on t(id)", 0, 0, 0);
assert(result == SQLITE_OK);
exists = 0;
result = sqlite3_exec(sqlite2, "pragma index_list(t)", mycb, &exists, 0);
assert(result == SQLITE_OK);
assert(exists);
return 0;
}
(*) It seems that sqlite3_enable_shared_cache(1) is required.
What's the downside in making this the default behavior?
It seems like a win/win from a memory usage and schema change detection point of view. |
|
2485 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
2
|
SQLite + Python segfaults at various places in the code
|
edit |
I've been getting segfaults while running unit tests on my code base (http://drproject.org). It is written in Python and uses SQLAlchemy for database abstraction. I believe the Python module is PySQLite2.
After taking some core dumps, they all seem to point to SQLite code (but different parts each time).
Another guy I'm working with is having similar problems with some code he is working on.
I have run memtest over night (turning up nothing), so I don't think it's my machine.
I am not sure what would be most helpful for you, so before I start throwing around 20 meg core dumps, I thought I'd check and see what you would prefer. |
2007-Jul-04 17:05:32 by anonymous:
Try the mailing list as your problem is not pure SQLite problem.
2007-Jul-05 06:25:40 by danielk1977:
If it's different places in the code each time, this really sounds
like a corrupted heap. It may be that it is SQLite corrupting the
heap, or it may be the wrapper code. Posting to the mailing list
is probably the best way to progress this.
2007-Jul-05 13:02:35 by anonymous:
Setting up and learning the inner workings of another computer language and third party wrappers requires a lot of effort. You greatly increase your odds of finding the source of your bug if you make a small standalone C or Tcl program that demonstrates the problem using only the SQLite API. This eliminates the possibility that the host language or wrapper is corrupting memory or doing something else wrong. Often in the process of creating such a standalone test case, people find their own mistake. |
|
2483 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
3
|
like clause not working
|
edit |
while using the Trac SCM tool I've experienced some issues with the database usage of the like clause in certain select statements.
with values for name such as 'TracIni', 'TracBrowser', 'TracFqastCGI' the following quert does not catch any of the above names:
SELECT name FROM wiki WHERE name like 'Trac';
seems to be that this should catch it. |
2007-Jul-04 03:56:32 by anonymous:
To catch the terms you are looking for, wouldn't you need this query:
SELECT name FROM wiki WHERE name like 'Trac%' |
|
2482 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
3
|
4
|
Possible optimizer bug
|
edit |
The versions I have tested are 3.3.5 and 3.4.0.
Here you see the same query four times with different table ordering and sometimes an additional OR clause. The queries are executed on an ARM device, but I observed the same behavior on x86.
I know that the table ordering makes a difference in query execution time but I'm rather puzzled by the behavior I get here. The "OR 0" doesn't make much sense to me, it was coincidence that I discovered it.
- The query as intended, this takes a rather long time:
"select pr_value from property join item_prop on ip_prop=pr_id where ip_item=1049545 and ip_visible=1 and pr_class=4"
Executed once: 127 ms
Executed 10 times: 264 ms
- The same as above but I added a "OR 0" which shouldn't change anything. The same query is now much faster:
"select pr_value from property join item_prop on ip_prop=pr_id where ip_item=1049545 and ip_visible=1 and (pr_class=4 OR 0)"
Executed once: 4 ms
Executed 10 times: 30 ms
- The same query as 1. but with exchanged table order:
"select pr_value from item_prop join property on ip_prop=pr_id where ip_item=1049545 and ip_visible=1 and pr_class=4"
Executed once: 3 ms
Executed 10 times: 28 ms
- Added an additional "OR 0" to 3. This is now slower than the previous:
"select pr_value from item_prop join property on ip_prop=pr_id where ip_item=1049545 and ip_visible=1 and (pr_class=4 OR 0)"
Executed once: 3 ms
Executed 10 times: 32 ms
The tables used:
create table property (
pr_id integer primary key,
pr_value text,
pr_class int
);
create index pr_idx1 ON property(pr_id);
create index pr_idx2 ON property(pr_value COLLATE NOCASE);
create index pr_idx3 ON property(pr_class);
create table item_prop (
ip_item int,
ip_prop int,
ip_visible int default 1
);
create index ip_idx2 ON item_prop(ip_item);
create index ip_idx3 ON item_prop(ip_prop);
|
2007-Jul-02 16:01:24 by drh:
Thank you for taking the time to learn enough about the wiki
formatting rules to format the problem description so that it
is easily readable!
We do not normally consider a problem to be a "bug" if it
gets the correct answer, even if the answer takes longer than
you want to obtain. My understanding is that all of the queries
above return the correct answer and you just want them to go
faster. This is not a bug. For help in optimizing your
queries, please post on the sqlite mailing list. Instructions
for subscribing to the mailing list can be found at
You will probably get better results in this case if you
do one or both of the following:
- Drop the pr_idx3 index.
- Run the ANALYZE command.
2007-Jul-02 20:55:18 by anonymous:
Yes, they actually work as expected. Thanks for the hints.
The actual reason why I posted this ticket is the weird improve in performance by adding a "OR 0" which doesn't change anything on the query itself. Everything is the same except for this no-op condition.
If the optimizer would do such a thing by default (whatever it is that it does) then this could possibly improve the sqlite performance in other scenarios as well. |
|
2481 |
code
|
closed
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
3
|
sqlite leaks memory (after 3.3.13)
|
edit |
After upgrade from 3.3.12 to 3.4.0 I noticed an huge negative impact on memory usage of my SQLite-based programs. I suspected a bug in my code. After some debugging, I created a simple program and narrowed this down to the following:
- this started from 3.3.14 and is still relevant for 3.4.0
- 3.3.13 was the last version which "worked" as expected
Attached is a sample program which demonstrates the problem. sqlite3 command utility exhibits the same increase and the same memory usage patterns.
Basically, what happens is that memory allocated by SQLite is first released after call to sqlite3_close(). It seems like the memory usage will eventually "stabilize" and only increase again in smaller chunks.
This is on OpenBSD 4.1/i386.
ssehic@dev-5-i386:/profense/devel$ ls -l /profense/log/logdata.db
-rwxrwxr-x 1 _admd profense 12106752 Jul 1 23:15 /profense/log/logdata.db
ssehic@dev-5-i386:/profense/devel$ sqlite3 /profense/log/logdata.db "select count(*) from log"
156000
ssehic@dev-5-i386:/profense/devel/sqlmem
SQLite version 3.3.13
Usage (bytes) initial, rssize=487424, dsize=241664
Usage (bytes) after SELECT COUNT(*), rssize=1417216, dsize=704512
Usage (bytes) after sqlite3_close, rssize=1318912, dsize=618496
ssehic@dev-5-i386:/profense/devel/sqlmem
SQLite version 3.4.0
Usage (bytes) initial, rssize=495616, dsize=241664
Usage (bytes) after SELECT COUNT(*), rssize=22118400, dsize=21331968
Usage (bytes) after sqlite3_close, rssize=1351680, dsize=618496
I'm sure something like this should not go unnoticed by the developers. However, I can't believe this is specific to OpenBSD. Something changed after 3.3.13 which broke this in a subtle way.
Any hints? |
2007-Jul-01 23:03:42 by drh:
Your test program appears to be OpenBSD-specific. I cannot compile
it on Linux. So I cannot replicate your problem.
We do test SQLite using both its own internal memory leak
detection logic and valgrind, and both report no memory
leaks over the entire test suite.
2007-Jul-02 07:31:57 by anonymous:
Yes. The test program is OpenBSD specific, but only the memory reporting stuff (print_memory_usage()). I'll see if I can provide a Linux variant and complete details on how to reproduce the problem.
More to come.
2007-Jul-02 09:28:42 by anonymous:
I think I figured this one out. The problem is only reproducible if the database is created using sqlite3 prior to 3.3.14 and queries are later run on the same database using 3.4.0.
This is weird, since the database format should be backwards compatible between releases. However, lots of "performance improvements" went in after 3.3.13. This could have something to do with it.
At http://insecure.dk/bin/logdata.db.gz is a test database created with 3.3.12. If you run a "SELECT COUNT(*) FROM log" on that using 3.4.0, you should see the memory usage increase greatly using sqlite3 utility.
2007-Jul-02 10:38:12 by anonymous:
This ticket can be closed. Increased memory usage is due to my test database (created with 3.3.12) used PRAGMA default_cache_size = 10000;
Apparently versions > 3.3.14 allocate all the memory on the first database query. That's why I saw the jump in memory usage.
Sorry for the noise.
2007-Jul-02 10:38:41 by drh:
I downloaded logdata.db from the link above and ran
"SELECT count(*) FROM log" against it using the latest
version of SQLite from CVS (which i closer to 3.4.1 than
to 3.4.0, I suspect). I did this using valgrind:
valgrind --leak-check=full --show-reachable=yes \
./sqlite3 logdata.db 'select count(*) FROM log'
Valgrind tells me that 156 bytes of memory were leaked in
11 allocations. All of the leaked memory was allocated
by the getpwuid_r() function in glibc - not from SQLite.
The total memory allocated was 13,515,680 bytes, which
considering that the logdata.db database specifies a
cache size of 10,000 pages and you are reading (and thus
attempting to cache) the entire 50MB database, this is
about what one would expect.
I am unable to reproduce the problem.
2007-Jul-02 10:50:40 by anonymous:
That was my conclusion as well. Thanks again for the great work and unbelievably speedy responses to "bug" reports. |
|
2480 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Aug
|
|
4
|
4
|
typo in faq.tcl
|
edit |
--- a/www/faq.tcl
+++ b/www/faq.tcl
@@ -202,8 +202,8 @@ faq {
threads. The <b>sqlite3</b> pointer must only be used in the same
thread in which it was created by
<a href="capi3ref.html#sqlite3_open">sqlite3_open()</a>. If you
- break the rules and use an <b>sqlite3</b> in more than one thread
- under these circumstances, then you will likely corrupt some
+ break the rules and use an <b>sqlite3</b> pointer in more than one
+ thread under these circumstances, then you will likely corrupt some
internal data structures resulting in a crash.</p>
<p>Under UNIX, you should not carry an open SQLite database across
|
|
2478 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
2
|
2
|
LIMIT and OFFSET abbreviation to LIMIT x,y bug!
|
edit |
Statement taken from Apress: The Definitive Guide to SQLite:
SELECT * FROM foods WHERE name LIKE 'B%'
ORDER BY type_id DESC, name LIMIT 1 OFFSET 2;
can be expressed equivalently with
SELECT * FROM foods WHERE name LIKE 'B%'
ORDER BY type_id DESC, name LIMIT 1,2;
SQLite3 3.4.0 bug - The parameters after LIMIT have been reversed in the implementation of this version of SQLite in error!... 2 tuples from the database are returned (LIMIT) and starting from the OFFSET 1 instead of the other way around, 1 tuple starting at offset 2. |
From the documentation for SELECT:
Note that if the OFFSET keyword is used in the LIMIT clause, then
the limit is the first number and the offset is the second number.
If a comma is used instead of the OFFSET keyword, then the offset
is the first number and the limit is the second number. This
seeming contradition is intentional - it maximizes compatibility
with legacy SQL database systems.
SQLite has always been this way. It's a bug in the book.
2007-Jun-29 11:49:02 by drh:
As an historical curiosity, see ticket #245. |
|
2472 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
1
|
smart quotes turning question marks while storing in oracle 9i DB
|
edit |
whenever end-user copy & paste the statement from the word which contains smart quotes into the java application and submit, it stores in the oracle 9i database. But the smart quotes are getting converted into question mark (?) / reverse question mark symbol. Kindly tell me the solution.
Environment:
Java 2.0,Jrun 4.0, Oracle 9.2.0.1.0 |
Where does SQLite figure into the system? |
|
2471 |
secure
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
1
|
a bug for 64 bit driver under operation system
|
edit |
Firstly,I can't find a 64bit driver just like a.so file under the specail system Unix/Linxu.
Secondly,I find a drvier writen by java,but it has many problem while multi threads operate the database.
Sometimes I lost all of my data.
Can you offer a 64bit driver under Unix/Linux in your website? |
This is probably better discussed on the mailing list.
Any bugs in a java wrapper (which one) can be figured out there too. |
|
2463 |
todo
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
anonymous
|
1
|
1
|
Crash after calling sqlite_close() if SQLITE_ENABLE_MEMORY_MANAGEMENT
|
edit |
Hi
I am using SQLITE amalgamated code to build sqlite static lib which is linked to my code.
All the sqlite queries are handled in separate thread.
So when the application shuts down, sqlite_close() is called.
Following section is executed in sqlite_close()
for(j=0; j<db->nDb; j++){
struct Db *pDb = &db->aDb[j];
if( pDb->pBt ){
sqlite3BtreeClose(pDb->pBt);
pDb->pBt = 0;
if( j!=1 ){
pDb->pSchema = 0;
}
}
}
Finally the crash appears in function
int sqlite3PagerClose(Pager *pPager){
#ifdef SQLITE_ENABLE_MEMORY_MANAGEMENT
/* Remove the pager from the linked list of pagers starting at
** ThreadData.pPager if memory-management is enabled.
*/
if( pPager==pTsd->pPager ){
pTsd->pPager = pPager->pNext;
}else{
Pager *pTmp;
for(pTmp = pTsd->pPager; pTmp->pNext!=pPager; pTmp=pTmp->pNext){}
pTmp->pNext = pPager->pNext;
}
#endif
Here pTsd appears invalid so assigning to pTmp creates crash.
VS Debugger doesnt gives any value for pTsd, just shows it as invalid data.
Please have a look at it and let me know if there is some solution.Let me know if further information is needed
Thanks
anand |
2007-Jun-26 18:16:53 by drh:
When using SQLITE_ENABLE_MEMORY_MANAGEMENT,
All interaction with a single sqlite3* handle, including calling
sqlite3_close() on that handle, must occur in the same thread that
sqlite3_open() was called in.
2007-Jun-26 18:22:35 by anonymous:
sqlite_close() is being called on same thread from where sqlite_open() is called.
I guess this is same issue as raised in Ticket #2357
2007-Jun-26 23:46:12 by drh:
When SQLITE_ENABLE_MEMORY_MANAGEMENT is turned on, the
sqlite3* handle may not be used in more than one thread.
That means if you call sqlite3_open() in thread A and then
call sqlite3_prepare() in thread B you have broken the rules
and are likely to get this problem.
It is not a matter of calling sqlite3_close() in the same
thread as sqlite3_open(). You have to call all sqlite3_*()
routines in the same thread as sqlite3_open().
2007-Jun-27 00:09:57 by drh:
The FAQ have been updated to description the
restriction on SQLITE_ENABLE_MEMORY_MANAGEMENT and threads.
Since SQLITE_ENABLE_MEMORY_MANAGEMENT is otherwise undocumented,
this is the only place I could find to put the information. |
|
2462 |
todo
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
5
|
5
|
www.sqlite.org/cvstrac/tktnew suggestion
|
edit |
In an effort to increase the value of bug tickets you might consider putting a brief blurb at the top of the http://www.sqlite.org/cvstrac/tktnew html page stressing the value of reproducability of bugs in getting them fixed. Sort of like a bug report check list. For example, a large percentage of bug reports fail to include the schema, valid SQL, or neglect to mention the platform and media on which the database is stored. |
2007-Jun-26 22:07:16 by drh:
This would be an enhancement request for the CVSTrac project.
Please go to http://www.cvstrac.org/cvstrac/ and enter your
request there. |
|
2461 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
2
|
3
|
BLOB retrieval produces garbled data in UTF-16
|
edit |
I came across this when using SQLiteJDBC; see http://groups.google.com/group/sqlitejdbc/t/e4ea318dea31c741 for the original description.
From a SQLite3 DB with UTF-16 encoding, retrieving a BLOB which contains a PNG image with the 3.2.7 CLI produces the correct content (displays
ëPNG...
for the head of the BLOB) and correct length(). In contrast the 3.4.0 CLI shows garbled binary content, but still returns the same length. SQLiteJDBC 0.3.4 now retrieves garbled content of an incorrect (greater) length. Setting up the DB with the same data, but encoding UTF-8 solves this issue, both CLI and SQLiteJDBC are now able to retrieve the BLOB as a valid PNG.
This happens on a Win2k system, using the provided SQLite binaries resp. SQLiteJDBC v034 with nested (pure Java) DB engine. |
2007-Jun-26 13:47:58 by danielk1977:
Can you upload a database file that exhibits the problem?
Thanks.
2007-Jun-26 14:24:30 by anonymous:
What does .dump produce for the BLOBs from the native (not nestedvm) sqlite3 commandline shell?
2007-Jun-29 12:50:35 by drh:
I'm not sure what problem is being reported here.
The APIs for retrieving BLOBs from a database appear to work
fine, both in our countless tests and on the sample database
in the attachments. This is clearly seen in the CLI if you
do
SELECT hex(avatar), length(avatar) FROM avatars;
When the CLI displays a value, it first converts that value
to UTF-8 text. If the value is originally a BLOB in a UTF-16
database, then the BLOB is first cast as UTF-16 text
then that text is converted to UTF-8. That whole conversion
process has changed to become more robust and to fix bugs
in between version 3.2.7 and 3.4.0. Are you saying that the
current UTF16->UTF8 conversion process is incorrect? If so,
can you please provide us with a well-formed UTF16 byte sequence
(not a PNG image that is ill-formed UTF16 text) that exhibits
the problem?
I cannot speak to the problem with SQLiteJDBC since that is
outside the scope of this project.
2007-Jun-29 13:12:33 by drh:
I think I see the problem now.
Back in version 3.2.7, if you requested a BLOB as a UTF8
string out of a UTF16 database then SQLite would return the
content of that blob directly. No conversions occurred.
This is, arguably, incorrect behavior. In version 3.4.0,
when you request a BLOB as a UTF8 string out of a UTF16
database, the BLOB is first cast to a UTF16 string, then
there is a UTF16->UTF8 conversion. We believe the current
behavior is correct.
Summary: The 3.2.7 behavior was bug. The 3.4.0 behavior
is correct.
2007-Jun-29 13:18:34 by anonymous:
The commandline sqlite3 shell compiled with NestedVM shows the correct blob value with .dump for the database in question.
http://www.sqlite.org/contrib/download/sqlite-java-shell-3.4.0.zip?get=19
When spaces are adjusted for the new .dump INSERT format, it produces the same values as the natively compiled sqlite 3.2.2 shell. So either you're not calling the correct sequence of JDBC statements, or this SQLiteJDBC driver should use the same sequence of sqlite API instructions that sqlite/src/shell.c uses for .dump to process binary values. |
|
2460 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
1
|
VC6 Compile Error
|
edit |
When 3.4.0 amalgamation codes are compiled by using MS-VC6 under "Release" Settings, the following error is reported:
sqlite3.c(25593) : fatal error C1001: INTERNAL COMPILER ERROR
Under "Debug" settings, there is no this error. The previous versions
don't have this problem also. |
2007-Jun-26 09:47:45 by drh:
This appears to be a duplicate of #2457. |
|
2458 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
1
|
sqlite caching results between calls to select on an open database
|
edit |
When I open a database and I do a refresh after dropping a table and inserting the same number of row before the drop I am always returned cached data, I don't see the new inserted data?
Step to reproduce:
you will most likely have to write c/c++ code
start with an empty table / database
1. open database
2. create a new table
3. insert 5 rows
4. do a select operation
5. drop the table
6. create a new table
7. insert 5 different rows
8. do a select operation
results: I see the old cached rows!
expected results: I should see the new insert rows
This only happens if you insert the same number of rows you insert before the drop table command.
Basically my refresh functionality is broken.
If I do all the same 8 steps but on step 7 change the row count up or down by 1 or more I alwasy see the new data, as it should be. |
2007-Jun-25 20:45:50 by drh:
Unable to reproduce.
Why do you think that C/C++ code is necessary to reproduce this?
Have you left out some steps. Based on your description above,
it seems like the following SQL script would suffice:
CREATE TABLE t1(a);
INSERT INTO t1 VALUES(1);
INSERT INTO t1 VALUES(2);
INSERT INTO t1 VALUES(3);
INSERT INTO t1 VALUES(4);
INSERT INTO t1 VALUES(5);
SELECT * FROM t1;
DROP TABLE t1;
CREATE TABLE t2(b);
INSERT INTO t2 VALUES(11);
INSERT INTO t2 VALUES(12);
INSERT INTO t2 VALUES(13);
INSERT INTO t2 VALUES(14);
INSERT INTO t2 VALUES(15);
SELECT * FROM t2;
2007-Jun-25 20:55:08 by anonymous:
I have 2 processes: i) viewer gui app and ii) a console test logger.
The viewer app opens the database table then does selects from the database table each time the refresh button is hit. I do not open and close the database between selects calls in the viewer. The sql statement is however finalized and released and prepared each time using the new sqlite3_prepare16_v2 API.
In the test logger app that generates entries, I have a switch that allows me to drop the table before the inserts are done.
If the number so rows inserted between drops is different I see fresh data, otherwise I see cached (old) data. Also if I don't drop the table between inserts, then I see fresh data.
2007-Jun-25 20:59:31 by anonymous:
c/c++ code is necessary because if you use some sqlite shell tool to enter sql statements, the database might be getting open and closed between the steps.
If I force the database to open and close between refresh I see fresh data, if I don't I see cached data.
2007-Jun-25 21:04:05 by anonymous:
Please also use the same table name!
2007-Jun-25 21:13:20 by drh:
My next test uses two processes.
Process 1:
create table t1(x);
insert into t1 values(1);
insert into t1 values(2);
insert into t1 values(3);
insert into t1 values(4);
insert into t1 values(5);
Process 2:
select * from t1;
Process 1:
drop table t1;
create table t1(x);
insert into t1 values(6);
insert into t1 values(7);
insert into t1 values(8);
insert into t1 values(9);
insert into t1 values(10);
Process 2:
select * from t1;
Process 2 sees 1,2,3,4,5 on the first SELECT and 6,7,8,9,10
on the second SELECT.
Still unable to reproduce. What else should I try?
Note that the command-line shell does not close or reopen the
database between commands.
2007-Jun-25 21:59:20 by drh:
Thanks you for providing screenshots of the problem in
your application, Rajinder. However, those screenshots
are no help in isolating this problem. I do not have
access to your code and so the screenshoots are useless
to me in reproducing the bug. And if I cannot reproduce
the problem, I cannot fix it.
Recognize that this is not necessarily a error in SQLite.
There could be any number of bugs in your application which
would give the same symptoms. And so until I have some kind
of problem description or test code with which I can reproduce
the symptoms here, I am going to assume that the bug is outside
of SQLite and leave this ticket closed.
2007-Jun-25 22:10:06 by anonymous:
I understand, I'll keep you posted if I figure out how you can reproduce this problem in some other way without the benefit of having my source code at your disposal. |
|
2452 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
drh
|
1
|
1
|
In Memory Query Performance
|
edit |
Hi,
When the DB is opened in Memory mode,performance of query does not improve. For table which has 10 columns of type Text and each column having 128bytes data and having a total of 10000 records.
Performance is around 2400 records/sec. Any ways to improve it.
Thanks in advance.
regards
ragha |
This is not a bug report. Please ask questions on the mailing list.
2007-Jun-25 02:39:44 by anonymous:
Thanks. |
|
2451 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
5
|
5
|
vdbe.c comment typo
|
edit |
"a P1 parameter of -1" is repeated twice. One of them is wrong.
** database accessed is ((P1+1)*-1). For example, a P1 parameter of -1
** corresponds to database 0 ("main"), a P1 of -1 is database 1 ("temp").
|
Thanks. |
|
2450 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
1
|
Crashes and random wrong results with certain column names
|
edit |
As reported on mailing list
http://www.mail-archive.com/sqlite-users%40sqlite.org/msg25614.html
CREATE TABLE "t a" ("c a", """cb""");
INSERT INTO "t a" ("c a", """cb""") VALUES (1, 2);
INSERT INTO "t a" ("c a", """cb""") VALUES (11, 12);
INSERT INTO "t a" ("c a", """cb""") VALUES (21, 22);
SELECT * FROM "t a";
|
Result-set * expansion was not working for column names
that contain quote characters.
Thanks for the report. |
|
2449 |
doc
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
1
|
BLOB and binary data
|
edit |
Does SQLite3 still support binary data in BLOB fields?
sqlite3 test
SQLite version 3.4.0
Enter ".help" for instructions
sqlite> CREATE TABLE test(data BLOB);
sqlite> INSERT INTO test VALUES("123" || X'00' || "567");
sqlite> SELECT * FROM test;
123
sqlite> SELECT LENGTH(data) FROM test;
3
sqlite>
|
2007-Jun-23 13:14:28 by anonymous:
The concat operator coerces its arguments to TEXT and returns TEXT. You should make a special function to concat BLOBs, if that's what you want.
2007-Jun-23 14:38:00 by danielk1977:
It does. But this sort of thing is better asked on the mailing list.
2007-Jun-30 17:04:22 by anonymous:
my solution as loadable extension:
static void concatFunc(
sqlite3_context *context, int argc, sqlite3_value **argv )
{
unsigned char *pz, *rz;
int i, blobSize=0;
for(i=0; i<argc; i++)
blobSize += sqlite3_value_bytes(argv[i]);
pz = rz = sqlite3_malloc( blobSize );
if( rz == NULL )
sqlite3_result_null(context );
else
{
for(i=0; i<argc; i++)
{
int addSize = sqlite3_value_bytes(argv[i]);
if( addSize )
{
memcpy( pz, sqlite3_value_blob(argv[i]), addSize );
pz += addSize;
}
}
sqlite3_result_blob(context, rz, blobSize, SQLITE_TRANSIENT);
sqlite3_free( rz );
}
}
sqlite3_create_function(db, "Concat", -1, SQLITE_ANY, 0, concatFunc, 0, 0);
My question to this:
Correct or not to sqlite3_free(rz) after SQLITE_TRANSIENT?
I am not sure if the result function is doing sqlite3_free or not. |
|
2447 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
4
|
select where TABLENAME="TABLENAME" returns whole table.
|
edit |
I am using sqlite3 on Windows XP.
SQLite version 3.4.0
Enter ".help" for instructions
sqlite> create table MYTABLE (name varchar(20),field2 varchar(20));
sqlite> insert into MYTABLE VALUES ("name1","name2");
sqlite> select * from MYTABLE;
name1|name2
sqlite> select * from MYTABLE where name="name1";
name1|name2
sqlite> select * from MYTABLE where name="name";
name1|name2
I expected the third sqlquery not to result in any output. It appears that if you use tablename="tablename", you are getting all rows of the table.
Am i missing something? |
Use name='name' instead. "name" means use the column named "name". |
|
2445 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
1
|
crash in sqlite3_prepare16
|
edit |
I just got a crash when using sqlite 3.4.0 inside our app.
This is the only time I had it crash so far, so it seems to be a sporadic issue.
From the backtrace and investigating the data, I can't see how this would be caused by our application code misbehaving,
so I have to assume it's something inside sqlite.
Our app does pretty heavy multithreading (and yes, we've built sqlite with --enable-threadsafe),
so this may be the reason this only happened once so far?
Anyway, the query being compiled is
CREATE TABLE __BrowserData__ AS SELECT
__lc_license_status_agent_id,
__agent_ids_id,
__agent_info_id,
__lc_license_specs_id,
__pseudoRowID__
FROM
__BrowserData___View
LIMIT 100
__BrowserData___View is a temporary view created as:
CREATE TEMP VIEW __BrowserData___View AS
SELECT
(IFNULL(lc_license_status_agent.rowID,'')||':'||IFNULL(agent_ids.rowID,'')||':'||IFNULL(agent_info.rowID,'')||':'||IFNULL(lc_license_specs.rowID,'')||':') as __pseudoRowID__,
agent_ids.id AS __agent_ids_id,
agent_info.id AS __agent_info_id,
lc_license_specs.id AS __lc_license_specs_id,
lc_license_status_agent.id AS __lc_license_status_agent_id,
lc_license_status_agent.InstallCount AS lc_license_status_agent_InstallCount,
agent_ids.AgentName AS column_6b3ec967,
lc_license_specs.LicenseType AS lc_license_specs_LicenseType,
lc_license_specs.Name AS column_00000001,
lc_license_specs.TrackAsMissingSoftware AS lc_license_specs_TrackAsMissingSoftware
FROM
lc_license_status_agent
LEFT JOIN
agent_ids ON (lc_license_status_agent.AgentSerial=agent_ids.AgentSerial)
LEFT JOIN
agent_info ON (agent_ids.id=agent_info.id)
LEFT JOIN
lc_license_specs ON (lc_license_status_agent.lc_specification_record_id=lc_license_specs.id)
WHERE
(((lc_license_status_agent_InstallCount = 0
AND
lc_license_specs_LicenseType <> 4
AND
lc_license_specs_TrackAsMissingSoftware = 1)
AND
(column_00000001 NOT LIKE 'fdsafdas' ESCAPE '\'
)))
ORDER BY
column_6b3ec967 COLLATE NOCASE ASC,
column_00000001 COLLATE NOCASE ASC
(ok, it's ugly, but this is a generated statement).
The sqlite database object at this point looks valid to me
(although I have to admit that other than checking for obvious garbage values,
I can't do too much checking):
(gdb) print *fDatabase.fObj->fSQLConnection
$2 = {
nDb = 5,
aDb = 0x17223330,
flags = 32768,
errCode = 0,
errMask = 255,
autoCommit = 1 '\001',
temp_store = 0 '\0',
nTable = 128,
pDfltColl = 0x168ceae0,
lastRowid = 0,
priorNewRowid = 0,
magic = -264537850,
nChange = 0,
nTotalChange = 0,
init = {
iDb = 0,
newTnum = 0,
busy = 0 '\0'
},
nExtension = 0,
aExtension = 0x0,
pVdbe = 0x2315600,
activeVdbeCnt = 0,
xTrace = 0x3594ac <MyTraceStatement(void*, char const*)>,
pTraceArg = 0x16af34c0,
xProfile = 0,
pProfileArg = 0x0,
pCommitArg = 0x0,
xCommitCallback = 0,
pRollbackArg = 0x0,
xRollbackCallback = 0,
pUpdateArg = 0x0,
xUpdateCallback = 0,
xCollNeeded = 0,
xCollNeeded16 = 0,
pCollNeededArg = 0x0,
pErr = 0x165ca020,
zErrMsg = 0x0,
zErrMsg16 = 0x0,
u1 = {
isInterrupted = 0,
notUsed1 = 0
},
xAuth = 0,
pAuthArg = 0x0,
xProgress = 0x359994 <_CheckForInterrupts(void*)>,
pProgressArg = 0x1688dca0,
nProgressOps = 20000,
aModule = {
keyClass = 3 '\003',
copyKey = 0 '\0',
count = 0,
first = 0x0,
xMalloc = 0x39a21c <sqlite3MallocX>,
xFree = 0x39a1c8 <sqlite3FreeX>,
htsize = 0,
ht = 0x0
},
pVTab = 0x0,
aVTrans = 0x0,
nVTrans = 0,
aFunc = {
keyClass = 3 '\003',
copyKey = 0 '\0',
count = 77,
first = 0x1725a0a0,
xMalloc = 0x39a21c <sqlite3MallocX>,
xFree = 0x39a1c8 <sqlite3FreeX>,
htsize = 128,
ht = 0x21db200
},
aCollSeq = {
keyClass = 3 '\003',
copyKey = 0 '\0',
count = 2,
first = 0x16a66530,
xMalloc = 0x39a21c <sqlite3MallocX>,
xFree = 0x39a1c8 <sqlite3FreeX>,
htsize = 8,
ht = 0x1657b9e0
},
busyHandler = {
xFunc = 0x409c4c <sqliteDefaultBusyCallback>,
pArg = 0x16af16f0,
nBusy = 0
},
busyTimeout = 900000,
aDbStatic = {{
zName = 0x46d5bc "main",
pBt = 0x168beee0,
inTrans = 0 '\0',
safety_level = 1 '\001',
pAux = 0x0,
xFreeAux = 0,
pSchema = 0x17238010
}, {
zName = 0x46bad4 "temp",
pBt = 0x0,
inTrans = 0 '\0',
safety_level = 1 '\001',
pAux = 0x0,
xFreeAux = 0,
pSchema = 0x16ab7ce0
}},
dfltLockMode = 0 '\0'
}
The backtrace of the thread that crashed was:
#0 0x003bef40 in sqlite3ValueFromExpr (pExpr=0x6e67436f, enc=3 '\003', affinity=114 'r', ppVal=0xf089e250) at sqlite/build/sqlite3.c:30197
#1 0x003f9fa8 in sqlite3ColumnDefault (v=0x2315600, pTab=0x170f9410, i=12) at sqlite/build/sqlite3.c:58010
#2 0x003d34f4 in sqlite3ExprCodeGetColumn (v=0x2315600, pTab=0x170f9410, iColumn=12, iTable=6) at sqlite/build/sqlite3.c:40564
#3 0x003d3938 in sqlite3ExprCode (pParse=0xf089ed2c, pExpr=0x16ac0560) at sqlite/build/sqlite3.c:40614
#4 0x003d4e40 in sqlite3ExprIfFalse (pParse=0xf089ed2c, pExpr=0x16ac0510, dest=-11, jumpIfNull=1) at sqlite/build/sqlite3.c:41170
#5 0x00403304 in sqlite3WhereBegin (pParse=0xf089ed2c, pTabList=0x16ae1110, pWhere=0x17238440, ppOrderBy=0xf089e98c) at sqlite/build/sqlite3.c:62143
#6 0x003f6db0 in sqlite3Select (pParse=0xf089ed2c, p=0x172163e0, eDest=7, iParm=1, pParent=0x0, parentTab=0, pParentAgg=0x0, aff=0x0) at sqlite/build/sqlite3.c:56496
#7 0x003dcbd4 in sqlite3EndTable (pParse=0xf089ed2c, pCons=0x0, pEnd=0x0, pSelect=0x172163e0) at sqlite/build/sqlite3.c:44696
#8 0x00404960 in yy_reduce (yypParser=0x2368600, yyruleno=27) at sqlite/build/sqlite3.c:64308
#9 0x00407734 in sqlite3Parser (yyp=0x2368600, yymajor=1, yyminor={z = 0x23802ab "100", dyn = 0, n = 3}, pParse=0xf089ed2c) at sqlite/build/sqlite3.c:65329
#10 0x00408e50 in sqlite3RunParser (pParse=0xf089ed2c, zSql=0x2380200 "CREATE TABLE __BrowserData__ AS SELECT __lc_license_status_agent_id,__agent_ids_id,__agent_info_id,__lc_license_specs_id, __pseudoRowID__ FROM __BrowserData___View LIMIT 100", pzErrMsg=0xf089edf4) at sqlite/build/sqlite3.c:65997
#11 0x003ef480 in sqlite3Prepare (db=0x16af16f0, zSql=0x2380200 "CREATE TABLE __BrowserData__ AS SELECT __lc_license_status_agent_id,__agent_ids_id,__agent_info_id,__lc_license_specs_id, __pseudoRowID__ FROM __BrowserData___View LIMIT 100", nBytes=-1, saveSqlFlag=0, ppStmt=0x170f81d0, pzTail=0xf089ee54) at sqlite/build/sqlite3.c:53254
#12 0x003efa70 in sqlite3Prepare16 (db=0x16af16f0, zSql=0x172597a0, nBytes=348, saveSqlFlag=0, ppStmt=0x170f81d0, pzTail=0xf089ef6c) at sqlite/build/sqlite3.c:53404
#13 0x003efb68 in sqlite3_prepare16 (db=0x16af16f0, zSql=0x172597a0, nBytes=348, ppStmt=0x170f81d0, pzTail=0xf089ef6c) at sqlite/build/sqlite3.c:53435
#14 0x00390cf4 in SQLiteQuery::PrepareStatement (this=0x170f8140)
#15 0x0038f6c0 in SQLiteQuery::GetResultSet (this=0x170f8140)
#16 0x00390f84 in SQLiteQuery::Execute (this=0x170f8140)
#17 0x00110fdc in (anonymous namespace)::CreateBrowserCacheTable (inDatabase=@0x1688dca0, inSelectDataQuery=@0xf08a0580, inCacheColumnTableList=@0xf08a0460, tableList=0x168de190, inNeedPersistentRowIDs=true, inCacheLimit=100)
#18 0x0012db9c in GenerateViewProperties (this=0x20dbc00, inDatabase=@0x1688dca0, inCreateBrowserCacheTable=true, inWantPlainSelectQuery=false, inUpdaterThread=0x16a54240)
#19 0x0012ebe8 in RecreateViewThread::Run (this=0x16a54240)
#20 0x00332f4c in ThreadEntry (inThread=0x16a54240)
#21 0x9002be88 in _pthread_body ()
Now here's a strange thing:
The calling function (#1 in the backtrace) executed this code:
Column *pCol = &pTab->aCol[i];
sqlite3ValueFromExpr(pCol->pDflt, enc, pCol->affinity, &pValue);
Here, i = 12, however pTab only appears to contain 10 column entries:
(gdb) print *pTab
$4 = {
zName = 0x16ad2b90 "lc_license_status_agent",
nCol = 10,
aCol = 0x16afb2c0,
iPKey = 0,
pIndex = 0x16ad5b40,
tnum = 139,
pSelect = 0x0,
nRef = 2,
pTrigger = 0x0,
pFKey = 0x0,
zColAff = 0x0,
pCheck = 0x0,
addColOffset = 518,
readOnly = 0 '\0',
isEphem = 0 '\0',
hasPrimKey = 1 '\001',
keyConf = 99 'c',
autoInc = 0 '\0',
isVirtual = 0 '\0',
isCommit = 0 '\0',
pMod = 0x0,
pVtab = 0x0,
nModuleArg = 0,
azModuleArg = 0x0,
pSchema = 0x16ad7700
}
For the records, here's also the contents of pExpr inside sqlite3ExprCode:
(gdb) print *pExpr
$5 = {
op = 149 '\225',
affinity = 100 'd',
flags = 4,
pColl = 0x168ceb08,
pLeft = 0x0,
pRight = 0x0,
pList = 0x0,
token = {
z = 0x0,
dyn = 0,
n = 0
},
span = {
z = 0x0,
dyn = 1,
n = 39
},
iTable = 6,
iColumn = 12,
pAggInfo = 0x0,
iAgg = -1,
iRightJoinTable = 0,
pSelect = 0x0,
pTab = 0x170f9410,
pSchema = 0x168ea360,
nHeight = 2
}
as well as the contents of the "wc" variable inside sqlite3WhereBegin, which is executing at this point:
/* For a LEFT OUTER JOIN, generate code that will record the fact that
** at least one row of the right table has matched the left table.
*/
if( pLevel->iLeftJoin ){
pLevel->top = sqlite3VdbeCurrentAddr(v);
sqlite3VdbeAddOp(v, OP_MemInt, 1, pLevel->iLeftJoin);
VdbeComment((v, "# record LEFT JOIN hit"));
for(pTerm=wc.a, j=0; j<wc.nTerm; j++, pTerm++){
if( pTerm->flags & (TERM_VIRTUAL|TERM_CODED) ) continue;
if( (pTerm->prereqAll & notReady)!=0 ) continue;
assert( pTerm->pExpr );
--> sqlite3ExprIfFalse(pParse, pTerm->pExpr, cont, 1);
pTerm->flags |= TERM_CODED;
}
}
(gdb) print wc
$6 = {
pParse = 0xf089ed2c,
pMaskSet = 0xf089e5c4,
nTerm = 10,
nSlot = 10,
a = 0xf089e6dc,
aStatic = {{
pExpr = 0x170e4ad0,
iParent = -1,
leftCursor = 3,
leftColumn = 4,
eOperator = 2,
flags = 4 '\004',
nChild = 137 '\211',
pWC = 0xf089e6c8,
prereqRight = 0,
prereqAll = 1
}, {
pExpr = 0x1729f140,
iParent = -1,
leftCursor = -1,
leftColumn = 561,
eOperator = 0,
flags = 4 '\004',
nChild = 0 '\0',
pWC = 0xf089e6c8,
prereqRight = 0,
prereqAll = 8
}, {
pExpr = 0x16ac0510,
iParent = -1,
leftCursor = 6,
leftColumn = 12,
eOperator = 2,
flags = 0 '\0',
nChild = 0 '\0',
pWC = 0xf089e6c8,
prereqRight = 0,
prereqAll = 8
}, {
pExpr = 0x16ac0600,
iParent = -1,
leftCursor = -1,
leftColumn = -3959,
eOperator = 0,
flags = 0 '\0',
nChild = 255 '\377',
pWC = 0xf089e6c8,
prereqRight = 0,
prereqAll = 8
}, {
pExpr = 0x17259d40,
iParent = -1,
leftCursor = 3,
leftColumn = 2,
eOperator = 2,
flags = 12 '\f',
nChild = 0 '\0',
pWC = 0xf089e6c8,
prereqRight = 2,
prereqAll = 3
}, {
pExpr = 0x17259e30,
iParent = -1,
leftCursor = 4,
leftColumn = -1,
eOperator = 2,
flags = 12 '\f',
nChild = 0 '\0',
pWC = 0xf089e6c8,
prereqRight = 4,
prereqAll = 6
}, {
pExpr = 0x17259f20,
iParent = -1,
leftCursor = 3,
leftColumn = 1,
eOperator = 2,
flags = 12 '\f',
nChild = 0 '\0',
pWC = 0xf089e6c8,
prereqRight = 8,
prereqAll = 9
}, {
pExpr = 0x17209b10,
iParent = 6,
leftCursor = 6,
leftColumn = -1,
eOperator = 2,
flags = 7 '\a',
nChild = 35 '#',
pWC = 0xf089e6c8,
prereqRight = 1,
prereqAll = 9
}, {
pExpr = 0x16ae10c0,
iParent = 5,
leftCursor = 5,
leftColumn = -1,
eOperator = 2,
flags = 7 '\a',
nChild = 49 '1',
pWC = 0xf089e6c8,
prereqRight = 2,
prereqAll = 6
}, {
pExpr = 0x16ae9a20,
iParent = 4,
leftCursor = 4,
leftColumn = 2,
eOperator = 2,
flags = 7 '\a',
nChild = 0 '\0',
pWC = 0xf089e6c8,
prereqRight = 1,
prereqAll = 3
}}
}
At the time of the crash, no other thread was doing any active work with sqlite.
I can't think of any additional info to provide here that would help track this problem down.
I hope what I supplied is sufficient to give you a hint where to start looking...
I'll save the database, so I can provide you with more information on the exact schema if you need.
sorry for the lengthy report and the ultra-wide formatting, but the stacktrace won't be readable if I divide the lines and I couldn't find a way of attaching things as a separate file |
2007-Jun-22 13:55:03 by anonymous:
I just found that I can reproduce this 100% with our application (at least in my current setup - it only happens when I do things in a certain order), so if you need further information, I can probably provide more info.
2007-Jun-22 15:24:00 by anonymous:
Did you run the test case through valgrind and find anything interesting?
2007-Jun-22 15:33:07 by anonymous:
The calling function (#1 in the backtrace) executed this code:
Column *pCol = &pTab->aCol[i];
sqlite3ValueFromExpr(pCol->pDflt, enc, pCol->affinity, &pValue);
Can you print all the arguments in gdb after the crash?
pCol
*pCol
enc
&pValue
pValue
2007-Jun-22 16:18:38 by anonymous:
Here's the gdb printout of the parameters of sqlite3ValueFromExpr after the crash:
(gdb) print pExpr
$1 = (Expr *) 0x6e67436f
(gdb) print *pExpr
Cannot access memory at address 0x6e67436f
(gdb) print enc
$2 = 3 '\003'
(gdb) print affinity
$3 = 114 'r'
(gdb) print ppVal
$4 = (sqlite3_value **) 0xf079c250
(gdb) print *ppVal
$5 = (sqlite3_value *) 0x0
Let me know if you need something else (you can also e-mail me at jum at mac dot com)
2007-Jun-22 18:38:47 by anonymous:
Can you reproduce the crash using only a single thread?
2007-Jun-23 06:19:27 by danielk1977:
Can you post the database? Or just the contents of the sqlite_master
table if you like. Or if you don't want to post it here, can you
send it to me at "dan@sqlite.org". Thanks.
2007-Jun-25 07:59:07 by anonymous:
I can't check whether this happens with just a single thread, since there's no way to have our app launch without background threads and cutting them off would require a major rewrite, so there's not really an easy way to get it single-threaded.
However, it is so easy and reliable to reproduce without even having much data or background operations, that I meanwhile doubt it's a thread synchronization issue.
Thanks for all the details. |
|
2444 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
2
|
3
|
SIGFPE from division of (1<<63)==9223372036854775808
|
edit |
select (1<<63) / -1
or
select (1<<63) % -1;
blow up.
Check-in [3945]
looks to be something that has attempted to address this and also added the regression test that SIGFPE's here (expr-1.104 {i1=0} {(-9223372036854775808 % -1)} 0.0).
I don't see how this check-in is supposed to work, but clearly the regression test passed somewhere at some point. Some explanation here would be of interest.
Tested on 32 & 64-bit Linux systems, from 3.3.3 -> 3.4.0.
from vdbe.c:
1183 default: {
1184 i64 ia = (i64)a;
1185 i64 ib = (i64)b;
1186 if( ia==0 ) goto divide_by_zero;
->1187 b = ib % ia;
1188 break;
(Sorry this report is terse, it's late here and I'll take another look tomorrow after some sleep). The most obvious fix is this somewhat ugly patch attached (I'm going to argue (i64)1<<63 is more intuitive in this case), but I'm not sure I like it as-is. |
2007-Jun-22 15:17:37 by anonymous:
What compiler version and compile flags are you using?
SQLite version 3.4.0
Enter ".help" for instructions
sqlite> select (1<<63) / -1;
-9223372036854775808
sqlite> select (1<<63) % -1;
0
2007-Jun-22 16:11:44 by danielk1977:
Note that in SQLite, a literal -9223372036854775808 is not
the same as (1<<63):
sqlite> select typeof( (1<<63) );
integer
sqlite> select typeof( -9223372036854775808 );
real
Which is why:
sqlite> select (-9223372036854775808 / -1)>1;
1
sqlite> select ((1<<63) / -1)>1;
0
yet:
sqlite> select -9223372036854775808 == (1<<63);
1
Why some systems get a SIGFPE and some systems happily
overflow the integer I'm not sure.
2007-Jun-22 21:16:10 by anonymous:
I see this with 64-bit (x86-64) versions of sqlite, versions shipping by both Red Hat (RHEL and FC), Debian and also versions I build.
I'm not able to get it to fail on 32-bit systems and looking at the code that makes sense (the previous reported failure on 32-bit systems was done at 2am or so, so I might have testing in the wrong session when I claimed it broke there).
Anyhow, after some sleep I really do think this is a corner case that should be dealt with explicitly.
SIGFPE is bad. Not noticing the overflow is also bad, so I think something like my suggested patch is needed. It's debatable as to whether using 1<<63 or -9223372036854775808 makes the most sense.
It probably could be done a little cleaner and a comment wouldn't be the worst idea ever. Maybe another updated regression test or two is needed. I'll happily provide updated patches if there is consensus here.
2007-Jun-22 21:58:14 by anonymous:
I just uploaded http://www.sqlite.org/cvstrac/attach_get/395/undef-i64-div.patch as an updated solution. May need some work.
2007-Jun-22 22:05:57 by anonymous:
Surely this is an x86-64 compiler bug.
Can you run this in gdb and show a backtrace as well as print out the dividend and divisor?
Recompile sqlite3 with no optimization of any kind (replace -O2 with -O0) and repeat these steps.
2007-Jun-22 23:10:32 by anonymous:
It's not a compiler bug. I can provide all the stack traces and printing you like, but indulge me for a second without using a CPU.
For 2s compliment integer math, the issue at hand is that the CPU's range is -(MAX_INT+1) to MAX_INT. So for 64-bit integers this works out to be -9223372036854775808 to 9223372036854775807. Hex representation of that being 0x8000000000000000 to 0x7FFFFFFFFFFFFFFF.
1<<63 is the greatest (absolute) negative value you can have. It's absolute value is greater than what you can represent with a positive integer. The 2s compliment range isn't symmetrical because we have only one 0 (1s compliment is and has -0 and +0 by contrast).
So there is no way to do this in integer math for 2s compliment, you either silently get undefined & wrong results (as tested now on 32-bit i386, 32-bit ppc, 64 bit ppc and 32-bit mips) or a CPU exception in the case of x86-64.
If you only have a 32-bit intel processor at hand try something like:
long foo()
{
long a = 1;
long b = -1;
long c;
a <<= 31;
c = a / b;
printf("a=%ld\n", a);
printf("b=%ld\n", b);
printf("c=%ld\n", c);
}
main()
{
foo();
return 0;
}
(I wrote it like this to make the (dis)assembly easier to follow).
So, I'm suggesting something along the changes I posted because of think null/NaN makes more sense than a crash or a wrong value.
The alternative is to promote the integer to a real and return the correct value. That doesn't seem useful given this is a corner case and my main concern is really the crash inside the library.
2007-Jun-23 00:35:56 by anonymous:
Okay, I see what you mean.
$ cat foo.c
long foo(long a, long b) {
a <<= 31;
return a / b;
}
$ gcc -S -O3 -fomit-frame-pointer foo.c
$ cat foo.s
.file "foo.c"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
movl 4(%esp), %edx
sall $31, %edx
movl %edx, %eax
sarl $31, %edx
idivl 8(%esp)
ret
The SIGFPE threw me, as this was an integer operation, not floating point. This is just what UNIX happens to call the divide error fault.
From an x86 manual for the opcode IDIV:
If the dividend is 0 or if the quotient is too large to fit
in the result accumulator, a divide error fault occurs.
So the long long handling GCC code for 32 bit x86 machines handles this case, while the x86-64 native hardware IDIV instruction does not. Interesting.
This is the sort of undefined behavior you get when you go beyond a signed int's limits.
2007-Jun-23 06:03:01 by danielk1977:
I'm inclined to handle all three cases as special cases. For the
two that use the '%' operator, can we not just do the following?
if( a==-1 ){
b = 0;
}else{
b %= a;
}
The divide case is a bit trickier I suppose. I think we should
either promote the result to a real number or throw an exception
(like the divide-by-zero case). Or maybe emulate the behaviour
currently produced by 32-bit systems. After all, we allow
integer overflow to occur in other cases:
sqlite> select ( (1<<62) * 17 ) = (1<<62);
1
So we would make changes so that there are two special cases
in SQLite's integer arithmatic:
1) Evaluating (X % -1) is always 0 (this should suit everybody), and
2) Evaluating ((1<<63)/-1) overflows the 64 bit integer and returns (1<<63).
Opinions?
2007-Jun-23 07:52:28 by anonymous:
For the % operator I agree.
For he / operator I'm not so sure.
Returning (1<<63) is wrong. Some implementations and CPUs will do that sometimes but not all, so there is no precedent. It even depends on the gcc optimization level on some (ie. ppc64). If this was a full-blown data base I would argue we should either return NULL so it's not mistaken as something that's valid or promote it to a real.
Given it's a light-weight embedded database and as you point out there are overflows (without promotion) elsewhere, then maybe the right approach for now is to just avoid the SIGFPE crash (except then we will have cases where the results vary between machines or between builds on the same machine in some cases).
I'm not sure what implications there are about promotion in these cases, if any. I think that probably requires some more thought.
This isn't exactly a new issue, it's been around for a long time without causing (reported) problems so I think it's reasonable to mull this over for a little bit.
2007-Jun-23 13:32:29 by anonymous:
Doing a mod of -1 is useless anyway, so any result is fine as long as it is the same on all platforms regardless of 32bit or 64bit chip.
While we're on the topic, is there an easy way to detect an overflowed integer multiplication in C so that it could be promoted to a double?
sqlite> select 15241578750190521 * 15241578750190521;
7423698896135986097
Is it more important to preserve this quirky overflowing 64 bit integer math at the cost of correct floating point math? I think most SQLite end-users (i.e., non-programmers) would expect the latter.
Maybe some pragma to control overall integer -> double promtion would be in order here?
PRAGMA floating_point_math = on/off;
If this proposed floating_point_math were on, then all arguments to multiplication and division would be unconditionally promoted to doubles. |
|
2441 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
2
|
3
|
Windows only error when deleting tempory files
|
edit |
When sqlite creates the temporary journal files, it sets the delete flag to true. On unix systems, this simply sets the file permissions to 0600, which equates to rw-------. On windows, it actually sets the FILE_FLAG_DELETE_ON_CLOSE, and the file gets deleted. However, sqlite then goes through and cleans these files up, so it actually deletes something on unix, but on windows it returns an error because the file no longer exists. When writing cross platform code, this makes things difficult. Since sqlite deletes these journal fils itself, it shouldn't be also setting the delete flag (or alternatively not closing the file). This bug also exists in the latest version (by looking at the code).
Downstream Bug (from Mozilla):
https://bugzilla.mozilla.org/show_bug.cgi?id=341137 |
2007-Jun-21 02:59:12 by anonymous:
I was under the impression that FILE_FLAG_DELETE_ON_CLOSE doesn't work on all Windows OSes, in particular Windows NT. Any Windows experts care to comment?
2007-Jun-21 12:18:30 by drh:
I think it is WinCE that does not support FILE_FLAG_DELETE_ON_CLOSE.
See ticket #279. Also ticket #2350.
For systems that do suppport DELETE_ON_CLOSE, we definitely
want to use it. Otherwise, if the process using SQLite
shuts down (for example via exit(0)) without first closing
its database connection, we do not want temporary files
hanging around afterwards. DELETE_ON_CLOSE will remove them
automatically.
On the other hand, we also want to manually delete temporary
files when shutting down for those cases where the
DELETE_ON_CLOSE flag does not work. See ticket #2350.
SQLite appears to be doing the right thing. It sets
DELETE_ON_CLOSE but also makes sure that the file really
does delete by manually deleting the file when the database
connection is closed. If the DELETE_ON_CLOSE worked right,
then there will be nothing to delete when the manual delete
comes around. But no harm is done either.
I think the correct fix for the original problem is to
changes the application so that it no longer upset
when someone tries to delete a file that does not
exist. The application should ignore the problem and
move on.
I fail to see how this make it any more difficult to write
a cross-platform application.
2007-Jun-21 23:36:08 by anonymous:
This complicates things for cross platform development because you get different behaviors on different platforms.
If you wanted to bring parity across platforms on behavior, you'd ideally unlink the file pointer you have on unix (it looks like os2 has code for automatic deletion as well). Unlinking it will decrement the link count of the file, but removal will not occur until all references to the file are closed.
My issue here is that there are different behaviors on different platforms, when sqlite really should behave the same if possible.
Ignoring return values of a function isn't the most ideal solution either...
2007-Jun-22 01:56:13 by anonymous:
I'm not sure what you're talking about.
Unix unlink()s temp file on open(). See delFlag.
static int sqlite3UnixOpenExclusive(const char *zFilename,
OsFile **pId, int delFlag){
int h;
CRASH_TEST_OVERRIDE(sqlite3CrashOpenExclusive, zFilename, pId, delFlag);
assert( 0==*pId );
h = open(zFilename,
O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_LARGEFILE|O_BINARY,
delFlag ? 0600 : SQLITE_DEFAULT_FILE_PERMISSIONS);
if( h<0 ){
return SQLITE_CANTOPEN;
}
return allocateUnixFile(h, pId, zFilename, delFlag);
}
...
static int allocateUnixFile(
int h, /* Open file descriptor on file being opened */
OsFile **pId, /* Write the resul unixFile structure here */
const char *zFilename, /* Name of the file being opened */
int delFlag /* If true, delete the file on or before closing */
){
unixFile *pNew;
unixFile f;
int rc;
memset(&f, 0, sizeof(f));
sqlite3OsEnterMutex();
rc = findLockInfo(h, &f.pLock, &f.pOpen);
sqlite3OsLeaveMutex();
if( delFlag ){
unlink(zFilename);
}
2007-Jun-22 15:42:39 by anonymous:
Thanks to this issue, myself and many others are having our temp folders filled with various etilqs_* files. Please reconsider your decision to not fix this issue.
2007-Jun-22 15:43:52 by anonymous:
By chance are you using the SQLiteJDBC driver?
2007-Jun-22 15:49:52 by anonymous:
I'm using a current trunk build of Firefox, which uses the 3.3.17 amalgamation file (as this bug was filed under).
2007-Jun-22 15:57:06 by anonymous:
I haven't had any problems with etilqs_* temp file on Windows when using the sqlite3 commandline shell, via an SQLite ODBC driver and SQLite native JDBC driver.
What is Firefox doing differently?
BTW the mozilla ticket you cited was closed as FIXED and I don't see any mention of these temp files.
2007-Jun-22 16:31:41 by anonymous:
You didn't mention that Mozilla has created its own async file I/O subsystem for SQLite:
http://developer.mozilla.org/en/docs/Storage:Performance#Lazy_writing
Just have to tweak this async I/O code to not return an error for deleting a file that does not exist.
2007-Jun-22 16:36:39 by anonymous:
Also, since you've replace all I/O calls to sqlite you must handle the file unlink ref count stuff yourself on Windows, since you're not using the default mechanisms provided by #ifdef OS_WIN in sqlite.
2007-Jun-22 16:54:48 by anonymous:
If WinCE is the only platform where FILE_FLAG_DELETE_ON_CLOSE doesn't work reliably, I'm not sure why the manual delete can't just live in a CE-specific ifdef. Either way, this seems like an expected error in most cases, and shouldn't require the app to handle it.
At the least, documentation about when it is and isn't acceptable to ignore that error seems appropriate, since apparently there isn't any...
2007-Jun-22 17:38:28 by anonymous:
Our code for async IO is just a wrapper around your IO functions but running on a different thread. In the end, we still call all of your functions:
http://mxr.mozilla.org/seamonkey/source/storage/src/mozStorageAsyncIO.cpp#1438
-sdwilsh
2007-Jun-22 18:32:48 by anonymous:
SQLite was not written with async I/O in mind. As such, if you replace SQLite's I/O functions with your own you must provide identical symantics to the functions you are replacing. It does not seem like you are doing that.
2007-Jun-22 19:40:45 by anonymous:
In your async IO you seem to put each IO request on a work-queue for another thread to process and then always return success immediately. You can only recognize errors on the next sqlite IO operation - whatever it may be.
So you don't have much choice but to do something like this:
case ASYNC_DELETE:
NS_ASSERTION(sqliteOrigDelete, "No delete pointer");
- rc = sqliteOrigDelete(aMessage->mBuf);
+ sqliteOrigDelete(aMessage->mBuf);
+ rc = SQLITE_OK;
break;
since you do not know the context in which it the file delete is called.
I think at the time test_async.c was written SQLite did not generally check the return code of sqlite3OSDelete. It assumed success. Even now, you can see that sometimes its return code is not checked (lines without rc assignments):
pager.c: rc = sqlite3OsDelete(pPager->zJournal);
pager.c: rc = sqlite3OsDelete(zMaster);
pager.c: sqlite3OsDelete(pPager->zJournal);
pager.c: sqlite3OsDelete(pPager->zJournal);
vdbeaux.c: sqlite3OsDelete(zMaster);
vdbeaux.c: sqlite3OsDelete(zMaster);
vdbeaux.c: rc = sqlite3OsDelete(zMaster);
Because test_async.c was a proof of concept and is not actively tested, you have to check that newer versions of sqlite do not break any of its assumptions. |
|
2439 |
code
|
closed
|
2007 Jun
|
rse
|
|
2007 Jul
|
|
1
|
1
|
FTS1 and FTS2 use the unportable <malloc.h>
|
edit |
The FTS1 and FTS2 extensions use the unportable and highly deprecated <malloc.h> on all platforms except Apple Mac OS X. The <malloc.h> actually is never required on any OS with an at least partly POSIX-conforming API as malloc(3) and friends officially live in <stdlib.h> since many years. Under FreeBSD the inclusion of
<malloc.h> since about 2-3 years even causes an "#error" and this way a build failure. So I recommend to just get rid of the <malloc.h> at all.
Index: ext/fts1/fts1.c
--- ext/fts1/fts1.c.orig 2007-06-12 14:18:00 +0200
+++ ext/fts1/fts1.c 2007-06-20 18:09:00 +0200
@@ -19,11 +19,7 @@
#endif
#include <assert.h>
-#if !defined(__APPLE__)
-#include <malloc.h>
-#else
#include <stdlib.h>
-#endif
#include <stdio.h>
#include <string.h>
#include <ctype.h>
Index: ext/fts1/fts1_porter.c
--- ext/fts1/fts1_porter.c.orig 2007-06-12 14:18:00 +0200
+++ ext/fts1/fts1_porter.c 2007-06-20 18:09:00 +0200
@@ -26,11 +26,7 @@
#include <assert.h>
-#if !defined(__APPLE__)
-#include <malloc.h>
-#else
#include <stdlib.h>
-#endif
#include <stdio.h>
#include <string.h>
#include <ctype.h>
Index: ext/fts1/fts1_tokenizer1.c
--- ext/fts1/fts1_tokenizer1.c.orig 2007-06-12 14:18:00 +0200
+++ ext/fts1/fts1_tokenizer1.c 2007-06-20 18:09:00 +0200
@@ -18,11 +18,7 @@
#include <assert.h>
-#if !defined(__APPLE__)
-#include <malloc.h>
-#else
#include <stdlib.h>
-#endif
#include <stdio.h>
#include <string.h>
#include <ctype.h>
Index: ext/fts2/fts2.c
--- ext/fts2/fts2.c.orig 2007-06-13 15:29:40 +0200
+++ ext/fts2/fts2.c 2007-06-20 18:10:05 +0200
@@ -269,9 +269,6 @@
#endif
#include <assert.h>
-#if !defined(__APPLE__)
-#include <malloc.h>
-#endif
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
Index: ext/fts2/fts2_porter.c
--- ext/fts2/fts2_porter.c.orig 2007-06-12 14:18:00 +0200
+++ ext/fts2/fts2_porter.c 2007-06-20 18:09:35 +0200
@@ -26,11 +26,7 @@
#include <assert.h>
-#if !defined(__APPLE__)
-#include <malloc.h>
-#else
#include <stdlib.h>
-#endif
#include <stdio.h>
#include <string.h>
#include <ctype.h>
Index: ext/fts2/fts2_tokenizer1.c
--- ext/fts2/fts2_tokenizer1.c.orig 2007-06-12 14:18:00 +0200
+++ ext/fts2/fts2_tokenizer1.c 2007-06-20 18:09:46 +0200
@@ -18,11 +18,7 @@
#include <assert.h>
-#if !defined(__APPLE__)
-#include <malloc.h>
-#else
#include <stdlib.h>
-#endif
#include <stdio.h>
#include <string.h>
#include <ctype.h>
|
|
2435 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
1
|
Data corruption in version 3.4.0
|
edit |
When updating to version 3.4.0 a new bug appeared. After executing a statement like "INSERT into xxx (p1, p2, p3) VALUES ( ?, ? ,?)" and binding some string parameters, a statement like "SELECT p1, p2 ,p3 FROM xxx" will return some of the data corrupted. NO changes made to the calling code and it is working just fine with the version 3.2.07. |
2007-Jun-20 14:20:36 by anonymous:
This bug report is not useful in determining if there is a problem.
At the very least you'd have to supply working code, or a schema and example SQL statements to reproduce the bug. |
|
2429 |
code
|
closed
|
2007 Jun
|
danielk1977
|
|
2007 Jun
|
shess
|
1
|
3
|
problem with fts2 snippet() function
|
edit |
There's a problem with the snippet() function when the
corresponding MATCH expression uses the left-most column
of a full-text table. See the attached testfixture script
for an example. Suggested patch follows.
RCS file: /sqlite/sqlite/ext/fts2/fts2.c,v
retrieving revision 1.33
diff -a -u -r1.33 fts2.c
--- ext/fts2/fts2.c 12 Jun 2007 18:20:05 -0000 1.33
+++ ext/fts2/fts2.c 19 Jun 2007 15:01:02 -0000
@@ -3105,7 +3105,7 @@
if( p->q.nTerms==0 ) return;
pFts = p->q.pFts;
nColumn = pFts->nColumn;
- iColumn = p->iCursorType;
+ iColumn = (p->iCursorType - QUERY_FULLTEXT);
if( iColumn<0 || iColumn>=nColumn ){
iFirst = 0;
iLast = nColumn-1;
|
2007-Jun-19 18:32:09 by shess:
Looks like it applies to any but the last two columns. |
|
2421 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
1
|
unresolved external
|
edit |
unresolved external for the _sqlite_open,exec,close etc.
referenced from the OBJ file created.. |
The ticket system is for SQLite bugs. General questions on how to use the library and how to compile and link a program should be sent to the mailing list. |
|
2420 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
5
|
5
|
sqlite3_prepare() don't work in php pdo implementation
|
edit |
i've to open this bug again, 'cause it was closed as outside of sqlite even if it's not so (infact the bugged behaviour doesn't occour in the pdo extension with a "correct" libsqlite - ie: 3.3.4)
I'm using SQLITE drivers for PHP's PDO extension. This extension binds abastract layered prepared statement functions to the specific driver's ones.
Specifically, PHP code calls sqlite3_prepare() function (see: http://cvs.php.net/viewvc.cgi/pecl/pdo_sqlite/sqlite_driver.c?revision=1.33&view=markup)
Somewhere between libsqlite 3.3.5 and 3.3.12 (i've tested these two version only) the result from calling sqlite3_prepare() went corrupted (the binding between value and placeholder in the prepared statement doesn't work). |
2007-Jun-17 21:02:49 by anonymous:
Someone who uses PHP would have to run it through valgrind to find the problem in the PHP wrapper. If you post the output of valgrind someone will take a look.
2007-Jun-17 21:39:24 by anonymous:
> Somewhere between libsqlite 3.3.5 and 3.3.12 ... the result
> from calling sqlite3_prepare() went corrupted
Or maybe PHP had a bug in its sqlite3_prepare() usage which was triggered by a change in libsqlite.
If it really is an SQLite3 bug, someone (you, maybe?) will be able to come up with a piece of example code using the C API which demonstrates the "bug". If such an example isn't available, it seems entirely reasonable to assume that the "bug" isn't in SQLite. Even if someone doesn't just close the ticket, you're probably not going to get a fix for a problem which can only be reproduced if the SQLite maintainers install PHP.
2007-Jun-18 01:56:09 by anonymous:
This is an sqlite ticket system. Please post your question to the sqlite mailing list with a short complete PHP example that exhibits the unstated problem.
If you can demonstrate the problem using the sqlite3 commandline shell, or via Tcl or via C code using the sqlite API then please re-open this ticket.
2007-Jun-18 07:45:42 by anonymous:
> Or maybe PHP had a bug in its sqlite3_prepare() usage
> which was triggered by a change in libsqlite.
ok, it could be, but as far as it is demostrated neither my hypothesis
nor this one, i think more research is needed befor closing the bug, isn't it?
> If it really is an SQLite3 bug, someone (you, maybe?) will be
> able to come up with a piece of example code using the
> C API which demonstrates the "bug".
i put a link to pdo source code which uses the c api, isn't it enough as example code?
2007-Jun-18 10:49:33 by anonymous:
> i think more research is needed befor closing the bug, isn't it?
I think more research was needed before opening the bug. For example, SQLite has a really nice ticket system. Did you search it for similar bugs? 3.3.12 has been out for quite a while, so if this was a core problem there may already a report of the same problem affecting more systems/bindings/whatever. If there is no such report, it's probably a PDO problem. If you didn't bother searching, that's just another reason to just close this ticket.
Anyhow, if you don't want the ticket closed, just re-open it.
> i put a link to pdo source code which uses the c api, isn't
> it enough as example code?
If, by itself, it demonstrates the bug.
If you actually want someone to fix this, you're going to have to overcome the initial "is this my problem?" question a SQLite maintainer is going to ask when they see this ticket. If the answer to that question is anything but a clear "yes", the best case is that the ticket will be closed with a "not reproducible" or "not in sqlite" or whatever (this is slightly better than just having the ticket get ignored, which is the other likely situation).
2007-Jun-21 07:36:53 by anonymous:
> If there is no such report, it's probably a PDO problem.
this is quite the same i was told on php bug center: if there's no such report, it's probably an sqlite problem.
no one, both here and there, seems to be interested in finding if the bug affected the software he's working on. free to do so, but i'm used differently on my own code.
> If you didn't bother searching, that's just another
> reason to just close this ticket.
that's a speech! it's surely most important being intransigent with awful user than caring about bugs.
it's a pity that fine sofwtare often has nasty developing community, the only thing an user could do about this kind of matters is to search his resources elsewhere, that's what i'll do: no more sqlite for me, i hope you'd appreciate the loss of a real pain user.
2007-Jun-21 07:48:14 by anonymous:
> If you actually want someone to fix this, you're going to have to
> overcome the initial "is this my problem?" question a SQLite
> maintainer is going to ask when they see this ticket.
first of all no one ask anything like so, the first ticket i opened on the subject was even closed with no comment at all from people who closed it.
as for the sqlite maintainer's problem: which ones would be? if a code maintener is not interested in bugged behaviour what should he be interested in?
i'm happy when people warns me about potential bugs in my code, 'cause this improve its quality, and i use to made my survey about what could be the causes: that's because good software is something to be proud of and that deserves my attention, most of all if it's mine.
if you haven't this basic attutidue how could you dedicate yourself to code's maintenance?
> If the answer to that question is anything but a clear "yes",
> the best case is that the ticket will be closed
so it's more important etiquette for you than have good code? that's a strange way to care about software improvement.
2007-Jun-21 12:44:48 by drh:
Two points:
- The official maintainers of SQLite all have logins. When we close
tickets, our logins appear by the close message. And when we add
comments, our names appear at the top of the comment. The SQLite
ticketing system, however, allows any anonymous user to modify a
ticket - even close a ticket - anytime they want. And a few of
the 10000 or so daily anonymous visitors to this site do take the
time to go in an clean up a ticket here or there. I am very
grateful for the help and hope it continues. But on the other hand,
you should not confuse the actions of anonymous users with the
actions of maintainers. Up until this comment, no maintainer has
taken any action on this ticket - everything up until now has been
done by anonymous passers-by.
- On the other hand, the assessment of the anonymous passers-by seems
to have been quite reasonable. The original problem statement in
this ticket has very low credibility. SQLite is very, very
externsively tested, so a serious problem in sqlite3_prepare()
is unlikely to go unnoticed for long. It is true that we do
not test against PHP here, but there are thousands of PHP+SQLite
users, many of whom write very precise and well-crafted bug
reports when things go wrong. Version 3.3.12 has been out for
almost half a year and I have not heard a peep from any of these
people which suggests to me that they are not having any problems.
In addition, the original bug report gives us only a
vague description of
the problem: there is no PHP script or C code or SQL
statement or anything else that might help us isolate the problem.
This suggests that the original bug reporter is unclear about
what is going on and perhaps what they are doing. All of these
factors conspire to give this bug report very low credibility.
So we, the official maintainers, did not object when
anonymous users closed the ticket.
We are appreciative of any and all bug reports and we read every
one. We do not want to do anything to discourage people from
entering new bug reports. On the other hand, if you want us
to act energetically on your bug report, the best way to make
that happen is to state precisely and consisely what the problem
is and provide a means for us to reproduce it. Bug reports with
vague problem statements about "doesn't work with PHP" tend to
languish since it is unclear what, if anything, we can do about
them.
2007-Jun-22 08:56:20 by anonymous:
> On the other hand, if you want us to act energetically on your bug
> report, the best way to make that happen is to state precisely and
> consisely what the problem is and provide a means for us to
> reproduce it. Bug reports with vague problem statements about
> "doesn't work withPHP" tend to languish since it is unclear
> what, if anything, we can do about them.
The matter is that my ticket was closed before I could produce any accurate code examples or requested test. I was asked to send a valgrind output, for example, but at the time I read that message the ticket was already closed.
I don't pretend "energically acting", it could be sufficient that the ticket were payed attention to. I repeat myself: when I receive a bug report I use to spend at least a few moments in order to ask the reporter the info I need to understand if it were really a bug or not. None of this was done here: it was preferred to ignore the ticket before any further details could be given, relying on the fact that "if no one had reported it before then it shouldn't exist".
Last thing: dropping responsibilty for bad managed ticket to anonymous user doesn't free the mainteiner from it, if they endorse anonymous' behaviour.
2007-Jun-22 11:13:32 by anonymous:
I think you might be misunderstanding the meaning of a "closed" ticket here. While it's true that in many ticket systems, a "closed" state is the end-of-the-line for a ticket, with CVSTrac it's not permanent. If you don't think the ticket should be closed, add remarks with additional information about the bug and just change the status back to what you think is appropriate. There are no "workflow" controls that will stop this.
Basically, in the context of SQLite's ticket system, all that "closed" means is "the maintainers can't do anything more with this ticket". You seem to be reading it more as "screw you, go away", which is entirely understandable if you've dealt with more "sophisticated" ticket systems. |
|
2412 |
build
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
a.rottmann
|
1
|
1
|
Can't make Sqlite 3.3.17 on Solaris 10 X86
|
edit |
Can't build Sqlite3.3.17 on Solaris 10 X86, make failed to make, the last two commands are as following:
./libtool --mode=link gcc -g -O2 -I. -I../sqlite-3.3.17/src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -o libsqlite3.la alter.lo analyze.lo attach.lo auth.lo btree.lo build.lo callback.lo complete.lo date.lo delete.lo expr.lo func.lo hash.lo insert.lo loadext.lo main.lo opcodes.lo os.lo os_unix.lo os_win.lo os_os2.lo pager.lo parse.lo pragma.lo prepare.lo printf.lo random.lo select.lo table.lo tokenize.lo trigger.lo update.lo util.lo vacuum.lo vdbe.lo vdbeapi.lo vdbeaux.lo vdbefifo.lo vdbemem.lo where.lo utf.lo legacy.lo vtab.lo \
-rpath /usr/local/lib -version-info "8:6:8"
gcc -shared -Wl,-h -Wl,libsqlite3.so.0 -o .libs/libsqlite3.so.0.8.6 .libs/alter.o .libs/analyze.o .libs/attach.o .libs/auth.o .libs/btree.o .libs/build.o .libs/callback.o .libs/complete.o .libs/date.o .libs/delete.o .libs/expr.o .libs/func.o .libs/hash.o .libs/insert.o .libs/loadext.o .libs/main.o .libs/opcodes.o .libs/os.o .libs/os_unix.o .libs/os_win.o .libs/os_os2.o .libs/pager.o .libs/parse.o .libs/pragma.o .libs/prepare.o .libs/printf.o .libs/random.o .libs/select.o .libs/table.o .libs/tokenize.o .libs/trigger.o .libs/update.o .libs/util.o .libs/vacuum.o .libs/vdbe.o .libs/vdbeapi.o .libs/vdbeaux.o .libs/vdbefifo.o .libs/vdbemem.o .libs/where.o .libs/utf.o .libs/legacy.o .libs/vtab.o -lc
(cd .libs && rm -f libsqlite3.so.0 && ln -s libsqlite3.so.0.8.6 libsqlite3.so.0)
(cd .libs && rm -f libsqlite3.so && ln -s libsqlite3.so.0.8.6 libsqlite3.so)
false cru .libs/libsqlite3.a alter.o analyze.o attach.o auth.o btree.o build.o callback.o complete.o date.o delete.o expr.o func.o hash.o insert.o loadext.o main.o opcodes.o os.o os_unix.o os_win.o os_os2.o pager.o parse.o pragma.o prepare.o printf.o random.o select.o table.o tokenize.o trigger.o update.o util.o vacuum.o vdbe.o vdbeapi.o vdbeaux.o vdbefifo.o vdbemem.o where.o utf.o legacy.o vtab.o
make: *** [libsqlite3.la] Error 1
|
2007-Jun-13 07:36:18 by anonymous:
I am Amber, my email address is :guxiaobo1982 at hotmail dot com
2007-Jun-13 13:37:02 by anonymous:
configure is not finding 'ar' and is using 'false' instead.
Change 'false' to 'ar' in the generated Makefile and see what happens. If that still fails, install the appropriate version of GNU ar.
2007-Jun-15 00:59:11 by anonymous:
ThanksCit is due to arB |
|
2405 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
1
|
sqlite3_prepare() don't work in php pdo implementation
|
edit |
I'm using SQLITE drivers for PHP's PDO extension. This extension binds abastract layered prepared statement functions to the specific driver's ones.
Specifically, PHP code calls sqlite3_prepare() function (see: http://cvs.php.net/viewvc.cgi/pecl/pdo_sqlite/sqlite_driver.c?revision=1.33&view=markup)
Somewhere between libsqlite 3.3.5 and 3.3.12 (i've tested these two version only) the result from calling sqlite3_prepare() went corrupted (the binding between value and placeholder in the prepared statement doesn't work). |
2007-Jun-08 12:17:16 by anonymous:
3.3.7 works for me with PHP 5.2.1 (so the range is a bit smaller)
2007-Jun-17 17:03:16 by anonymous:
the bug it's not outside of sqlite, the demonstration is that the bugged behaviour depends on libsqlite version (excluding the pdo lib for sqlite) |
|
2402 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
3
|
3
|
Left Outer Join and Where clause
|
edit |
Is this a bug or is it how WHERE is supposed to work with LEFT OUTER JOIN?
CREATE TABLE t1(a,b);
INSERT INTO t1 VALUES(1,2);
INSERT INTO t1 VALUES(NULL,2);
INSERT INTO t1 VALUES(3,NULL);
CREATE TABLE t2(x,y);
INSERT INTO t2 VALUES(2,3);
INSERT INTO t2 VALUES(NULL,1);
select * from t1 left join t2 where x=b;
a b x y
---------- ---------- ---------- ----------
1 2 2 3
2 2 3
select * from t1 left join t2 on x=b;
a b x y
---------- ---------- ---------- ----------
1 2 2 3
2 2 3
3
|
2007-Jun-07 19:14:51 by drh:
This is correct behavior. Result rows are excluded if the
WHERE clause is NULL, but can be included if the ON clause
is NULL. |
|
2400 |
code
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
4
|
4
|
SELECT COUNT (*); returns 1 rather than 0.
|
edit |
In a command shell under linux the following commands were used, with my annotations prefixed by '--'
justin@buttercup:~$ sqlite t.db
SQLite version 2.8.17
Enter ".help" for instructions
sqlite> SELECT COUNT (*);
1
-- I'd expect a 0 result here.
sqlite> CREATE TABLE test (a,b);
sqlite> INSERT INTO test VALUES ("hello","there");
sqlite> SELECT COUNT (*) FROM test;
1
-- Seems fine; it's not an off-by-one error.
sqlite> CREATE TABLE test2 (a,b);
sqlite> SELECT COUNT (*) FROM test2;
0
-- Seems to be that an empty table always returns 0.
It seems that when SELECT COUNT (*); is used on its own, with no table to select from, the answer 1 is given despite there being no rows returned. Is that right ? |
There is a single implicit row returned by a SELECT with no
FROM clause. The same reason statements like "SELECT 1+1"
return a single row. |
|
2395 |
todo
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
mani
|
4
|
1
|
SQLite3 cmd prompt interface problem
|
edit |
I am unable to run sqlite3 command. When I enter sqlite3 Test.db from command line on windows XP nothing happens. When I try to create a table its throws a syntax error for the first line. Below is the snapshot of the problem.
SQLite version 3.3.17
Enter ".help" for instructions
sqlite> sqlite3 test.db
...> create table TB1(one varchar(10);
SQL error: near "sqlite3": syntax error
sqlite> |
|
2394 |
todo
|
closed
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
mani
|
4
|
1
|
SQLite3 cmd prompt interface problem
|
edit |
I am unable to run sqlite3 command. When I enter sqlite3 Test.db from command line on windows XP nothing happens. When I try to create a table its throws a syntax error for the first line. Below is the snapshot of the problem.
SQLite version 3.3.17
Enter ".help" for instructions
sqlite> sqlite3 test.db
...> create table TB1(one varchar(10);
SQL error: near "sqlite3": syntax error
sqlite>
|
This is not a bug. Please use the mailing list for these sorts of questions. |
|
2391 |
todo
|
closed
|
2007 May
|
danielk1977
|
|
2007 May
|
danielk1977
|
1
|
1
|
Inconsistent behaviour from explicit collate clauses.
|
edit |
Usually, explicit collation sequences take precedence over implicit
ones. For example, in the following:
CREATE TABLE t1(x COLLATE c1);
SELECT * FROM t1 WHERE x = 'value' COLLATE c2;
the collation sequence "c2" would be used. However, if an index
is created on table t1 and then the query rerun, collation sequence
c1 is used.
CREATE INDEX i1 ON t1(x);
SELECT * FROM t1 WHERE x = 'value' COLLATE c2;
|
|
2390 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
drh
|
1
|
1
|
defect in select with max(id)
|
edit |
Hi,
Defect related to select statement on scalars.
OS: SuSE9.0
>create table test(id integer,col text);
>echo "this table has no records"
>select max(id) from test where col='aaa';
>echo "select statement return a row and when accessed application crash"
regards
ragha |
2007-May-29 04:19:10 by anonymous:
I can't reproduce the crash. Select max(id) on an empty table will return NULL. Are you running these commands within the commandline sqlite3 or via the C API?
2007-May-29 15:07:31 by anonymous:
Am using C API.
Code is as below [search for ERROR key]
CppSQLite3Query CppSQLite3DB::execQuery(const char* szSQL)
{
checkDB();
sqlite3_stmt* pVM = compile(szSQL);
int nRet = sqlite3_step(pVM);//ERROR:On completion of this statement nRet= SQLITE_ROW for the above sql query [select max(id),xx from tbl;
if (nRet == SQLITE_DONE)
{
// no rows
return CppSQLite3Query(mpDB, pVM, true/*eof*/);
}
else if (nRet == SQLITE_ROW) //ERROR
{
// at least 1 row
return CppSQLite3Query(mpDB, pVM, false/*eof*/);
}
else
{
nRet = sqlite3_finalize(pVM);
const char* szError= sqlite3_errmsg(mpDB);
throw CppSQLite3Exception(nRet, (char*)szError, DONT_DELETE_MSG);
}
}
2007-May-29 15:49:38 by anonymous:
I don't think there is a problem here.
Please consult the API documentation.
2007-May-30 08:08:22 by anonymous:
It's perfectly correct result, it returns one row with a one column containing NULL. |
|
2389 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 Jun
|
|
1
|
1
|
database placed in the non ASCII named folder could not be opened
|
edit |
Just try to open database placed in the folder whose name consists of non ASCII characters. Versions of SQLite about year ago could and new version could not open such a database. It is a great problem for us in Poland.
We use XP or Vista (Polish versions). Database can't be stored in any folder named with Cp1250 characters, example: C:\gęś\qwe.sdb
Error message: "unable to open database file", when we change name to C:\ges\qwe.sdb it works
We connect to the database through Delphi 2007 or through sqlite3.exe shell |
This works under some circumstances (see the attached Tcl
script for the test I tried on Linux) so we need more information:
What OS/OS Version are you using?
What is the full database path?
What error is returned?
Thanks,
Dan.
2007-May-29 09:29:31 by anonymous:
Let me assume that the original poster uses Windows (maybe even 9x). The thing is that sqlite3_open function accepts the file name parameter as UTF8 string and not a string in the ANSI character set used in Windows, so you have to explicitly use UTF8 file names in the application.
2007-May-29 15:41:27 by anonymous:
Delphi uses ANSI encoded strings by default. You have to convert path and file name to UTF8 encoding before passing it to sqlite3_open() :
sqlite3_open(PAnsiChar(AnsiToUtf8(FileName)));
2007-Jun-11 11:21:59 by danielk1977:
Assuming the above comment fixes this problem. |
|
2387 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
1
|
1
|
query: problem with update anagrafica SET nome='nome' where id = '4';
|
edit |
when execute a query update into table (ex.anagrafica) there's no update (i try with 3.3.6 to 3.3.17 api and a command line tools like sqlite3.exe)
for example:
my database have this table
CREATE TABLE anagrafica(
id int(8),
nome varchar(32)
);
my command step:
insert into anagrafica VALUES ('4','test');
update anagrafica SET nome="nome" where id = "4";
and there's no update (the column 'name' remain with value 'test')
(select * from anagrafica; --> result: 4|test)
but if i change with:
update anagrafica SET nome="nome1" where id = "4";
all work's fine
if i try:
select * from anagrafica; ---> result: 4|nome1 |
Use single quotes around 'nome' to treat it as a string literal. Otherwise SQL treats it like set nome = nome (i.e., set it to the same thing). |
|
2386 |
doc
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
5
|
4
|
Suggestion for wiki speed comparisson: order by, group by, subselect
|
edit |
It would be very nice to have on the speed comparisson wiki page tests for order by, group by, and subselects.
It should be trivial to add and be very meaningful.
Just a suggestion. Thanks! |
The Wiki is open to everyone. Feel free to add any new speed comparison you like. |
|
2385 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
5
|
4
|
Comment for SQLITE_VERSION_NUMBER has a typo (missing zero).
|
edit |
** The SQLITE_VERSION_NUMBER is an integer with the value
** (X*100000 + Y*1000 + Z). For example, for version "3.1.1beta",
** SQLITE_VERSION_NUMBER is set to 3001001. To detect if they are using
** version 3.1.1 or greater at compile time, programs may use the test
** (SQLITE_VERSION_NUMBER>=3001001).
*/
#ifdef SQLITE_VERSION_NUMBER
# undef SQLITE_VERSION_NUMBER
#endif
#define SQLITE_VERSION_NUMBER 3003017
In the second line above, X*100000 should be X*1000000. |
Duplicate of #2384. See [4038]
. |
|
2384 |
doc
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
1
|
5
|
an error in comments
|
edit |
Please review the lines 65-69 of the sqlite3.c. Yes, it's true, it's just comments:
** The SQLITE_VERSION_NUMBER is an integer with the value
** (X*100000 + Y*1000 + Z). For example, for version "3.1.1beta",
** SQLITE_VERSION_NUMBER is set to 3001001. To detect if they are using
** version 3.1.1 or greater at compile time, programs may use the test
** (SQLITE_VERSION_NUMBER>=3001001).
So let do some mathematics: X.Y.Z ==> 3.1.1 THEN X is 3, Y is 1 and Z is 1. SQLITE_VERSION_NUMBER = X*100000 + Y*1000 + Z = 3*100000 + 1*1000 + 1 = 300000 + 1000 + 1 = 301001 (???!!! A N D N O T 3001001) |
Thanks. |
|
2380 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
1
|
1
|
Order By Collum1, Collum2, Collum3 for Pocket PC incorrect in device
|
edit |
Order By Collum1, Collum2, Collum3 for Pocket PC WM5.0 and Pocket PC 2003 correct in Emulator but not correct on Pocket PC device.
nmtdhbk@yahoo.com
thangnm@vega.com.vn |
Cannot reproduce. Please provide a test case with complete schema, data and the actual query and then re-open this ticket. |
|
2375 |
doc
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
4
|
4
|
sqlite3_exec docs mentions sqlite3_reset
|
edit |
The documentation for sqlite3_exec (capi3.html) says that it invokes sqlite3_reset (and suggests it gets invoked after sqlite3_finalize). The actual (amalgamated) source code does not call sqlite3_reset, unless I missed some trickery.
The documenation may say a bit more about relation between sqlite3_reset and sqlite3_finalize: whether it is OK to call sqlite3_reset after sqlite3_finalize or whether this is a no-go. |
Those passages are not about sqlite3_exec(), they are supposed
to be an overview of how to execute SQL queries. The details
are in capi3ref.html.
It's not OK to call sqlite3_reset() after sqlite3_finalize().
sqlite3_finalize() invalidates the statement handle and passing
it to another function will likely cause a crash. |
|
2370 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
3
|
2
|
Data is converted without me telling it to do so
|
edit |
I've created a table that looks like this:
CREATE TABLE Database (Name NVARCHAR(100) PRIMARY KEY, Value NONE)
I chose NONE, because "A column with affinity NONE does not prefer one storage class over another. It makes no attempt to coerce data before it is inserted.", as per the documentation.
So I'll happily insert some data:
INSERT INTO Database (Name,Value) VALUES ('Version','1.0')
But to surprise, a SELECT reveals that not '1.0' has been inserted, but '1', even tough it was explicitly inserted as a string, as proven by the single quotes. |
2007-May-17 22:16:55 by drh:
In the same document which you quote, just
below the sentence you quote, in section 2.1 is an explanation of
how the column affinity is determined. The 3rd case is the one you
are interested in.
Perhaps it would be clearer
if a declared datatype of "NONE" would result in a column affinity
of "NONE", but to change that now would break backwards compatibility
which is something we are unwilling to do.
2007-May-17 22:19:14 by anonymous:
I think that a column with affinity NONE means to not specify anything for the column type, as follows:
CREATE TABLE Database (Name NVARCHAR(100) PRIMARY KEY, Value);
INSERT INTO Database (Name,Value) VALUES ('Version1.0','1.0');
INSERT INTO Database (Name,Value) VALUES ('Version2.0',2.0);
INSERT INTO Database (Name,Value) VALUES ('Version2',2);
select * from Database;
Version1.0|1.0
Version2.0|2.0
Version2|2
|
|
2369 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
3
|
3
|
if you do a configure --prefix=/home/someotherdir tcl installs wrong
|
edit |
install tcl to a "private" directory
install sqlite3 to the same "private" directory
./configure --prefix=/home/whatever
make (works now)
make install yields
tclsh ./tclinstaller.tcl 3.3
can't create directory "/usr/share/tcl8.4/sqlite3": permission denied
while executing
"file mkdir $LIBDIR/sqlite3"
(file "./tclinstaller.tcl" line 15)
make: *** [tcl_install] Error 1
if you go to makefile and change the line HAVE_TCL = 1
to
HAVE_TCL =
then it installs correctly.
Note also that I wanted to 'just' install sqlite3, not it and its tcl bindings, which thing appears either hard or impossible from the current source distros. It would have been nice to have a configure option to 'don't attempt to compile tcl bindings', but that was overcomeable. Thank you! |
Try the --disable-tcl option:
./configure --prefix=/home/whatever --disable-tcl
It works for me. |
|
2368 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
1
|
1
|
vdbeblob.c missing from Makefile.in
|
edit |
This is also the cause of the testfixture default build+link problem. |
Thanks again. |
|
2367 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
2
|
2
|
SQLITE_OMIT_INCRBLOB breaks default "make test"
|
edit |
Running "./configure && make test" on a new tree pulled from CVS yields a failed link for testfixture and many unresolved externals dealing with SQLITE_OMIT_INCRBLOB symbols. (Note: I am not #defining SQLITE_OMIT_INCRBLOB in the build).
I think that vdbemem.c and vdbeblob.c should be added to TESTSRC in Makefile.in.
It might be more maintainable if every sqlite3 library .c file were listed in TESTSRC. Or perhaps testfixture should be built using the amalgomation.
There are also these warnings, which might be harmless, but seem wrong:
./src/tclsqlite.c:297: warning: excess elements in struct initializer
./src/tclsqlite.c:297: warning: (near initialization for `IncrblobChannelType')
./src/tclsqlite.c:297: warning: excess elements in struct initializer
./src/tclsqlite.c:297: warning: (near initialization for `IncrblobChannelType')
Compiled with Tcl 8.4. |
|
2366 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
4
|
4
|
"make test" failures: pragma-1.15, pragma-1.16
|
edit |
Fresh CVS checkout followed by "./configure && make test"
pragma-1.15...
Expected: [1]
Got: []
pragma-1.16...
Expected: [0]
Got: []
These tests deal with PRAGMA vdbe_listing. Perhaps the default compile flags for testfixture do not enable vdbe_listing support. |
|
2365 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
1
|
1
|
incrvacuum2, zeroblob regressions from check-ins on 2007-May-16
|
edit |
Windows, Tcl 8.4, -DSQLITE_OMIT_INCRBLOB=1, make test
incrvacuum2-1.1...
Expected: [32768]
Got: [3072]
incrvacuum2-1.2...
Expected: [31744]
Got: [3072]
incrvacuum2-1.3...
Expected: [26624]
Got: [3072]
incrvacuum2-1.4... Ok
incrvacuum2-2.1...
Expected: [32768 32768]
Got: [3072 3072]
incrvacuum2-2.2...
Expected: [32768 31744]
Got: [3072 3072]
incrvacuum2-2.3...
Expected: [32768 26624]
Got: [3072 3072]
incrvacuum2-2.4...
Expected: [27648 26624]
Got: [3072 3072]
incrvacuum2-2.5...
Expected: [27648 3072]
Got: [3072 3072]
incrvacuum2-2.6...
Expected: [26624 3072]
Got: [3072 3072]
zeroblob-1.1...
Expected: [10]
Got: [0]
zeroblob-1.2...
Expected: [10000]
Got: [0]
zeroblob-1.3...
Expected: [10010]
Got: [0]
zeroblob-1.4...
Expected: [1 10000 10000 1]
Got: [1 0 0 1]
zeroblob-1.5...
Expected: [11]
Got: [0]
zeroblob-1.6...
Expected: [1 10000 10000 1 10000 10000]
Got: [1 0 0 1 0 0]
zeroblob-1.7...
Expected: [10]
Got: [0]
zeroblob-1.8...
Expected: [10000 10000]
Got: [0 0]
zeroblob-2.1... Ok
zeroblob-2.2... Ok
zeroblob-3.1...
Expected: [1]
Got: [2]
|
Thanks. |
|
2362 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
4
|
4
|
Can't add a column with ALTER TABLE
|
edit |
I have a table named "students" with only one column:
sqlite> .schema students
CREATE TABLE students ("id" INTEGER PRIMARY KEY NOT NULL);
I'm trying to add a new column, but I get a syntax error:
sqlite> alter table students add column photo blob;
SQL error: near "add": syntax error
I tried doing the same thing with a Rails migration file and got the same error:
def self.up
add_column :students, :photo, :binary
end
% rake db:migrate
-- add_column(:students, :photo, :binary)
rake aborted!
SQLite3::SQLException: near "ADD": syntax error: ALTER TABLE students ADD "photo" blob
The same problem occurs with other data types, e.g. changing "blob" to "integer" gives the same message. |
2007-May-16 05:21:21 by danielk1977:
ALTER TABLE ADD COLUMN was not added until version 3.2.0
You should upgrade if possible. 3.1.3 is over 2 years old now. |
|
2361 |
new
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
3
|
3
|
Why is no LIMIT suported in UPDATE-queries?
|
edit |
This is a question and a feature-request:
if I have a query like
UPDATE people SET capo='new' WHERE capo='old';
the execution would be faster (the table people has many entries) if I could tell how much times capo has the old value (i know it). This could be done using a LIMIT:
UPDATE people SET capo='new' WHERE capo='old' LIMIT 3;
Thanks |
2007-May-15 22:37:47 by drh:
UPDATE people SET capo='new' WHERE rowid IN
(SELECT rowid FROM people WHERE capo='old' LIMIT 3); |
|
2358 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
3
|
4
|
Incorrect index chosen for query
|
edit |
I have a table with following columns:
- type_id (int)
- some_value (varchar)
Indexes:
- idx_type (type_id)
- idx_some_value (some_value)
- idx_type_value (type_id,some_value)
A query is invoked:
select * from table where type_id = 10 and some_value = 'txt'
The behavior is correct: idx_type_value is used for this query.
However, when the query looks like this:
select * from table where type_id = 10 and some_value IN ('txt')
the index used is idx_type.
I looked at the file where.c. I discovered that the additional column for an index (some_value IN (...)) adds some estimated cost for an index (row 1546 in where.c), and that's why the index with single column is chosen.
Correct me if I'm wrong, but shouldn't the number of matched columns have priority over estimated cost?
The solution is to change row 1617 in where.c from:
to
if( nEq >= bestNEq && cost < lowestCost){
Best regards,
Jacek
|
2007-May-14 13:03:40 by anonymous:
The changed line should be:
if( nEq > bestNEq || (nEq == bestNEq && cost < lowestCost)) {
Jacek
2007-May-14 13:13:10 by anonymous:
It would be helpful if you posted some SQL create table/index statements with EXPLAIN QUERY PLAN showing the wrong index being selected.
2007-May-14 13:31:50 by drh:
The best solution is for your to drop the TYPE_ID index since
it is redundant. The IDX_TYPE_VALUE index is a superset of
TYPE_ID. Dropping TYPE_ID will make your database smaller and
faster. |
|
2357 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 Jun
|
anonymous
|
2
|
2
|
Crash in sqlite3PagerClose when SQLITE_ENABLE_MEMORY_MANAGEMENT is def
|
edit |
I have used the latest amalgamated SQLite code to build a dll, with SQLITE_ENABLE_MEMORY_MANAGEMENT defined and set the soft upper limit to 2^25 (32MB).
My app runs multi-threaded (is an ISAPI dll called from IIS on Windows) - I create a pool of database connections at startup and whenever a thread needs to access the database, it asks the pool for an idle connection, calls sqlite3_soft_heap_limit((1<<25)/pool_size), does its stuff, calls sqlite3_soft_heap_limit(0) and releases the database connection.
All works fine, except that when the dll is unloaded, there is a crash in sqlite3PagerClose() - pTmp becomes NULL in the for loop in the code below. Debugger tells me that pTsd->pager is NULL (all field of pTsd are 0, except for nAlloc which is -16754).
#ifdef SQLITE_ENABLE_MEMORY_MANAGEMENT
/* Remove the pager from the linked list of pagers starting at
** ThreadData.pPager if memory-management is enabled.
*/
if( pPager==pTsd->pPager ){
pTsd->pPager = pPager->pNext;
}else{
Pager *pTmp;
for(pTmp = pTsd->pPager; pTmp->pNext!=pPager; pTmp=pTmp->pNext){}
pTmp->pNext = pPager->pNext;
}
#endif
I guess it is not too serious because it happens only during shut-down and probably after all database ops have been committed to the disk, but still, it is a crash.
I am building the amalgamated code with Intel 9.1 on WindowsXP, crash seen in debug mode.
|
2007-May-14 03:04:26 by anonymous:
Can you post a small self-contained test program that reliably demonstrates this crash?
2007-May-14 10:28:22 by drh:
One wonders if this is somehow related to #2277.
2007-Jun-27 00:13:01 by drh:
See the FAQ for information about using
SQLITE_ENABLE_MEMORY_MANAGEMENT and threads. |
|
2355 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
3
|
4
|
Segfault with looooong sql string
|
edit |
Good day.
I am using sqlite (amalgama) in my apache module.
Following sequience work OK for me:
const char *create_table = " \
CREATE TABLE IF NOT EXISTS log \
( \
peer_ip TEXT, \
date INTEGER, \
gmt_diff INTEGER, \
category TEXT, \
policy TEXT, \
client_ip TEXT, \
client_port TEXT, \
host_name TEXT, \
dest_url TEXT, \
request_method TEXT, \
site_profile TEXT, \
matched_pattern TEXT, \
error_string TEXT, \
http_headers TEXT, \
text BLOB \
) \
";
return sqlite3_exec(
db_handler,
create_table,
NULL, NULL, NULL
);
But when I change format to
const char *create_table = " \
CREATE TABLE IF NOT EXISTS log \
( \
peer_ip TEXT, \
date INTEGER, \
gmt_diff INTEGER, \
category TEXT, \
policy TEXT, \
client_ip TEXT, \
client_port TEXT, \
host_name TEXT, \
dest_url TEXT, \
request_method TEXT, \
site_profile TEXT, \
matched_pattern TEXT, \
error_string TEXT, \
http_headers TEXT, \
text BLOB \
) \
";
I.e make string a bit longer, my module (with whole apache) is segfault.
It's looks like there is a buffer overflow somewhere in the sqlite code.
I was trying to find it by myself, but soon gave up :(
Valery |
2007-May-14 04:09:15 by danielk1977:
I tried to reproduce this, but could not. Does the attached C program
crash for you?
Can we have a stack trace from the apache crash?
Thanks.
2007-May-14 11:40:14 by drh:
The automated test suite for SQLite uses CREATE TABLE statements
that are much, much bigger than the example above. So we seriously
doubt the problem is a buffer overflow in SQLite. Since we are
unable to reproduce the problem, pending evidence to the contrary,
we will assume this is a problem in either apache or in the application
and not in SQLite.
2007-May-14 15:37:11 by anonymous:
Long ago I've seen the visual studio 1.xx (can't remember) make a mess of a multi line define after editing the define. When retyping the lines all was well. Maybe its an editor issue. |
|
2353 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
1
|
1
|
Issue with selecting values of indexed column
|
edit |
I have a database with ~500000 records in the table TAB.
The table has several columns.
One column is INTEGER and other columns are TEXT type.
Also there is an index for column of INTEGER type.
Let say the column of INTEGER type has name XXX.
Now the problem:
1) select * from TAB where XXX >= 10000 order by rowid;
Works very fast (as expected for indexed column).
2) select * from TAB where XXX >= 10000 and XXX <=20000 order by rowid;
Works VERY slowly (as slow as there is no index for XXX).
I have tried to rewrite previous request:
3) select * from TAB where not (XXX < 10000 or XXX > 20000) order by rowid;
This request returns the same records as previous one, but it works as FAST as request from the first example.
What wrong with request in second example?
Also I have noted, after removing "order by rowid" the second example also works fast but the order of records is incorrect. |
2007-May-11 16:15:39 by drh:
This appears to be a request for technical support, not a bug
report. Please use the mailing list for technical support
and reserve tickets for report real bugs. See
http://www.sqlite.org/support.html for information on how
to access the mailing list. |
|
2346 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
1
|
1
|
Inserting a certain integer
|
edit |
Seems to be an issue storing large numbers.
Recreate:
> CREATE TABLE f (i INTEGER);
> INSERT INTO f (i) VALUES (243484607108059);
> SELECT i FROM f;
-37990369602597 (expected 243484607108059)
It is interesting if you look at the HEX for these two numbers.
-37990369602597 => 0xFFFFDD72AD83D3DB
243484607108059 => 0xDD72AD83D3DB
|
2007-May-09 17:53:36 by anonymous:
SQLite version 3.3.13
Enter ".help" for instructions
sqlite> CREATE TABLE f (i INTEGER);
sqlite> INSERT INTO f (i) VALUES (243484607108059);
sqlite> select i from f;
243484607108059
2007-May-09 19:30:23 by drh:
This is a duplicate of ticket #1212. |
|
2338 |
todo
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
4
|
3
|
3.3.17 windows dll download gives 3.2.7
|
edit |
I downloaded the pre-built windows 3.3.17 dll and did a "SELECT sqlite_version()" (via a variant of the ctypes Python code at <http://osdir.com/ml/python.db.pysqlite.user/2006-12/msg00014.html>) and got the response "3.2.7". |
You either have a path problem or python is using a specific version of sqlite. |
|
2332 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
danielk1977
|
1
|
1
|
incrblob: Data error writing large blobs
|
edit |
The new incremental blob interface chokes on large blobs. Data is not stored correctly if it exceeds a certain size (roughly more than 2 MB). See this code to reproduce:
#include <locale.h>
#include <stdio.h>
#include <stdlib.h>
#include "sqlite3.h"
sqlite3 *db;
int check ( int rc ){
if( rc != SQLITE_OK && rc != SQLITE_ROW && rc != SQLITE_DONE ){
printf ("%d - %s\n", rc, sqlite3_errmsg(db) );
}
return rc;
}
const char *fn = "test_blob.db3";
const buf_size = 0x4000 * 2 * 16 * 4;
#pragma argsused
int main(int argc, char* argv[])
{
unsigned char * buf;
int i;
sqlite3_stmt *pStmt;
sqlite3_blob *pBlob;
sqlite_int64 RowId;
remove( fn );
check( sqlite3_open( fn, &db) );
check( sqlite3_exec( db, "CREATE TABLE blobs (k INTEGER PRIMARY KEY, v BLOB);", 0, 0, 0));
check( sqlite3_prepare( db, "INSERT INTO blobs (k, v) VALUES (?,?);", -1, &pStmt, NULL));
check( sqlite3_bind_int ( pStmt, 1, 1) );
check( sqlite3_bind_zeroblob ( pStmt, 2, buf_size ) );
check( sqlite3_step( pStmt) );
check( sqlite3_finalize( pStmt ));
RowId = sqlite3_last_insert_rowid ( db );
check( sqlite3_blob_open ( db, "main", "blobs", "v", RowId, 1, &pBlob ));
buf = sqlite3_malloc( buf_size );
for (i = 0; i < buf_size; i++) {
buf[i] = i % 0xff;
}
check( sqlite3_blob_write( pBlob, buf, buf_size, 0) );
for (i = 0; i < buf_size; i++) {
buf[i] = 0xFF;
}
check( sqlite3_blob_read( pBlob, buf, buf_size, 0) );
for (i = 0; i < buf_size; i++) {
if (buf[i] != i % 0xff ) {
/* Flag error */
printf ("Expected: %d - Found: %d\n", i, buf[i]);
};
}
sqlite3_free( buf );
check( sqlite3_blob_close( pBlob ));
check( sqlite3_close ( db ));
printf ("Done");
scanf ("*%s");
return 0;
}
|
Thanks! |
|
2331 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
|
1
|
1
|
Performance problem with complex where clause
|
edit |
I'm running a query against attached database and it runs very slow - about 5 seconds(on larger database it can ran for a whole minute).
Select [Node_Entity].* From [Node] AS [Node_Node] JOIN [Entity] AS [Node_Entity] ON [Node_Node].LOCAL_ID = [Node_Entity].LOCAL_ID
, [Link] AS [Link_Link] JOIN [Entity] AS [Link_Entity] ON [Link_Link].LOCAL_ID = [Link_Entity].LOCAL_ID
Where ((
(([Link_Link].[Target.Id]='06d15df5-4253-4a65-b91f-cca52da960fe') AND ([Link_Link].[Source.Id]=[Node_Entity].[Id]))
OR (([Link_Link].[Target.Id]=[Node_Entity].[Id]) AND ([Link_Link].[Source.Id]='06d15df5-4253-4a65-b91f-cca52da960fe'))
))
If I remove a part of where clause
" OR (([Link_Link].[Target.Id]=[Node_Entity].[Id]) AND ([Link_Link].[Source.Id]='06d15df5-4253-4a65-b91f-cca52da960fe'))"
It runs in 16 ms.
All .Id fields are indexed |
This would be better answered on the mailing list. |
|
2330 |
code
|
closed
|
2007 May
|
anonymous
|
|
2007 May
|
drh
|
2
|
2
|
Usage of fieldname Session is impossible for where clause
|
edit |
I found a problem when using the word "Session" as a field name. In such case it is impossible to filter out using a where clause. Using same data and structure but with another field name works find. Is this a bug or what meaning has Session ? There is no warning or error message but only wrong or unexpected behaviour. Here is the code to demonstrate this from the command line (but also from within applications).
D:\Boat>sqlite3.exe Crew.sqb
SQLite version 3.3.17
Enter ".help" for instructions
sqlite> .headers on
sqlite> .schema
CREATE TABLE 'Boat1' (
Session varchar(20),
Pos int,
Name varchar(20),
kg int,
Primary key(Session,Pos) );
CREATE TABLE 'Boat2' (
ID varchar(20),
Pos int,
Name varchar(20),
kg int,
Primary key(ID,Pos) );
sqlite> select * from Boat1 where Session="Session";
Session|Pos|Name|kg
2007-04-30|21|Andreas T|60
2007-04-30|31|Udo|61
2007-04-30|41|Manfred|62
2007-04-30|51|Andreas R|63
2007-04-30|61|Alex|64
2007-04-30|71|Simone|55
2007-04-30|81|Cesar|75
2007-04-30|91|Wolfgang|76
2007-04-30|101|Lisa|56
2007-04-30|22|Adalbert|65
2007-04-30|32|Andrea|57
2007-04-30|52|Tim T|52
2007-04-30|62|Andreas S|66
2007-04-30|72|Ralf|67
2007-04-30|82|Joerg K|68
2007-04-30|92|Heike|54
2007-04-30|102|Uwe|72
2007-04-30|42|Karsten|73
2007-04-30|1|Joerg E|55
Session|10|Zusatzgewicht 5kg|5
Session|20|Zusatzgewicht 10kg|10
Session|30|Zusatzgewicht 15kg|15
Session|40|Zusatzgewicht 20kg|20
sqlite> select * from Boat2 where ID="Session";
ID|Pos|Name|kg
Session|10|Zusatzgewicht 5kg|5
Session|20|Zusatzgewicht 10kg|10
Session|30|Zusatzgewicht 15kg|15
Session|40|Zusatzgewicht 20kg|20
sqlite>
One Structure, one Query, two different results. Only difference is the renaming of field Session into eg ID (or something else). |
2007-May-01 10:08:58 by anonymous:
Learn to use correct quotes in SQL or use binding parameters (from code). The first query should be written as
select * from Boat1 where Session='Session'; (note the single quotes)
Otherwise the "Session" string is treated as name of the column and interpreted as such. Of course Session=Session is always true. |
|
2325 |
code
|
closed
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
1
|
1
|
Link Fails w/ SQLITE_OMIT_ALTERTABLE
|
edit |
Compiling the windows zip package (sqlite3.c) from 3.3.17 w/ -DSQLITE_OMIT_ALTERTABLE results in these linkage errors:
sqlite3/sqlite3.o(.text+0x6a24c):sqlite3.c: undefined reference to `sqlite3AlterBeginAddColumn'
sqlite3/sqlite3.o(.text+0x6a39f):sqlite3.c: undefined reference to `sqlite3AlterFinishAddColumn'
sqlite3/sqlite3.o(.text+0x6a3c5):sqlite3.c: undefined reference to `sqlite3AlterRenameTable' |
2007-Apr-27 17:47:07 by drh:
Many of the -DSQLITE_OMIT options do not work when you compile
from the windows ZIP archive. The files there have already been
processed by tools that need to know what is being omitted. If
you want to use SQLITE_OMIT compile-time options, you need to
compile from sources, not preprocessed files. |
|
2317 |
code
|
closed
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
4
|
4
|
Floats rendered to strings differently in WHERE and GROUP BY clauses.
|
edit |
SQLite renders floats differently in the WHERE and in the
GROUP BY clauses.
Observe:
sqlite> CREATE TABLE test(x FLOAT);
sqlite> INSERT INTO test VALUES (1.0);
sqlite> SELECT * FROM test WHERE "A" || x = "A1.0" GROUP BY "A" || x;
1
Note that when rendering x to a string for the WHERE clause, it
becomes "1.0", but for the GROUP BY clause, it becomes "1".
This behavior seems inconsistent. |
SQLite 3.3.16 produces the correct result "1.0". |
|
2316 |
code
|
closed
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
4
|
4
|
2 prepared statements on same database cause RC = 21
|
edit |
Hi,
I used wxSQLite3 to created a database and create 2 prepared statements.
I serialized access to both prepared statements (1 mutex for each), but somehow this was interfering with the other thread his calls.
What happened was the following:
[threadID] function_call
...
[2808] sqlite3_reset
[2808] sqlite3_bind_text
[2352] sqlite3_reset
[2808] sqlite3_bind_int
[2352] sqlite3_bind_text
[2808] sqlite3_bind_int
[2352] sqlite3_bind_int
[2808] sqlite3_bind_int
[2352] sqlite3_bind_int
[2352] sqlite3_bind_int
[2352] sqlite3_bind_blob
[2352] sqlite3_bind_null
[2352] sqlite3_bind_int
[2352] sqlite3_bind_int
[2352] sqlite3_bind_int
[2352] sqlite3_step
[2808] sqlite3_step
So the thread 2808 was interfering with the statement of 2352.
I would suspect SQLite to work on the prepared statement only, and only work on the database if it needed to do that (where it would first check the 'state' it was in, and return RC=busy if it was busy).
But now it returns RC=21 (invalid sequence), which is a little illogical to me.
I solved it by serializing access to the database, not the prepared statements themselves.
Greetz,
Steven |
The user seems to have solved their own problem, so I'm not sure
why this ticket is here.... |
|
2315 |
code
|
closed
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
1
|
1
|
Macro Redefinition Warning
|
edit |
When compiling sqlite3.c from the 3.3.16 zip package, Visual Studio 6.0 gives the following warnings:
sqlite3.c(57066) : warning C4005: 'ARRAYSIZE' : macro redefinition
C:\program files\Microsoft Platform SDK\Include\winnt.h(950) : see previous definition of 'ARRAYSIZE'
This occurs when using the latest platform SDK from Microsoft. The code should be #ifndef'd to fix the warning. |
2007-Apr-23 18:23:48 by rdc:
This is a duplicate of ticket #2311 |
|
2312 |
code
|
closed
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
mike
|
1
|
1
|
Using ODBC. Only saves first 5 characters of text fields. Can you help
|
edit |
I am using the ODBC with Powerbuilder. It is only saving the first 5 characters of any char, text, varchar field. I cannot continue until I have sorted this problem. Is there a setting I need to set in the database to get around this? Please help. Regards John |
Please post your question on the mailing list. |
|
2305 |
doc
|
closed
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
4
|
4
|
Function replace(X,Y,Z) doesn't exist ?
|
edit |
sqlite3
SQLite version 3.3.15
Enter ".help" for instructions
sqlite> select replace('toto','to', 'ti');
SQL error: no such function: replace |
Where did the SQLite binary come from? When I compile
from source the replace function is there. It's in the
pre-compiled shell binaries from the download page too:
dan@linux-7qa0:~/tmp> ./sqlite3-3.3.15.bin
SQLite version 3.3.15
Enter ".help" for instructions
sqlite> select replace('toto', 'to', 'it');
itit
sqlite> .quit
2007-Apr-18 09:08:48 by anonymous:
sorry, you can close this ticket, i have made a mistake ... |
|
2300 |
code
|
closed
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
1
|
1
|
compound query ORDER BY expression problem
|
edit |
CREATE TABLE t4(a TEXT, b TEXT);
INSERT INTO "t4" VALUES('a','1');
INSERT INTO "t4" VALUES('b','2');
INSERT INTO "t4" VALUES('c','3');
SELECT b from t4 union SELECT 3 b order by b;
3
1
2
3
SELECT b from t4 union SELECT 3 b order by +b;
SQL error: ORDER BY term number 1 does not match any result column
sqlite> SELECT b from t4 union all select b from t4 order by -b;
SQL error: ORDER BY term number 1 does not match any result column
|
2007-Apr-13 19:17:27 by drh:
For a compound query, the ORDER BY expressions must be columns
in the result set.
My understand is that standard SQL requires all ORDER BY expressions
everywhere to be expressions from the result set. SQLite relaxes
this requirement for single queries, but for compound queries it
does require that the order by terms be result set columns.
2007-Apr-13 19:28:04 by anonymous:
This is not my understanding of common practise. I often ORDER BY columns - or even complex expression - not present in my result set on several different makes of databases.
If you make such an exception for a single table but not compound queries, then VIEWs are essentially useless.
2007-Apr-13 19:35:52 by anonymous:
I stand corrected - ORACLE does not allow ORDER BY expressions not seen in a compound SELECT's SELECT list.
2007-Apr-13 19:43:20 by anonymous:
The view comment is also wrong, as it transforms this failing query:
select 4 b union select 3 b order by -b;
SQL error: ORDER BY term number 1 does not match any result column
to this:
select * from (select 4 b union select 3 b) order by -b;
which works.
I will close this ticket. |
|
2293 |
code
|
closed
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
2
|
2
|
Extra file operations with sub journal when DB in MEM
|
edit |
Hi, I working with DB created in MEMORY and exec only SELECT query for It. I have found that sqlite create temp file on file system each time and then delete it. What is the purpose of this temp file. Is it possible to turn off creation of this file? It decrease perfomance on my embended system very much. |
2007-Apr-11 01:37:52 by drh:
I think this is a technical support question, not a bug report.
Please ask technical support questions on the SQLite mailing
list. See http://www.sqlite.org/support.html for instructions. |
|
2292 |
code
|
closed
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
1
|
1
|
VACUUM => constraint failed
|
edit |
Behavior not evident in 3.3.13, but exists in 3.3.14/3.3.15.
The only difference between the following two SQL files is the position of the value-ful entry. After loading the first file, VACUUM gives rise to "SQL error: constraint failed". The other file allows VACUUMing without incident.
Script started on Tue 10 Apr 2007 02:01:18 PM EDT
# cat 0
BEGIN TRANSACTION;
CREATE TABLE userinfo(username TEXT PRIMARY KEY,amid TEXT,uid INTEGER,name TEXT);
INSERT INTO "userinfo" VALUES('aaa','00023966',6638,'Alexander^^Au^');
INSERT INTO "userinfo" VALUES('aan001',NULL,NULL,NULL);
INSERT INTO "userinfo" VALUES('ags001',NULL,NULL,NULL);
CREATE UNIQUE INDEX idx_amid ON userinfo(amid);
CREATE UNIQUE INDEX idx_uid ON userinfo(uid);
COMMIT;
#
# cat 1
BEGIN TRANSACTION;
CREATE TABLE userinfo(username TEXT PRIMARY KEY,amid TEXT,uid INTEGER,name TEXT);
INSERT INTO "userinfo" VALUES('aan001',NULL,NULL,NULL);
INSERT INTO "userinfo" VALUES('aaa','00023966',6638,'Alexander^^Au^');
INSERT INTO "userinfo" VALUES('ags001',NULL,NULL,NULL);
CREATE UNIQUE INDEX idx_amid ON userinfo(amid);
CREATE UNIQUE INDEX idx_uid ON userinfo(uid);
COMMIT;
#
# rm db
# sqlite3 -init 0 db
Loading resources from 0
SQLite version 3.3.15
Enter ".help" for instructions
sqlite> vacuum;
SQL error: constraint failed
sqlite> .exit
#
# rm db
# sqlite3 -init 1 db
Loading resources from 1
SQLite version 3.3.15
Enter ".help" for instructions
sqlite> vacuum;
sqlite> .exit
#
script done on Tue 10 Apr 2007 02:02:08 PM EDT
|
2007-Apr-10 19:49:43 by drh:
This appears to be a duplicate of ticket #2291. |
|
2279 |
code
|
closed
|
2007 Mar
|
anonymous
|
|
2007 Mar
|
|
3
|
4
|
sqlite3_exec NULL pointer crash
|
edit |
When calling into sqlite3_exec if the first parameter is NULL (meaning the database handle) then the system will crash. |
2007-Mar-29 21:11:18 by drh:
If it really makes your system crash, that is an OS bug that you
should report to your OS maker.
Perhaps you mean that passing an illegal (eg. NULL) pointer to
sqlite3_exec() makes your program crash? OK. What were you
expecting it to do?
2007-Mar-30 18:58:33 by rdc:
I think it is a bug that sqlite3_exec() can't accept a NULL sqlite3* pointer.
SQLite should validate its API function arguments to a reasonable degree. This particular case seems like something that might be common enough to warrant the extra check. sqlite3_exec should probably return SQLITE_MISUSE in this case.
Simply add a test before (or after) the existing zSql pointer test.
if( db==0 ) return SQLITE_MISUSE;
If you want to get fancier you could (and probably should) also set error message string if that pointer is not null.
if( db==0 ){
rc = SQLITE_MISUSE;
if( pzErrMsg ){
*pzErrMsg = sqlite3_malloc(1+strlen(sqlite3ErrStr(rc)));
if( *pzErrMsg ){
strcpy(*pzErrMsg, sqlite3ErrStr(rc));
}
}
return rc;
}
|
|
2277 |
code
|
closed
|
2007 Mar
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
Incorrect usage of CRITICAL_SECTION and TLS on Windows
|
edit |
We found this problem during our product certification for MS Vista. SQLITE.DLL breaks into WinDbg when been (a) used (b) unloaded. The reasons are (1) Initialized CRITICAL_SECTION, which was created, but not deleted, (2) Allocated index in TLS, which was not deleted as well. We fixed both of then in our local copy of source code.
Plese, contact me slava@raxco.com if you need the changes. |
2007-May-22 22:14:39 by anonymous:
Can you post the changes here?
2007-Jun-27 20:58:25 by anonymous:
What CRITICAL_SECTION is causing this bug ? Can you post your patches (or the fixes) here ? will help us a lot
2007-Jul-28 21:16:33 by anonymous:
The CRITICAL_SECTION being referenced is:
static CRITICAL_SECTION cs
declared in os_win.c
The thread local storage in reference is acquired in sqlite3WinThreadSpecificData().
The critical section is never destroyed via DeleteCriticalSection and will therefore appear as a leaked resource. The TlsAlloc is never matched to a TlsFree and again will appear as a leaked resource.
As a side note, the double checked locking used in sqlite3WinThreadSpecificData() to guard against multiple TLS allocations may or may not survive compiler optimization. The same is true of the spin/sleep in sqlite3WinEnterMutex(). Worst case the compiler generates code that loops indefinately.
Possibly the best solution to these problems is to introduce an API for initializing the critical section and TLS index. Along with an API to perform the inverse. It would the responsiblity of the programmer to ensure that these APIs are called in a thread safe manner prior to the use of any other sqlite APIs. This would be easily achieved by inclusion in the main() of an executable or the initialization and finalization exports for a DLL.
2007-Jul-31 05:27:48 by anonymous:
IMO this is a non-issue. the Tls index is allocated the first time it's needed, and never needs to be deallocated until the program terminates. Same with the critical section. You can't "leak" something that only gets allocated one time, and is automatically freed by the operating system when the calling program terminates.
2007-Oct-12 19:33:55 by drh:
As of version 3.5.0, SQLite no longer uses TLS. |
|
2275 |
code
|
closed
|
2007 Mar
|
anonymous
|
|
2007 Mar
|
|
2
|
4
|
Can't get where clause to recognize equality with generated value
|
edit |
I can't get a where clause to recognize an equality between a column value and a calculated value:
# Preparatory:
load ../lib/tclsqlite3.dll
sqlite3 db mydb
proc atan {x} {expr {atan($x)}}
db function atan atan
# Fill a table with values:
db eval {create table t2(a integer, b real, c real, d real)}
db eval {insert into t2 values(3, 0.463646484842, 0.999992077664, 0.785398163397)}
db eval {insert into t2 values(5, 0.51122921115, 0.14786560362, 0.540417767899)}
db eval {insert into t2 values(6, 0.495893111807, 0.0928603152509, 0.51122921115)}
# Initialize variables with values from first row:
db eval {select b, c from t2 where a = 3} {set valueb $b ; set valuec $c}
# Verify function is being calculated properly:
db eval {select a, ($valueb + $valuec*(atan(a - 1) - atan(a - 2))), d from t2} values {
foreach {w x y z} [array names values] {
puts "$values($y) $values($w) $values($x)"'
}
}
# Output looks like:
# 3 0.785398163397 0.785394490223
# 5 0.540417767899 0.540417767899
# 6 0.51122921115 0.51122921115
#
# Middle float value is calculated, end float value is
# taken from last column of table row.
# Note that middle and end values are equal in second and third rows.
# This is as expected.
#
# Now try to select just integer values based on equality:
# (function is identical, just moved to where clause)
db eval {select a from t2 where ($valueb + $valuec*(atan(a - 1) - atan(a - 2))) = d}
# I expect to get back 5 and 6, but the result is nothing
This looks like a bug to me. If I am making an obvious newcomer's mistake, I'd appreciate a gentle hint. Thanks. |
2007-Mar-29 14:28:56 by anonymous:
You're making a common mistake: trying to compare two floating-point values for exact equality. This isn't SQLite-specific; it's simply in the nature of floating-point numbers that rounding errors can cause the results of two calculations that are mathematically the same to differ in one "binary place."
2007-Mar-29 15:52:04 by anonymous:
Thanks for the tip. I now remember reading that sqlite stores numbers as double-precision values, so clearly I need to update my procedures to account for that. |
|
2271 |
doc
|
closed
|
2007 Mar
|
anonymous
|
|
2007 Mar
|
|
3
|
4
|
Can't use "limit" as column name
|
edit |
On WinXP:
% load tclsqlite3.dll
% sqlite3 db mydb
% db eval {create table t1(limit real)}
near "limit": syntax error
% db eval {create table t1(limitx real)}
%
Note column named "limit" causes error, same statement with column name "limitx" works OK. |
2007-Mar-26 07:19:26 by anonymous:
Surround limit by quotation marks:
create table t1("limit" real)
Above is correct. See: http://www.sqlite.org/lang_keywords.html |
|
2269 |
code
|
closed
|
2007 Mar
|
anonymous
|
|
2007 Mar
|
anonymous
|
2
|
1
|
SQLite3_Column_decltype treat [char] (32) as 'char',but not 'char(32)'
|
edit |
Create a table use following statement:
CREATE TABLE XTollData (
DutyID char (32) NOT NULL ,
CarNumber char (10) NULL
);
SQLite3_Column_decltype treat DutyID as 'char(32)'
But if you create a table using following statement:
CREATE TABLE [XTollData] (
[DutyID] [char] (32) NOT NULL ,
[CarNumber] [char] (10) NULL
);
SQLite3_Column_decltype will treat DutyID as 'char', not 'char(32)' |
2007-Mar-22 19:00:48 by rdc:
As pointed out at http://www.mail-archive.com/sqlite-users@sqlite.org/msg23237.html
quoting the column data type is not valid SQL syntax.
Using [char] or even "char" should generate a syntax error. The data type is not an identifier.
2007-Mar-27 14:13:54 by drh:
You can also say:
CREATE TABLE x(a [char(32)]);
In other words, put the entire type inside of quotes.
2007-Mar-29 16:34:56 by rdc:
This should generate a syntax error.
CREATE TABLE x(a "char(32)");
^
The data type in a column definition is not an identifier and the parser should not accept quotes around a data type. Leaving this as an "extension" just allows people to create code that won't compile on a standard compliant database. |
|
2265 |
doc
|
closed
|
2007 Mar
|
anonymous
|
|
2007 Mar
|
|
1
|
1
|
windows + xampp (php) + sqlite3 ... how?
|
edit |
Please can you provide a receipe how to use ...
- sqlite3
- on ms windows
- with xampp (with php)
Can this done without compilation? On several places
I read that just the php.ini has to be adapted ... however
it does not work.
btw: sqlite2 works, even via PDO ... but sqlite has its limits.
Thanks. |
This is not an SQLite bug. Ask your question on the mailing list. |
|
2263 |
code
|
closed
|
2007 Mar
|
anonymous
|
|
2007 Mar
|
|
1
|
1
|
Apparent potential leak or concurrency problem when using codec
|
edit |
In the pager when about to write to the file, the codec encrypts the page and returns a pointer to the encrypted page. If the encrypted page is written to a static space, then there might be concurrency problems when multiple threads execute the same patch of code. If the encrypted page is allocated by the codec, there is no place to tell the codec to free it or lock it.
I am not asking for coding to be done, just advice. Is there a working version available for license that has the encryption fully fleshed out? Thanks - Tim |
2007-Mar-07 05:36:32 by anonymous:
Thanks for the fine work. I have exercised the library on large (to me) data sets, up to 55 million records. It is quick and clean.
2007-Mar-07 12:27:51 by drh:
A working implementation of the codec exists as
proprietary code.
I can assure you that it does not have a concurrency problem and
it does not leak memory.
2007-Mar-08 19:26:55 by anonymous:
Thanks for the quick response |
|
2261 |
build
|
closed
|
2007 Mar
|
anonymous
|
|
2007 Mar
|
|
1
|
1
|
Problem under Windows 95
|
edit |
SQLITE3 bombs on WINDOWS 95.
If I try running SQLITE3 with an existing data base (e.g. SQLITE3 existing.dat) it bombs immediately.
If I try running SQLITE3 with a new data base (e.g. SQLITE3 NEW.DAT) it displays its prompt but bombs upon invoking the first CREATE TABLE Command.
Not just SQLITE3 bombs but also an application that I recompiled upgrading from version 3.2.2 to 3.3.13 bombs under WINDOWS 95 but runs well under 98, 2000 and XP. |
2007-Mar-06 12:59:00 by drh:
Link against UNICOWS and the problem will go away, I am told. |
|
2260 |
code
|
closed
|
2007 Feb
|
anonymous
|
|
2007 Mar
|
|
1
|
1
|
virtual table/vdbe does not call xFilter() making xColumn segv
|
edit |
I have the following schema:
create virtual table foo using wrsv (a INTEGER);
create virtual table bar using wrsv (a INTEGER);
and insert the following data:
insert into foo values (100);
insert into foo values (200);
insert into foo values (300);
insert into bar values (100);
insert into bar values (200);
rowid a
---------- ----------
1 100
2 200
3 300
rowid a
---------- ----------
1 100
2 200
The following queries work:
select * from foo, bar where foo.a = bar.a and bar.a >1;
select * from foo, bar where foo.a = bar.a and bar.a =1;
select * from foo, bar where foo.a = bar.a and bar.a <1;
select * from foo, bar where foo.a = bar.a and bar.a >=1;
select * from foo, bar where foo.a = bar.a and bar.a <=1;
However, none of the following work; they all cause xColumn to SEGV (indirectly) because xFilter() does not get called.
select * from foo, bar where foo.a = bar.a and foo.a >1;
select * from foo, bar where foo.a = bar.a and foo.a =1;
select * from foo, bar where foo.a = bar.a and foo.a <1;
select * from foo, bar where foo.a = bar.a and foo.a <=1;
select * from foo, bar where foo.a = bar.a and foo.a >=1;
select * from foo, bar where foo.a = bar.a and foo.rowid>1;
select * from foo, bar where foo.a = bar.a and foo.rowid=1;
select * from foo, bar where foo.a = bar.a and foo.rowid<1;
select * from foo, bar where foo.a = bar.a and foo.rowid<=1;
select * from foo, bar where foo.a = bar.a and foo.rowid>=1;
I see that the xColumn() virtual table method is called without a preceeding call to xFilter(). Here's the vdbe trace from the last SQL query above:
VDBE Execution Trace:
SQL: [select * from foo, bar where foo.a = bar.a and foo.rowid>=1;]
0 Goto 0 25
25 Transaction 0 0
26 VerifyCookie 0 2
27 Goto 0 1
1 VOpen 0 0 vtab:8384E30:80C8CC0
2 VOpen 1 0 vtab:8383238:80C8CC0
3 VColumn 1 0 # bar.a
sqlite3: ext/eb/eb.c:3578: wrsv_column: Assertion `c->row_data' failed.
Whereas here's the trace from the first query listed which shows the call to xFilter() being made.
Incomplete SQL: VDBE Execution Trace:
SQL: [select * from foo, bar where foo.a = bar.a and bar.a >1;]
0 Goto 0 25
25 Transaction 0 0
26 VerifyCookie 0 2
27 Goto 0 1
1 VOpen 0 0 vtab:8D82E30:80C8CC0
2 VOpen 1 0 vtab:8D81238:80C8CC0
3 Integer 0 0
Stack: i:0
4 Integer 0 0
Stack: i:0 i:0
5 VFilter 0 22
6 Integer 1 0
Stack: i:1
7 VColumn 0 0 # foo.a
Stack: i:100 i:1
8 Integer 2 0
Stack: i:2 i:100 i:1
9 Integer 0 0
Stack: i:0 i:2 i:100 i:1
10 VFilter 1 21
21 VNext 0 6
6 Integer 1 0
Stack: i:1
7 VColumn 0 0 # foo.a
Stack: i:200 i:1
8 Integer 2 0
Stack: i:2 i:200 i:1
9 Integer 0 0
Stack: i:0 i:2 i:200 i:1
10 VFilter 1 21
21 VNext 0 6
6 Integer 1 0
Stack: i:1
7 VColumn 0 0 # foo.a
Stack: i:300 i:1
21 VNext 0 6
6 Integer 1 0
Stack: i:1
7 VColumn 0 0 # foo.a
Stack: i:200 i:1
8 Integer 2 0
Stack: i:2 i:200 i:1
9 Integer 0 0
Stack: i:0 i:2 i:200 i:1
10 VFilter 1 21
21 VNext 0 6
6 Integer 1 0
Stack: i:1
7 VColumn 0 0 # foo.a
Stack: i:300 i:1
8 Integer 2 0
Stack: i:2 i:300 i:1
9 Integer 0 0
Stack: i:0 i:2 i:300 i:1
10 VFilter 1 21
21 VNext 0 6
22 Close 0 0
23 Close 1 0
24 Halt 0 0
|
I've tried a bit and cannot reproduce so far. What were the inputs and
outputs of the xBestIndex() call prior to the crash?
Thanks.
2007-Mar-05 10:47:02 by anonymous:
This is an error in my code. I was setting aConstraint[].argvIndex to the wrong argvIndex value. Apologies for the waste of bandwidth, but many thanks for fixing the other vtable issues. |
|
2255 |
code
|
closed
|
2007 Feb
|
scouten
|
|
2007 Mar
|
|
3
|
3
|
Temporary DB files are deleted twice in pager_unwritelock, once implic
|
edit |
Summary: pager_unwritelock in pager.c does this sequence:
sqlite3OsClose(&pPager->jfd);
pPager->journalOpen = 0;
sqlite3OsDelete(pPager->zJournal);
That code will result in two requests to delete the same file. That's because temporary DB journal files are opened with the "delete on close" flag, and thus the file will no longer exist by the time sqlite3OsDelete is called. Redundant delete requests doesn't cause an issue with the above code with synchronous writes because the return code is ignored. However, it does cause an issue on our test_async.c Windows port. Specifically, test_async.c has this code in the writer thread:
case ASYNC_DELETE:
TRACE(("DELETE %s\n", p->zBuf));
rc = xOrigDelete(p->zBuf);
break;
The windows implementation of sqlite3OsDelete will return an error code when attempting to delete a non-existent file. (The Unix version of sqlite3OsDelete always returns SQLITE_OK). So, our test_async port doesn't work on Windows because we receive a sticky I/O error due to the double delete.
We're going to fix our test_async port like this:
case ASYNC_DELETE:
TRACE(("DELETE %s\n", p->zBuf));
rc = xOrigDelete(p->zBuf);
if( rc != SQLITE_OK && !xOrigFileExists( p->zBuf ) ) rc = SQLITE_OK;
break;
However, we believe that the sqlite code should probably either:
- never attempt to delete files that have been opened with the "delete on close" flag set. or
- change the Windows implementation of sqlite3OsDelete to return SQLITE_OK if the DeleteFileW call fails due to attempting to delete a non-existent file
|
Took the former option. SQLite now avoids deleting a file
that has already been deleted via the 'delete on close' flag. |
|
2253 |
code
|
closed
|
2007 Feb
|
anonymous
|
|
2007 Mar
|
danielk1977
|
1
|
1
|
src/vdbe.c:3639: sqlite3VdbeExec: Assertion `pC!=0' failed.
|
edit |
In my virtual table I'm setting the estimatedCost of the query in a manner similar to what I see in where.c:
/* If the table scan does not satisfy the ORDER BY clause,
increase the cost by NlogN to cover the expense of sorting.*/
cost += cost*estLog(cost);
However, I get an assertion failure in vdbe.c:3639.
This problem appears to be generic as I can get fts1 to fail in the same way. I changed the last few lines in fts1.c:fulltextBestIndex to the following. Note: I copied the estLog function from where.c to fts1.c.
pInfo->estimatedCost *= pInfo->estimatedCost * estLog(pInfo->estimatedCost);
printf ("estimatedCost: %g\n", pInfo->estimatedCost);
pInfo->idxNum = QUERY_GENERIC;
return SQLITE_OK;
The following statements raise the assertion:
: ./sqlite3
Loading resources from /home/aim/.sqliterc
SQLite version 3.3.13
Enter ".help" for instructions
sqlite> create virtual table foo using fts1(name, address);
sqlite> insert into foo (name, address) values ('amanda', '43 elm avenue');
sqlite> select * from foo where name like 'a';
estimatedCost: 2.475e+199
sqlite3: ./src/vdbe.c:3639: sqlite3VdbeExec: Assertion `pC!=0' failed.
Aborted
I get a similar assertion in vdbe.c:3587
: ./sqlite3
Loading resources from /home/aim/.sqliterc
SQLite version 3.3.13
Enter ".help" for instructions
sqlite> create virtual table foo using fts1(name, address);
sqlite> insert into foo (name, address) values ('amanda', '43 elm avenue');
sqlite> select max (rowid) from foo;
sqlite3: ./src/vdbe.c:3587: sqlite3VdbeExec: Assertion `pC!=0' failed.
Aborted
which is ticket #2250. |
2007-Feb-26 13:07:23 by anonymous:
There is a slight difference to the estimated cost calulation as it appears in where.c. In my case the estimated cost is *=, but in the where.c case it is +=.
2007-Feb-26 13:11:21 by anonymous:
I replaced the *= with += and the assertion is still raised.
: ./sqlite3
Loading resources from /home/aim/.sqliterc
SQLite version 3.3.13
Enter ".help" for instructions
sqlite> create virtual table foo using fts1(name, address);
sqlite> insert into foo (name, address) values ('amanda', '43 elm avenue');
sqlite> select * from foo where name like 'a';
estimatedCost: 5e+100
sqlite3: ./src/vdbe.c:3639: sqlite3VdbeExec: Assertion `pC!=0' failed.
Aborted
|
|
2250 |
code
|
closed
|
2007 Feb
|
anonymous
|
|
2007 Mar
|
danielk1977
|
1
|
1
|
segmentation violation when using "select max(rowid)" in fts1
|
edit |
Using the following statements I find that: "select max(rowid) from foo" gives a segementation violation.
create virtual table foo using fts1(name, address);
insert into foo (name, address) values ('amanda', '43 elm avenue');
select * from foo;
select rowid, * from foo;
select max(rowid) from foo;
Running the above in gdb:
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
`/home/aim/src/sqlite-cvs/sqlite3' has changed; re-reading symbols.
Starting program: /home/aim/src/sqlite-cvs/sqlite3
Loading resources from /home/aim/.sqliterc
SQLite version 3.3.13
Enter ".help" for instructions
sqlite> .read testcase
name address foo
---------- ------------- ----------
amanda 43 elm avenue @
rowid name address foo
---------- ---------- ------------- ----------
1 amanda 43 elm avenue @
Program received signal SIGSEGV, Segmentation fault.
0x0806083a in sqlite3VdbeExec (p=0x9073098) at ./src/vdbe.c:3588
3588 if( (pCrsr = pC->pCursor)!=0 ){
(gdb) where
#0 0x0806083a in sqlite3VdbeExec (p=0x9073098) at ./src/vdbe.c:3588
#1 0x08062d90 in sqlite3Step (p=0x9073098) at ./src/vdbeapi.c:236
#2 0x08062f32 in sqlite3_step (pStmt=0x9073098) at ./src/vdbeapi.c:289
#3 0x0806e551 in sqlite3_exec (db=0x9064330,
zSql=0x9073fd0 "select max(rowid) from foo;",
xCallback=0x8049e10 <callback>, pArg=0xbf86e0cc, pzErrMsg=0xbf86c6ac)
at ./src/legacy.c:78
#4 0x0804df8b in process_input (p=0xbf86e0cc, in=0x9063be8)
at ./src/shell.c:1606
#5 0x0804d051 in do_meta_command (zLine=0x9063b80 ".read", p=0xbf86e0cc)
at ./src/shell.c:1314
#6 0x0804dd43 in process_input (p=0xbf86e0cc, in=0x0) at ./src/shell.c:1566
#7 0x0804ee5e in main (argc=1, argv=0xbf86f6a4) at ./src/shell.c:1936
(gdb)
I ran it again this time touching 'vdbe_trace' and 'vdbe_explain' but this time compiled with SQLITE_DEBUG=1 and I get an assertion (see below). Note, I also see this with my own virtual table so I don't believe it's confined to fts1 and in my own virtual table I also see this assertion raised after calls to xBestIndex - for which I'll raise a separate ticket.
sqlite> select max(rowid) from foo;
VDBE Program Listing:
SQL: [select max(rowid) from foo;]
0 Goto 0 6
1 Last 0 0
2 VRowid 0 0
3 Callback 1 0
4 Close 0 0
5 Halt 0 0
6 Transaction 0 0
7 VerifyCookie 0 3
8 Goto 0 1
9 Noop 0 0
VDBE Execution Trace:
SQL: [select max(rowid) from foo;]
0 Goto 0 6
6 Transaction 0 0
7 VerifyCookie 0 3
8 Goto 0 1
1 Last 0 0
sqlite3: ./src/vdbe.c:3587: sqlite3VdbeExec: Assertion `pC!=0' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread -1208944960 (LWP 18456)]
0x00557402 in __kernel_vsyscall ()
(gdb) where
#0 0x00557402 in __kernel_vsyscall ()
#1 0x0087fd40 in raise () from /lib/libc.so.6
#2 0x00881591 in abort () from /lib/libc.so.6
#3 0x0087938b in __assert_fail () from /lib/libc.so.6
#4 0x080647a6 in sqlite3VdbeExec (p=0x8dc6c78) at ./src/vdbe.c:3587
#5 0x080682a5 in sqlite3Step (p=0x8dc6c78) at ./src/vdbeapi.c:236
#6 0x0806857e in sqlite3_step (pStmt=0x8dc6c78) at ./src/vdbeapi.c:289
#7 0x0807674e in sqlite3_exec (db=0x8db9c90,
zSql=0x8dc7668 "select max(rowid) from foo;",
xCallback=0x8049e10 <callback>, pArg=0xbfa1026c, pzErrMsg=0xbfa1011c)
at ./src/legacy.c:78
#8 0x0804df8b in process_input (p=0xbfa1026c, in=0x0) at ./src/shell.c:1606
#9 0x0804ee5e in main (argc=1, argv=0xbfa11844) at ./src/shell.c:1936
(gdb)
|
Thanks for the report. |
|
2245 |
new
|
closed
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
a.rottmann
|
5
|
1
|
Union Problem on Empty Table
|
edit |
There is problem on union query if source table is empty, and the empty table is the first data source of union.
Suppose we have STOCK table contains Fields : Code, Name and Quantity
while the table is empty.
Then make a union query like this :
Select Code, Name, Qty from STOCK
union all
Select 'SomeCode', 'Some Name', 100
union all
Select 'OtheCode', 'OtherName, 25
and the result was :
Code Name Qty
100
25
where is the value of "Code" and "Name" ????? |
2007-Feb-22 15:45:33 by drh:
Unable to reproduce. When I try the query shown in the description
it works fine. |
|
2244 |
code
|
closed
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
danielk1977
|
1
|
2
|
xUpdate in virtual table being called when no record exists
|
edit |
I have the following virtual table schema:
create virtual table foo using wrsv (a, b, c, d FLOAT, e TEXT);
and I insert the following records:
insert into foo values(100,100,100,100.1, "100");
insert into foo values(200,200,200,200.2, "200");
insert into foo values(300,300,300,300.3, "300");
insert into foo values(400,400,400,400.4, "400");
which gives me:
$ ./sqlite3 < foo
a b c d e
---------- ---------- ---------- ---------- ----------
100 100 100 100.1 100
200 200 200 200.2 200
300 300 300 300.3 300
400 400 400 400.4 400
If I query for records matching `rowid=10'
sqlite> select * from foo where rowid=10;
sqlite>
there are indeed no records. However, if I now use UPDATE to update record 10 using:
sqlite> update foo set e="hello world" where rowid=10;
then this record ends up being inserted (via xUpdate) into the virtual table. Looking at the documentation for xUpdate I see that the following condition is being met: argc > 1 && argv[0] == NULL: a new row is inserted with rowid argv[1]. The types argv[0] and argv[1] are SQLITE_NULL. I double-checked my xEof method and that returns 1 (EOF) during xOpen/xFilter. I changed my build to use "-DSQLITE_DEBUG=1" and touched vdbe_explain and vdbe_trace. (The output is below - lines beginning with WRSV_TRACE are from my module.) From a cursory glance at the trace I see that wrsv_eof returns EOF (1) but then the stack is populated with column values - all NULL. If the existing record cannot be found then the insert/update should not happen. At the moment I'm getting a new record inserted into the DB which is not correct.
Any light you can shed on this would be appreciated.
sqlite> update foo set e="hello world" where rowid=10;
VDBE Program Listing:
SQL: [update foo set e="hello world" where rowid=10;]
0 Goto 0 32
1 Noop 0 0
2 OpenEphemeral 1 6
3 VOpen 0 0 vtab:8149200:80BFC80
4 Integer 10 0
5 Integer 1 0
6 Integer 0 0
7 VFilter 0 19
8 VRowid 0 0
9 VColumn 0 0 # foo.a
10 VColumn 0 1 # foo.b
11 VColumn 0 2 # foo.c
12 VColumn 0 3 # foo.d
13 String8 0 0 hello world
14 MakeRecord 6 0
15 NewRowid 1 0
16 Pull 1 0
17 Insert 1 0
18 VNext 0 8
19 Close 0 0
20 Rewind 1 0
21 Column 1 0
22 Dup 0 0
23 Column 1 1
24 Column 1 2
25 Column 1 3
26 Column 1 4
27 Column 1 5
28 VUpdate 0 7 vtab:8149200:80BFC80
29 Next 1 21
30 Close 1 0
31 Halt 0 0
32 Transaction 0 1
33 VerifyCookie 0 1
34 VBegin 0 0 vtab:8149200:80BFC80
35 Goto 0 1
36 Noop 0 0
VDBE Execution Trace:
SQL: [update foo set e="hello world" where rowid=10;]
0 Goto 0 32
32 Transaction 0 1
33 VerifyCookie 0 1
34 VBegin 0 0 vtab:8149200:80BFC80
35 Goto 0 1
1 Noop 0 0
2 OpenEphemeral 1 6
3 VOpen 0 0 vtab:8149200:80BFC80
WRSV_TRACE: WRSV_OPEN
4 Integer 10 0
Stack: i:10
5 Integer 1 0
Stack: i:1 i:10
6 Integer 0 0
Stack: i:0 i:1 i:10
7 VFilter 0 19
WRSV_TRACE: wrsv_eof: 1
19 Close 0 0
WRSV_TRACE: wrsv_close
20 Rewind 1 0
21 Column 1 0
Stack: NULL
22 Dup 0 0
Stack: NULL NULL
23 Column 1 1
Stack: NULL NULL NULL
24 Column 1 2
Stack: NULL NULL NULL NULL
25 Column 1 3
Stack: NULL NULL NULL NULL NULL
26 Column 1 4
Stack: NULL NULL NULL NULL NULL
27 Column 1 5
Stack: NULL NULL NULL NULL NULL
28 VUpdate 0 7 vtab:8149200:80BFC80
WRSV_TRACE: wrsv_update: argc = 7
29 Next 1 21
30 Close 1 0
31 Halt 0 0
|
Thanks for reporting this. See [3652]
. |
|
2243 |
code
|
closed
|
2007 Feb
|
anonymous
|
|
2007 Jul
|
|
2
|
3
|
sqlite3 authorizer cannot be exposed in garbage collected languages
|
edit |
While a documentation fix (#2242) certainly clarifies that nested subqueries are forbidden, could at least sqlite3_finalize be supported? It would be a shame if languages that are garbage collected (as opposed to reference counted ala TCL) cannot expose the authorizer functionality. |
2007-Feb-21 17:08:03 by anonymous:
Why must garbage be collected in this particular call? Can't you control when and where garbage can be collected in your wrapper API?
2007-Feb-22 02:03:46 by anonymous:
I can instruct the runtime to disable garbage collection for a critical section. Unfortunately, this is no help: when the 'authorizer' is invoked, it is invoked from C and is thus not in a critical section, yet. Supposing I then marked the entire function body as a a critical section, when I return from the authorizer the critical section would have to end, and a garbage collection would be possible. So unless I could wrap the entire invocation from C as atomic, there's nothing I can do.
Sadly, there is no way to specify that garbage collection is impossible for methods called from C (in SML/MLton; maybe java/other languages can do this). This would be a horrible thing to do anyways. Think of a gtk program where all the user code is invoked as a callback. This would mean it was impossible to reclaim memory. ever.
2007-Feb-22 02:55:25 by anonymous:
There's always a way to control when garbage can be collected. Does SML use a precise or a conservative garbage collector? I suspect that garbage collections in SML are only triggered on calls to any malloc or free call? Running arbitray GC finalization code from a random C function is a recipe for thread deadlock - in both C and Java. So are you assuming only single-threaded code in your API?
2007-Feb-22 16:04:30 by anonymous:
re: deadlock, finalization will only occure if the resource will never be used again. Also, MLton (at least) does not support multiple system-level threads. When/if it did, the garbage collector would be running in its own thread, and all finalization would occure serialized there.
re: controlling garbage collection. I can stop it within a critical section (begin ... end style) and explicitly invoke it. That's all the control I have.
re: alloc/free. A programmer has no idea which structures will be allocated on the stack/heap. This is all subject to very complex analysis and optimization by the compiler. Memory is never explicitly allocated or freed in SML.
One solution I could probably use is to keep a list of 'freed queries' associated with each database. Then, on every API call using that database, run the finalizers for any queries on the free list. This would might be a good idea anyways in case of concurrent SML implementations.
One last question: is it allowed to execute subqueries within a callback from SQLite? I just assumed so, but I also assumed I could execute subqueries as part of authorization (subject to not being stupid and causing infinite recursion).
2007-Feb-23 13:09:04 by anonymous:
I've implemented the work-around I mentioned: When a query is garbage collected, I move it to a list of queries that need to be finalized for its database. Then, when any API call is made involving that database or its queries, any queries in the free list are finalized. It's not space-safe, but it works. The obvious benefit is also that the finalization will always happen in the same thread as the rest of the API calls made on that database (assuming the user only accesses that SQLite db from one thread).
Feel free to close this bug. I would still like to know for documentation purposes if a callback from SQL (aggregate, collation, or scalar) may execute subqueries in computing the result.
Also, I still think that allowing the authorizer to make subqueries would be a good idea. It would let you build an access control policy similar to MySQL's (in a table). However, I realize this is a feature request, not a bug.
2007-Feb-23 14:52:41 by anonymous:
I do agree that SQLite should be made to be reentrant through the authorization callback function, but the new way your wrapper finalizes objects is much safer, more deterministic and relies less on the inner workings of the sqlite3 library.
2007-Feb-23 18:50:45 by anonymous:
I believe you call new SQL commands from within sqlite registered functions or other callbacks. |
|
2240 |
code
|
closed
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
1
|
1
|
Parser command termination problem fails to catch illegal statements
|
edit |
Same problem exists in the shell or when a file is piped to sqlite3:
SQLite version 3.3.13
Enter ".help" for instructions
sqlite> select 'one', 'two'
...> 'three';
one|two
sqlite> select current_timestamp
...> junk;
2007-02-19 14:54:35
sqlite> select 'foo'
...> bar;
foo
|
2007-Feb-19 16:01:02 by drh:
The statements are not illegal. In the first case 'three' is
an alias for the second column and in the second case junk is
an alias for the first columln. It is as if the keyword AS had
been inserted. All SQL database engines that I am aware of
work this way.
2007-Feb-19 18:56:27 by anonymous:
Ugh. Aliases - of course... it must be Monday.
2007-Feb-20 23:38:10 by anonymous:
Standard SQL does not allow a string literal (in single quotes) as an alias identifier. In standard SQL a quoted identifier (in double quotes) would be allowed as an alias identifier.
Furthermore, in standard SQL the first example should still work but for a different reason. The database should concatenate the two string literals ('two' and 'three') that are separated by whitespace only into a single string literal (just as C and C++ do) to produce a single result value of 'twothree'. |
|
2239 |
doc
|
closed
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
1
|
1
|
Size of database in Speed Comparison?
|
edit |
In the speed comparison, how big is the database?
It would be interesting to see speed comparisons with a database with at least 1 gig size.
http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison
Best Regards |
The databases in the tests are all quite small and are 100% in the machine's disk cache which positively skews results in SQLite's favor. But this question belongs on the mailing list. |
|
2236 |
code
|
closed
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
1
|
1
|
inserts with selects do not work in 3.1.13
|
edit |
When trying to do an insert via a select statement using the sqlite3 command line tool, it states that there is an SQL error, when there really isn't one:
sqlite> insert into snwstaticparam (obj_id, parameter, value) values select obj_id, "A", "2007-02-16" from snwobject where name="IMS-AAA";
SQL error: near "select": syntax error
However, please note that the select statement by itself works just fine:
sqlite> select obj_id, "A", "2007-02-16" from snwobject where name="IMS-AAA";
1|A|2007-02-16
sqlite>
And if I simply do the insert based on this information, it goes in just fine:
sqlite> insert into snwstaticparam (obj_id, parameter, value) values (1, "A", "2007-02-16" );
sqlite> select * from snwstaticparam;
1|1|A|2007-02-16
sqlite> |
2007-Feb-16 20:54:22 by drh:
The correct syntax is:
INSERT INTO snwstaticparm(obj_id,parameter,value)
SELECT obj_id, 'A', '2007-02-16'
FROM snwobject
WHERE name='IMS-AAA'
|
|
2234 |
code
|
closed
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
1
|
1
|
3.3.13 is identical to 3.3.12 except VERSION file
|
edit |
I just the new 3.3.13 zips, but source is identical to 3.3.12 (except VERSION file). |
2007-Feb-16 11:16:22 by anonymous:
edit ticked is broken...
correct is "I just downloaded "..
incorrect! it's indeed different. sorry. |
|
2232 |
build
|
closed
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
3
|
3
|
corrupt2.test fails with newer versions of Tcl
|
edit |
I commented on the mailing list that corrupt2.test failed on an Ultra 5 running Solaris 9 and DRH replied:
I get the same problem on OS-X. But it appears to be a bug in
the older version of TCL you have installed, not in SQLite itself.
After installing Debian over Solaris 9 I did some testing and duplicated the bug:
I was trying to make a test case to report the Tcl bug and noticed
that (in 8.5a5 at least) they added some extra file mode tests.
After looking at those tests I now think this is a bug in the
SQLite test suite.
ISTM opening files in corrupt2-1.x with an 'a' flag writes all
changes to the end, which is what I'm seeing. 'a' for append.
I think the files should be opened with a 'RDWR' flag instead.
Making that changes means the tests pass under Tcl 8.5a5 but I
haven't tested the other versions of Tcl yet. I don't know why
the test passed under Tcl8.4.9 either.
There's a simple fix which I've tested on two machines running Debian Linux with various versions of Tcl:
s/a/RDRW/ makes corrupt2.test work with Tcl 8.4.9, 8.4.12, 8.4.14
and 8.5a5 on recent versions of Debian/Ubuntu on sparc64 and x86.
|
This problem was fixed a day before the ticket was
written. See check-in [3645]
|
|
2230 |
code
|
closed
|
2007 Feb
|
danielk1977
|
|
2007 Feb
|
danielk1977
|
1
|
1
|
Problem with virtual tables and grouping by aggregate function.
|
edit |
There is some problem with the logic for grouping by
aggregate functions when querying a virtual table. Using the
demo "schema" table from test_schema.c, the first of the
following queries works, the following two return NULL:
SELECT length(tablename) FROM schema GROUP by tablename;
SELECT length(tablename) FROM schema GROUP by length(tablename);
SELECT tablename FROM schema GROUP by length(tablename);
Background: The "schema" table implements a linear scan
strategy only.
The following is for vtab2.test. Currently 2-1.2 passes, 2-1.3
and 2-1.4 fail.
do_test vtab2-1.2 {
execsql {
SELECT length(tablename) FROM schema GROUP by tablename;
}
} {6}
do_test vtab2-1.3 {
execsql {
SELECT length(tablename) FROM schema GROUP by length(tablename);
}
} {6}
do_test vtab2-1.4 {
execsql {
SELECT tablename FROM schema GROUP by length(tablename);
}
} {schema}
|
|
2213 |
code
|
closed
|
2007 Feb
|
danielk1977
|
|
2007 Feb
|
danielk1977
|
1
|
1
|
Bug handling strings that are not nul-terminated.
|
edit |
If a user-function has an sqlite3_value* containing a string that has a non-nul-terminated internal representation, multiple calls to sqlite3_value_text() may return distinct pointers. Calls to sqlite3_value_bytes() may also invalidate pointers returned by previous calls to sqlite3_value_text().
Compile and load the attached extension, then execute:
SELECT user_function(user_function('hello'));
an assert() fails if the bug exists.
The bug is that the sqlite3VdbeMemNulTerminate()
function is not setting the MEM_Term flag. |
|
2212 |
code
|
closed
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
5
|
4
|
function request: sqlite3_bind_literal()
|
edit |
The following idea just came to mind, as it would simplify some of my client code a bit:
int sqlite3_bind_literal( sqlite3_stmt * st,
int index, char const * str );
str is bound to the statement in an unquoted/unescaped fashion. The main use for this is to bind function calls or sqlite3 special var names, including NULL. e.g.:
sqlite3_bind_literal( myStatement, 1, "current_timestamp" );
sqlite3_bind_literal( myStatement, 2, "some_function()" );
sqlite3_bind_literal( myStatement, 3, "NULL" );
Naturally, there should also be a sqlite3_bind_literal16() as well.
:)
----- stephan at s11n dot net |
2007-Feb-06 23:45:29 by drh:
An interface such as requested above would required that the
underlying bytecode for a statement be modified on the fly.
Currently, the bytecode is generated once when sqlite3_prepare()
is called and never changes thereafter. Changing the bytecode
after the fact is both expensive and impractical. Better to
rerun sqlite3_prepare(). |
|
2209 |
doc
|
closed
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
5
|
5
|
Wrong Comment in the change #3622
|
edit |
In the change #3622 comment says:
/*
**
** Changing this from a 64-bit to a 32-bit type limits the number of
** tables in a join to 32 instead of 64. But it also reduces the size
** of the library by 738 bytes on ix86.
*/
Is it OK in the coherency with :
Allow up to 64 tables in a join (the number of bits in a long long int). The old limit was 32 tables.
??
|
2007-Feb-01 13:54:43 by anonymous:
The existing comment is correct and useful. It tells SQLite embedders how to reduce code size by limiting the number of tables in a join to 32, from the default of 64. |
|
2197 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
4
|
5
|
invalid(?) join syntax results in runnable sql code
|
edit |
While learning about JOINs from this page:
http://en.wikipedia.org/wiki/Join_(SQL)
i think i quite accidentally found a bug in sqlite3. First, the tables:
stephan@owl:~/tmp> sqlite3 foo.db
SQLite version 3.3.11
Enter ".help" for instructions
sqlite> create table em (name,dept);
sqlite> create table dept(name,id);
sqlite> insert into dept values('Sales',31);
sqlite> insert into dept values('Engineering',33);
sqlite> insert into dept values('Clerical',34);
sqlite> insert into dept values('Marketing',35);
sqlite> insert into em values('Smith',34);
sqlite> insert into em values('Jones','33');
sqlite> insert into em values('Robinson',34);
sqlite> insert into em values('Jasper',36);
sqlite> insert into em values('Steinberg', 33);
sqlite> insert into em values('Rafferty',31);
Now the query as it SHOULD be:
sqlite> select em.name,dept.name from em inner join dept on em.dept = dept.id;
Smith Clerical
Robinson Clerical
Steinberg Engineering
Rafferty Sales
No problem, of course
However, the first time i entered the query i made what would appear to be a gross syntactical mistake, but it still runs with the same results as above:
sqlite> select em.name,dept.name from em inner join dept on dept where em.dept = dept.id;
Smith Clerical
Robinson Clerical
Steinberg Engineering
Rafferty Sales
The erroneous part is the extra stuff around 'inner join dept on dept where...'.
Maybe this is a bug, maybe not. If it is, i suspect that the fix lies in parser.y. If it's not a bug, then let's just call it a fluke or a misunderstanding on my part and close this ticket.
:)
----- stephan (stephan at s11n dot net) |
2007-Jan-27 02:22:38 by drh:
By virtue of the fact that "dept" is a unique column name within the
query and the value of "dept" is always true, the query with the
wrong syntax really is valid SQL and really does do the same thing
as the correctly formatted query.
This is not a bug. |
|
2196 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
5
|
3
|
Bug in PRAGMA full_column_names with SELECT *
|
edit |
SQLite version 3.3.11
Enter ".help" for instructions
sqlite> pragma full_column_names;
0
sqlite> pragma full_column_names=1;
sqlite> pragma full_column_names;
1
sqlite> .headers on
sqlite> create table t(a);
sqlite> insert into t values ('hello');
sqlite> select a from t;
t.a
hello
sqlite> select * from t;
a
hello
sqlite>
Shouldn't that last query's column be "t.a"? |
2007-Jan-26 23:19:38 by anonymous:
You need both:
PRAGMA full_column_names=1;
and
PRAGMA short_column_names=0;
It doesn't make any sense to me either.
2007-Jan-27 00:10:42 by drh:
The current behavior is for backward compatibility issues going
back to the 2.1 series. |
|
2190 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
3
|
4
|
bogus lines on "left join" with a "where right_table.column is NULL"
|
edit |
Refer to the attached file left_join_bug.sql for the following discussion.
When I run sqlite3 on this script, I get this output:
shell-prompt> /usr/mbench2.2-nightly/bin/sqlite3 <left_join_bug.sql
default only|do||
both|default both||
shell-prompt>
Clearly, the last line ("both|default both||") is bogus. A left join on the my_key column being equal will produce a line
both|default both|both|current both
And the "WHERE current_settings.my_key IS NULL" clause should
exclude that line, resulting in no "both" line.
Change the "IS NULL" to "IS NOT NULL", or get rid of the WHERE clause altogether, and you get the expected output, containing one "both" line with no null values.
Just to check that it wasn't me misunderstanding what should happen, I ran the same script through mysql. Results were as expected; no "both" line:
shell-prompt> mysql --version
mysql Ver 14.7 Distrib 4.1.20, for redhat-linux-gnu (i686) using readline 4.3
shell-prompt> mysql -D test <left_join_bug.sql
my_key my_value my_key my_value
default only do NULL NULL
shell-prompt>
I built the binary myself from the sqlite-3.3.10.tar.gz tarball I downloaded from your site. Built on CentOS 4.4 thusly:
shell-prompt> configure --prefix=/my/path --disable-tcl && make && make install
I have a workaround. I was wanting to use the SELECT statement in the script as part of a larger statement. I wanted to select my_key and my_value out of both tables such that any my_key value that occurred in either table would show up exactly once. If the my_key value occurred in the current_settings table, then (regardless of what was in default_settings), current_settings.my_value would be chosen. Otherwise, default_settings.my_value would be chosen.
A left-join statement that should yield these results would be:
SELECT
*
FROM
current_settings
UNION
SELECT
default_settings.*
FROM
default_settings LEFT JOIN current_settings
ON default_settings.my_key = current_settings.my_key
WHERE
current_settings.my_key IS NULL;
However, because of the cited bug, this statement results in a line from each table whenever a my_key occurs in both, instead of just the one from current_settings. The workaround is to use a sub-select, thusly:
SELECT
*
FROM
current_settings
UNION
SELECT
*
FROM
default_settings
WHERE
my_key NOT IN (SELECT my_key FROM current_settings);
This works correctly. So I'm ok for now. |
This appears to a duplicate of ticket #2189. |
|
2186 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
drh
|
1
|
1
|
database seems to be corrupted during a huge transaction
|
edit |
During a huge transaction delete, update and insert of some records fails. In this transaction schema changes are done too (in this concrete example in one column of a table null values are allowed - nothing more). On delete and update some records could not be found (but they definitly exist!). On insert an error code is returned that says that the record already exists (but it does definitly not!). There are a few hundred thousands of deletes, updates and inserts in that transaction, but it already fails after a few thousand operations.
We tested the operations without opening a transaction and they succeeded. |
2007-Jan-23 13:45:53 by drh:
Does the database really go corrupt? What happens when you
enter
PRAGMA integrity_check;
after the incident you describe? What errors do you get?
Is this reproducible? If so, can you send in a script that
will reproduce the problem? Without information on how we
might reproduce the problem, it will be difficult to fix.
2007-Jan-24 18:15:46 by drh:
The person who originally reported this bug now says that the
problem was an application error. |
|
2179 |
new
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
4
|
1
|
Odbc driver for sqlite takes more time in executing a query.
|
edit |
I developed an application for testing the execution time of an query between MS-ACCESS and Sqlite.
1.Sqlite databse when it is accessed through ODBC driver(sqliteodbc.exe), an execution of a query takes 19 secs.
2.when the same query is executed directly(using sqlite3.dll) it takes less than a second.
how can i make Odbc driver perform in similar way(fast).
Waiting for ur reply at vipul.dpatel@patni.com
Regards,
Vipul Patel |
Please send general SQLite questions to the mailing list. |
|
2178 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Apr
|
|
1
|
1
|
On Windows Vista, a simple select returns different results.
|
edit |
A simple query:
SELECT value FROM some_pairs WHERE key = 'foo';
The value is supposed to be 100, for example.
With different client invoking the sqlite3.dll, sometimes it returns 1, not 100.
On other versions of Windows have no problem with the same database file and sqlite3.dll. |
Please supply a reproducable test case including full schema, data and select statement.
2007-Feb-08 20:20:29 by anonymous:
After I reboot the Windows Vista, the inconsistency was disappeared... I will try my best to reproduce it ASAP.
2007-Feb-26 04:18:50 by anonymous:
It's really hard to re-produce the situation. On my Vista, only PieTTY (a custom PuTTY) still has this problem. Since my program with SQLite is a DLL attached to some other application, it's quite complicated to rebuild the whole environment to test it.
I have to figure out a more stable and simple way.
2007-Apr-25 09:36:55 by anonymous:
I guess I found the reason -- not SQLite's fault basically:
http://b6s.blogspot.com/2007/04/previous-version-ghost-on-vista-can-be.html
Cheers,
/Mike T. J. "b6s" Jiang/
|
|
2174 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
anonymous
|
2
|
3
|
DBD::SQLite does not return number of rows affected. Count(XXX) OK
|
edit |
Using DBD:SQlite perl interface, the number of affected rows is not returned as for the other DBD interfaces. I will investigate if it is the perl side (I have reason to think not).
The call returns 0E0 which means "ok, but no rows" but an explicit
"select Count(XXX)" returns the correct value.
I will return to make a comment if I find it is infact the perl side
Many Thanks |
2007-Jan-17 09:24:56 by anonymous:
First ask newsgroup and Perl group.
|
|
2170 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Mar
|
anonymous
|
3
|
3
|
-init does not execute .exit/.quit
|
edit |
sqlite3 terminates with a prompt when called with -init commandfile and the last (or prevous line) of commandfile contains .exit/.quit
.exit/.quit will never be executed.
With this "feature" it can't be used in a WIN-batch file. |
2007-Jan-24 14:40:36 by anonymous:
There's a workaround for this bug: Create a text file with ".quit" in it (e.g., quit.txt). Run sqlite3.exe redirecting standard input from this file. Ex:
sqlite3.exe -init some_init_file.sql targetdatabase.db < quit.txt
2007-Mar-29 20:08:51 by drh:
Or just redirect input from the original script. I do not understand
the problem here.... |
|
2169 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Mar
|
adamd
|
2
|
1
|
cast function
|
edit |
A select statement does not support CAST when the table is empty
select cast(a_float_field as float) from fields;
the type of a_float_field is float( REAL ) but it returns intgere... |
2007-Mar-29 20:06:40 by drh:
SQLite is dynamically typed, not statically typed. Type is
associated with values, not with containers. So it makes
no sense to cast a value that does not exist. |
|
2162 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
1
|
1
|
c code compile fails with "Undefined reference to sqlite3_open()"
|
edit |
Hi,
I am new to sqlite. My environment is MinGw C compiler, Msys and sqlite3. When I try compiling my c code, I get the following error.
"Undefined reference to sqlite3_open()"
"Undefined reference to sqlite3_close()"
"Undefined reference to sqlite3_exec()"
I followed the following steps to install.
1. Download mingw from www.mingw.org
2. Get the sqlite3 source tree
3. Get the makefile attached to #931
4. Make sure you have 'gawk', 'sed' and 'grep' (call grep ggrep, or edit the makefile). Also get upx
and install it.
5. Type 'make'.
Thanks |
2007-Jan-10 18:57:43 by drh:
Please seek help with project or compiler issues on the sqlite
users mailing list. Tickets are for reporting bugs in SQLite itself. |
|
2158 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
1
|
2
|
SCHEMA error still returned if SQL becomes invalid
|
edit |
SQLITE_SCHEMA is still returned if the SQL becomes invalid. eg
- Register collation dummy
- prepare, execute "select .... collate dummy", reset statement
- Unregister collation dummy
- step statement
In the last step, the collation name is now an error. SQLite returns SQLITE_SCHEMA. I believe it should return SQLITE_ERROR and the same error data as a fresh prepare would.
The expectation is for preparev2 to allow the removal of all SQLITE_SCHEMA handling from code. If cases like this are going to happen then I'll have to have SQLITE_SCHEMA handling code again. And if that is the case then I may as well use the preparev1 api since I'll have to keep a copy of the sql around to rerun prepare with. (ie I'll have to have code that effectively duplicates preparev2). |
2007-Jan-09 15:08:43 by anonymous:
I understand the behaviour, but don't think it is justified. This now means I have to save a copy of the string and re-run prepare in order to get the actual error code (ie the SQL is now invalid). That means I have to have code that duplicates prepare_v2 making prepare_v2 and its extra copy of the string pointles.
2007-Jan-09 15:16:27 by drh:
The current behavior is OK. You just have to start thinking of
SQLITE_SCHEMA as a fatal error, akin to SQLITE_IOERR or
SQLITE_FULL, instead of something that requires a retry. We
could change theh SQLITE_SCHEMA return to be SQLITE_ERROR,
but SQLITE_SCHEMA gives more specific error information so
what not use it.
After sqlite3_step() returns SQLITE_SCHEMA, the
reason for the parse error is available from sqlite3_errmsg().
There is no need to rerun sqlite3_prepare_v2() to find the
error text.
Documentation and test cases have been updated to try to bring
out this point.
2007-Jan-09 15:25:52 by anonymous:
My problem is a difference in behaviour. If I have invalid SQL and call prepare on a new statement then I get SQLITE_ERROR. If the invalid SQL is re-prepared then I will get SQLITE_SCHEMA.
I am using exceptions based on the error code so different exceptions will get raised. The reason why I'll have to run the re-prepare myself is to get consistent behaviour. |
|
2157 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
1
|
2
|
Profile called back too many times if a prepare_v2 statement is reused
|
edit |
select max(x) from foo
drop index foo_x
select max(x) from foo
The second select re-uses the sqlite3_stmt. If there is a profile callback registered during both selects, then it is called twice on the second select. If I use a new sqlite3_stmt then it is only called once on the second select.
Code is attached showing this. Output when statement is reused and hence reprepared internally due to schema change:
PCB: 31462312 select max(x) from foo
PCB: 11587143 select max(x) from foo
PCB: 26553869 select max(x) from foo
Output expected, and what you get if a new statement is used:
PCB: 31462311 select max(x) from foo
PCB: 24582445 select max(x) from foo
|
2007-Jan-09 03:20:10 by drh:
This is correct. The statement really does run three times.
The second run fails with SQLITE_SCHEMA and is automatically
retried.
Please use sqlite3_profile() with caution as it is currently
undocumented and unsupported at this time.
2007-Jan-09 03:42:05 by anonymous:
I certainly see your logic, but this results in different behaviour between repeatedly making new statements vs reusing them. preparev2 is generally most useful for the latter case.
It would be really nice if the callback wasn't called when a re-prepare happens. That will hide the existence of SQLITE_SCHEMA which was kinda the point of the v2 interface in the first place!
2007-Jan-09 14:03:28 by drh:
Seems to me that users would want to know about every run of a
statement, and their timings, even those runs that abort early
with an error and are automatically retried.
The purpose of sqlite3_prepare_v2 is not to hide the existance
of SQLITE_SCHEMA but rather to fix it so that users do not have
to deal with it so much.
2007-Jan-09 14:30:08 by anonymous:
I disagree with your last comment. It certainly makes their code way more complicated since they will have to be aware of whether statements are reused, which means they also have to know the replacement policy for any statement caching. ie instead of a one to one mapping of callbacks to statements, they now have one or more callbacks per statement. I first discovered this problem with my test suite and it could be nasty trying to code a test for this kind of behaviour.
I also have an underlying assumption that the detection and re-preparation take close to zero time. If that is not the case then notifying of the costs makes sense giving the extra complexity. |
|
2155 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
4
|
4
|
Should %s in strftime() be rounded up?
|
edit |
Or should %s it be consistant with %S and truncated to the lower integer?
sqlite> select strftime('%s', '2007-01-01 12:34:59');
1167654899
sqlite> select strftime('%s', '2007-01-01 12:34:59.3');
1167654899
sqlite> select strftime('%s', '2007-01-01 12:34:59.6');
1167654900
sqlite> select strftime('%s', '2007-01-01 12:35:00');
1167654900
The 0.5 second additions can accumulate in a multi-stage date arithmetic to throw the time off by a second or two.
All occurances of 0.5 in date.c should be double-checked. |
2007-Jan-08 18:56:01 by drh:
Adding 0.5 and taking the integer part causes it to round to the
nearest integer - not round up. Rounding to the nearest integer
is an entirely reasonable thing to do, I believe.
2007-Jan-08 19:12:55 by anonymous:
Arguments could be made for rounding the seconds to the nearest integer or just using integer truncation. man strftime and man mktime for major UNIX variants do not discuss what happens in fractional cases. So I guess it can be implementation defined. |
|
2152 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
1
|
1
|
there is not tclsqlite.h in sqlite3.3.9
|
edit |
dev c++ of windows doesn't compile sqlite3.3.9 source
perhaps there is not tclsqlite.h |
2007-Jan-08 13:38:09 by drh:
There is no file tclsqlite.h on any platform and that file
is not mentioned anywhere in the source code. |
|
2150 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
3
|
3
|
use of %W in strftime produces unreliable results
|
edit |
I find that if I execute the following SQL multiple times in succession, I get different values for %W:
SELECT strftime('%Y-%W', 'now');
Sometimes I get '2007-01' and other times I get '2007-02'. |
Blindly adding 0.5 seconds will not work for dates within 0.5 seconds of the next date.
With latest CVS change:
sqlite> select strftime('%m-%d-%Y %H:%M:%S', julianday('2004-01-01 23:59:59.6', 'utc'), 'localtime');
01-01-2004 23:59:60
2007-Jan-08 15:42:27 by anonymous:
... or within 0.5 seconds of the next minute, for that matter:
sqlite> select strftime('%m-%d-%Y %H:%M:%S', julianday('2004-01-01 17:14:59.6', 'utc'), 'localtime');
01-01-2004 17:14:60
2007-Jan-08 15:48:16 by drh:
This is an unrelated issue and should be in a separate ticket. |
|
2146 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
1
|
2
|
Correlated subqueries as columns of select return a syntax error
|
edit |
A correlated sub-query in a column causes the CLP to report a syntax error near the FROM outside of the sub-query. After fighting my own tables and queries, I created the sample table and query in "The Definitive Guide to SQLite" and reproduced the same problem.
create table food_types
id INTEGER PRIMARY KEY
name TeXT
);
insert into food_types values(1,"bread");
insert into food_types values(2,"rice");
insert into food_types values(3,"serial");
create table foods (
type_id INTEGER,
name TEXT,
percentage INTEGER
);
insert into foods values(1, "ryebread", 10);
insert into foods values(1, "wheatbread", 20);
insert into foods values(2, "basamati", 100);
insert into foods values(3, "oatmeal", 10);
insert into foods values(3, "cornflakes", 10);
select (select name from food_types where id = f.type_id) Type, fRoM foods f;
|
2007-Jan-06 02:11:14 by anonymous:
remove ',' after type. i think the problem is in your sql code.
2007-Jan-06 03:35:35 by drh:
You are missing a common after "KEY" in the definition of
food_types and you have an extra comma after "Type" in the
query. |
|
2142 |
build
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
2
|
2
|
make fails on cygwin
|
edit |
$ uname -a
CYGWIN_NT-5.1 aurora 1.5.23(0.156/4/2) 2006-12-19 10:52 i686 Cygwin
$ make
(many lines deleted)
./libtool --mode=link gcc -g -O2 -DOS_WIN=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -
I. -I../sqlite-3.3.8/src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_THREAD_OVERRIDE_LOCK
=-1 -DSQLITE_OMIT_CURSOR -o libsqlite3.la alter.lo analyze.lo attach.lo auth.lo
btree.lo build.lo callback.lo complete.lo date.lo delete.lo expr.lo func.lo hash
.lo insert.lo loadext.lo main.lo opcodes.lo os.lo os_unix.lo os_win.lo os_os2.lo
pager.lo parse.lo pragma.lo prepare.lo printf.lo random.lo select.lo table.lo t
okenize.lo trigger.lo update.lo util.lo vacuum.lo vdbe.lo vdbeapi.lo vdbeaux.lo
vdbefifo.lo vdbemem.lo where.lo utf.lo legacy.lo vtab.lo \
-rpath /usr/local/lib -version-info "8:6:8"
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries
(more lines deleted)
$ make install
tclsh ../sqlite-3.3.8/tclinstaller.tcl 3.3
can't read "env(DESTDIR)": no such variable
while executing
"set LIBDIR $env(DESTDIR)[lindex $auto_path 0]"
(file "../sqlite-3.3.8/tclinstaller.tcl" line 10)
make: *** [tcl_install] Error 1 |
No problem here.
tar xzvf sqlite-3.3.8.tar.gz
cd sqlite-3.3.8
./configure && make
./sqlite3.exe
|
|
2138 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
1
|
2
|
COLLATE and multiple order by problem
|
edit |
execute: make sql;sh insert.sh
My query: ./sql collate.db "SELECT * FROM test ORDER BY name,date"
Result:
Example 19950101
Example 19950302
Example 19950306
Example 19950131
Example 19950202
Example 19950607
Why isn't the date column sorted out the right order? |
2007-Jan-03 16:02:10 by anonymous:
I forgot to write: this is with hu_HU.UTF-8 locale settings.
2007-Jan-03 17:08:30 by drh:
There are bugs in the implementation of your comparison
function for the MAGYAR collating sequence. You are
assuming that the strings are NUL-terminated, which they
are not. You also assume that the second string is not
shorter than the first, which is not necessarily the case.
There my be other bugs - these where the ones I saw on
first glance. The first bug above will definately cause
the erroneous behavior you observe.
2007-Jan-04 14:18:43 by anonymous:
I think you are wrong.
uncomment the printf line in the sql.c file 93. row.
Result:
-1 - 79: 'Example' - 'Example'
-1 - 79: 'Example' - 'Example'
35 - 39: 'Example' - 'Example'
35 - 39: 'Example' - 'Example'
20 - -1: 'Example' - 'Example'
20 - -1: 'Example' - 'Example'
-1 - 3: 'Example' - 'Example'
79 - 3: 'Example' - 'Example'
Example 19950101
Example 19950302
Example 19950306
Example 19950131
Example 19950202
Example 19950607
I think my collate function is invoked only for the name column.
2007-Jan-04 15:02:33 by drh:
Your test proves that I am right. Comparing 'Example' to
'Example' should always return 0.
2007-Jan-04 15:31:32 by anonymous:
No you aren't right.
sqlite> select * from test;
Example|19950302
Example|19950306
Example|19950202
Example|19950607
Example|19950101
Example|19950131
sqlite>
The first column is always "Example" so the comparsion result must be 0, this is right.
But the problem is not here but the second column sorting, named "date".
Now I found one workaround for the bug.
If I change the "date" column type to VARCHAR, the result is ok.
Plase, test this, change in the insert.sh the date column type to VARCHAR and execute:
rm collate.db;sh insert.sh;./sql collate.db "SELECT * FROM test ORDER BY name,date"
Now the result is ok.
2007-Jan-04 16:09:35 by drh:
Yes I am right and you are wrong.
Because of the problems in the comparsion function, SQLite thinks
that some cases of 'Example' in the name column
are less than others. The name
column is the primary sort key. The date is the secondary sort key
and is therefore only used when the primary key compares equal.
In other words, the secondary sort key is only used to break a tie
in the primary sort key.
But ties never happen in the primary sort key due to bugs
in your comparision function.
So as far as SQLite is concerned, the content of the Date column
is irrelevant.
2007-Jan-04 17:21:54 by anonymous:
Ahh I see now.
Big sorry for you.
I'm fixed my function and now it's rock. :) |
|
2137 |
code
|
closed
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
shess
|
4
|
4
|
I cannot find tcl.h header file. So, I am not able to compile the code
|
edit |
I cannot find tcl.h header file. So, I am not able to compile the code. Can you provide me with one. |
Here it is: tcl.h
Kidding aside, you don't need Tcl to build SQLite. It's just for the optional test suite. Anyway, this is a mailing list question and does not belong here. |
|
2134 |
code
|
closed
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
2
|
1
|
is this a bug of sqlite3_prepare?
|
edit |
when i use sqlite3_prepare,sql statement:update table1 set aaa='aaa' where bbb=?;
use sqlite3_bind_*() to set parameter
set the second argument(index) to 5
get the result code:25(out of bounds)
then i call sqlite3_step,and get the result code:101(done)
but if i change the sql statement to:update table1 set bbb=? where aaa='aaa';
use sqlite3_bind_*() to set parameter
set the second argument(index) to 5
get the result code:25(out of bounds)
then i call sqlite3_step,and get the result code:1(err)
i wanna know whether this is a bug
thanks |
2006-Dec-31 10:57:47 by anonymous:
It would be considerably easier to understand your question if you posted the actual code. You can do that by using attach, or pasting it into a remark. If you paste it into a remark, make sure each line has two spaces at the begining
2006-Dec-31 11:06:27 by drh:
Since your code is not calling sqlite3_bind_*() correctly (evidenced
by the fact that it returns an error) I think it is a safe assumption
that the bug is in your code, not in SQLite.
2006-Dec-31 14:48:16 by anonymous:
what I want to say is:
since I called sqlite3_bind_*() and got an error code, why it can be sqlite3_step correctly(return code is 101).
Happy New Year~
2006-Dec-31 17:16:07 by drh:
Unbound parameters are interpreted as NULLs.
2007-Jan-08 04:03:35 by anonymous:
Thanks a lot. |
|
2124 |
code
|
closed
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
1
|
1
|
default ./configure && make broken on Linux in latest CVS
|
edit |
Something checked into CVS in the past couple of days that broke the default build on Linux. Following was done after a fresh CVS checkout:
$ ./configure && make
...
ranlib .libs/libsqlite3.a
creating libsqlite3.la
(cd .libs && rm -f libsqlite3.la && ln -s ../libsqlite3.la libsqlite3.la)
./libtool --mode=link gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_CURSOR -DHAVE_READLINE=0 \
-o sqlite3 ./src/shell.c libsqlite3.la \
gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_CURSOR -DHAVE_READLINE=0 -o .libs/sqlite3 ./src/shell.c ./.libs/libsqlite3.so
./.libs/libsqlite3.so: undefined reference to `dlclose'
./.libs/libsqlite3.so: undefined reference to `dlopen'
./.libs/libsqlite3.so: undefined reference to `dlsym'
collect2: ld returned 1 exit status
|
2006-Dec-21 22:19:45 by anonymous:
Problem introduced by this checkin [3541]
2006-Dec-22 04:35:33 by anonymous:
Regarding this ongoing autoconf issue - you mentioned in another ticket that you run Windows from VMWare. Just grab a VMWare image of Ubuntu or any current Linux distro and it will have a working version of autotools. |
|
2121 |
code
|
closed
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
3
|
4
|
Paths on Win9x following API specs (UTF-8) will fail
|
edit |
Background
The codepage usually associated with the -A api's on Windows is the ANSI codepage. For example, DeleteFileA expects an ANSI codepage encoded string (unless file API's are set to OEM in which case it expects a CP_OEM encoded string). DeleteFileW always expects a UTF-16 encoded string. char * strings in Windows are implicitly assumed to be in the ANSI codepage. Conversely, sqlite expects all char * strings to be in UTF-8.
Problem
There is a problem with current implementation of the os_win.c functions. The utf8ToUnicode function will fail (by design) on Windows 9x platforms. This fall back for this failure sends the char* string directly into the ANSI API function.
Consequently, in the current version of sqlite, for char* strings to be correctly interpreted by the operating system:
- UTF-8 strings need to be used on Windows NT
- ANSI codepage encoded strings need to be used on Windows9x
Note that problems will only be exhibited when the string contains characters not in the ASCII character set.
This is contrary to the published sqlite interface specification. Note that this bug will only occur on Windows 9x (or when malloc fails on Windows NT). Thus this bug affects only users on Windows 9x.
Solution
The existing code logic needs to be changed to implement logic similar to:
winNT UTF-8 --convert--> UTF-16 ==> *W
win9x UTF-8 --convert--> UTF-16 --convert--> Current-Codepage ==> *A
Note: the current codepage needs to be determined via:
currentCodePage = (AreFileApisANSI() ? CP_ACP : CP_OEM);
This means an implementation something like:
wchar_t bufW[];
convertUTF8toUTF16(infile, bufW);
if (IsNT) {
retval = funcW(bufW);
}
else {
char bufA[];
convertUTF16toCP(bufW, bufA)
retval = funcA(bufA);
}
Rewriting the existing os_win.c code to use this format is a substantial undertaking and rework. |
2006-Dec-20 23:59:11 by anonymous:
I think the current code should fail rather than silently mangling the name (treating UTF8 as ANSI).
However a far easier "fix" is to tell people in Windows 9x to use Unicows instead. If you use Unicows then you can always use the W version of the win32api on any version of Windows.
http://en.wikipedia.org/wiki/Unicows
http://www.microsoft.com.nsatc.net/globaldev/handson/dev/mslu_announce.mspx
http://opencow.sourceforge.net/
http://libunicows.sourceforge.net/
http://www.microsoft.com/downloads/details.aspx?FamilyID=73BA7BD7-ED06-4F0D-80A4-2A7EEAEE17E2&displaylang=en
2006-Dec-21 00:41:46 by drh:
The premise of this ticket appears to be incorrect. The current
os_win.c implement works like this:
- Check to see if the system is winNT or win95
- If the system is winNT then invoke utf8ToUnicode() to
convert utf8 filenames into microsoft unicode and then
call the -W() apis.
- If the system is win95 then invoke utf8ToMbcs() to convert
utf8 filenames into the current code page then use the
-A() apis.
Each os_win.c interface calls convertUtf8Filename() to convert
the filename from utf8 into the appropriate encoding based on
whether or not the system is winNT or win95. Then an if statement
is used to branch to either a -W() implementation of the interface
for winNT or a -A() implement for win95.
In every case, the os_win.c interface expects to get a utf-8
inputs. ASCII input is never correct at the os_win.c interface.
The problem statement above says that "the utf8ToUnicode
function will fail (by design) on win9x". This is false.
The utf8ToUnicode function should never fail except in an
out-of-memory condition. On win9x, utf8ToUnicode() is called
and the result is sent to unicodeToMbcs() and by this two-step
process, utf8 input strings are converted into the current
codepage, whatever that happens to be.
The current implementation appears to be correct.
2006-Dec-21 14:22:21 by anonymous:
Yes, this bug was written looking at the source for 3.3.8
This bug was fixed with the checkin to os_win.c
2006-Oct-30 13:37 1.66 Check-in [3495]
: Changes to support non-ASCII characters in win95 filenames. Ticket #2047 . By drh. (diff) |
|
2119 |
new
|
closed
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
5
|
4
|
Unable to use place holders as part of the actual SQL query
|
edit |
Example within a PHP context:
/* using sqlite 3 database SQLLDB is a define() path to the database location elsewhere */
if (!($db = new PDO('sqlite:' . SQLLDB)))
{
$error = $db->errorInfo();
die($error[2]);
}
/* the direction in which to order the query */
$direction = "ASC";
$query = $db->prepare('SELECT * FROM table_name ORDER BY value :dir');
$query->bindParam(':dir', $direction, PDO::PARAM_STR, 4);
$query->execute();
Here, a error stating that the prepare() failed occurs due to acting on a non-object. Would it be possible to maybe allow place holders for actual parts of the SQL query, rather than just values?
Cheers |
2006-Dec-20 16:39:05 by drh:
No, it is not possible to use place holders to change the
syntax of a query. If you have varying syntax, just rerun
prepare. |
|
2115 |
code
|
closed
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
5
|
4
|
mix of allocator functions
|
edit |
SQLite now uses directly realloc() (in os_unix.c, FTS1 and shells) and also defines sqlite3GenericRealloc() and sqlite3_realloc(). This makes it harder to replace the allocators with custom made ones.
Also struct sqlite3_api_routines has member "realloc" which may clash if someone does:
#define realloc(p, s) my_realloc(p, s)
The same holds for malloc(). |
2006-Dec-19 17:11:05 by anonymous:
Also locating call to realloc() into <os_common.h> may result in bugs if one uses macro to rename "realloc" and forgets to check all the locations.
2006-Dec-20 02:17:51 by drh:
The call to realloc() in os_unix.c is required because the routine
in which it is used has no way to propagate an SQLITE_NOMEM error
back up the call stack.
The other requests in this ticket cannot be satisfied without breaking
backwards compatibility which we are unwilling to do. |
|
2108 |
code
|
closed
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
4
|
3
|
potential memory leak in prepare.c
|
edit |
In the function sqlite3InitCallback() in the file src/prepare.c the conditional at about line 65 calls sqlite3_exec() passing in the pointer zErr. This allocates memory from the heap for zErr. As the code continues it is possible for zErr to leak at line 89 if the conditional that follows it does not trigger. The potential is very low and the leak is pretty small. But it still exists. |
2006-Dec-14 20:50:46 by drh:
The conditional that follows must trigger if zErr contains
a valid string, as the assert() on the previous line proves.
Thus zErr will always be freed. |
|
2103 |
secure
|
closed
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
2
|
2
|
No bound check for the insert string data!
|
edit |
when I create a table like "table1",
I can insert a data which is out of the bound of column "c2".
example:
CREATE TABLE table1(c1 char(100) PRIMARY KEY,c2 char(256));
insert into table1 (c1,c2) values('tt', '11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111');
This SQL sentences could work well and no error or exception output! Which means no bound check for column "c2"!
Please figure it out! |
http://www.sqlite.org/faq.html#q11 |
|
2102 |
code
|
closed
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
1
|
1
|
locking failing on w2k on vmware
|
edit |
We have a system that uis using sqlite.ado.net (but the issue appears to be with locking, hence the ticket here).
It can be reproduced 100% of the time at present within 2 minutes of running.
Using filemon from sysinternals we can see that a lock that is granted then fails to be released then no further locks are granted.
My initial thoughts were that thuis must be an OS issue, but I thought I'd post it here to see whether you can shed any light on debugging it further?
I've taken a look at os_win.c and the only thing of note there is that the system uses lockfile and lockfileex, but only uses unlockfile, not unlockfileex (not sure whether those unlock routines are actually one and the same though?)
I have a trace of this happening, but I'm not sure how to attach a file here, if somebody can send me an email address I'll forward it on. |
2006-Dec-07 18:40:11 by anonymous:
vmware in question is the latest version of vmware workstation (can't see as though it coudl be that as locking is OS, not hardware/BIOS)
sqlite.ado.net version is 1.0.36.1 (which incorporates the 3.3.8 codebase)
2006-Dec-07 20:51:45 by anonymous:
Can you write a 10 line C program that locks and unlocks a file in the manner SQLite does on Windows and test it under normal "gen-u-ine" Windows and under VMWare?
2006-Dec-07 21:19:56 by anonymous:
Not an SQLite bug. You must explicitly Close() and Dispose() of your database connection when you are done with it.
http://blogs.msdn.com/lyzh/archive/2004/09/20/231637.aspx
2006-Dec-07 21:35:57 by anonymous:
This is nothing to do with close/dispose, we're still running at this point!
We do close and dispose of all datareaders.
Tomorrow I'm going to rebuild the sqlite code with debug enabled and also add some debugs for the returns from lock calls to see whether this throws any light on the issue.
Can you re-open this ticket, I'm still exploring the reasons behind this problem.
2006-Dec-07 22:30:55 by drh:
Anybody can reopen a ticket. No special permissions are required.
Just change the "Status" to whatever you want it to be. This
bug tracking system is very wiki-like in that anybody can edit
just about anything.
Please do submit any additional information you find on the problem.
The windows locking code has been in heavy use for a long time and
nobody else has ever encountered this trouble. I do all of my
testing on VMWare, and there are many explicit tests of the locking
logic in the SQLite regression test suite. So this is something
of a mystery. Any information you can provide in helping to track
the problem down will be appreciated.
2006-Dec-07 22:32:03 by drh:
Is the database on a local filesystem or on a network filesystem?
2006-Dec-07 22:35:29 by anonymous:
local filesystem, is there a way i can post a file here?
if not I'll paste an amount ofthe trace which will make it easier to see the issue.
2006-Dec-08 00:01:13 by drh:
To add a file here, click on the [Attach] link in the upper
right-hand corner of the page.
2006-Dec-08 09:31:16 by anonymous:
Sorry, had missed that one!
I've now rebuitl the dll, have added some debugging to it and am currently running, I'll add more debugging as required and post the results here shortly.
2006-Dec-08 09:56:00 by anonymous:
We're seeing a 33 (ERROR_LOCK_VIOLATION), however I don't think the debug logs every error so I'm going to add logging for all lockin gerrors and see whether that shows anything different.
2006-Dec-08 10:41:08 by anonymous:
Ok, here's some of the debug from the run:-
I've included some run-up to when the error occurs
In essence it's trying to acquire an exclusive lock.
The unlockreadlock works.
The lockfile fails with 33 (ERROR_LOCK_VIOLATION)
- WRITE 648 lock=0
- WRITE 648 lock=0
- WRITE 944 lock=0
- SEEK 648 0
- WRITE 648 lock=0
- WRITE 648 lock=0
- WRITE 648 lock=0
- WRITE 648 lock=0
- SEEK 648 0
- WRITE 648 lock=0
- WRITE 648 lock=0
- WRITE 648 lock=0
- WRITE 648 lock=0
- SEEK 648 0
- SEEK 932 38985728
- READ 932 lock=2
- WRITE 648 lock=0
- WRITE 648 lock=0
- WRITE 648 lock=0
- WRITE 944 lock=0
- SEEK 648 0
- SEEK 540 577536
- READ 540 lock=4
- SEEK 932 6696960
- READ 932 lock=2
- WRITE 648 lock=0
- WRITE 648 lock=0
- WRITE 648 lock=0
- WRITE 944 lock=0
- SEEK 648 0
- SEEK 932 39116800
- READ 932 lock=2
- WRITE 648 lock=0
- WRITE 648 lock=0
- WRITE 648 lock=0
- WRITE 944 lock=0
- SEEK 648 0
- WRITE 648 lock=0
- WRITE 648 lock=0
- WRITE 648 lock=0
- WRITE 648 lock=0
- SEEK 648 0
- LOCK 932 4 was 2(0)
- unreadlock = 1
- error-code = 33
- LOCK FAILED 932 trying for 4 but got 3
- LOCK 932 4 was 3(0)
- unreadlock = 0
- error-code = 33
- LOCK FAILED 932 trying for 4 but got 3
- LOCK 932 4 was 3(0)
- unreadlock = 0
- error-code = 33
- LOCK FAILED 932 trying for 4 but got 3
- LOCK 932 4 was 3(0)
- unreadlock = 0
- error-code = 33
- LOCK FAILED 932 trying for 4 but got 3
- LOCK 932 4 was 3(0)
- unreadlock = 0
- error-code = 33
- LOCK FAILED 932 trying for 4 but got 3
- LOCK 932 4 was 3(0)
- unreadlock = 0
- error-code = 33
- LOCK FAILED 932 trying for 4 but got 3
- LOCK 932 4 was 3(0)
- unreadlock = 0
- error-code = 33
- LOCK FAILED 932 trying for 4 but got 3
- LOCK 932 4 was 3(0)
- unreadlock = 0
- error-code = 33
- LOCK FAILED 932 trying for 4 but got 3
- LOCK 932 4 was 3(0)
- unreadlock = 0
- error-code = 33
- LOCK FAILED 932 trying for 4 but got 3
- LOCK 932 4 was 3(0)
- unreadlock = 0
- error-code = 33
And so on.....
2006-Dec-08 11:06:26 by anonymous:
Just noticed a couple of other places that no errors are being logged and having checked the filemon output, this isn't the first error so ignore the above.
The first error is probably attempting to aquire the
reserved lock.
Just re-running now with the extra debug.
2006-Dec-08 11:53:34 by anonymous:
Ok, nothing new from that run.
2006-Dec-08 12:11:56 by anonymous:
Coding error, I was using the wrong connection to execute one of my queries and blocked myself out. |
|
2101 |
event
|
closed
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
1
|
1
|
sqlite files filling up Temp folder 7,700 files so far can not delete
|
edit |
over 7,700 + sqlite files in temp folder can not get rid of , do not know what may be causeing them? |
2006-Dec-07 17:40:16 by drh:
http://www.sqlite.org/cvstrac/wiki?p=McafeeProblem |
|
2097 |
code
|
closed
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
1
|
1
|
MAX function broken
|
edit |
given a table with an integer column I can
select min(number) from testtable
to get an integer value; doing
select max(number) from testtable
on the same table returns the empty string. |
2006-Dec-04 17:59:23 by anonymous:
the very same code used to work before 3.3.8
2006-Dec-04 18:08:04 by drh:
Unable to reproduce.
Please provide additional information, such as the content of the
table that is giving an incorrect answer. |
|
2094 |
code
|
closed
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
1
|
3
|
Virtual table cursors are not freed (memory leak)
|
edit |
Cursors in virtual tables are not freed and the memory leaks. The bug is in the function sqlite3VdbeFreeCursor.
The cursor (pCx->pVtabCursor) is passed as a parameter to the xClose method on line 873.
At the end of the function various members of pCx are freed as well as pCx itself but not pCx->pVtab Cursor
The issue was found using valgrind, a stack trace from gdb in my xClose method and inspection of the source code |
2006-Dec-14 01:49:09 by anonymous:
A documentation issue, not a bug. http://www.sqlite.org/cvstrac/wiki?p=VirtualTableMethods has been updated to say exactly what you should do for memory in xOpen and xClose. |
|
2092 |
code
|
closed
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
4
|
5
|
Bind null on an insert doesn't allow a WHERE bound with null
|
edit |
I have two parts of my code for inserting into a table and then selecting from the table. The insert part would use a sqlite3_bind_null to set some of the fields to null. I then wanted to lookup the null values later with a similar sqlite3_bind_null. However, that didn't work. I changed the first bit of code to sqlite3_bind_text with an empty string, and it worked.
So some pseudo-ish code to reproduce would be:
sqlite3_exec(db, "CREATE TABLE MyTable(value TEXT)");
sqlite3_prepare(db, &insert, "INSERT INTO MyTable VALUES(?)");
sqlite3_bind_null(insert, 1);
sqlite3_step(insert);
sqlite3_prepare(db, &select, "SELECT value FROM MyTable WHERE value=?");
sqlite3_bind_null(select, 1);
sqlite3_step(select); /* this should return the row I inserted, but it doesn't */
|
2006-Dec-01 19:08:10 by anonymous:
Of course, nothing is equal to NULL, including NULL. So your WHERE clause isn't going to select any rows anyway, even if you could bind the parameter to NULL.
2006-Dec-01 19:29:46 by drh:
I run across the same problem sometimes. A while ago, I proposed
making the IS keyword a binary operator that was the same as ==
except that it compared NULLs as equal. Right now "IS NULL" is
a right unary operator. With IS as a binary operator you could
say:
... WHERE value IS ?
and get the results you want. You would also do funky things like
NULL IS value
in place of
value IS NULL
But for some reason which escapes my mind, nobody else thought
this was a good idea so I abandoned it.
2006-Dec-01 19:49:45 by anonymous:
this is the SQL standard... nothing else is EQUAL NULL (neither NULL = NULL evaluates to TRUE), only (value) IS NULL syntax is allowed |
|
2091 |
code
|
closed
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
3
|
3
|
thread unsafety + solution
|
edit |
I've been doing a scan on the PHP codebase looking for the usage of thread unsafe functions and found a number in libsqlite. Ilia Alshanetsky who you probably know has fixed a number of them in the PHP builds, but of course the problem in libsqlite remains. Ilia also suggested I would contact you. I'm not familiar with the sqlite codebase, but the problems are as follows:
date.c contains gmtime() (use gmtime_r), localtime() (use localtime_r) and rand() (use rand_r). All mentioned functions are not thread safe and should be replaced by the mentioned thread-safe counterparts.
I think it would be wise to grep the rest of sqlite for the usage of these functions as well.
Kind regards,
Ron Korving |
Already fixed. See ticket #1906. |
|
2085 |
code
|
closed
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
5
|
4
|
Round statement with different behavior between 3.2.8 and 3.3.7
|
edit |
Sqlite 3.2.8 :
SELECT ROUND (julianday(datetime('now','localtime')) - julianday (datetime('2005-12-31 12:13:14')));
return : 331
Sqlite 3.3.7 :
SELECT ROUND (julianday(datetime('now','localtime')) - julianday (datetime('2005-12-31 12:13:14')));
return : 331.0
It seems to be due to Sqlite 3.3.5 modification :
Change the round() function to return REAL instead of TEXT.
Two questions :
- Is this behavior works as designed ?
- What is the best way to retrieve 331 again ?
|
2006-Nov-27 18:09:38 by anonymous:
select cast( ROUND (julianday(datetime('now','localtime')) - julianday (datetime('2005-12-31 12:13:14'))) as integer );
2006-Nov-27 21:34:17 by anonymous:
Thanks :) |
|
2079 |
code
|
closed
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
1
|
1
|
strftime doesn't work in where statement
|
edit |
sqlite3 -version
3.3.5
sqlite> select distinct strftime('%H',timeOnly) from sampleData;
14
12
10
09
15
13
11
16
19
sqlite> select count(*) from sampleData where strftime('%H',timeOnly) = 12;
0
Why didn't this return any rows? |
2006-Nov-22 02:08:53 by anonymous:
Try '12'
sqlite> select a from (select '12' a) where a=12;
sqlite> select a from (select 12 a) where a=12;
12
|
|
2073 |
code
|
closed
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
4
|
4
|
Ordering by a named expression which includes random doesn't work
|
edit |
When sorting results by a named expression that includes random() (or another function whose outputs don't depend soley on its inputs), random gets called twice: once for computing the output field, and once for sorting. The following example (using the database example from the man page) illustrates the problem:
sqlite> select random() as x from memos order by x;
1225575423885923075
1023558125602533105
|
2006-Nov-20 17:11:16 by anonymous:
SQLite currently copies any matching aliased expressions from the SELECT list to the ORDER BY clause. As result, random() is executed twice - once in the result set for the row and once in the ORDER BY clause. If you wish to preserve this random() value you have to do it in an inner select.
select * from (select random() r union all select random() r) order by r;
Databases in general do not agree on how random() works. Some optimize the call out altogether and replace it with a constant for the SELECT, and others only return one random value per select statement. |
|
2064 |
code
|
closed
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
3
|
4
|
Table Name ignored if table Alias specified
|
edit |
Table aliases should not disallow the use of the original table name, they should just be an alternative name for the table if there is no ambiguity.
create table t1(a integer);
select a, t.a, t1.a from t1 t;
SQL error: no such column: t1.a
|
2006-Nov-11 23:18:19 by anonymous:
This patch allows table aliases or the original table names to be used in column references within the same SELECT. The sole regression in "make test" was join3-3.1, but its failure seems correct because the SELECT is indeed ambiguous. That test is corrected in this patch.
Index: src/expr.c
===================================================================
RCS file: /sqlite/sqlite/src/expr.c,v
retrieving revision 1.268
diff -u -3 -p -r1.268 expr.c
--- src/expr.c 24 Aug 2006 15:18:25 -0000 1.268
+++ src/expr.c 11 Nov 2006 23:15:38 -0000
@@ -863,10 +863,7 @@ static int lookupName(
iDb = sqlite3SchemaToIndex(db, pTab->pSchema);
assert( pTab->nCol>0 );
if( zTab ){
- if( pItem->zAlias ){
- char *zTabName = pItem->zAlias;
- if( sqlite3StrICmp(zTabName, zTab)!=0 ) continue;
- }else{
+ if( pItem->zAlias==0 || sqlite3StrICmp(pItem->zAlias, zTab)!=0 ){
char *zTabName = pTab->zName;
if( zTabName==0 || sqlite3StrICmp(zTabName, zTab)!=0 ) continue;
if( zDb!=0 && sqlite3StrICmp(db->aDb[iDb].zName, zDb)!=0 ){
Index: test/join.test
===================================================================
RCS file: /sqlite/sqlite/test/join.test,v
retrieving revision 1.22
diff -u -3 -p -r1.22 join.test
--- test/join.test 20 Jun 2006 11:01:09 -0000 1.22
+++ test/join.test 11 Nov 2006 23:15:38 -0000
@@ -458,4 +458,15 @@ do_test join-10.1 {
} {}
} ;# ifcapable subquery
+# Ticket #2064: Allow table names and table aliases to coexist
+# in column references.
+#
+do_test join-10.2 {
+ execsql {
+ CREATE TABLE t2064(a);
+ INSERT INTO t2064 VALUES(123);
+ SELECT a, t.a, t2064.a FROM t2064 t;
+ }
+} {123 123 123}
+
finish_test
Index: test/join3.test
===================================================================
RCS file: /sqlite/sqlite/test/join3.test,v
retrieving revision 1.4
diff -u -3 -p -r1.4 join3.test
--- test/join3.test 19 Jan 2005 23:24:51 -0000 1.4
+++ test/join3.test 11 Nov 2006 23:15:38 -0000
@@ -53,7 +53,7 @@ for {set N 1} {$N<=$bitmask_size} {incr
# Error of too many tables in the join
#
do_test join3-3.1 {
- set sql "SELECT * FROM t1 AS t0, t1"
+ set sql "SELECT * FROM t1 AS a1, t1 AS a2"
for {set i 2} {$i<=$bitmask_size} {incr i} {append sql ", t$i"}
catchsql $sql
} [list 1 "at most $bitmask_size tables in a join"]
2006-Nov-15 05:30:25 by anonymous:
This proposed syntax might not be standard SQL.
PostgreSQL can parse it, but it rewrites the query internally as something completely different: "select t.a, t.a, f.a from t1 t, t1 f;"
template1=# create table t1(a integer);
CREATE TABLE
template1=# insert into t1 values(12);
INSERT 17306 1
template1=# insert into t1 values(23);
INSERT 17307 1
template1=# select a, t.a, t1.a from t1 t;
NOTICE: adding missing FROM-clause entry for table "t1"
a | a | a
----+----+----
12 | 12 | 12
12 | 12 | 23
23 | 23 | 12
23 | 23 | 23
(4 rows)
MySQL just chokes on it:
mysql> select a, t.a, t1.a from t1 t;
ERROR 1109: Unknown table 't1' in field list
Could someone with access to other major databases post the output of this SELECT?
2006-Nov-15 20:22:01 by anonymous:
Both Oracle and Sybase reject t1.a in the example SELECT, so this enhancement request is withdrawn. |
|
2058 |
code
|
closed
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
1
|
1
|
sum or total result in only 1 row returned
|
edit |
If I run the following query it returns 61,000 rows, if I uncomment the sum() or total() (I've tried both) then it returns 1 row.
How can I debug this?
select f.checksum||f.data_size as [groupby],
dups.count as [Occurences],
/* total(f.data_size) as [size Total Size], /
path||"\"||name as [Location]
from files as f
join (select count() as count,checksum,data_size
from files
where is_duplicate=1 and
data_size<>0
I can select the sum(data_size) from files with no issue, add a group by, add the where etc, with no problem.
group by checksum,data_size) as dups on dups.checksum=f.checksum and dups.data_size=f.data_size
|
2006-Nov-09 11:15:53 by anonymous:
The formatter seems to have removed the asterisk from the closing comment in the attached select.
2006-Nov-09 11:19:53 by anonymous:
In fact, it seems to have removed quite a bit, wish I'd done a preview now :(
Here's the correct code:-
select f.checksum||f.data_size as [groupby],
dups.count as [Occurences],
/* total(f.data_size) as [size Total Size], */
path||"\"||name as [Location]
from files as f
join (select count(*) as count,checksum,data_size
from files
where is_duplicate=1 and
data_size<>0
group by checksum,data_size) as dups on
dups.checksum=f.checksum and dups.data_size=f.data_size
2006-Nov-09 13:43:07 by drh:
TOTAL() and SUM() are aggregate functions and cause the query to
become an aggregate query. This is the way it is suppose to work.
All other SQL database engines do the same thing.
2006-Nov-09 13:56:00 by anonymous:
I think you've missed the point, there should be a vast number of rows, the sum or total is failing.
Is there a way I can debug this as the database is about 300Mb in size, therefore can't attach it.
The group by without the sum() returns 60+ thousand rows, adding the sum shoudl merely add an extra column to the output, not reduce to a single row, the sum should be 1 per grouping.
2006-Nov-09 13:57:25 by anonymous:
Sorry, just spotted what you mean, I've dropped my group by off the end....
hangs head in shame and withdraws ticket!!!!!
2006-Nov-09 14:10:19 by anonymous:
Actually, there possibnly is a syntax bug here as I think in other databases you wouldn't be able to output a field that wasn't either an aggregate or in the group by?
sqlite is allowing the output but then reducing to a single column |
|
2054 |
code
|
closed
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
1
|
1
|
material to learn SQLite
|
edit |
Hai
i am new to SQLite
where do i get materials to start from basics. |
2006-Nov-07 10:09:41 by anonymous:
There's a link called documentation...
http://www.sqlite.org/docs.html
In this page there's another link called Sqlite in 5 minutes or less...
http://www.sqlite.org/quickstart.html |
|
2053 |
code
|
closed
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
1
|
1
|
problem on solaris 10
|
edit |
I make and install sqlite3.3.8 on Solaris 10, i need to vork with tcl, but it didnt work. Example in Quick Start dont work also. I try resolve this problem with wiki, nothing.
Error:
couldn't load file ... fatal: rellocation error ... symbol fdatasync: referenced symbol not found |
2006-Nov-03 12:06:02 by drh:
See ticket #1545.
I am unable to fix this right now because it requires a change
to the configure script and autoconf is busted in SuSE 10.1 which
is what I have installed on all my systems. |
|
2052 |
code
|
closed
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
1
|
1
|
BLOBs still do not work on version 3.0
|
edit |
I use Python 2.5 to access sqlite3:
- Create a pil Image file, then
- convert to string throught img.save to StringIO
- insert into a BLOB column
- Finally try to "select * from tab"
ERROR:
c.execute('select * from tab order by path')
OperationalError: Could not decode to UTF-8 column 'pic' with text 'X`'
- i have already a working python program where this same data works fine in a 'dumdbm' database or write, then read a binary files. But I need the sql power, that is why I started trying of sqlite. |
2006-Nov-01 23:24:38 by drh:
This website is for reporting problems about SQLite. Your problem appears to be with Python. |
|
2049 |
code
|
closed
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
1
|
1
|
sqlite_HrmKZy6ma4XBUGl is in my temp file and cannot be deleted.
|
edit |
the above just showed up and can't be deleted from my temp file.
what is it? A bug?
thanks for help.
Don |
2006-Oct-31 21:06:49 by drh:
This is a problem with Mcafee Anti-virus.
See McafeeProblem for additional information.
2006-Nov-01 13:22:08 by anonymous:
Ideally, the temp file name would be prefixed by the name of the parent application. That should make it easier for users to find the correct people to complain at or, at least, make it harder to find the wrong people.
Not sure how feasible this is in Windows. It certainly doesn't appear necessary for non-Windows users. |
|
2042 |
code
|
closed
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
2
|
3
|
Subquery does not return the expected NULL
|
edit |
If a one of the fields in a field list gets its values from a subquery then this field will have a value if the subquery returns NULL, of course since this value can be meaningful this causes major problems in the logic of the program using the DB. My current work around is to use another subquery that the count the records that should be returned by the first subquery (0 or 1) soi that I could identify the NULLs
Code Ex:
select field1, field2,
/*The next subquery will return 0 either when the fieldB has 0
or when no record was found*/
(select fieldB
from TABLE2 T2
where (T2.fieldA = T1.field1)) as field3 /*An integer field*/,
/*The next subquery will return 0 when there is actually no
records and 1 when there was a record so we identify NULLs*/
(select count(1)
from points_SBL_programs GG
where (GG.point = B.point)) as ProgramReallyExists
from bicos B inner join pumps P
on B.pump_code = P.pump_code
where B.status <> 0;
|
2006-Oct-25 15:05:17 by drh:
I have read through the description above multiple times, but I
still cannot tell if this is a bug report, an behavioral
observation, or a feature request.
If you are having a problem, please describe what the problem is.
If you think SQLite is doing something incorrectly, then provide
a reproducible example of the incorrect behavior together with
a description of what you think the correct behavior should be.
If this is a feature request, please do a better job of saying
what feature it is that you want. |
|
2040 |
code
|
closed
|
2006 Oct
|
anonymous
|
|
2006 Nov
|
|
1
|
1
|
Fatal reloc error: Using sqlite-3.3.6 with apache-2.2.0 on SPARC Solar
|
edit |
Hi,
I am on a Solaris 8 system.
Main package I am trying to use SQLite with is apache. After unbundling all required packages, I get the following message when trying to run the http server
I unbundled sqlite-3.3.6-sol8-sparc-local.gz from SUN's sunfreeware site.
+++++++++++++++++++++++++++
ftcnssqadal3% !!
./httpd -f /usr/local/apache2/conf/httpd-std.conf
ld.so.1: httpd: fatal: relocation error: file /usr/local/apr/lib/libaprutil-1.so.0: symbol sqlite_freemem: referenced symbol not found
Killed
ftcnssqadal3%
Note: all s/w are gotten from http://sunfreeware.com/. They are
apache-2.2.0-sol8-sparc-local.gz
sqlite-3.3.6-sol8-sparc-local.gz
----------------------------------------
How can I get the "sqlite_freemem" symbol resolved ?
Thank you in advance
Regards
AhLek Chin
617.563.9722
ahlek.chin@fmr.com
|
Similar thing happens in Solaris 9 (x86) :
./apache2 start
httpd starting.
ld.so.1: httpd: fatal: libsqlite.so.0: open failed: No such file or directory
Killed
exit status 137
--- Then I create a link for libsqlite.so.0 in /usr/local/lib :
ln -s libsqlite3.so.0 libsqlite.so.0
./apache2 start
httpd starting.
ld.so.1: httpd: fatal: relocation error: file /usr/local/apr/lib/libaprutil-1.so.0: symbol sqlite_freemem: referenced symbol not found
Killed
exit status 137
Same versions of packages : apache 2.2.0, sqlite 3.3.6 |
|
2039 |
code
|
closed
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
1
|
1
|
How to delete SQLITE Temp files
|
edit |
Hundreds of "SQLITE" Temp files are adding up on my company and I am not able to delete them. Please tell me how to do this. I am not an IT or programer. I don't need this program. Thanks, Penne |
2006-Oct-24 14:09:52 by anonymous:
I noticed in the sqlite3 code that temp files are deleted before they are closed in UNIX (by design), and opened with a "delete on close" type of flag on Windows. Obviously, it works fine on those systems, but non-mainstream OSes that do not have such a delete-before-close feature do have the problem of accumulating sqlite_* temp files as the original ticket poster reports. Even on Windows with some mainstream crappy anti-virus software, I still see this sort of thing from time to time. It would be a useful compile-time option to either delete temp files matching a certain pattern with a certain header, or to provide a more non-OS specific way of deleting a temp file that does not rely on delete-on-close OS semantics.
2006-Oct-24 14:29:24 by drh:
This is bug in McAfee Antivirus, not SQLite.
See http://www.sqlite.org/cvstrac/wiki?p=McafeeProblem |
|
2035 |
code
|
closed
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
jenglish
|
1
|
1
|
lazarus and sqlite3
|
edit |
I'm using lazarus version 0.9.16 with Sqlite 3, and unit TSqlite3DataSet.
With sqlite3.exe I create this table:
create table producto (codigo varchar(6), ean varchar(15), desc varchar(30), precio numeric(10,2));
then with lazarus I insert 4000 records like this:
insert into producto values ( '00011','12312344','test test',3000);
I check the result with sqlite3.exe and everything is ok.
then I make a recorsed with lazarus, but when I open it I receive this error message: FIELD VARCHAR(6) NOT RECOGNIZED
I create the table again:
create table producto (codigo varchar, ean varchar, desc varchar, precio numeric(10,2));
I do the insert, and then open the recorsed and obtain the error again, FIELD NUMERIC(10,2) NOT RECOGNIZED.
I have to use all fields like varchar, for may application work |
|
2034 |
code
|
closed
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
jenglish
|
1
|
1
|
lazarus and sqlite3
|
edit |
I'm using lazarus version 0.9.16 with Sqlite 3, and unit TSqlite3DataSet.
With sqlite3.exe I create this table:
create table producto (codigo varchar(6), ean varchar(15), desc varchar(30), precio numeric(10,2));
then with lazarus I insert 4000 records like this:
insert into producto values ( '00011','12312344','test test',3000);
I check the result with sqlite3.exe and everything is ok.
then I make a recorsed with lazarus, but when I open it I receive this error message: FIELD VARCHAR(6) NOT RECOGNIZED
I create the table again:
create table producto (codigo varchar, ean varchar, desc varchar, precio numeric(10,2));
I do the insert, and then open the recorsed and obtain the error again, FIELD NUMERIC(10,2) NOT RECOGNIZED.
I have to use all fields like varchar, for may application work |
2006-Oct-19 14:59:56 by anonymous:
Complain to the Lazarus people (or whoever is author of the wrapper). The is not SQLite bug at all and SQLite itself doesn't check the data type (with the exception of INTEGER PRIMARY KEY and type affinity). |
|
2033 |
code
|
closed
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
1
|
1
|
SQLite 3.3.8 breaks Rails 1.1.6 (SQLite 3.3.6 OK)
|
edit |
Running Typo (a rails application) SQLite 3.3.6 works just fine.
Trying SQlite 3.3.8 breaks the application.
I belive it is in the way 3.3.8 handles text fields. Typo uses
YAML in a text field for its configuration information.
SQLite 3.3.6 retrives the YAML configuration, alright, but
something in 3.3.8 doesn't and the application breaks. |
2006-Oct-19 11:31:03 by drh:
I suspect that this is the same issue as described in tickets
#1968 and #2020. If so, then the problem is not in SQLite but
rather that Ruby misuses SQLite in a way that you could get away
with in version 3.3.6 but not in 3.3.8. Thus, if my guess is correct,
the problem is in Ruby and you should report the problem there.
If you can provide me with specific information about what
you think SQLite is doing incorrectly, I will be happy to
look into the matter. But a vague description about "breaking
Ruby" and some speculation about YAML handling (note that
SQLite does not know anything about YAML) is not sufficient
information on which to base a bug hunt. |
|
2031 |
code
|
closed
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
1
|
1
|
.DEF file missing from 3.3.8 source code distribution
|
edit |
I just downloaded the latest source code distribution of Sqlite v3.3.8 and noticed that a .DEF file needed to build a library is missing from the packages:
http://www.sqlite.org/sqlite-source-3_3_8.zip
http://www.sqlite.org/sqlite-3.3.8.tar.gz
Please check. |
2006-Oct-18 12:57:37 by anonymous:
It is automatically generated during the build.
2006-Nov-09 19:34:28 by anonymous:
I thought the sqlite-3.3.8.zip archive was supposed to include all of the contents of the src directory after it has been processed by the MinGW32 cross-compilation process. I thought the purpose of this zip archive was so folks on Windows that don't have the tools used by the formal build process could still build sqlite.
If I am correct, then the zip archive should also include the sqlite3.def file. This file is generated, but must be included if one is to successfully build from just the files in the zip archive.
Thanks |
|
2021 |
code
|
closed
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
a.rottmann
|
2
|
1
|
Expression Always Returning String
|
edit |
I downloaded Sqlite ver 3, and then I started to review sqlite characteristic and behavior, speed, sql compliance, etc.
most of all look good and work very well.
but I found a big problem, on some expression that allways returns string. for example, I use "SELECT SUM(PRICE*QTY) FROM INVOICE"
this returning string rather than float. and I try other functions like COUNT, TOTAL, CAST, Etc.
why?????? |
2006-Oct-13 11:50:39 by drh:
Please use the sqlite users mailing list for asking questions about
how to use sqlite. Tickets should be used for reporting bugs.
For information on how to subscribe to the sqlite mailing list
see http://www.sqlite.org/support.html |
|
2020 |
code
|
closed
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
1
|
1
|
sqlite3_column_type always returns 1
|
edit |
After executing a query, sqlite3_column_type() always returns 1 regardless of column data type. Works fine in 3.3.6 and 3.3.7 on both, Linux and Windows. |
Duplicate of ticket #1968 |
|
2007 |
code
|
closed
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
1
|
1
|
Server has unexpecedly died/u've found a bug/ i cant connect to hub
|
edit |
I can not connect to my hub, I've tried several times to input it manually, and it still does not work. Than after a couple minutes a pop up that states Server has unexpectedly died. You've found a bug :-) shows up. please help |
2006-Oct-04 04:00:29 by drh:
This website is for reporting bugs against SQLite - which
does not have a "server" or a "hub" and which is currently
at version 3.3.7. I'm not sure what software you are
having problems with, but it appears to be something other
than SQLite. |
|
2003 |
warn
|
closed
|
2006 Sep
|
anonymous
|
VDBE
|
2006 Sep
|
|
4
|
4
|
vdbeaux.c:1585: warning: unused variable 'sqlite3_search_count'
|
edit |
Is this a valid fix?
#ifdef SQLITE_TEST
extern int sqlite3_search_count;
#endif
|
Already fixed. See [3419]
|
|
2000 |
doc
|
closed
|
2006 Sep
|
anonymous
|
Unknown
|
2006 Sep
|
|
1
|
3
|
Teorical questions.
|
edit |
Can you put in your documentation of sqlite3 library/db (or answer to me) information about: 1) how many tables may contain a single db ?
2) how many rows may be in the table ?
3) How many databases can be atached for virtual table query?
PS: I couldn't find information about these quations in your documentation/
With best regards Sergey. |
2006-Sep-28 19:55:56 by drh:
- http://www.sqlite.org/faq.html#q9
- http://www.sqlite.org/faq.html#q10
- http://www.sqlite.org/lang_attach.html
|
|
1999 |
code
|
closed
|
2006 Sep
|
anonymous
|
Unknown
|
2006 Sep
|
|
3
|
3
|
Memmory leak and wrong passed argument to calback function
|
edit |
Memmory leak after opening dbase file detailed info and code is on
- http://phpfi.com/158092
and there is also a problem when fetching results from SELECT statement,
(somethings is wrong with 4th argument of callback function) here is code provided (not standalone)
- http://phpfi.com/158094
for details or full source you can contact me via e-mail, i would be glad to help you.
greetings,
Tomasz Gawęda. |
2006-Sep-28 20:01:45 by drh:
This ticket contains two complaints. The first one is a
duplication of ticket #856 and it not a bug. I do not
understand the second complaint but I don't think it is a
problem either. As best as I can determine, the author is
saying that if he accesses memory the bounds of an array
he is about to see query results, which is a bug in the
demonstration program not in SQLite. |
|
1997 |
code
|
closed
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
2
|
3
|
can't select rows if column name is contained in data
|
edit |
SELECT * FROM <db> WHERE <column> = "<data>";
fails when <data> is the same as <column> name. Expected that quoted data would be differentiated from column names. |
2006-Sep-26 17:42:37 by anonymous:
Use single quotes. |
|
1995 |
code
|
closed
|
2006 Sep
|
anonymous
|
|
2006 Oct
|
|
2
|
1
|
SHARED lock does not kick in (DEFERRED does not work ?)
|
edit |
According to documentation the SHARED lock should kick in as soon as a SELECT is executed. I tried the following (pseudo) code:
sqlite3_prepare(... "SELECT * FROM A_TABLE" ...)
sqlite3_step(...)
<============================= Another process does an UPDATE
sqlite3_finalize(...)
The other process is able to do an update so the SHARED lock is NOT active even though the _prepare and _step is called !
Adding a sqlite3_exec(... "BEGIN TRANSACTION" ...) before the _prepare/_step does not help
But sqlite3_exec(... "BEGIN IMMEDIATE TRANSACTION" ...) does.
With IMMEDIATE a SHARED lock kicks in and in the above the UPDATE fails.
Either the docs are wrong, locks get dropped after each _step or there is an error.
A workaround is to do a sqlite3_exec(... "BEGIN IMMEDIATE TRANSACTION" ...) before each SELECT but this may be problematic since nested transactions are not supported. |
2006-Sep-25 21:09:15 by drh:
Unable to reproduce.
When I run the TCL test script shown below, which implements the
pseudo-code above, the UPDATE statement returns an error that the
database is locked.
file delete -force test.db test.db-journal
sqlite3 db1 test.db
db1 eval {
CREATE TABLE t1(x);
INSERT INTO t1 VALUES(1);
INSERT INTO t1 VALUES(2);
}
sqlite3 db2 test.db
db1 eval BEGIN
db1 eval {SELECT * FROM t1} {
db2 eval {UPDATE t1 SET x=x+1}
}
db1 eval COMMIT
There are also a whole bunch of tests in the regression test suite
that verify the correction operation in scenarios like this one.
I'm thinking this is a problem with a specific SQLite build or
else a filesystem that does not support file locking.
After recompiling SQLite and (probably more important) recreating the database the error went away. Either the database was corrupted in some way or the SQLite version that created the database (3.3.4?) had some kind of bug.
My fault, I should have tested with another database. |
|
1993 |
event
|
closed
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
3
|
1
|
bit operators problemm
|
edit |
I've found this problemm in Sqlite3 for PHP 5.1.4 PDO driver version more than 3.2.8. I'm not shure that is a problemm of SQLite, but nevertheless ...
In TABLE a have FIELD (INT UNSIGNED), where bit mask putted.
SELECT ... FROM TABLE WHERE FIELD&1 -> WORKS correctly
BUT !!!!
SELECT ... FROM TABLE WHERE NOT FIELD&1 -> DON'T WORK
SELECT ... FROM TABLE WHERE !FIELD&1 -> DON'T WORK
SELECT ... FROM TABLE WHERE ~FIELD&1 -> DON'T WORK
SELECT ... FROM TABLE WHERE 1&~FIELD -> DON'T WORK
All this expressions (NOT FIELD&1, !FIELD&1, FIELD&~1, ~1&FIELD) returns TRUE always |
2006-Sep-24 16:13:00 by anonymous:
Use parantheses. "NOT" has lower precedence than "&" in SQLite.
sqlite> select not(7&128), (not 7)&128, not 7&128;
1|0|1
Likewise, "~" has lower precedence than "&".
sqlite> select ~7, ~7&128, ~(7&128), (~7)&128;
-8|-1|-1|128
|
|
1989 |
build
|
closed
|
2006 Sep
|
anonymous
|
Unknown
|
2006 Sep
|
a.rottmann
|
2
|
2
|
100's daily in XP temp folder-Cannot delete w/out reboot-Stop create?
|
edit |
This problem has been going on since I installed (2nd one) AOL Safety & Security Center. Not sure what is causing it, however. AOL non committal as always. 100's create daily in my temporary folder in XP. PROBLEM: You can't delete them without a reboot. They just keep on coming along with a "ver.." temp file that you can delete. How do I get these from not creating in the first place? You are about my 15th person/group to ask this question of. Please, someone, help! They are about 3k in size, but when I installed XP over a year ago I wasn't getting these at all. Thank you in advance!! |
2006-Sep-23 20:45:10 by drh:
See http://www.sqlite.org/cvstrac/wiki?p=McafeeProblem |
|
1988 |
code
|
closed
|
2006 Sep
|
anonymous
|
Parser
|
2006 Sep
|
|
2
|
2
|
linker error wih SQLITE_OMIT_VIRTUALTABLE
|
edit |
There's a problem with compiling with SQLITE_OMIT_VIRTUAL_TABLE.
There are 4 functions that still begin used (and referenced) in pager.c:
unresolved external symbol _sqlite3VtabArgExtend
unresolved external symbol _sqlite3VtabArgInit
unresolved external symbol _sqlite3VtabBeginParse
unresolved external symbol _sqlite3VtabFinishParse
there is a fix in sqliteint.h
#ifdef SQLITE_OMIT_VIRTUALTABLE
# define sqlite3VtabClear(X)
# define sqlite3VtabSync(X,Y) (Y)
# define sqlite3VtabRollback(X)
# define sqlite3VtabCommit(X)
# define sqlite3VtabBeginParse(a,b,c,d)
# define sqlite3VtabFinishParse(X,Y)
# define sqlite3VtabArgInit(X)
# define sqlite3VtabArgExtend(X,Y)
#else
void sqlite3VtabClear(Table*);
int sqlite3VtabSync(sqlite3 *db, int rc);
int sqlite3VtabRollback(sqlite3 *db);
int sqlite3VtabCommit(sqlite3 *db);
void sqlite3VtabBeginParse(Parse*, Token*, Token*, Token*);
void sqlite3VtabFinishParse(Parse*, Token*);
void sqlite3VtabArgInit(Parse*);
void sqlite3VtabArgExtend(Parse*, Token*);
#endif
|
2006-Sep-22 19:03:36 by anonymous:
The lemon parses isn't receiving the -DSQLITE_OMIT_VIRTUALTABLE in command line. This problem is related to the SQLITE makefile, that is ignoring this flag (and also other that I don't remember now).
2006-Sep-23 20:39:40 by drh:
Anonymous is correct. You have to pass -DSQLITE_OMIT_VIRTUALTABLE
to lemon when you are converting parse.y into parse.c. Do this
and the problem goes away. |
|
1985 |
doc
|
closed
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
1
|
4
|
how get table names
|
edit |
How get table names from single db file with sqlite api? |
Not only it's described in the FAQ - http://www.sqlite.org/faq.html (question 9), but this is also not a place for asking questions. That's what mailing list is for. |
|
1984 |
code
|
closed
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
1
|
1
|
sqlite3_exec problem
|
edit |
after execute sqlite3_exec function - azColName[0] was losed when funtion job finished. How i can get again? |
2006-Sep-19 12:05:25 by drh:
The arguments passed into the callback of sqlite3_exec() are
ephemeral. You must make a copy if you want them to persist.
This is documented behavior.
2006-Sep-19 12:15:14 by anonymous:
thanks
ps. I wanted save the copy :) |
|
1973 |
code
|
closed
|
2006 Sep
|
anonymous
|
Parser
|
2006 Nov
|
|
1
|
2
|
sqlite3_prepare (DLL 3.3.7) exception in two programs
|
edit |
I'm using Sqlite3explorer to browse Sqlite databases under Windows. Sometime it shows window "Access violation at address 609306F0 in module sqlite3.dll. Read of address 02DC206F" - just at startup time. When use Sqlite from my own code I also see exceptions at the same address:
EXCEPTION! CODE:C0000005 ADDRESS:609306F0 REGISTERS:
279E210 00 00 00 00 00 00 00 58 C7 95 14 40 00 00 00 00
279E220 00 00 00 D0 02 40 00 00 00 00 00 00 00 00 00 00
279E230 AB 03 00 00 2B 00 00 00 53 00 00 00 2B 00 00 00
END OF EXCEPTION REPORT
during execute sqlite3_prepare library call. In most cases it
works with the same database and same select statements OK, but
sometimes gives this error. In the previous Sqlite versions 3.3.4-3.3.6 there is same bug, but access violation address differs:
60925543 or (most often) 6092F520.
(The entry point of sqlite3_prepare in 3.3.7 is 0x609263D8). |
2006-Sep-10 07:43:20 by anonymous:
Sorry. 3.3.4 seems to be free of this bug.
2006-Sep-10 15:38:42 by anonymous:
Some sample code, the SQL statement being prepared, a sample database or some schema info would go a long way toward tracking this down ...
2006-Sep-16 13:31:42 by anonymous:
Here it is: http://sqlite.snop.ru/sqlite337_bug.zip (1 Mb - sqlite3explorer + DLL + database sample)
Sqlite3explorer with sqlite3.3.7 dll unable to show a database structure of test.db3. Replace 3.3.7 with 3.3.4 - and all becomes OK.
2006-Sep-17 01:40:15 by anonymous:
Works fine in Sqlite3explorer 1.1. No crashes after many repeated attempts. The table names appear garbled since my machine is not configured for the cyrillic character set, but the column names and data appear fine. You should contact the author of Sqlite3explorer, as it is probably an issue in that program.
2006-Sep-19 21:18:19 by anonymous:
As I wrote before, I have similar problem when use this dll from my own program too. Access violation occures at the same address in the Sqlite3.dll module.
Is there debug version of this dll? If it can write debug log, I will send it to you when next exception will be captured.
2006-Sep-19 22:55:22 by anonymous:
The 3.3.7 DLL worked fine for me. A debug log and the exception stack trace is not useful in solving your problem. Your program may be in error. Please supply the smallest possible C source code that exhibits this crash. Otherwise there is not much we can do to help you. |
|
1971 |
code
|
closed
|
2006 Sep
|
anonymous
|
Unknown
|
2006 Oct
|
|
4
|
4
|
66 tests fail out of 26937
|
edit |
I understand that perhaps this is not a very important thing but I wanted to report it nevertheless.
I am building sqlite 3.3.7 in a debian sarge box.
I prompt make test and I get a long battery of tests running (which is nice). At the end I get a report that says:
66 errors out of 26937 tests
Failures on these tests:
collate4-4.3 collate4-4.4 corrupt2-1.2 corrupt2-1.3 corrupt2-1.4 corrupt2-1.5 index-11.1 intpkey-3.4 intpkey-3.6 intpkey-3.7 intpkey-3.8 minmax-1.6 minmax-1.8 rowid-4.5 rowid-4.5.1 select2-3.2d select2-3.2e where-1.1 where-1.2 where-1.3 where-1.4 where-1.5 where-1.6 where-1.7 where-1.8 where-1.9 where-1.10 where-1.11 where-1.12 where-1.13 where-1.14 where-1.15 where-1.16 where-1.17 where-1.18 where-1.19 where-1.20 where-1.21 where-1.22 where-1.23 where-1.24 where-1.25 where-1.27 where-2.1 where-2.2 where-2.3 where-2.4 where-2.5 where-2.6 where-2.7 where-3.1 where-3.2 where-3.3 where-5.2 where-5.3 where-5.4 where-5.6 where-5.7 where-5.8 where-5.9 where-5.10 where-5.11 where-5.12 where-5.13 where-5.14 where-5.15
Should I worry about this? |
2006-Sep-09 17:40:53 by anonymous:
I don't see these errors on my machine. Can you post the relevant sections of the log showing the results for each of these failed tests?
What version of TCL are you using? I find that some test results are TCL version specific.
2006-Sep-10 11:17:02 by drh:
It works fine on my SuSE 10.2 box, so in the absence of any
additional information that might help me to track down the
problem, I am going to assume this is some kind of configuration
error during the build.
2006-Sep-10 15:24:57 by anonymous:
I think this ticket was closed too early, and the original bug reporter should at least be given at least a week to post requested information. His Linux box is running a very popular Linux distro, Debian, and it would be worth following up on for the sake of other Debian users.
2006-Sep-10 16:50:21 by drh:
Anybody can reopen a ticket. Just click on the "Edit" link near
the upper right corner, then go down an modify the status to whatever
you want.
2006-Sep-17 16:11:18 by anonymous:
All failed tests appear to be related to sqlite_search_count.
2006-Sep-18 03:49:09 by anonymous:
All SQL queries in the failed tests do in fact return the correct results. Just the sqlite_search_count does not match (the last column in each result). This is not a big deal, as this internal variable is only used in debug/test builds and does not exist in a release build. Even so, the non-determinism of sqlite_search_count is odd. Perhaps there is an invalid assumption in the tests themselves and they require re-tooling.
2006-Sep-23 22:24:16 by drh:
I have Debian Sarge running under VMWare now and I don't get any
of the errors reported above.
2006-Sep-24 01:54:42 by anonymous:
If either of the two Debian bug reporters could list how they configured sqlite and ran the tests, it would be helpful. Judging by the following lines in the test log, I suspect they ran a default configure && make test:
Skipping malloc tests: not compiled with -DSQLITE_DEBUG...
Skipping malloc tests: not compiled with -DSQLITE_MEMDEBUG...
I wonder if, by chance, Debian ships with sqlite3 libraries and headers and something is getting inadvertantly mixed up during the build.
2006-Oct-04 16:55:28 by anonymous:
Hi. Got similar failures for tests related to sqlite_search_count on Gentoo x64 and hardened (stack protection, PaX, Grsecurity).
See attach.
utf16-rowid-4.5.1...
Expected: [3 3]
Got: [3 2]
open-file-count=0
Memory leaked: 0 bytes in 0 allocations
Thread-specific data deallocated properly
130 errors out of 80400 tests
Failures on these tests: collate4-4.3 collate4-4.4 index-11.1 intpkey-3.4 intpkey-3.6 intpkey-3.7 intpkey-3.8 malloc2.1.5 minmax-1.6 minmax-1.8 printf-8.1 printf-8.2 rowid-4.5 rowid-4.5.1 select2-3.2d select2-3.2e types3-1.3 utf16-collate4-4.3 utf16-collate4-4.4 utf16-index-11.1 utf16-intpkey-3.4 utf16-intpkey-3.6 utf16-intpkey-3.7 utf16-intpkey-3.8 utf16-minmax-1.6 utf16-minmax-1.8 utf16-rowid-4.5 utf16-rowid-4.5.1 utf16-select2-3.2d utf16-select2-3.2e utf16-where-1.1 utf16-where-1.2 utf16-where-1.3 utf16-where-1.4 utf16-where-1.5 utf16-where-1.6 utf16-where-1.7 utf16-where-1.8 utf16-where-1.9 utf16-where-1.10 utf16-where-1.11 utf16-where-1.12 utf16-where-1.13 utf16-where-1.14 utf16-where-1.15 utf16-where-1.16 utf16-where-1.17 utf16-where-1.18 utf16-where-1.19 utf16-where-1.20 utf16-where-1.21 utf16-where-1.22 utf16-where-1.23 utf16-where-1.24 utf16-where-1.25 utf16-where-1.27 utf16-where-2.1 utf16-where-2.2 utf16-where-2.3 utf16-where-2.4 utf16-where-2.5 utf16-where-2.6 utf16-where-2.7 utf16-where-3.1 utf16-where-3.2 utf16-where-3.3 utf16-where-5.2 utf16-where-5.3 utf16-where-5.4 utf16-where-5.6 utf16-where-5.7 utf16-where-5.8 utf16-where-5.9 utf16-where-5.10 utf16-where-5.11 utf16-where-5.12 utf16-where-5.13 utf16-where-5.14 utf16-where-5.15 vtab_err-1.26.3 vtab_err-2.1166 where-1.1 where-1.2 where-1.3 where-1.4 where-1.5 where-1.6 where-1.7 where-1.8 where-1.9 where-1.10 where-1.11 where-1.12 where-1.13 where-1.14 where-1.15 where-1.16 where-1.17 where-1.18 where-1.19 where-1.20 where-1.21 where-1.22 where-1.23 where-1.24 where-1.25 where-1.27 where-2.1 where-2.2 where-2.3 where-2.4 where-2.5 where-2.6 where-2.7 where-3.1 where-3.2 where-3.3 where-5.2 where-5.3 where-5.4 where-5.6 where-5.7 where-5.8 where-5.9 where-5.10 where-5.11 where-5.12 where-5.13 where-5.14 where-5.15
(Gentoo) Linux localhost 2.6.16-hardened-r11 #8 SMP Fri Sep 29 17:05:46 BST 2006 x86_64 Intel(R) Pentium(R) 4 CPU 2.80GHz GNU/Linux
gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --enable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix gcc version 4.1.1 (Gentoo 4.1.1)
2006-Oct-04 18:39:07 by drh:
The reason I cannot reproduce this is that I'm running off of
the latest sources from CVS. This issue has already been fixed.
See ticket #1918.
2006-Oct-05 11:04:55 by anonymous:
Yes, confirmed here on that Gentoo x64. Thanks! |
|
1970 |
build
|
closed
|
2006 Sep
|
anonymous
|
Unknown
|
2006 Sep
|
|
4
|
4
|
Cannot make Loadable Extensions to work for me.
|
edit |
Hi. I hope this is the right place to tell this story.
I am building sqlite from sources in a debian sarge box.
I am interested in Loadable Extensions.
I had to introduce into the Makefile the following lines to enable the loadable extension mechanism:
TCC += -DHAVE_DLOPEN
and
TLIBS += /usr/lib/libdl.so
And then I go, no problems building. I have sqlite built with this feature I guess.
But the thing is that I cannot make it to work. I prepared a c file following the template given in the wiki. I generated a .so using:
gcc -I/path_to_sqlite-3.3.7/src -c -o Extension.o Extension.c
And
gcc -shared -o Extension.so Extension.o /path_to_libsqlite3.so/libsqlite3.so
I linked with this warning:
/usr/bin/ld: Warning: size of symbol 'sqlite3_api' changed from 4 to 460 in /path_to_libsqlite3.so/libsqlite3.so
But it produced the .so that I wanted.
When I do in sqlite3 prompt:
.load Extension.so
It goes:
unable to open shared library [Extension.so]
Any clues of what is going on?
Perhaps a sample gcc invokation line for building the extension would also be a good thing in the docs.
Thank you very much.
jima |
2006-Sep-10 11:08:48 by drh:
This is not the right place to tell your story, actually.
Tickets are for reporting bugs. You are having difficulting
compiling and using SQLite which is not really a bug.
For help on compiling and using SQLite, please send your
request to the sqlite mailing list. Instructions for joining
the mailing list can be found at
http://www.sqlite.org/support.html
|
|
1969 |
code
|
closed
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
3
|
2
|
Degrade of INSERT performance between 3.3.4 and 3.3.6/3.3.7
|
edit |
I don't agree with your resolution, so far.
- Maybe it's not the insert speed that suffered. It looks like it takes longer to parse the statement.
- Your TCL script repeats the same statement 1000 times, while I've inserted 24 different lines (ok, my report was inaccurate in this regard). I don't know, whether TCL's sqlite3 binding has any influence on this.
- I've used the precomiled sqlite3.dll for Windows.
- Can you give me a hint, how to reproduce your test scenario with sqlite3.exe, in a way that it parses and executes the mentioned statement 1000 times? When I put 1000 statements in a file to execute, does sqlite3 parse 1000 statements and then execute 1000 statements or does it 1000 times parse and execute a single statement?
|
2006-Sep-09 17:45:31 by anonymous:
If you put 1000 statements in a file then SQLite will parse and execute 1000 statements.
2006-Sep-17 12:29:15 by anonymous:
The performance degrade is the result of opening the in memory database by using a NULL filename (sqlite3_open(NULL, &pDB) ). The right way to open an in memory database seems to be sqlite3_open(":memory:", &pDB) , as mentioned in InMemoryDatabase on 2006-02-22. |
|
1968 |
code
|
closed
|
2006 Sep
|
anonymous
|
Unknown
|
2006 Sep
|
|
1
|
2
|
sqlite3_column_type() returns 1 instead of 0 since 3.3.7
|
edit |
It seems that sqlite3_column_type() now returns 1 where it used to return 0 and moreover it seems that it even returns 1 where it previously returned a different value (like 3). Up to and including version 3.3.6, the following code deduced the column type correctly even for a statement like
select * from [report] limit 0
which one might use to just get the column definition of the table report:
for (int i = 0; i < sqlite3_column_count(m_statement); i++)
{
const CString colName = sqlite3_column_name(m_statement, i);
int columnType = sqlite3_column_type(m_statement, i);
if (0 == columnType)
{
const CString colDeclType = sqlite3_column_decltype(m_statement, i);
if (0 == colDeclType.CompareNoCase("TEXT") || colDeclType.IsEmpty())
columnType = SQLITE_TEXT;
else if (0 == colDeclType.CompareNoCase("INTEGER"))
columnType = SQLITE_INTEGER;
else if (0 == colDeclType.CompareNoCase("REAL"))
columnType = SQLITE_FLOAT;
else if (0 == colDeclType.CompareNoCase("BLOB"))
columnType = SQLITE_BLOB;
else if (0 == colDeclType.CompareNoCase("NULL"))
columnType = SQLITE_NULL;
else
ASSERT(false);
}
}
In case you are looking for a table definition to test with, see ticket #1967. |
sqlite3_column_type() should only be called after sqlite3_step()
has returned SQLITE_ROW. You appear to be calling it before
calling sqlite3_step(), in which case the results are undefined. |
|
1967 |
code
|
closed
|
2006 Sep
|
anonymous
|
Unknown
|
2006 Sep
|
|
3
|
2
|
Degrade of INSERT performance between 3.3.4 and 3.3.6/3.3.7
|
edit |
I've recognized a severe performance degrade of the INSERT statement in versions 3.3.6/3.3.7 compared to version 3.3.4.
What did I do?
- create an empty memory database
- create an empty table by executing the attached statement by sqlite3_exec(m_sqlite3, sql, 0, 0, 0);
- insert 24 rows by executing 24 times the below statement with alternating data by sqlite3_exec(m_sqlite3, sql, 0, 0, 0);
Although there are only 24 rows to insert the performance issue is quite noticeable (takes about ten times longer to process).
BTW: I know that is recommended to use a prepared statement and the binding functions, but so far it was no bottleneck. |
2006-Sep-08 18:24:21 by drh:
I tried to reproduce this using the test script in the attachment.
(insert-speed.txt). I'm getting 562 microseconds per insert for
version 3.3.7 and 548 microseconds per insert for version 3.3.3
averaged over 1000 inserts. |
|
1966 |
build
|
closed
|
2006 Sep
|
anonymous
|
Unknown
|
2007 Feb
|
|
3
|
4
|
Add a --disable-readline option to configure
|
edit |
The configure script assumes that there is a version of readline available. It does some searching to find readline and will only decide that there is no readline and set TARGET_HAVE_READLINE to 0 if it fails the search.
This does not work when cross-compiling because the checks it does to find readline fail when cross-compiling.
I would like a --disable-readline (or --without-readline) option to configure that skips all the checks and just sets TARGET_HAVE_READLINE to 0.
I have attached a possible implementation, but I can't seem to test it because the configure fails for me if I run autoconf. |
2006-Sep-08 18:07:43 by drh:
See my comment on check-in [3307]
: I recently upgraded to SuSE 10.2
and now autoconf is busted on my system. Hence, I cannot regenerate
the configure script from the configure.ac file. I'll keep you patched
configure.ac around, but for the time being there is nothing I can do
with it.
Sorry.
2007-Feb-17 11:16:06 by vapier:
i've posted a patch to the mailing list to clean up the readline handling
http://thread.gmane.org/gmane.comp.db.sqlite.general/26261
... which is now merged into cvs |
|
1965 |
code
|
closed
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
3
|
3
|
sqlite returns wrong error code
|
edit |
I found what the problem is that sqlite returns the wrong error code. What happens is next (in version 3.3.7):
-vdbe.c:2593 -> sqlite3BtreeCursor returns code 6 (table locked) => rc = 6
-vdbe.c:2606 -> switch checks rc value
-vdbe.c:2642 -> falls to default which is goto abort_due_to_error (:4975)
-vdbe.c:4980 -> goto vbe_halt (:4947)
-vdbe.c:4948 -> rc > 0 == true
-vdbe.c:4950 -> rc = SQLITE_ERROR <== PROBLEM we forget the correct error code
-vdbe.c:4956 -> return rc (value is 1) == WRONG!
|
2006-Sep-08 11:43:29 by drh:
When sqlite3_step() fails, it always returns a generic error
SQLITE_ERROR. To get the specific error code, you have to call
sqlite3_reset().
See, for example, tickets #1633, #1366, #1178, #906, and probably
a bunch of others.
I'm going to go fix the documentation right now.... |
|
1963 |
new
|
closed
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
2
|
2
|
sqlite3_aggregate_context() should be improved
|
edit |
For implementing an OO wrapper (Java) around sqlite, I need to save information between aggregation function calls in an object (not in an fix-sized memory block).
For this I need a way to somehow attach a callback to the aggregation context, which is called once the aggregate context is no longer needed. In this callback I would finalize (=free/delete) my object.
Another reason why this is needed:
Imagine an aggregation function "concat(str, ',')" which concatinats aggregated values in a comma seperated list. Since the length of the resulting string is not known in advance, it is not possible to do this with the current sqlite3_aggregate_context() call. |
2006-Sep-07 14:48:24 by anonymous:
This is really easy to do. When your aggregate step() is called for the first time (sqlite3_aggregate_count() == 1) you call sqlite3_aggregate_context() and allocate 1 byte of storage. Then you use the resulting memory pointer as the key part of a static dictionary class of key/value pairs. Allocate your own data and store it in the dictionary and refer to it during step().
When your xFinal() function is called, do your wrapup work, deallocate your memory, remove your dictionary entry, and return the result.
2006-Sep-07 15:16:36 by anonymous:
Thank you for your suggestion. Under normal conditions, this will work. But what happens in case of an error: Is the xFinal() call guaranteed, even if an error occurs while processing the statement?
2006-Sep-07 16:35:10 by drh:
xFinal() is always called, even if an error occurs that aborts
the query. Some of the built-in aggregate functions depend on
this behavior. |
|
1962 |
new
|
closed
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
4
|
2
|
sqlite3_column_value() not exported
|
edit |
It would be nice to have the sqlite3_column_value() function exported into the DLL. This helps when implementing wrapper classes. |
2006-Sep-07 16:39:11 by drh:
Already fixed. See ticket #1951. |
|
1956 |
code
|
closed
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
1
|
1
|
ALTER TABLE ADD COLUMN does not support asian language column names.
|
edit |
The contents below contain asian characters, to be viewed more correctly, please visit the snapshot at here:
F:\tmp>sqlite test.db
SQLite version 3.3.7
Enter ".help" for instructions
sqlite> .dump
BEGIN TRANSACTION;
COMMIT;
sqlite> CREATE TABLE FOOBAR ("中文一" integer, "中文二" varchar(32));
sqlite> ALTER TABLE FOOBAR ADD COLUMN "中文三" integer;
sqlite> .dump
BEGIN TRANSACTION;
CREATE TABLE FOOBAR ("中文一" integer, "? "中文三" integer形亩? varchar(32));
COMMIT;
sqlite> .exit
F:\tmp>
|
2006-Sep-03 16:22:14 by drh:
I tried this and it works correctly for me on Linux.
SQLite expects to see UTF-8 characters. Perhaps you are
using win95 and the asian characters are encoded using
a "code page" rather than UTF-8? Or perhaps the DOS box
on windows just isn't able to handle UTF-8? Does anybody
know?
2006-Sep-03 16:28:14 by anonymous:
He use gb2312 chinese encoding, not utf8 encoding .So he should convert the text to utf8 encoding to create the table |
|
1952 |
code
|
closed
|
2006 Sep
|
anonymous
|
Parser
|
2006 Sep
|
|
2
|
2
|
Memory leak in select with duplicate colum names
|
edit |
reproduce:
"select * from a, b ... " where a and b have columns with the same name, e.g. "EntryId" => Memory leaks with "EntryId:1", "EntryId:2"...
the error is in the file select.c:
/* Make sure the column name is unique. If the name is not unique,
** append a integer to the name so that it becomes unique.
*/
zBasename = zName;
for(j=cnt=0; j<i; j++){
if( sqlite3StrICmp(aCol[j].zName, zName)==0 ){
==>>> old zName should be deleted here <<<===
zName = sqlite3MPrintf("%s:%d", zBasename, ++cnt);
j = -1;
if( zName==0 ) break;
}
}
|
2006-Sep-01 14:37:36 by drh:
Look again. The old value of zName gets freed in the code
that follows what you quoted above:
if( zBasename!=zName ){
sqliteFree(zBasename);
}
|
|
1950 |
new
|
closed
|
2006 Aug
|
anonymous
|
|
2006 Sep
|
|
4
|
4
|
AUTOINCREMENT too picky about type
|
edit |
Of these four statements,
CREATE TABLE tab (col INT PRIMARY KEY AUTOINCREMENT);
CREATE TABLE tab (col INT(11) PRIMARY KEY AUTOINCREMENT);
CREATE TABLE tab (col INTEGER PRIMARY KEY AUTOINCREMENT);
CREATE TABLE tab (col INTEGER(11) PRIMARY KEY AUTOINCREMENT);
only the third one works and the rest gives an error:
SQL error: AUTOINCREMENT is only allowed on an INTEGER PRIMARY KEY
But since they're all kind of equivalent, it would be nice if they would all work. |
2006-Sep-01 00:15:18 by anonymous:
They aren't equivalent. Please reread the section on INTEGER PRIMARY KEY at http://sqlite.org/lang_createtable.html. In particular, this:
An INTEGER PRIMARY KEY column man also include the keyword AUTOINCREMENT. The AUTOINCREMENT keyword modified the way that B-Tree keys are automatically generated. Additional detail on automatic B-Tree key generation is available separately.
2006-Sep-01 00:45:48 by anonymous:
That's because the average users don't know what is b-tree and are not concerned about the c code but they only think the sqlite supports the common sql language and they use it!
I personally the next version of sqlite change the its own policy even it might not be compatible with the former version of sqlite.
2006-Sep-01 01:20:19 by anonymous:
My vote is also for making INT == INTEGER as far as PRIMARY KEY is concerned. The current distinction is not obvious and not useful to new users of this database.
2006-Sep-01 15:16:23 by drh:
Backwards compatibility is much more important that the
syntactic preferences of new users.
2006-Sep-01 15:35:48 by anonymous:
Under what circumstance is the current behavior of "INT PRIMARY KEY" useful? Who would want the current less-efficient indexing behavior? |
|
1949 |
new
|
closed
|
2006 Aug
|
anonymous
|
|
2006 Aug
|
|
4
|
1
|
Missing 64Bit type
|
edit |
I missing a 64Bit integer type, something like "SQLITE_INTEGER64".
sqlite3_column_type returns only SQLITE_INTEGER so there is no chance to get the correct type before storing the value in a proper variable. |
2006-Aug-30 22:02:11 by drh:
SQLITE_INTEGER means a 64-bit integer. |
|
1945 |
code
|
closed
|
2006 Aug
|
anonymous
|
|
2006 Nov
|
|
1
|
1
|
symbol not found: sqlite_freemem
|
edit |
sqlite_freemem |
Similar thing happens in Solaris 9 (x86) :
./apache2 start
httpd starting.
ld.so.1: httpd: fatal: libsqlite.so.0: open failed: No such file or directory
Killed
exit status 137
--- Then I create a link for libsqlite.so.0 in /usr/local/lib :
ln -s libsqlite3.so.0 libsqlite.so.0
./apache2 start
httpd starting.
ld.so.1: httpd: fatal: relocation error: file /usr/local/apr/lib/libaprutil-1.so.0: symbol sqlite_freemem: referenced symbol not found
Killed
exit status 137
Same versions of packages : apache 2.2.0, sqlite 3.3.6 |
|
1944 |
new
|
closed
|
2006 Aug
|
anonymous
|
Unknown
|
2006 Aug
|
|
4
|
4
|
no UTF16 counterpart to sqlite3_exec()
|
edit |
(almost) all functions that manipulate strings in sqlite have an UTF16 counterpart but not sqlite3_exec().
you can execute an UTF16 sql statement using sqlite3_prepare16(), but it would be cleaner if we had an sqlite3_exec16() (more coherent with the rest of the API) |
2006-Aug-27 14:12:17 by drh:
The decision to omit sqlite3_exec16 was deliberate. If you need
such a function, you can make a copy of the implementation of
sqlite3_exec (found in the legacy.c source file) and modify it
appropriately. |
|
1940 |
code
|
closed
|
2006 Aug
|
anonymous
|
|
2006 Aug
|
|
3
|
3
|
insert default values
|
edit |
"UnsupportedSql" / 2004-11-17
sql92 says that the following syntax is allowed:
insert into test default values;
insert into test () values ();
with integer autoincrementing primary keys, the above makes sense.
currently, the workaround is to choose the autoincrement primary key <pk> and issue the command:
insert into test(<pk>) values (NULL); |
2006-Aug-25 08:38:26 by anonymous:
duplicate of 299 |
|
1936 |
code
|
closed
|
2006 Aug
|
anonymous
|
Unknown
|
2006 Aug
|
|
2
|
3
|
Altering schema seems to invalidate existing database connections
|
edit |
This may be related to previous tickets regarding schema changes, e.g. ALTER TABLE, invalidating previously prepared statements. Now, we don't keep any prepared statements, they are all prepared and executed immediately (we're using C++ with classes etc. and we guarantee this although it might not be the most efficient use of SQLite). However, when we create a table on one thread then, any other existing thread seems unable to use any previously opened database connection even with newly prepared statements. Any execution appears to return "SQL logic or database error" in sqlite3_step. I've listed this as a defect but this may be the required functionality but it doesn't appear to be documented as such. |
2006-Aug-22 12:29:37 by drh:
Everything works when I try it. If you really think this is an
error in SQLite and not in your code, then please provide additional
details so that we can reproduct the problem.
My test was to create a database like this:
CREATE TABLE t1(a,b);
INSERT INTO t1 VALUES(1,2);
INSERT INTO t1 VALUES(3,4);
Then open two connections to the database. In
the first connection, I ran
ALTER TABLE t1 ADD COLUMN c;
Then in the second connection I run
SELECT * FROM t1
And that works for me. If this is not what you are doing to
create the problem, then please provide additional details
so that we can recreate it.
2006-Aug-22 12:55:05 by anonymous:
We have two (or more) threads with open connections to the database. In the first we create a new table. In the second we then try to update an existing table and the update fails (not queries). We also get the same behaviour if we have sqlite3 open the database first before starting our server (so we have no open threads). Everything starts but if we create a table using sqlite3 then our server is no longer able to create new tables (unless we start a new thread). However, the converse is not true. If we start our server and create tables and then start sqlite3 it is able to create new tables. Our existing server thread(s) are then again not aboe to do this but new ones can. Our threads use long lived database connections and we also use a connection factory to ensure that no thread opens more than one connection to the database. I can provide C++ code snippets but we have tried to track this down in our code and see no obvious errors which is why I raised the original ticket. By getting the same behaviour using sqlite3 to create a new table we know that it isn't our creation that is the problem. It may be something else we are doing but it's not a question of a previously prepared statement. Unfortunately (for us) we can't reverse the roles and get the same failure which makes me think it is something we are doing although it isn't obvious to us (we're not using a shared cache).
2006-Aug-22 13:58:53 by drh:
Thousands of programmers (literally) have been doing what you describe
above for years and have not had a problem. Therefore, if you want us
to take your bug report seriously, you are going to have to provide
better instructions on how to reproduce the issue.
Vague and imprecise descriptions such
as given above are inadequate. We need a reproducible test case. In
the absence of a reproducible test case, we will assume that the problem is in your code.
Extraordinary claims require extraordinary proof.
If you would like help debugging your application, please
ask on the SQLite mailing list.
2006-Aug-23 11:39:09 by anonymous:
Well we obviously have failed to grasp something obvious here. We have an example that exhibits the behaviour I described previously that I enclose (in line). It may well be that there is a fundemental flaw in my understanding of the use of sqlite and if so, please point it out. Our example uses two threads the first creates a table, then the second creates a table and then the first attempts to insert into the table it creates. A mutex is used to ensure that each thread prepares, executes and finalizes a statement before releasing the mutex. We get the same behaviour with sqlite3 version 3.3.4 and 3.3.5 on Gento and 3.3.4 on Fedora 4, RedHat Enterprise 3 and Sun Solaris 2.9
If I use sqlite3_exec instead of sqlite3_prepare & sqlite3_step then it (and other test programs that continually loop around doing this) work as expected. So have I just missed some obvious step?
/*
./configure --prefix=/usr
--host=i686-pc-linux-gnu
--mandir=/usr/share/man
--infodir=/usr/share/info
--datadir=/usr/share
--sysconfdir=/etc
--localstatedir=/var/lib
--enable-incore-db
--enable-tempdb-in-ram
--enable-cross-thread-connections
--enable-threadsafe
--disable-tcl
--build=i686-pc-linux-gnu
*/
#include <sqlite3.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <pthread.h>
pthread_mutex_t critical = PTHREAD_MUTEX_INITIALIZER;
/* Prepare, execute, finalize as an atomic operation */
void execute(struct sqlite3 *db, const char *sql)
{
int status = 0;
struct sqlite3_stmt *stmt;
const char *tail = 0;
// CRITICAL SECTION
pthread_mutex_lock(&critical);
fprintf(stdout, "%s\n", sql);
if((status = sqlite3_prepare(db, sql, strlen(sql), &stmt, &tail)) != SQLITE_OK)
{
fprintf(stderr, "sqlite3_prepare: %d\n", status);
}
status = sqlite3_step(stmt);
if(status != SQLITE_DONE)
{
fprintf(stderr, "sqlite3_step: %d, %s\n", status, sqlite3_errmsg(db));
}
if((status = sqlite3_finalize(stmt)) != SQLITE_OK)
{
fprintf(stderr, "sqlite3_finalize: %d, %s\n", status, sqlite3_errmsg(db));
}
pthread_mutex_unlock(&critical);
// END CRITICAL SECTION
}
void *thread1(void *arg)
{
int status = 0;
struct sqlite3 *db = 0;
if((status = sqlite3_open("test.db", &db)) != SQLITE_OK)
{
fprintf(stderr, "sqlite3_open: %d\n", status);
}
/* Here's the critical bit. We create a table,
* then give the other thread time to create a
* table, then we insert into to ours.
*/
execute(db, "create table t1 (name varchar)");
sleep(2);
execute(db, "insert into t1 values ('x')");
if((status = sqlite3_close(db)) != SQLITE_OK)
{
fprintf(stderr, "sqlite3_close: %d\n", status);
}
return (void *)0;
}
void *thread2(void *arg)
{
struct sqlite3 *db = 0;
int status = 0;
if((status = sqlite3_open("test.db", &db)) != SQLITE_OK)
{
fprintf(stderr, "sqlite3_open: %d\n", status);
}
/* Here's the critical bit. We give the other thread
* time to create a table, then we create ours.
*/
sleep(1);
execute(db, "create table t2 (name varchar)");
if((status = sqlite3_close(db)) != SQLITE_OK)
{
fprintf(stderr, "sqlite3_close: %d\n", status);
}
return (void *)0;
}
int main()
{
remove("test.db");
pthread_t tid1, tid2;
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_create(&tid1, &attr, thread1, 0);
pthread_create(&tid2, &attr, thread2, 0);
pthread_join(tid1, 0);
pthread_join(tid2, 0);
return 0;
}
2006-Aug-23 15:12:35 by anonymous:
I have had a look at sqlite3_exec and see that it works because it retries sqlite3_prepare again if sqlite_step errors and the following sqlite2_finalize returns SQLITE_SCHEMA. But why doesn't the sqlite3_prepare know that the schema has changed? There's no race condition (it's not a problem of schema change between the prepare and step which we know invalidates the prepared statement), the schema change can have happened (on another thread) some time previously. |
|
1932 |
new
|
closed
|
2006 Aug
|
anonymous
|
|
2006 Aug
|
|
3
|
4
|
I want a way to make db open fail if file does not exist
|
edit |
I wish "sqlite3 foo.db" would fail if foo.db does not exist, instead
of creating it as a zero-length file. I'd be perfectly happy with
something like "sqlite3 --no-create foo.db".
I wish the same functionality was accessible in the API. |
2006-Aug-21 21:14:21 by anonymous:
Create a shell script called sqlite
and use it instead of sqlite3 :
#!/bin/sh
FILE=$1
if [ ! -f $FILE ]
then
echo "No such file $FILE"
else
sqlite3 $FILE
fi
2006-Aug-21 21:15:01 by drh:
The following code is untested, but should be sufficient to give
you the idea. This code will open a database file if the file
exists and return the sqlite3* pointer. If the file does not
exist, or if anything else goes wrong, return NULL.
sqlite3 *open_database_if_exists(const char *zDbName){
sqlite3 *db;
if( sqlite3_open(zDbName, &db)!=SQLITE_OK ){
return 0;
}
if( access(zDbName, 0) ){
sqlite3_close(db);
return 0;
}
return db;
}
|
|
1931 |
new
|
closed
|
2006 Aug
|
anonymous
|
|
2006 Aug
|
|
3
|
3
|
timezone difference between PDO/Sqlite and PHP
|
edit |
The date.timezone option defined in php.ini has no effect on
PDO/Sqlite.
date.timezone = Europe/Zurich
I've entered a bug with reproducing code in php team :
http://bugs.php.net/bug.php?id=38537
The answer is : "date.timezone sets timezone only for PHP's datetime functions. All third-party libraries are not affected."
It could be great to have the php extension working with the php timezone.
or
To have a PRAGMA command in sqlite for specify the timzone.
Example :
I give a DB outside my country. In all tables, there's a column called 'last_modif_d' who is filled by trigger like
UPDATE table_x SET last_modif_d = (SELECT datetime ('now','2 hours')) WHERE old.id = id ;
The user have to modifiy all triggers before using the DB. |
2006-Aug-21 17:02:03 by drh:
SQLite date/time functions use GMT. Convert to localtime using
the 'localtime' modifier.
2006-Aug-21 17:23:59 by anonymous:
OK, thanks. Works on Linux. Will try on HP-UX.
2006-Aug-22 07:23:04 by anonymous:
Works on HP-UX too :)
The problem was :
TZ was set to Europe/Zurich. This timezone format is not recognized on HP-UX (it's MET-1METDST) and localtime modifier had no effect. The solution is to use php.ini for specify the default timezone. This solution worked not with my old version of PHP 5.1.1 on HP-UX but works with my current version (5.1.2). |
|
1930 |
code
|
closed
|
2006 Aug
|
anonymous
|
Unknown
|
2006 Aug
|
adamd
|
1
|
1
|
the select command can't support NOT_FOUND.
|
edit |
When I use the "select"command ,there is no record in the table,but
It return value is 0,I think "it must be NOT_FOUND". |
The proposed change (in addition to being dubious) would break
backward compatibility. |
|
1929 |
warn
|
closed
|
2006 Aug
|
anonymous
|
|
2007 Sep
|
|
4
|
3
|
3.3.7 sqlite3_index_info incompatible with C++
|
edit |
The definition of sqlite3_index_info in sqlite3.h release 3.3.7 causes problems when compiling as C++ because "const" structure members can only be initialised by a user-defined constructor. I think the "const" should probably be removed. I get the following warnings with MSVC 6.0:
sqlite3.h(1644) : warning C4510: 'sqlite3_index_info' : default constructor could not be generated
sqlite3.h(1619) : see declaration of 'sqlite3_index_info'
sqlite3.h(1644) : warning C4610: struct 'sqlite3_index_info' can never be instantiated - user defined constructor required
|
2007-Feb-08 15:13:58 by anonymous:
I also meet this problem.
Why this issue is Pending?
I need this fixed to use the 3.3.x series.
2007-Sep-07 22:23:51 by anonymous:
I ran into this today. I spent some time working on it. It would be nice if this were fixed up or if a workaround were published.
2007-Sep-08 15:54:55 by anonymous:
Just hack the sources to remove the const or upgrade your compiler.
2007-Sep-21 14:31:29 by anonymous:
Fixed by Check-in [4445]
|
|
1922 |
code
|
closed
|
2006 Aug
|
anonymous
|
Parser
|
2006 Aug
|
|
1
|
1
|
field name with space can not be specified as primary key
|
edit |
field name with space looks like can not be specified as primary key. following script will fail with "table Abc has no column named Client name" error message
Create TABLE Abc(
[CUST_NO_1] INTEGER NOT NULL
, [CUSTOMER] VARCHAR(25) NOT NULL
, [Client name] INTEGER
, Primary Key([Client name])
) |
2006-Aug-16 01:15:14 by drh:
Unable to reproduce. I run the following script from the
command-line shell:
Create TABLE Abc(
[CUST_NO_1] INTEGER NOT NULL,
[CUSTOMER] VARCHAR(25) NOT NULL,
[Client name] INTEGER ,
Primary Key([Client name])
);
INSERT INTO Abc VALUES(1,2,3);
SELECT * FROM Abc;
And I get back and answer of 1|2|3, just as you would
expect. |
|
1921 |
code
|
closed
|
2006 Aug
|
anonymous
|
|
2006 Aug
|
|
4
|
4
|
misc1-10.1 failure on cygwin aborts make test
|
edit |
This test fails on Cygwin, but I don't know enough about TCL to know why. If I comment out the append line, then make test will continue with the rest of the tests, otherwise it aborts at this test. I'm using TCL v8.4.
do_test misc1-10.1 {
set ::where {WHERE x0>=0}
for {set i 1} {$i<=99} {incr i} {
append ::where " AND x$i<>0" # cygwin chokes on this line
}
catchsql "SELECT count(*) FROM manycol $::where"
} {0 9}
|
2006-Aug-16 01:17:34 by drh:
There does not appear to be anything wrong with the test case
shown, and it works on other platforms. Perhaps this is a bug
in Cygwin. What was the error message?
2006-Aug-16 05:33:29 by anonymous:
No error or message is produced.
testfixture.exe simply exits at that point:
$ testfixture test/misc1.test
misc1-1.1... Ok
misc1-1.2... Ok
misc1-1.3.1... Ok
misc1-1.3.2... Ok
misc1-1.4... Ok
misc1-1.5... Ok
misc1-1.6... Ok
misc1-1.7... Ok
misc1-1.8... Ok
misc1-1.9... Ok
misc1-1.10... Ok
misc1-1.11... Ok
misc1-2.1... Ok
misc1-2.2... Ok
misc1-2.3... Ok
misc1-3.1... Ok
misc1-4.1... Ok
misc1-5.1... Ok
misc1-5.2... Ok
misc1-6.1... Ok
misc1-6.2... Ok
misc1-6.3... Ok
misc1-6.4... Ok
misc1-7.1... Ok
misc1-7.2... Ok
misc1-7.3... Ok
misc1-7.4... Ok
misc1-7.5... Ok
misc1-7.6... Ok
misc1-8.1... Ok
misc1-8.2... Ok
misc1-9.1...
Expected: [0 {a 1234567890123456789 b 1234567891123456789 c 1234567892123456789}]
Got: [0 {a 2112454933 b -1182512363 c -182512363}]
misc1-10.0... Ok
The misc1-9.1 false error is unrelated. Sqlite3 produces the correct value on Cygwin, but Cygwin's TCL long integer math support is broken (expr 1234567890123456789+0 produces 2112454933).
If I comment out the append line in question
do_test misc1-10.1 {
set ::where {WHERE x0>=0}
for {set i 1} {$i<=99} {incr i} {
# append ::where " AND x$i<>0"
}
catchsql "SELECT count(*) FROM manycol $::where"
} {0 9}
then the nature of the subsequent tests change and I get a lot of false positives, but it does run to completion.
$ testfixture test/misc1.test
misc1-1.1... Ok
misc1-1.2... Ok
misc1-1.3.1... Ok
misc1-1.3.2... Ok
misc1-1.4... Ok
misc1-1.5... Ok
misc1-1.6... Ok
misc1-1.7... Ok
misc1-1.8... Ok
misc1-1.9... Ok
misc1-1.10... Ok
misc1-1.11... Ok
misc1-2.1... Ok
misc1-2.2... Ok
misc1-2.3... Ok
misc1-3.1... Ok
misc1-4.1... Ok
misc1-5.1... Ok
misc1-5.2... Ok
misc1-6.1... Ok
misc1-6.2... Ok
misc1-6.3... Ok
misc1-6.4... Ok
misc1-7.1... Ok
misc1-7.2... Ok
misc1-7.3... Ok
misc1-7.4... Ok
misc1-7.5... Ok
misc1-7.6... Ok
misc1-8.1... Ok
misc1-8.2... Ok
misc1-9.1...
Expected: [0 {a 1234567890123456789 b 1234567891123456789 c 1234567892123456789}]
Got: [0 {a 2112454933 b -1182512363 c -182512363}]
misc1-10.0... Ok
misc1-10.1... Ok misc1-10.2... Ok
misc1-10.3... Ok
misc1-10.4... Ok
misc1-10.5... Ok
misc1-10.6... Ok
misc1-10.7... Ok
misc1-10.8... Ok
misc1-10.9... Ok
misc1-10.10... Ok
misc1-11.1... Ok
misc1-11.2... Ok
misc1-12.1... Ok
misc1-12.2... Ok
misc1-12.3... Ok
misc1-12.4... Ok
misc1-12.5... Ok
misc1-12.6... Ok
misc1-12.7... Ok
misc1-12.8... Ok
misc1-12.9... Ok
misc1-12.11... Ok
misc1-12.12... Ok
misc1-12.13... Ok
misc1-13.1... Ok
misc1-14.1... Ok
misc1-14.2... Ok
misc1-14.3... Ok
misc1-15.1.1... Ok
misc1-15.1.2... Ok
misc1-15.1.3... Ok
misc1-15.2... Ok
misc1-16.1... Ok
misc1-16.2... Ok
misc1-16.3... Ok
misc1-16.4... Ok
misc1-16.5... Ok
misc1-16.6... Ok
misc1-17.1... Ok
misc1-18.1... Ok
Thread-specific data deallocated properly
1 errors out of 74 tests
Failures on these tests: misc1-9.1
As you say, it's probably a Cygwin TCL bug. |
|
1910 |
event
|
closed
|
2006 Aug
|
anonymous
|
|
2006 Aug
|
|
3
|
4
|
Lost clusters generated by "create TEMP Table" (DJGPP/GCC2.953)
|
edit |
SQLite 3.36 (compiled with DJGPP/GCC 2.953 - all optimizations disabled and running under plain DOS 6) generates lost clusters when creating temporary tables. No problem with "standard" tables though.
Is this a glibc specific issue? |
2006-Aug-09 11:43:47 by anonymous:
-DSQLITE_DISABLE_LFN has no effect.
2006-Aug-09 14:00:27 by anonymous:
I would seem like a DOS or libc issue. SQLite only uses the basic file I/O system calls. It would be hard pressed to create lost clusters on its own.
How would one create lost clusters on a DOS filesystem, anyway? If there is a repeatable set of I/O calls, perhaps it can be avoided or worked around.
2006-Aug-11 12:32:44 by anonymous:
It seems to be programming error which trashes DOS areas and
invalidates FAT in memory which is next written to disk.
|
|
1909 |
code
|
closed
|
2006 Aug
|
anonymous
|
VDBE
|
2006 Aug
|
anonymous
|
3
|
3
|
cannot use sqlite3_prepare() when DB is in "BEGIN EXCLUSIVE" mode
|
edit |
It is not possible to use sqlite3_prepare() when the database is busy, where busy is defined as "BEGIN EXCLUSIVE".
To reproduce, create a new DB (/tmp/sqlite3.db):
sqlite> .schema
CREATE TABLE foo (x integer primary key, y, z);
sqlite> begin exclusive;
In another process I execute the following code, but sqlite3_prepare() fails with "SQLITE_BUSY"
#include <stdio.h>
#include <stdlib.h>
#include <sqlite3.h>
int main (int argc, char *argv[])
{
sqlite3 *db = 0;
sqlite3_stmt *stmt = 0;
int rc = sqlite3_open (argv[1], &db);
if (rc != SQLITE_OK)
{
fprintf (stderr, "open error: %s\n", sqlite3_errmsg (db));
exit (EXIT_FAILURE);
}
rc = sqlite3_prepare (db,
"INSERT INTO foo VALUES (?, ?, ?)",
-1,
&stmt,
NULL);
if (rc != SQLITE_OK)
{
fprintf (stderr, "prepare error: %s\n", sqlite3_errmsg (db));
exit (EXIT_FAILURE);
}
return 0;
}
If I use any of "BEGIN DEFERRED" or "BEGIN IMMEDIATE" then the result from sqlite3_prepare is OK. Is there a reason why "BEGIN EXCLUSIVE" returns SQLITE_BUSY? |
2006-Aug-07 13:48:40 by anonymous:
I forget to add I'm compiling this code snippet as:
gcc test.c -I/usr/local/sqlite-3.3.6/include -L/usr/local/sqlite-3.3.6/lib -lsqlite3
and ldd on sqlite3.so reports:
ldd /usr/local/sqlite-3.3.6/lib/libsqlite3.so
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00cd9000)
libc.so.6 => /lib/tls/libc.so.6 (0x00111000)
/lib/ld-linux.so.2 (0x00655000)
2006-Aug-07 14:35:15 by anonymous:
work as designed. SQLite executable is holding a database lock and you must take account of that in your program.
2006-Aug-07 15:23:55 by anonymous:
Doesn't "BEGIN IMMEDIATE" also hold a RESERVED? lock on the DB? If so, why doesn't sqlite3_prepare() fail for this case?
2006-Aug-07 15:38:18 by drh:
sqlite3_prepare() might require access to the database in order
to read the database schema. This is not possible if another
process has the database locked.
Works as designed. |
|
1908 |
code
|
closed
|
2006 Aug
|
anonymous
|
Unknown
|
2006 Aug
|
anonymous
|
2
|
4
|
ORDER BY clause does not allow quoting
|
edit |
Problem found using the .schema below.
CREATE TABLE 'Labels' (
'Id' INTEGER PRIMARY KEY AUTOINCREMENT,
'Version' VARCHAR(10) NOT NULL UNIQUE,
'Date' VARCHAR(10) NOT NULL);
CREATE INDEX 'LabelVersions' ON 'Labels' ('Version');
After INSERTing data, the following SELECT ignores "ORDER BY" clause.
SELECT * FROM 'Labels' ORDER BY 'Version';
However, removing the single quotes produces the proper sort.
SELECT * FROM 'Labels' ORDER BY Version;
My assumption is the parser is not removing the single quotes from the ORDER BY clause. |
2006-Aug-07 01:02:41 by anonymous:
You should really use double quotes for quoting identifiers. Single quotes are used for quoting string literals only.
I don't know why parser even allows single quotes for quoting of identifiers. Another one of compatibility hacks, I guess.
2006-Aug-07 10:28:35 by drh:
Single-quoted strings are interpreted as string literals where
possible. Use double-quotes on column names. |
|
1904 |
code
|
closed
|
2006 Aug
|
anonymous
|
Unknown
|
2006 Aug
|
|
2
|
3
|
error using drop table "if exists" in exec
|
edit |
Hello,
I'm quite new to sqlite and I'm doing some tests using Qt with the sqlite-driver.
I guess, that Qt is not parsing and manipulating the sql-statement, therefore I post it here:
I have a text-file, where I put various sql-statements to create a new database. Each "create table" is prefixed by an "drop table if exists".
Using the textfile with the sqlite3-commandline-tool works fine.
In my app, where I read the textfile and execute each statement with sqlexec I get the error: error #1 - near "exists": syntax error
May be it correlates with not treating "if" as a keyword?
May be I could query the meta-data for an existing table, but I would appreciate it a lot, if it was possible, using the same statements with sqlite3-commandline-tool and the sqlexec-api. |
2006-Aug-02 12:02:38 by drh:
If it works using the command-line tool, then the problem must
be in the Qt driver. Either that or Qt is linked against an
older version of SQLite that does not support IF EXISTS.
Either way, the problem is not a bug that needs to be reported
here. Please send your problem to the mailing list. |
|
1903 |
code
|
closed
|
2006 Aug
|
anonymous
|
|
2006 Aug
|
|
2
|
2
|
LIKE string search sometimes fails
|
edit |
LIKE fails with sqlite3.exe:
create table test ( name varchar(20) primary key );
insert into test ( name ) values ( 'Y' );
insert into test ( name ) values ( 'YA' );
insert into test ( name ) values ( 'ZA' );
insert into test ( name ) values ( 'Z' );
select * from test WHERE name LIKE 'Y%'; -- returns 'Y' and 'YA'
select * from test WHERE name LIKE 'Z%'; -- returns nothing ????
|
2006-Aug-01 19:45:46 by anonymous:
above selects should be select * from test WHERE name like 'Y%', etc.
2006-Aug-01 21:04:43 by drh:
Unable to reproduce. |
|
1894 |
event
|
closed
|
2006 Jul
|
anonymous
|
Unknown
|
2006 Jul
|
|
4
|
3
|
"library routine called out of sequence" when using progress (TCL)
|
edit |
If one use progress to register a callback and that callback themselves contain a sqlite-command, a "library routine called out of sequence"-error occur.
Example-code (tclsh):
load tclsqlite3.dll
sqlite3 db ""
proc test {} {db eval "SELECT count(*) FROM sqlite_master"}
db progress 1 {test}
db eval "CREATE TABLE test(v1 text)"
|
2006-Jul-19 18:26:58 by anonymous:
A similar problem was reported for version 3.3.5 and has now (3.3.6) been fixed (ticket #1827). |
|
1891 |
code
|
closed
|
2006 Jul
|
anonymous
|
Shell
|
2006 Jul
|
pweilbacher
|
4
|
4
|
OS/2 may not have access to C:\ drive
|
edit |
OS/2 can be installed/booted from non-C:\ partitions. Assuming all attempts to set home_dir fail and C:\ isn't accessible (a Windows partition, for example) the code fragment:
-#if defined(_WIN32) || defined(WIN32) || defined(__OS2__)
if (!home_dir) {
home_dir = "c:";
}
would fail. |
2006-Jul-17 00:14:09 by drh:
The solution is to set the HOME environment variable,
I think.
The supplied patch seems wrong in a number of ways. For
one, it uses "c%" rather than "%c" inside an sprintf().
And for another, the first argument to the same sprintf()
appears to be a NULL pointer.
2006-Jul-25 13:19:32 by anonymous:
Same problem applies to Windows NT series OS (NT/2000/XP/...). |
|
1888 |
code
|
closed
|
2006 Jul
|
anonymous
|
Unknown
|
2006 Jul
|
anonymous
|
1
|
1
|
connetion to db extremely slow
|
edit |
I use SQLite 2.8.14 under PHP 5.0.5 on a Linux machine. My PHP code
<?php
$sqlite = new SQLiteDatabase( DB_SQLITE_DBNAME . ".db" );
if ( NULL !== $sqlite )
{
... do nothing yet
?>
Even just the connection to DB_SQLITE_DBNAME . ".db" is terribly slow!! When I try to run a query, it just runs forever, no timeout, no result. What's up with this??? I can't change SQLite version, since I'm not server admin or something. I heard (and saw in the tests) that SQLite is a fast db machine, but this is terrible! |
Please take your concerns to the SQLite mailing list.
Instructions for using the mailing list can be found
at http://www.sqlite.org/support.html |
|
1883 |
code
|
closed
|
2006 Jul
|
anonymous
|
|
2006 Jul
|
|
1
|
2
|
"no such table error" using sqlite-odbc driver
|
edit |
I have found a serious bug in the sqite-odbc driver. I wrote a simple test program which uses two ODBC connections to an sqlite database. The first connection is used to issue a "create table" query. The second one is used to do a "select" on this table. The select query reports an error : "no such table". However if you use the same connection for the create and select statement, everything is alright.
My version of sqlite is 3.3.6 built from tarball. Sqlite-odbc version is 0.66. The program runs on linux Mandrake 10.1 with 2.4.28 kernel with tls and O(1) patch, glibc 2.3.3-21mdk.
I have written a similar program which uses only the sqlite library, it works well with one or two connections. That's why I think the bug comes from sqlite-odbc.
I will attach the program.
To compile it with two distinct connections:
gcc sqlite.c -o sqlite -lodbc
And with only one connection:
gcc -DSAME_CONNECTION sqlite.c -o sqlite -lodbc |
Please submit this problem to odbc author as it is not
the Sqlite problem. |
|
1881 |
code
|
closed
|
2006 Jul
|
anonymous
|
Parser
|
2006 Jul
|
anonymous
|
2
|
1
|
error in inserting strings with single quotes
|
edit |
underlying is the insert query in which we are trying to insert a data with value as 'hello'
insert into Probes(Name) values(''hello'');
this insert query is giving sql error as
SQL Error: near "hello": syntax error <insert into Probes(Name) values(''hello'');>
Is it possible to insert a data with single quotes? |
2006-Jul-05 11:45:01 by anonymous:
String literals in SQL queries are delimited with single quotes. To insert single quote as part of literal string, you need to escape each of those single quotes that are part of string literal it self with 2 single quotes.
So in this case you'll need one single quote as a delimiter, and then 2 more that would represent one single quote that is actually part of your data.
Like this:
insert into Probes(Name) values('''hello''');
|
|
1880 |
code
|
closed
|
2006 Jul
|
anonymous
|
|
2006 Jul
|
|
3
|
3
|
Errors testing sqlite 3.3.6
|
edit |
$ make test
./libtool --mode=link gcc -s -O3 -march=i686 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -I. -I./src -DNDEBUG -DSQLITE_ALLOW_XTHREAD_CONNECT=1 -I/usr/local/include -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=1 -DSQLITE_OMIT_CURSOR -DTCLSH=1 -DSQLITE_TEST=1 -DSQLITE_CRASH_TEST=1 \
-DTEMP_STORE=3 -o testfixture ./src/btree.c ./src/date.c ./src/func.c ./src/os.c ./src/os_unix.c ./src/os_win.c ./src/os_os2.c ./src/pager.c ./src/pragma.c ./src/printf.c ./src/test1.c ./src/test2.c ./src/test3.c ./src/test4.c ./src/test5.c ./src/test6.c ./src/test7.c ./src/test_async.c ./src/test_md5.c ./src/test_server.c ./src/utf.c ./src/util.c ./src/vdbe.c ./src/where.c ./src/tclsqlite.c \
libsqlite3.la -L/usr/local/lib -ltcl8.5 -ldl -lpthread -lieee -lm
gcc -s -O3 -march=i686 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -I. -I./src -DNDEBUG -DSQLITE_ALLOW_XTHREAD_CONNECT=1 -I/usr/local/include -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=1 -DSQLITE_OMIT_CURSOR -DTCLSH=1 -DSQLITE_TEST=1 -DSQLITE_CRASH_TEST=1 -DTEMP_STORE=3 -o .libs/testfixture ./src/btree.c ./src/date.c ./src/func.c ./src/os.c ./src/os_unix.c ./src/os_win.c ./src/os_os2.c ./src/pager.c ./src/pragma.c ./src/printf.c ./src/test1.c ./src/test2.c ./src/test3.c ./src/test4.c ./src/test5.c ./src/test6.c ./src/test7.c ./src/test_async.c ./src/test_md5.c ./src/test_server.c ./src/utf.c ./src/util.c ./src/vdbe.c ./src/where.c ./src/tclsqlite.c ./.libs/libsqlite3.so -L/usr/local/lib -ltcl8.5 -ldl -lpthread -lieee -lm
creating testfixture
./testfixture ./test/quick.test
aggerror-1.1... Ok
[...]
conflict-6.1... Ok
conflict-6.2...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
conflict-6.3...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.4... Ok
conflict-6.5... Ok
conflict-6.6... Ok
conflict-6.7...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.8...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
conflict-6.9...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.10...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
conflict-6.11...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.12...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.13...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
conflict-6.14... Ok
[...]
date-3.17... Ok
/tmp/sqlite-3.3.6/.libs/lt-testfixture: invalid command name "clock"
while executing
"clock seconds"
invoked from within
"clock format [clock seconds] -format "%Y-%m-%d" -gmt 1"
invoked from within
"set now [clock format [clock seconds] -format "%Y-%m-%d" -gmt 1]"
(file "./test/date.test" line 142)
invoked from within
"source $testfile"
("foreach" body line 4)
invoked from within
"foreach testfile [lsort -dictionary [glob $testdir/*.test]] {
set tail [file tail $testfile]
if {[lsearch -exact $EXCLUDE $tail]>=0} continue
so..."
(file "./test/quick.test" line 64)
make: *** [test] Error 1 |
The test scripts only work with Tcl version 8.4. They have not
been ported to Tcl 8.5. |
|
1876 |
event
|
closed
|
2006 Jun
|
anonymous
|
Unknown
|
2006 Jun
|
|
4
|
4
|
Creating table disrupts previously prepared statement
|
edit |
This sequence of API calls fails:
open
exec(create table a)
prepare(insert into a)
exec(create table b)
prepare(insert into b)
bind(statement a)
step(statement a) * fails *
Moving creation of table b ahead of prepare for table a works |
2006-Jun-28 10:34:45 by drh:
Yes. Schema changes, ATTACH or DETACH, VACUUM, and various other
actions all invalidate prepared statements, requiring them to
be recompiled.
2006-Jun-29 01:59:26 by anonymous:
Would it be possible to get a specific error returned, such as 'stale statment' or 'schema changed' rather than 'SQL error or missing database'?
2006-Jun-29 07:26:12 by anonymous:
A subsequent call to sqlite3_finalize() or sqlite3_reset() should return SQLITE_SCHEMA. The error message at that point is more descriptive. |
|
1870 |
code
|
closed
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
2
|
2
|
dbWriteTable in RSQLite can't write strings that contain commas.
|
edit |
Currently if your data.frame contains any character strings with commas the intermediate CSV file used in the sqliteWriteTable will cause errors.
Here I slightly alter the sqliteWriteTable routine to support text with commas.
sqliteWriteTable <- function (con, name, value, row.names = TRUE,...)
{
fn <- tempfile("rsdbi")
on.exit(unlink(fn), add = TRUE)
dots <- list(...)
safe.write(value, file = fn, batch = dots$batch, row.names = FALSE,sep="\t")
a <- list(con = con, name = name, value = fn, header = TRUE, sep="\t")
do.call("sqliteImportFile", c(a, dots))
} |
2006-Jun-26 06:11:22 by anonymous:
sqliteWriteTable <- function (con, name, value, row.names = TRUE,...)
{
fn <- tempfile("rsdbi")
on.exit(unlink(fn), add = TRUE)
dots <- list(...)
safe.write(value, file = fn, batch = dots$batch, row.names = FALSE,sep="\t")
a <- list(con = con, name = name, value = fn, header = TRUE, sep="\t")
do.call("sqliteImportFile", c(a, dots))
}
For greater certainty, I think the original poster is talking about an SQLite-related module that allows users of the (very wonderful) statistical programming language R (a free implementation of S-Plus) to import SQLite datasets.
2006-Jun-26 09:51:04 by drh:
This system is for reporting bugs against the SQLite core.
Please report bugs against RSQLite to the creators of that
software. We have no ability to work on RSQLite. |
|
1868 |
code
|
closed
|
2006 Jun
|
anonymous
|
Shell
|
2006 Jun
|
|
4
|
4
|
where a = b = c
|
edit |
Shouldn't this be a syntax error?
create table t( catch text, me text );
select * from t where catch = me = 'if you can'; |
2006-Jun-23 13:57:40 by drh:
The expression is correct (according to SQLite at least -
other SQL parsers might disagree). It parses this way:
(a = b) = c
The (a=b) part evalutes to a boolean (0 or 1) then
it compares the 0 or 1 result to c. |
|
1866 |
event
|
closed
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
1
|
1
|
SQLite.NET ExecuteNonQuery() limit of text size
|
edit |
SQLite.NET ExecuteNonQuery() does not allow CommandText to be more than 110 K, it was found out by experimental way.
If text is more than 110 K it gives exception, "Attempted to read or write protected memory. This is often an indication that other memory is corrupt." |
2006-Jun-22 15:06:37 by drh:
This site is for the SQLite core only. The .NET wrappers
(there are several) are all developed separately. Use
google to find the right site. |
|
1865 |
code
|
closed
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
1
|
2
|
Encoding problem using order by
|
edit |
As I understand SQLite should be using OS functions to sort strings in order by clause, but non ASCII characters are not sorted correctly.
Example:
CREATE TABLE proba
(
id INTEGER PRIMARY KEY,
tekst TEXT
);
INSERT INTO proba VALUES(1,'Cicak');
INSERT INTO proba VALUES(2,'Čičak');
INSERT INTO proba VALUES(3,'Dida');
SELECT * FROM proba ORDER BY tekst ASC;
Expected results:
1|Cicak
2|Čičak
3|Dida
Actuall results:
1|Cicak
3|Dida
2|Čičak
Tested platforms:
WinXP SP2, Ubuntu |
By default, sqlite sorts strings in memcmp() order. If you need it to do
anything else you need to define and use a "collation sequence". See
section 7 of this for more detail:
http://www.sqlite.org/datatype3.html |
|
1859 |
code
|
closed
|
2006 Jun
|
anonymous
|
Unknown
|
2006 Jun
|
danielk1977
|
4
|
3
|
Wrong calculation og log2() in check-in [3274]
|
edit |
This part of check-in [3274]
look odd to me:
+ /* Approximation of log2(nRow). */
+ for( ii=0; ii<(sizeof(int)*8); ii++ ){
+ if( nRow & (1<<ii) ){
+ pIdxInfo->estimatedCost = (double)ii;
+ }
+ }
If you only want the MSB, then loop from sizeof(int)*8 to 0, and
break when a set bit is seen (faster ?!!).
Or if you want all bits to matter, then use "+=", not "="
Erling Jacobsen, linuxcub@email.dk |
2006-Jun-20 11:26:43 by anonymous:
Probably the first. Thinking about it, adding (with +=) will make things worse. But the loop can be made faster ...
2006-Jun-26 07:22:11 by anonymous:
Poster is right, this is a bit lazy and can be improved upon. But the block in question comes from test code, not from the library itself,
and the same function - echoBestindex() - test function has some other
really inefficient stuff too. So for now leave things as they are. |
|
1855 |
doc
|
closed
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
5
|
5
|
how to configure SQLite with jboss
|
edit |
i want to configure SQLite with jboss server.anybody can help me in doing this |
2006-Jun-19 09:59:20 by drh:
Please ask on the SQLite mailing list.
See http://www.sqlite.org/support.html for instructions
on how to subscribe to the mailing list. Please use
ticket for reporting bugs, not for asking questions. |
|
1854 |
event
|
closed
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
3
|
3
|
i am unable to view the tables by using .tables command
|
edit |
i am unable to view the tables created by using .tables ,once after coming out of the sqlite prompt. |
2006-Jun-19 09:48:07 by drh:
The .table command is a artifact of the command-line shell.
It is not built into the SQLite core library. |
|
1852 |
code
|
closed
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
4
|
5
|
AUTOINC NOT NULL problem
|
edit |
The INSERT fails with "SQL error: t.ID may not be NULL".
CREATE TABLE t (ID INT AUTOINC NOT NULL);
INSERT INTO t VALUES (null); |
2006-Jun-17 23:55:30 by drh:
OK. You declared a column to be NOT NULL and you tried to
insert a NULL into it and you get an error. What exactly
where you expecting to happen?
If you want autoincrement, declare the column to be
INTEGER PRIMARY KEY. ("INTEGER" spelled out, not abbreviated
to "INT".) |
|
1846 |
code
|
closed
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
1
|
1
|
Memory leak after returning error message
|
edit |
There is a memory leaking after returning error message:
SQLite3_Open(':memory:',db);
SQLite3_Exec(db,'DROP TABLE TEST',NIL,NIL,ErrMsg);
SQLite3_Exec(db,'DROP TABLE TEST',NIL,NIL,ErrMsg);
...
SQLite3_free(ErrMsg);
This will return error message to ErrMsg to both SQLite3_Exec() calls.
According to SQLite sources, memory for ErrMsg is allocated every time by malloc(), which causes memory manager to report memory leaking. Using realloc instead (when ErrMsg pointer is non NIL) will probably solve the problem.
It is slow and a bit unpractical using SQLite3_free(ErrMsg) after every SQLiteAPI call which use ErrMsg. |
2006-Jun-13 20:19:53 by drh:
You are requesting that *pzErrMsg be automatically freed if it
is reused. This is a reasonable idea. But it is not how SQLite
is documented to work. To make this change now would not be
backward compatible. It may well break existing code that
follows the documentation. For that reason, we must reject the
feature request.
Note that you can write a simple wrapper around sqlite3_exec()
or whatever other APIs you are using, to accomplish the the
automatic freeing effect that you desire. |
|
1844 |
warn
|
closed
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
2
|
3
|
compiler warnings with gcc 3.3.4 on Tru64 V5.1B
|
edit |
Here are few warnings you might want to fix since they seem to be actual bugs on 64-bit systems:
table.c: In function `sqlite3_get_table':
table.c:149: warning: cast to pointer from integer of different size
table.c: In function `sqlite3_free_table':
table.c:194: warning: cast from pointer to integer of different size
vdbemem.c: In function `sqlite3ValueText':
vdbemem.c:779: warning: cast from pointer to integer of different size
For the first two cases changing 'nData' in 'TabResult' and local variable 'n' from 'int' to 'long' fixes the problem on LP64 systems but not on LLP64 systems such as Windows.
In the third case cast the pointer to a 'long' instead of an 'int'. Same remark about LLP64 though. |
2006-Jun-12 13:09:21 by drh:
The warnings in table.c are false. Line 779 of vdbemem.c for
version 3.2.8 is in the middle of a header comment to a function
and is several dozen lines removed from sqlite3ValueText().
So I do not have any idea what line that is referring to.
2006-Jun-12 13:55:28 by anonymous:
It's SQLite 3.3.6 not 3.2.8.
I have no idea what went wrong, I remember typing 3.3.6.
2006-Jun-12 13:59:00 by anonymous:
Line 779 of vdbemem.c looks like:
if( (enc & SQLITE_UTF16_ALIGNED)!=0 && 1==(1&(int)pVal->z) ){
and the problem is the int cast.
Lines 149 and 194 of table.c look like:
res.azResult[0] = (char*)res.nData;
n = (int)azResult[0];
and the problem is conversion from/to pointer to/from int.
2006-Jun-12 14:24:30 by drh:
None of these things are actual problems.
2006-Jun-12 19:03:00 by anonymous:
Ah, good. I guess that's not a problem because the cast order is always:
32-bit integer -> 64-bit pointer
res.nData -> res.azResult[0]
64-bit pointer -> 32-bit integer
res.azResult[0] -> n
and there's even an assert() to ensure that there's no truncation in that order:
assert( sizeof(res.azResult[0])>= sizeof(res.nData) );
Still, it could be a good idea to work around the warnings, and since the warnings seem to occur with gcc only, it could be fixed on LP64 systems Unix/Linux/Mac only by using 'long' instead of 'int'. I don't know, maybe it's not worth the pain. |
|
1843 |
code
|
closed
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
3
|
2
|
compile with gcc 3.3.4 on Tru64 V5.1B
|
edit |
The version of SQLite 3.2.8 bundled with Qt 4.1.* doesn't build on Tru64 V5.1B:
$ gcc -c -g -D_REENTRANT -Wall -W -fPIC -DQT_NO_CAST_TO_ASCII -DQT_NO_CAST_FROM_ASCII -DQT_PLUGIN -DQT_SQL_LIB -DQT_CORE_LIB -DQT_SHARED [...] ../../../3rdparty/sqlite/os_unix.c
[...]
../../../3rdparty/sqlite/os_unix.c:832:63: operator '&&' has no right operand
[...]
I can't decide whether it's a compiler bug or an SQLite bug. See for yourself the attached build session.
In any case it's easy to work around, you just need to change from:
defined(_POSIX_SYNCHRONIZED_IO) && _POSIX_SYNCHRONIZED_IO>0
to:
defined(_POSIX_SYNCHRONIZED_IO) && (_POSIX_SYNCHRONIZED_IO>0)
The relevant code is not used anymore in SQLite 3.3.*. I doubt you're willing to release SQLite 3.2.9 just to fix this build issue, but I thought I'd report this issue nevertheless because the same problem could be found in SQLite 3.3.*. For now SQLite 3.3.6 builds just fine on the same platform, but such preprocessor directives could fail if using different compiler options. |
2006-Jun-12 12:51:12 by drh:
I think this is a compiler bug. But it is simple enough to
work around if it comes up again. Just report it and we will
implement the fix then.
2006-Jun-12 19:38:39 by anonymous:
Indeed this looks like a compiler bug.
The problem is that the actual bug is the parentheses fixing the error. Indeed parentheses did fix the error with gcc 3.4.4 on Tru64 but they don't fix the problem with gcc 4.1.1 on Linux:
foo.c:2:25: error: operator '>' has no left operand
or Sun's cc 5.5 on Solaris:
"foo.c", line 2: missing operand
"foo.c", line 3: warning: empty translation unit
cc: acomp failed for foo.c
or HP's aCC A.03.57 on HP-UX:
Error 123: "foo.c", line 2 # Syntax error in '#if' or '#elif' directive.
#if defined(FOO) && (FOO>0)
^
I'm not sure how to fix this if the _POSIX_SYNCHRONIZED_IO issue or a similar issue of macro constants defined to no value occurs again. This looks like a shortcoming of the C pre-processor.
2006-Jun-19 12:08:25 by anonymous:
Aaargh... The solution is easy, just need to change from:
#if defined(FOO) && (FOO>0)
to:
#if defined(FOO) && (FOO-0>0)
That's a standard workaround for the C preprocessor.
Anyway, I wasn't able to find similar problems in SQLite 3.3: all "#if" and ">" or "<" combinations involve SQLite internal macros and I doubt these internal macros can be defined to nothing. |
|
1842 |
code
|
closed
|
2006 Jun
|
anonymous
|
Unknown
|
2006 Jun
|
anonymous
|
1
|
1
|
The field data saved in the table is corrupt
|
edit |
The field data saved in the table is corrupt.
-------------detail----------------------------
we executed the SQL:
select * from etolldata where dutyid='352EC3C196F7DA119FF200D0F864D127'
and we got:
352EC3C196F7DA119FF200D0F864D127 ....
352EC3C196F7DA119FF200D0F864D127 ....
352EC3C196F7DA119FF200D0F864D127 ....
352EC3X/F7DA119FF200D0F864D127 ....
352EC3C196F7DA119FF200D0F864D127 ....
352EC3C196F7DA119FF200D0F864D127 ....
352EC3C196F7DA119FF200D0F864D127 ....
notice the fourth record, the content of field 'DutyID' is corrupt. |
2006-Jun-12 03:17:20 by anonymous:
You've provided no information that could help in tracking down the problem. The issue could very well be bad RAM, or a faulty hard disk, and not SQLite for all we know.
2006-Jun-12 11:10:04 by drh:
I agree with the remarks by anonymous above. This bug report
gives us no information that can be used to track down the error,
or even to suggest that the error is in SQLite. Probably this
is a bug in the application that is using SQLite or possibly in
the wrapper for whatever language is being used. |
|
1841 |
warn
|
closed
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
mani
|
3
|
2
|
a scan in safe mode says my sqlite file is wrong size
|
edit |
I'm having trouble opening my new computer so I opened it in safe mode. After a disk check it says the two sqlite files are the wrong size. Is this a big problem? |
2006-Jun-12 11:21:43 by drh:
The description above gives no context information. So, I will have
to take a wild guess at what is happening.
I'm guessing that the OS is windows since Linux does not normally
have anything called "safe mode". Also, most Linux distributions
use either ext3 or reiserfs, both of which will automatically
repair file metainformation after an unclean shutdown.
It is unclear what an "sqlite" file is. From the lack of useful
information in the trouble report, I assume that the reporter is
not a programmer. I am guessing that the user is using AOL and
has a disk full of "sqlite" files caused by the Mcafee virus
scanner bug
documented at http://tinyurl.com/pobqu
If my guesses above are correct, then the answer is "no" - this
does not matter in the least. |
|
1840 |
code
|
closed
|
2006 Jun
|
anonymous
|
Unknown
|
2006 Jun
|
|
4
|
4
|
sqlite3_get_table returns null pointer for aggregate queries
|
edit |
Simply put, it appears that aggregate queries on empty tables produce an output different from a non-aggregate function on a similarly empty table.
The following query: "select max(hnd) from mytable where 0=1;" put in sqlite3_get_table returns an array of two pointers, one for the column name, the other is null.
However, the following query: "select hnd from mytable where 0=1;" put in sqlite3_get_table returns an array of one pointer, pointing to the column name.
I'm sorry I cannot provide a sample of my code. I'm using an obscure language called J and it would be more trouble for you to try and find why it happened. It's no big trouble getting around the null pointer, but I was curious about this difference. |
2006-Jun-12 11:08:00 by drh:
The behavior you describe above is correct. The aggregate
query should return a single row with a value of NULL. Consider
a slightly different query:
SELECT count(*) FROM mytable WHERE 0=1
Most people expect this to return a count of 0, not an empty set.
If you agree that the above should return 0, then consider this:
SELECT count(*), max(hnd) FROm mytable WHERE 0=1
By adding the count(*) to your original query above, should that
cause the query to change from returning no rows to returning
one row? That seems very wrong. The correct and consistent
thing to do is to return one row in an aggregate query even if
there are no rows of input.
2006-Jun-17 00:10:47 by anonymous:
Makes sense. Thanks for taking the time to clear that up. |
|
1835 |
code
|
closed
|
2006 Jun
|
anonymous
|
Unknown
|
2006 Jun
|
|
1
|
2
|
Memory leak on sqlite3_step with Select with no result row
|
edit |
Memory leak on sqlite3_step with Select with no result row
Create table eventsout (mobpid integer primary key, eventdate text, eventtime text, senddate text, sendtime text, eventid integer, eventdata blob);
Select EventID, MobPID, EventDate, EventTime, EventData from eventsout where SendDate is NULL order by EventDate, EventTime;
sqlite3_step on that select consumes about 4KB of memory that is not returned on free-statement.
(Also tested SQLite 3.2.2 with same code; no memory problem !)
System: WindowsXP VS.Net 2005; using sqlite sources |
2006-Jun-08 12:59:38 by drh:
Unable to reproduce. Extensive internal checks inside SQLite reveal
no memory leaks. Valgrind also finds
nothing. Perhaps you have omitted you call to sqlite3_finalize? |
|
1834 |
code
|
closed
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
5
|
5
|
Can't create database with the é name (french E)
|
edit |
Hello,
Can't create database with the é name (french E) |
2006-Jun-07 17:59:29 by drh:
You have to pass the filename to sqlite3_open() as UTF-8.
You cannot use the microsoft codepage. |
|
1832 |
code
|
closed
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
1
|
1
|
Segmentation fault when placing a 0 limit on a joined subquery.
|
edit |
A segmentation fault occurs when running a nested query with a 0 limit on the inner query.
SQL commands to recreate the problem:
CREATE TABLE a (id INTEGER PRIMARY KEY);
CREATE TABLE b (id INTEGER PRIMARY KEY);
SELECT * FROM (SELECT * FROM a LIMIT 0) JOIN b;
SQLite should crash when trying to handle the SELECT.
Note that the following SELECT statement does not cause a crash:
SELECT * FROM (SELECT * FROM a LIMIT 1) JOIN b;
This bug only appears to occur on some architectures. It occurs on an Intel web server that I am working on but not on my desktop PowerPC Mac. The output of "uname -a" for the Intel machine is:
Linux www2 2.6.15-1-486 #2 Mon Mar 6 15:19:16 UTC 2006 i686 GNU/Linux
(Apologies if I've misclassified this ticket.) |
2006-Jun-06 17:50:24 by drh:
Duplicate of #1784 and #1793. |
|
1829 |
code
|
closed
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
1
|
1
|
Odbc driver parameter bind offset pointer does not work
|
edit |
ODBC driver does not use parameter bind offset pointer:
SQLSetStmtAttr and SQL_SQL_ATTR_PARAM_BIND_OFFSET_PTR does not work
I can provide a sample project demonstrating this defect if needed. |
2006-Jun-05 01:09:02 by anonymous:
ODBC problems should be reported to its creator, or perhaps the SQLite mailing list. This is a bug system for the SQLite library only. |
|
1828 |
code
|
closed
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
1
|
3
|
if not exists doesn't work with a qt program I'm designing.
|
edit |
I can work around this in the code by not checking for an error, but it would be nice to have this work properly.
Error:
near "NOT": syntax error Unable to execute statement
where my statemet is:
create table if not exists agent(id int primary key, firstname varchar(25), lastname varchar(25)) |
2006-Jun-02 17:25:26 by drh:
Works when I try it.
Are you sure you are linking against version 3.3.5 and not an
earlier version of SQLite from before it support IF NOT EXISTS?
You can check by invoking "SELECT sqlite_version()" from within
your program. |
|
1826 |
code
|
closed
|
2006 May
|
anonymous
|
Parser
|
2006 May
|
anonymous
|
4
|
4
|
Select unused table in from clause produces no results
|
edit |
If there is an unused table in the from clause on a join then a select returns no results:
BEGIN TRANSACTION;
CREATE TABLE TP ( TP_ref INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, TP_id VARCHAR(255) NOT NULL );
INSERT INTO "TP" VALUES(1, 'A');
INSERT INTO "TP" VALUES(2, 'B');
INSERT INTO "TP" VALUES(3, 'C');
INSERT INTO "TP" VALUES(4, 'D');
INSERT INTO "TP" VALUES(5, 'E');
COMMIT;
BEGIN TRANSACTION;
CREATE TABLE TC ( TC_ref INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, TC_id VARCHAR(255) NOT NULL);
INSERT INTO "TC" VALUES(1, 'V');
INSERT INTO "TC" VALUES(2, 'W');
INSERT INTO "TC" VALUES(3, 'X');
INSERT INTO "TC" VALUES(4, 'Y');
INSERT INTO "TC" VALUES(5, 'Z');
COMMIT;
BEGIN TRANSACTION;
CREATE TABLE TPC
(
TP_ref INTEGER NOT NULL,
TC_ref INTEGER NOT NULL,
TLE_ref INTEGER,
TPC_sca TINYINT NOT NULL,
TPC_nbd TIMESTAMP NOT NULL,
TPC_pkd TIMESTAMP NOT NULL,
TPC_lsn INTEGER NOT NULL
);
INSERT INTO "TPC" VALUES(1, 1, NULL, 1, '2006-05-07:23:59:59', '2006-05-07:23:59:59', 12345);
INSERT INTO "TPC" VALUES(1, 3, NULL, 1, '2006-05-07:23:59:59', '2006-05-07:23:59:59', 99);
INSERT INTO "TPC" VALUES(2, 1, NULL, 1, '2006-05-06:23:59:59', '2006-05-06:23:59:59', 99);
INSERT INTO "TPC" VALUES(2, 2, NULL, 0, '2006-05-06:23:59:59', '2006-05-06:23:59:59', 99);
INSERT INTO "TPC" VALUES(2, 3, NULL, 1, '2006-05-06:23:59:59', '2006-05-06:23:59:59', 99);
INSERT INTO "TPC" VALUES(2, 4, NULL, 0, '2006-05-06:23:59:59', '2006-05-06:23:59:59', 99);
INSERT INTO "TPC" VALUES(2, 5, NULL, 1, '2006-05-06:23:59:59', '2006-05-06:23:59:59', 99);
INSERT INTO "TPC" VALUES(3, 3, NULL, 0, '2006-05-01:23:59:50', '2006-05-01:23:59:50', 60);
INSERT INTO "TPC" VALUES(5, 3, NULL, 1, '2006-05-25 23:59:59', '2006-05-25 00:00:00', 9999);
COMMIT;
BEGIN TRANSACTION;
CREATE TABLE TLE (TLE_ref INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, TLE_id VARCHAR(255) NOT NULL);
COMMIT;
SELECT pc.TPC_sca, pc.TPC_nbd, pc.TPC_pkd, pc.TPC_lsn
FROM TP p, TC c, TLE le, TPC pc
WHERE pc.TLE_ref is NULL
AND p.TP_id = 'A'
AND pc.TP_ref = p.TP_ref
AND c.TC_id = 'V'
AND pc.TC_ref = c.TC_ref;
SELECT pc.TPC_sca, pc.TPC_nbd, pc.TPC_pkd, pc.TPC_lsn
FROM TP p, TC c, TPC pc
WHERE pc.TLE_ref is NULL
AND p.TP_id = 'A'
AND pc.TP_ref = p.TP_ref
AND c.TC_id = 'V'
AND pc.TC_ref = c.TC_ref;
The first select will return nothing but when TLE is removed from the from clause then the correct result is returned. |
2006-May-26 12:20:44 by drh:
An inner join with an empty table always gives an empty result.
Works as designed. |
|
1823 |
code
|
closed
|
2006 May
|
anonymous
|
|
2006 May
|
|
1
|
1
|
pysqlite2.dbapi2.OperationalError: unable to open database file
|
edit |
pysqlite2.dbapi2.OperationalError: unable to open database file |
2006-May-23 16:09:56 by anonymous:
This must be the most useless bug report ever filed here. It provides absolutely no information about the problem supposedly being reported.
2006-May-23 18:03:54 by drh:
This appears to be a report on an error for PySQLite.
There is a separate website covering PySQLite. Please
use Google to find it. This site covers only the
core SQLite library. |
|
1819 |
code
|
closed
|
2006 May
|
anonymous
|
Unknown
|
2006 May
|
persicom
|
4
|
3
|
faulty html code for concatenated field with "<" character
|
edit |
Faulty HTML code generated. Sample code below for field "email"
stored as john@myisp.com
.mode=html
.output=body.html
select name, hphone,
'<a href="mailto:'||email||'">'||email||'</a>'
from mydata;
Produces the following html code for the email field:
TD><a href="mailto:john@myisp.com">john@myisp.com</a></TD>
Notice how the first and last "<" are produced as "<" in the
generated output file.
By the way, I just picked a random person to assign this ticket
since I couldn't find a list of who works specific items. |
2006-May-23 23:32:31 by drh:
The .html output format escapes all characters in the result
set of the query that are special to HTML. Hence, your <
is escaped to <. This is by design and is exactly what
you want want to happen if you had an arbitrary text field
that just happened to contain a less-than sign. |
|
1818 |
code
|
closed
|
2006 May
|
anonymous
|
Unknown
|
2006 May
|
drh
|
3
|
3
|
sqlite3_mprintf() misbehaving on %*. formats
|
edit |
cpb@earth:~/tmp$ cat test_mprintf.c
#include <stdio.h>
#include <stdlib.h>
#include <sqlite3.h>
int main( int ac, char *av[] ) {
char *z;
z = sqlite3_mprintf("%.*s", 6, "abcdef ");
printf( "z = '%s'\n", z );
z = sqlite3_mprintf("%.*q", 6, "abcdef ");
printf( "z = '%s'\n", z );
z = sqlite3_mprintf("%.*z", 6, strdup("abcdef "));
printf( "z = '%s'\n", z );
exit(0);
}
cpb@earth:~/tmp$ gcc test_mprintf.c -lsqlite3
cpb@earth:~/tmp$ ./a.out
z = 'abcdef'
z = 'abcdef '
z = 'abcdef '
Either the formatter isn't stopping at the right character count, or it's forgetting the NUL. In any case, it's handling at least one of the three cases incorrectly ;)
I suspect this is where http://www.cvstrac.org/cvstrac/tktview?tn=551 came from, so it's possible that CVSTrac's vxprintf() would need the same fix. |
2006-May-22 22:05:56 by drh:
The precision is ignored for %q and %Q. I'm not sure the
documentation says this anyplace, but there is a comment in
the code that does.
The use of %z is not allowed in sqlite3_mprintf(). That converter
is for SQLite's internal use only. There was a bug that was not
enforcing this but it is fixed now.
2006-May-22 22:38:17 by anonymous:
I'm not sure the documentation says this anyplace
Nope. In fact, it strongly suggests that it should work.
The documentation says that "All of the usual printf formatting options apply" and (repeatedly) says that "%q" is a substitute for "%s".
The documentation doesn't mention %Q at all, but I think there's another ticket open for that.
The use of %z is not allowed in sqlite3_mprintf()
Not a problem. I only included it as an afterthought to help narrow down the "bug". |
|
1813 |
new
|
closed
|
2006 May
|
anonymous
|
|
2007 Nov
|
|
2
|
3
|
select distinct doesn't take advantage of existing indexes
|
edit |
Simple testcase, execute to reproduce the problem:
create table test(archive integer, host text, priority integer);
create index test_idxA on test(archive, host, priority);
-- This uses test_idxA
explain query plan select distinct archive, host from test order by archive, host;
-- But This doesn't
explain query plan select distinct archive, host from test;
-- Nor does this
explain query plan select distinct archive, host, priority from test;
-- Let's try and change things a bit...
drop index test_idxA;
create index test_idxB on test(archive, host);
-- This still doesn't use test_idxB
explain query plan select distinct archive, host from test;
|
2007-Nov-12 07:52:50 by anonymous:
Fixed by this patch to sqlite 3.5.2:
http://marc.info/?l=sqlite-users&m=119483059920564&w=2
2007-Nov-12 16:21:36 by anonymous:
Fixed in Check-in [4538]
|
|
1808 |
code
|
closed
|
2006 May
|
anonymous
|
|
2006 May
|
|
1
|
1
|
Wrong index is chosen
|
edit |
Simple testcase:
sqlite> create table test(guid text, arcid integer, url text, timestamp integer, keeptime integer);
sqlite> create index test_idx1 on test(arcid, url);
sqlite> create index test_idx2 on test(arcid, timestamp, keeptime);
sqlite> explain query plan select guid, timestamp from test where arcid=1 and url='foobar';
0|0|TABLE test WITH INDEX test_idx2
As you can see, the wrong index is chosen. This was not happening before the optimizer rewrite.
If the table is filled with some data and then ANALYZE is executed, the right index is chosen. But if the table is empty, running ANALYZE will not correct the problem. |
If a order by clause is added, the wrong index is still chosen. Try this:
explain query plan select guid, timestamp from test where arcid=1 and url='foobar' order by timestamp;
Again, this bug was not present with the old optimizer.
2006-May-18 11:24:57 by drh:
This is not a bug. The optimizer is making the correct choice in
this case, based on the limited information it has available.
The optimizer will make a better choice if you run ANALYZE so that
it can gather statistics about the table you are querying.
Or, you can disable the ORDER BY term as a candidate for using
indices by saying:
ORDER BY +timestamp
|
|
1800 |
new
|
closed
|
2006 May
|
anonymous
|
|
2006 May
|
linus
|
1
|
2
|
possible to have the lastest version of sqlite with PHP 5?????
|
edit |
i ve searched a long time, but i didn't found how to get the lastest sqlite version with php !
i only got the the 3.2.8 (if my memory is good), with the pdo_sqlite with php5.
There is a way to get the lastest ???
i ve try to manual compil and install the lastest SQLite (all was OK, library installed into /usr/local/lib/ )
Then on my PHP install i ve put
--with-sqlite=/usr/local/lib
but it when doing the configure .
Impossible to find the library....
if someone have the answer. please contact me |
2006-May-07 16:23:03 by anonymous:
They are talking of this install method on the zend site (Installing SQLite)
http://www.zend.com/php5/articles/php5-sqlite.php
but it look i don't have the library. but i got this into my /usr/local/lib
-rw-r--r-- 1 root root 517636 May 7 09:59 libsqlite3.a
-rwxr-xr-x 1 root root 825 May 7 09:59 libsqlite3.la
lrwxrwxrwx 1 root root 19 May 7 09:59 libsqlite3.so -> libsqlite3.so.0.8.6
lrwxrwxrwx 1 root root 19 May 7 09:59 libsqlite3.so.0 -> libsqlite3.so.0.8.6
-rwxr-xr-x 1 root root 439786 May 7 09:59 libsqlite3.so.0.8.6
2006-May-07 16:25:10 by anonymous:
contact me at contact AT super-barre.com
2006-May-08 09:20:52 by anonymous:
why status is close ? my question is still valable.
2006-May-08 11:16:57 by anonymous:
i m trying to install sqlite3 with php 4
i ve found the SQLite-1.0.3 from pecl website.
which is gave with the version 2.8.14 of sqlite.
normal install is like this.
phpize;
./configure;
make; make install; (that way work but with the bundle version of sqlite).
i need to grab the last one .
i ve try
phpize;
./configure --with-sqlite=../sqlite-3.3.5/src/ (the relative path to the sqlite source)
and the ./configure stop with
checking for sqlite support... yes, shared
checking for sqlite_open in -lsqlite... no
configure: error: wrong sqlite lib version or lib not found
i ve try
./configure --with-sqlite=/usr/local/lib (its where sqlite have copy the library when installing).
and got the same thing !
Please need some help.
2006-May-08 11:19:27 by anonymous:
this list is used to report bugs of sqlite. this issue is related to php. please ask php mailing list. |
|
1796 |
code
|
closed
|
2006 May
|
anonymous
|
|
2006 May
|
|
1
|
1
|
.import command not working in 3.3.5
|
edit |
The .import seems to be broken. I upgraded to 3.3.5 this morning (from 3.2.7) and code that depends on the TCL COPY command stopped working.
I tried the sqlite3 shell, and verified that the .import command is not working either.
It will import a one column file into a one column table, but will not do two or more columns. To reproduce:
sqlite> create table zyx (col1,col2);
sqlite> .import /home/centadm/win_pol4.csv zyx
/home/centadm/win_pol4.csv line 1: expected 2 columns of data but found 1
Contents of win_pol4.csv,one line (yes it is a tab between the two columns, doesn't show well in this page):
DATA1 DATA2
the tclib COPY command has the same affect, but no error message. |
2006-May-05 16:36:02 by drh:
The default separator is "|". To use a type you first must run
.separator \t
That should fix your problem with .import. Please provide more
details about the TCL COPY command problem. |
|
1795 |
code
|
closed
|
2006 May
|
anonymous
|
Unknown
|
2006 Aug
|
|
1
|
1
|
Incorrect result if a nested view contains a union
|
edit |
I've recreated a small test case showing how the bug can be reproduced. The main idea is to create views on top of tables which contain generated keys for export purposes.
create table names (name varchar(32));
insert into names (name) values ('John');
insert into names (name) values ('Brigit');
insert into names (name) values ('Bart');
create table cities (city varchar(32));
insert into cities (city) values ('New York');
insert into cities (city) values ('San Diego');
insert into cities (city) values ('Denver');
insert into cities (city) values ('Albuquerque');
insert into cities (city) values ('Philedelphia');
create table cityofresidence (person varchar(32), city varchar(32), prevcity varchar(32));
insert into cityofresidence (person, city, prevcity) values ('John', 'New York', 'Denver');
insert into cityofresidence (person, city, prevcity) values ('Brigit', 'San Diego', 'Albuquerque');
insert into cityofresidence (person, city, prevcity) values ('Bart', 'Denver', 'Philedelphia');
create view export_names as
select
(select 1+count(*) from names n2 where n2.name < n.name) as personno,
n.name as Name
from names n;
The view below causes problems later on (but only if it contains a union).
create view export_cities as
select
(select 1+count(*) from cities c2 where c2.city < c.city) as cityno,
c.city as CityName
from cities c
where c.city like 'A%'
union
select
(select 1+count(*) from cities c2 where c2.city < c.city) as cityno,
c.city as CityName
from cities c
where c.city not like 'A%';
Using only the SELECT statement still shows the correct results. However once converted into a view and querying the view returns the wrong result.
create view export_cityofresidence as
select
n.personno as personno,
c.cityno as cityno,
c1.cityno as prevcityno
from cityofresidence cor
join export_names n on n.name = cor.person
join export_cities c on c.cityname = cor.city
join export_cities c1 on c1.cityname = cor.prevcity;
Hope this report helps, good luck hunting it down. |
2006-May-05 13:05:55 by anonymous:
What's the problem, exactly?
select * from export_cities;
1|Albuquerque
2|Denver
3|New York
4|Philedelphia
5|San Diego
select
(select 1+count(*) from cities c2 where c2.city < c.city) as cityno,
c.city as CityName
from cities c
where c.city like 'A%'
union
select
(select 1+count(*) from cities c2 where c2.city < c.city) as cityno,
c.city as CityName
from cities c
where c.city not like 'A%';
1|Albuquerque
2|Denver
3|New York
4|Philedelphia
5|San Diego
2006-May-05 16:30:09 by drh:
I, also, am confused about what the problem is. Please identify
a specific query that you think is giving an incorrect answer. |
|
1793 |
code
|
closed
|
2006 May
|
anonymous
|
|
2006 May
|
|
2
|
3
|
sqlite3.dll crashes when doing an inner join with limit 0
|
edit |
Doing the following select on any table results in a crash
select * from (select * from sometable limit 0) inner join sometable;
The crash happens in sqlite3.dll and is reproducible in sqlite3.exe. |
Looks like a duplicate of ticket #1784. |
|
1787 |
code
|
closed
|
2006 Apr
|
anonymous
|
|
2006 Apr
|
|
1
|
1
|
Certain integer values are written/read incorrectly to/from database
|
edit |
Certain integer values are written or read incorrectly to or from a database. Only integer values that are 48-bit positive values exhibit this problem. More specifically integers with these characteristics:
- bit 47 is set to 1
- bits 48 to 63 are 0 (including the sign bit - making the integer positive)
- bits 0 to 46 can be any value
Example of such integers are: 0x0000800000000000, 0x0000FFFFFFFFFFFF, 0x0000BA9876543210.
Here is an example showing how to reproduce this problem on the command line.
Type sqlite3 on the command prompt and enter the following:
create table t1 (c1 int);
insert into t1 values(140737488355328);
insert into t1 values(281474976710655);
insert into t1 values(205163983024656);
insert into t1 values(148763136124106);
insert into t1 values(123);
insert into t1 values(9223372036854775807);
select * from t1;
This is what you will see:
Silver:~ Mark$ sqlite3
SQLite version 3.1.3
Enter ".help" for instructions
sqlite> create table t1 (c1 int);
sqlite> insert into t1 values(140737488355328);
sqlite> insert into t1 values(281474976710655);
sqlite> insert into t1 values(205163983024656);
sqlite> insert into t1 values(148763136124106);
sqlite> insert into t1 values(123);
sqlite> insert into t1 values(9223372036854775807);
sqlite> select * from t1;
-140737488355328
-1
-76310993686000
-132711840586550
123
9223372036854775807
Note that the first four values inserted into the table are reported incorrectly. Any other values, such as the last two are fine.
I have also tested this using the APIs directly and have observed the same behavior. I have a small piece of C code that demonstrates this problem. I could email it to you if needed.
I have tested this with the SQLite that comes with Mac OS X 10.4.6. |
See ticket #1212 |
|
1780 |
code
|
closed
|
2006 Apr
|
anonymous
|
BTree
|
2006 Apr
|
|
1
|
1
|
What's mean for "b0G1X" or "b0G0" in the head of payload in cell?
|
edit |
I don't know that the meaning of "b0G0" or "b1G1X"
thanks! |
2006-Apr-24 13:23:02 by drh:
Ask questions on the mailing list please. Use tickets to
report bugs. |
|
1779 |
new
|
closed
|
2006 Apr
|
anonymous
|
|
2007 Nov
|
|
5
|
4
|
enhancement request (+ pointer) -- group_concat() aggregate function
|
edit |
Any thoughts as to incorporating the group_concat() function patch as at http://pugs.blogs.com/pugs/2006/01/more_random_rec.html ? :)
Thanks... |
2006-Apr-22 00:12:21 by anonymous:
http://perlcabal.org/~autrijus/tmp/sqlite3-src-func.c.diff
Why would anyone favor this function over using GROUP BY?
This function does not even support numeric ordering correctly.
It treats all numeric sub-keys as strings.
2006-Jun-16 22:36:16 by anonymous:
Err, wait, GROUP_CONCAT is meant to be used with GROUP BY, not as a replacement. See http://db4free.blogspot.com/2006/01/hail-to-groupconcat.html and http://dev.mysql.com/doc/refman/5.0/en/group-by-functions.html
Audrey
2007-Nov-01 20:51:53 by anonymous:
Fixed by Check-in [4519]
for future 3.5.2 version.
Not enabled by default. |
|
1776 |
code
|
closed
|
2006 Apr
|
anonymous
|
Unknown
|
2006 Apr
|
anonymous
|
1
|
2
|
Max(DateTime column) returns a String, not a DateTime
|
edit |
Running a simple query (select MAX(last_change) from ...) where last_change is a DateTime, the query returns a String.
More precisely, the problem comes from sqlite3_column_decltype. The latter, when called against a datetime field, works well but not again any calculation done on that field.
I discovered that while using the ADO.NET driver from Finisar, which relies on sqlite3_column_decltype and then on sqlite3_column_type to determine the type of a column.
Best regards
Lionel,
Aulofee supervision systems (http://www.aulofee.com)
* security and log correlation
* IT asset management and inventory
* reporting
* network cartography |
2006-Apr-18 19:54:45 by drh:
Everything in SQLite is either a string, a BLOB, an integer, a
floating point number, or a NULL. There is no such thing as
a DateTime. Users commonly represent a DateTime as an
ISO8601 string or as a floating point number which is the
julian day number. The built-in date/time manipulation
functions accept either format. |
|
1774 |
code
|
closed
|
2006 Apr
|
ghaering
|
|
2006 Apr
|
|
1
|
1
|
sqlite3_column_decltype() stopped working in SQLite 3.3
|
edit |
There was a behaviour change between older versions of SQLite and the SQLite 3.3 series (at least 3.3.4 and 3.3.5).
Python example code, but doesn't matter. This query:
cur.execute("create table person (id integer, birthday timestamp)")
cur.execute("insert into person values (?,?)", (23, datetime.now()))
cur.execute('select birthday, count(*) from person')
used to produce a result "timestamp" for the birthday column for the sqlite3_column_decltype() API call. This worked with older SQLite versions at least until 3.2.2 (not all versions tested).
Newer 3.3 versions produce NULL for the sqlite3_column_decltype() API call here.
This breaks wrappers and applications depending on useful data from this API call. |
See #1726 #1755 and [3169]
|
|
1767 |
warn
|
closed
|
2006 Apr
|
anonymous
|
Unknown
|
2006 Apr
|
|
5
|
4
|
Unused variable in function sqlite3VdbeChangeEncoding
|
edit |
Please replace line 37:
int rc;
with following lines :
#ifndef SQLITE_OMIT_UTF16
int rc;
#endif |
2006-Apr-11 12:25:49 by drh:
For stylistic reasons, I prefer to avoid the use of #ifdef where
possible. I would rather take a compiler warning about an
unused variable that put an extra #ifdef in the code to work
around the warning. Unused variables are always harmless.
Surplus #ifdefs, on the other hand, can lead to bugs.
2006-Apr-11 13:05:20 by anonymous:
Here is another workaround withoud ifdef:
int sqlite3VdbeChangeEncoding(Mem * pMem, int desiredEnc){
if( !(pMem->flags&MEM_Str) || pMem->enc==desiredEnc ){
return SQLITE_OK;
}
#ifdef SQLITE_OMIT_UTF16
return SQLITE_ERROR;
#else
/* MemTranslate() may return SQLITE_OK or SQLITE_NOMEM. If NOMEM is returned,
** then the encoding of the value may not have changed.
*/
{
int rc;
rc = sqlite3VdbeMemTranslate(pMem, desiredEnc);
assert(rc==SQLITE_OK || rc==SQLITE_NOMEM);
assert(rc==SQLITE_OK || pMem->enc!=desiredEnc);
assert(rc==SQLITE_NOMEM || pMem->enc==desiredEnc);
if( rc==SQLITE_NOMEM ){
/*
sqlite3VdbeMemRelease(pMem);
pMem->flags = MEM_Null;
pMem->z = 0;
*/
}
}
return rc;
#endif
} |
|
1766 |
new
|
closed
|
2006 Apr
|
anonymous
|
Unknown
|
2006 Apr
|
|
3
|
2
|
Order by NO Case Sensitive
|
edit |
The order by is case sensitive when in other DBMS like SQLServer is not. I am not meaning that the correct behaviour should be the one of SqlServer; but that they should be more logical. In my opinion it should be done the order by the same way the Like (No case) works. Grouping all special characters but the latin ones
Example:
CREATE TABLE COMPANIES (NAME VARCHAR)
INSERT INTO COMPANIES (NAME) VALUES (' ')
INSERT INTO COMPANIES (NAME) VALUES ('1a')
INSERT INTO COMPANIES (NAME) VALUES ('A_a')
INSERT INTO COMPANIES (NAME) VALUES ('a_c')
INSERT INTO COMPANIES (NAME) VALUES ('bsdas')
INSERT INTO COMPANIES (NAME) VALUES ('Cass')
INSERT INTO COMPANIES (NAME) VALUES ('sa')
INSERT INTO COMPANIES (NAME) VALUES ('Sc')
INSERT INTO COMPANIES (NAME) VALUES ('ra')
INSERT INTO COMPANIES (NAME) VALUES ('RS')
INSERT INTO COMPANIES (NAME) VALUES ('zas')
INSERT INTO COMPANIES (NAME) VALUES ('ZZs')
SELECT NAME FROM COMPA ORDER BY NAME
Results in SQLite:
' '
1a
A_a
Cass
RS
Sc
ZZs
a_c
bsdas
ra
sa
zas
Results in SQLServer:
' '
1a
A_a
a_c
bsdas
Cass
ra
re
RS
sa
Sc
zas
ZZs
If there would not be a resolution I would be grateful for a workaround. Someone comented me that there was a NOCASE command for the orderBy but there is not in the documentation and I could not get it work.
Thanks in advance
Jon |
2006-Apr-11 11:07:27 by drh:
SQL Server is the one that has the problem here. SQLite does it
correctly. ORDER BY is case sensitive.
If you want a case-insensitive sort, either add COLLATE NOCASE to
the column declaration, or do "ORDER BY lower(column)". |
|
1765 |
code
|
closed
|
2006 Apr
|
anonymous
|
|
2006 Apr
|
|
1
|
2
|
SQLite3_BindText fails with a floating point error (explicited)
|
edit |
Ticket 1761 was closed as being a floating-point issue, however this understanding completely missed the point: the value I've to get into the database is "4598554E8989898" as a String, not as a floating point, it's one of many batch identification codes, and is really not a floating point, but a string.
As it is, I cannot enter that string into the database, because SQLite wrongly "recognizes" it as a floating number and attempts to encode it... despite explicitly binding as string.
This also raises a peripheral issue which would be that of data corruption, if I have a string like "123456789123456789123456789E01" the error would not happen as SQLite would be able to encode it as a float, but by doing so, it would lose "precision digits", even though the value was explicitly bound as a string and intended as such, and not as a floating point value.
See Ticket 1761 for the technical details. |
2006-Apr-10 11:35:47 by drh:
If the declared type of the column is REAL or FLOAT or NUMERIC,
then SQLite tries to convert strings that look like numbers into
numbers. This is by design because it is what other RDBMSes do
and SQLite wants to be compatible.
If the declared type of the column is TEXT or CHAR or VARCHAR,
then strings are stored as strings and no attempt is made to
convert to floating point.
2006-Apr-10 13:06:24 by anonymous:
"if the declared type of the column is REAL or FLOAT or NUMERIC"
The column type was neither REAL, nor FLOAT nor NUMERIC, but declared as "STRING". After a few quick tests, to avoid further confusion it seems the documentation should be updated to:
"Only if the declared type of the column begins with TEXT or CHAR or VARCHAR will strings be stored as strings and no attempt is made to convert to floating point."
as floating point conversion is attempted even when the column type is not REAL/FLOAT/NUMERIC.
2006-Apr-10 13:41:32 by drh:
The rules are documented at
http://www.sqlite.org/datatype3.html
in section 2.1. From these four simple rules, it is clear that
a declared type of STRING hits case 4 resulting in a NUMERIC
affinity for the column.
We will investigate ways of clarifying this elsewhere in the
documentation. |
|
1764 |
code
|
closed
|
2006 Apr
|
anonymous
|
Unknown
|
2006 Apr
|
|
1
|
2
|
database file format not inter-operable between 32-bit/ 64-bit systems
|
edit |
Created files on 64-bit AMD systems (e.g. AMD64 Linux 2.6 ,Fedora Core 3 on AMD64, available at the compile farm at sourceforge.net) can't be read on 32-bit systems (e.g. Suse-9.3 /Pentium)
SQLite simply create with ./configure && make
Error message:
sqlite> select * from sqlite_master;
SQL error: unsupported file format
sqlite> |
2006-Apr-09 11:30:03 by drh:
Please attach samples of database files that exhibit this problem.
2006-Apr-09 17:01:50 by drh:
I can read the attached database without any problems
on my (32-bit) SuSE 9.2 system.
2006-Apr-12 08:20:52 by anonymous:
Gentoo, 32bit, sqlite 3.2.1
sqlite> select * from sqlite_master;
SQL error: unsupported file format
2006-Apr-12 11:49:52 by anonymous:
It's a database created with SQLite 3.3.5, so SQLite 3.2.1 isn't going to be able to read it. I wonder if that isn't what happened to the person who posted the bug report originally. |
|
1761 |
code
|
closed
|
2006 Apr
|
anonymous
|
Unknown
|
2006 Apr
|
|
1
|
3
|
SQLite3_BindText fails with a floating point error
|
edit |
When performing a parameter bind with
sqlite3_bind_text(statement, paramIndex, value, value_length, SQLITE_TRANSIENT);
with value being for instance "4598554E8989898" (though any string that looks like a floating point number, but isn't one encodable by a double precision float will trigger the issue), an invalid floating point operation exception will occur.
Same behaviour with SQLITE_STATIC instead of SQLITE_TRANSIENT.
Same behaviour with sqlite3_bind_text16. |
2006-Apr-07 12:54:17 by anonymous:
Same error with
create table foo (a integer);
insert into foo values ("4598554E8989898");
2006-Apr-07 13:17:50 by drh:
4598665e8989898 is a valid floating point number on my system
(SuSE 9.2 Linux). If I print out the value that is stored
SELECT a FROM foo;
I get the answer "inf". But that is still a valid floating point
number, even if it is not all that useful.
This appears to be a problem with the floating point processor
on whatever computer you are running on, not a problem with
SQLite.
2006-Apr-07 17:29:38 by anonymous:
Under WinXP I don't get any exceptions, but I do get some some strange results. I get NAN instead of INF for the values regardless of the sign of the number. I would have expected +INF and -INF. Large negative exponents are stored as zeros, which is OK. And when I try to generate an INF by dividing by zero or a value with a large negative exponent, I get a null value.
SQLite version 3.3.5
Enter ".help" for instructions
sqlite> create table t(a integer, b float);
sqlite>
sqlite> insert into t values(0, 0);
sqlite> insert into t values(0.0, 0.0);
sqlite> insert into t values(1, 1);
sqlite> insert into t values(1.0, 1.0);
sqlite> insert into t values(123456789E123456789, 123456789E123456789);
sqlite> insert into t values(-123456789E123456789, -123456789E123456789);
sqlite> insert into t values(123456789E-123456789, 123456789E-123456789);
sqlite> insert into t values(1/0, 1/0);
sqlite> insert into t values(1.0/0, 1.0/0);
sqlite> insert into t values(1/0.0, 1/0.0);
sqlite> insert into t values(1.0/0.0, 1.0/0.0);
sqlite> insert into t values(1/123456789E-123456789, 1/123456789E-123456789);
sqlite> insert into t values(1.0/123456789E-123456789, 1.0/123456789E-123456789);
sqlite>
sqlite> .mode column
sqlite> select typeof(a), a, typeof(b), b from t;
integer 0 real 0.0
integer 0 real 0.0
integer 1 real 1.0
integer 1 real 1.0
real NaN real NaN
real NaN real NaN
integer 0 real 0.0
null null
null null
null null
null null
null null
null null
sqlite>
|
|
1760 |
code
|
closed
|
2006 Apr
|
anonymous
|
|
2006 Apr
|
|
4
|
4
|
sqlite3_open(), then sqlite3_close()
|
edit |
The smallest test:
sqlite3* db;
sqlite3_open("new_file", &db); // empty database created
int err = sqlite3_close(db);
The err after sqlite3_close() will be 21. It is not common situation but I have couple of unit tests that create/close/then delete such empty database and it is annoying to see them fail.
I use BCB 6.4, preprocessed C sources. |
2006-Apr-07 13:02:04 by drh:
Unable to reproduce. Test program as follows:
#include "sqlite3.h"
int main(void){
sqlite3 *db;
int rc1, rc2;
rc1 = sqlite3_open("new_file", &db);
printf("rc1=%d\n", rc1);
rc2 = sqlite3_close(db);
printf("rc2=%d\n", rc2);
}
|
|
1759 |
code
|
closed
|
2006 Apr
|
anonymous
|
|
2006 Apr
|
|
3
|
4
|
"int primary key" not the same as "integer primary key"
|
edit |
Trying to get auto increment working, I wrote
CREATE TABLE books (
id int PRIMARY KEY,
title text NOT NULL,
published_year char(4) NOT NULL,
authors text NOT NULL
);
but it did not work until I changed "int" to "integer" -- id was null. (Odd behavior for a primary key!) |
2006-Apr-06 21:56:00 by drh:
Correct. INT PRIMARY KEY is not the same as INTEGER PRIMARY KEY.
This is by design.
2006-Apr-07 02:29:40 by anonymous:
Is this difference described anywhere? |
|
1758 |
code
|
closed
|
2006 Apr
|
anonymous
|
Unknown
|
2006 Apr
|
|
3
|
1
|
problem with: select ... UNION ... select .. ORDER BY LOWER(column)
|
edit |
After simple preparation statements:
CREATE TABLE foo( a text );
CREATE TABLE bar( a text );
INSERT INTO foo VALUES( 'xxx' );
INSERT INTO bar VALUES( 'aaa' );
A statement:
SELECT a FROM foo UNION SELECT a FROM bar ORDER BY lower(a);
reports an error message:
SQL error: ORDER BY term number 1 does not match any result column
while a similar one, only without 'lower' works well. Same when aliasing 'a AS b' and then 'order by lower(b)' . |
2006-Apr-06 20:55:44 by drh:
The ORDER BY clause of a compound SELECT can reference result
columns only. lower(a) is not a result column.
2006-Apr-07 15:20:43 by anonymous:
A workaround is:
SELECT lower(a) as la from (SELECT a FROM foo UNION SELECT a FROM bar) ORDER BY la;
|
|
1757 |
code
|
closed
|
2006 Apr
|
anonymous
|
|
2006 Apr
|
|
2
|
1
|
sqlite not using index
|
edit |
I've created a table that has like 10 million entries the table structure are 3 fields (type<int>, key<string>, content<int>). This is basically an index table.
The thing is that I've created and index based on the first two field so whe I do a "SELECT content FROM table WHERE type = num AND key = 'string'" (tried it with and without "ORDERY BY content") it takes really long, more than a simple index on the field key that also was REALLY slow.
I'm using the CPPSqlite wrapper, the thing is that the performance is really poor but in this table is worse... 90 seconds per search. |
2006-Apr-07 13:19:44 by drh:
Please use the SQLite mailing list for help in optimizing your
code.
See http://www.sqlite.org/support.html for instructions on how
to join the mailing list. |
|
1753 |
code
|
closed
|
2006 Apr
|
anonymous
|
Unknown
|
2006 Apr
|
anonymous
|
2
|
1
|
Order by not working on a column with random() function
|
edit |
I provide a very small db dump and a query on it that doesn't seem to work properly: it should produce ascending order results on a column that uses the random() function, but sometimes the order is inverted (execute it multiple times!). |
2006-Apr-05 15:28:02 by drh:
The random() function is evaluated twice, once to compute
the second column of the result set and a second time to
compute the ORDER BY key. So the output is not necessarily
ordered by the second column.
This is what you get with nondeterministic functions.
If you need to sort by the second column of the result set,
use a subquery. |
|
1752 |
code
|
closed
|
2006 Apr
|
anonymous
|
Unknown
|
2006 Apr
|
|
3
|
4
|
New compile warnings with default ./configure && make on MinGW
|
edit |
For the default MinGW ./configure && make for 3.3.5 you now see these warnings in compiling every .c file:
In file included from src/sqliteInt.h:62,
from src/callback.c:19:
parse.h:152:1: warning: "TK_TO_TEXT" redefined
parse.h:137:1: warning: this is the location of the previous definition
parse.h:153:1: warning: "TK_TO_BLOB" redefined
parse.h:138:1: warning: this is the location of the previous definition
parse.h:154:1: warning: "TK_TO_NUMERIC" redefined
parse.h:139:1: warning: this is the location of the previous definition
parse.h:155:1: warning: "TK_TO_INT" redefined
parse.h:140:1: warning: this is the location of the previous definition
parse.h:156:1: warning: "TK_TO_REAL" redefined
parse.h:141:1: warning: this is the location of the previous definition
parse.h:157:1: warning: "TK_END_OF_FILE" redefined
parse.h:142:1: warning: this is the location of the previous definition
parse.h:158:1: warning: "TK_ILLEGAL" redefined
parse.h:143:1: warning: this is the location of the previous definition
parse.h:159:1: warning: "TK_SPACE" redefined
parse.h:144:1: warning: this is the location of the previous definition
parse.h:160:1: warning: "TK_UNCLOSED_STRING" redefined
parse.h:145:1: warning: this is the location of the previous definition
parse.h:161:1: warning: "TK_COMMENT" redefined
parse.h:146:1: warning: this is the location of the previous definition
parse.h:162:1: warning: "TK_FUNCTION" redefined
parse.h:147:1: warning: this is the location of the previous definition
parse.h:163:1: warning: "TK_COLUMN" redefined
parse.h:148:1: warning: this is the location of the previous definition
parse.h:164:1: warning: "TK_AGG_FUNCTION" redefined
parse.h:149:1: warning: this is the location of the previous definition
parse.h:165:1: warning: "TK_AGG_COLUMN" redefined
parse.h:150:1: warning: this is the location of the previous definition
parse.h:166:1: warning: "TK_CONST_FUNC" redefined
parse.h:151:1: warning: this is the location of the previous definition
|
2006-Apr-05 15:44:14 by anonymous:
Generated file parse.h shown below. Note that TK_TO_TEXT has been defined to 137 on line 137 and to 152 on line 152 later on in the file.
137 #define TK_TO_TEXT 137
138 #define TK_TO_BLOB 138
139 #define TK_TO_NUMERIC 139
140 #define TK_TO_INT 140
141 #define TK_TO_REAL 141
142 #define TK_END_OF_FILE 142
143 #define TK_ILLEGAL 143
144 #define TK_SPACE 144
145 #define TK_UNCLOSED_STRING 145
146 #define TK_COMMENT 146
147 #define TK_FUNCTION 147
148 #define TK_COLUMN 148
149 #define TK_AGG_FUNCTION 149
150 #define TK_AGG_COLUMN 150
151 #define TK_CONST_FUNC 151
152 #define TK_TO_TEXT 152
153 #define TK_TO_BLOB 153
154 #define TK_TO_NUMERIC 154
155 #define TK_TO_INT 155
156 #define TK_TO_REAL 156
2006-Apr-05 16:03:58 by drh:
You likely have some stale files that are being picked up by
the Makefile. Start over again from a fresh download after
first removing all legacy SQLite source files from your system. |
|
1751 |
code
|
closed
|
2006 Apr
|
anonymous
|
Unknown
|
2006 Sep
|
mike
|
1
|
1
|
sqlite doesn't work on a cifs-mounted drive
|
edit |
I use an OpenWRT-Linux (for Linksys-Router). A drive was mounted with cifs.
SQLITE works on Linux perfectly. But, then I use a database on mounted drive, I get "I/O Error".
root@OpenWrt:/mnt# ./sqlite test.sdb
SQLite version 3.3.4
Enter ".help" for instructions
sqlite> .databases
Error: disk I/O error
sqlite>
The file test.sdb was created by SQLITE, but SQLITE can't write to this file. |
2006-Sep-06 14:58:44 by anonymous:
Note sure if this helps but:
I'm getting the same problem. The setup is a bit odd (involving running fedora5 in a chroot'd jail inside fedora4 where the files are copied into a unionfs mount). The problem appears to occur where, if I open (say) /tmp/sqlite as the database file, then strace shows the /tmp directory being opened and fsync on the descriptor thence returns EINVAL (compared to doing the same in the main fedora4 where the fsync succeeds).
If I loop mount a file-based ext2 filesystem into the jail and try the database file in there, it works OK, so I deduce its not the chroot'ing that triggers the problem.
Here's the relevant strace bit
open("/tmp/SQLTest-journal", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open("/tmp", O_RDONLY|O_LARGEFILE) = 5
_llseek(4, 0, [0], SEEK_SET) = 0
open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 6
read(6, "\371\210\t\266M3<:g\\=Jla\354\35\r7\v\340\257\204\274`"..., 256) = 256
close(6) = 0
write(4, "\331\325\5\371 \241c\327\0\0\0\0Q\350\226\332\0\0\0\0\0"..., 24) = 24
_llseek(4, 511, [511], SEEK_SET) = 0
write(4, "\0", 1) = 1
fsync(4) = 0
fsync(5) = -1 EINVAL (Invalid argument)
close(5) = 0
close(4) = 0
unlink("/tmp/SQLTest-journal") = 0
2006-Sep-06 15:23:22 by drh:
If the directory containing the rollback journal is not fsync()-ed
after the rollback journal is created or deleted, then there is a
race condition that can lead to database corruption on an untimely
power failure. See, for example, ticket #410.
SQLite appears to be doing the right thing here. The bug
appears to be OpenWRT-Linux, not in SQLite.
You can work around the problem by compiling with
-DSQLITE_DISABLE_DIRSYNC=1
That macro disables the directory syncing logic. But then
if you lose power at exactly the wrong moment and your rollback
journal vanishes (or gets moved to /lost+found) and your database
is corrupted - don't complain. I better solution, it seems,
would be to fix OpenWRT-Linux. |
|
1748 |
code
|
closed
|
2006 Apr
|
anonymous
|
VDBE
|
2006 Apr
|
|
3
|
3
|
Memory leak in insert.c: sqlite3TableAffinityStr
|
edit |
I think there is memory leak in the function "sqlite3TableAffinityStr" in insert.c. The pointer allocated to "pTab->zColAff" is not freed.
Am I right? I checked in later versions, the free statement is still
missing. |
2006-Apr-03 17:40:05 by drh:
Please read the comments a few lines above the spot where
zColAff is allocated to learn how it is eventually freed. |
|
1739 |
code
|
closed
|
2006 Mar
|
anonymous
|
Unknown
|
2006 Mar
|
|
4
|
1
|
sqlite3_bind_int on UPDATE * SET COLUMN1='Test' WHERE ID=?
|
edit |
I've got the following problem:
SQL: UPDATE SOFTWARE SET Title=? WHERE ID=?
My code:
sqlite3_bind_text(res, 0, "Test", -1, SQLITE_STATIC);
sqlite3_bind_int64(res, 1, 1); // This should update ID=? to ID=1
Right? The function succeeds (including sqlite3_step), but it doesn't update the row with ID=1
It seems that there's a bug in the bind, because when I write the ID# in the SQL, it works |
2006-Mar-28 19:17:59 by anonymous:
Parameter indexes are 1-based, not zero based.
2006-Mar-28 19:28:53 by anonymous:
Thnx...
Just found out, wanted to post it =P very dump mistake =P |
|
1738 |
code
|
closed
|
2006 Mar
|
anonymous
|
Unknown
|
2006 Mar
|
a.rottmann
|
1
|
1
|
The function "sqlite3_get_table" doen't do well with blob data.
|
edit |
When I get my blob data in my database using function "sqlite3_get_table", I find that it will loss some data. I think that the function "sqlite3_get_table" refers to the "strlen", so it will cut some data which it has '\0' in it. |
2006-Mar-28 12:23:18 by drh:
The sqlite3_get_table() API is not intended for use with
BLOBs. This is a legacy API held over from the days before
SQLite supported BLOBs. If you need to access a BLOB, use
the sqlite3_prepare()/sqlite3_step()/sqlite3_finalize()
API chain. |
|
1736 |
code
|
closed
|
2006 Mar
|
anonymous
|
Unknown
|
2006 Mar
|
|
4
|
4
|
#define SQLITE_OMIT_ALTERTABLE causes unresolved externals
|
edit |
When I defined SQLITE_OMIT_ALTERTABLE and SQLITE_OMIT_REINDEX
(and couple of other options) I got linker errors:
parse.obj : error LNK2001: unresolved external symbol _sqlite3AlterBeginAddColumn@8
parse.obj : error LNK2001: unresolved external symbol _sqlite3AlterFinishAddColumn@8
parse.obj : error LNK2001: unresolved external symbol _sqlite3AlterRenameTable@12
parse.obj : error LNK2001: unresolved external symbol _sqlite3Reindex@12
Using Intel C++ 7.0 plugged in VC++ 6 IDE, 3.3.4 fully generated source. |
2006-Mar-28 06:54:24 by anonymous:
I now realize that one should re-generate parser.c for changed settings. |
|
1734 |
code
|
closed
|
2006 Mar
|
anonymous
|
Parser
|
2006 Mar
|
drh
|
5
|
5
|
when not null is before integer primary key, syntax error occurs
|
edit |
SQLite version 3.3.4
Enter ".help" for instructions
sqlite> create table test (id not null integer primary key);
SQL error: near "integer": syntax error
sqlite> |
2006-Mar-27 15:01:22 by anonymous:
this is a incorret SQL statement. must be
CREATE TABLE test (id integer not null primary key) |
|
1730 |
new
|
closed
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
|
2
|
5
|
referential integrity
|
edit |
do u have any plan to support referential integrity |
2006-Mar-24 19:10:04 by drh:
Please ask questions like this on the mailing list.
Tickets are for reporting bugs. See
http://www.sqlite.org/support.html for instructions on
how to subscribe to the mailing list. |
|
1729 |
code
|
closed
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
|
1
|
1
|
SQLite loses precision on 64-bit integers
|
edit |
I need full precision on 64-bit integers that I insert into SQLite. If I put in 15687216181554097151, I need to pull out 15687216181554097151 instead of 1.56872161815541e+19. I am working with 64-bit integers as my primary datatype and so the loss of precision is a deal-breaker for my project. |
2006-Mar-24 16:56:19 by drh:
SQLite uses 64-bit signed integers having a range of
-9223372036854775808 to 922372036854775807. The number
you specify is outside of this range, cannot be represented
as a 64-bit signed integer, and is therefore converted into
a floating point value.
There are no plans to modify SQLite to support larger integers
at any time in the near future.
2006-Mar-24 16:59:59 by anonymous:
Actually the field I'm storing that in is of type "BIGINT UNSIGNED".
2006-Mar-24 17:02:50 by drh:
There are also no plans to modify SQLite to support unsigned integers.
2006-Mar-24 17:27:50 by anonymous:
Yes, but SQLite doesn't support unsigned ints. You will have to cast your unsigned ints to signed ints before saving them into the sqlite database, and similarly cast them from signed back to unsigned when you retreive them.
The biggest difficulty will ocurr if you are doing comparisons in your queries. You will need to convert simple comparisons into a more comlex comparisons that handle the wrapping of your large unsined values into negative values.
For comparisons like x > k;
if k converts to a positive signed value you need (x > k OR x < 0)
if k converts to a negative signed value you need (x > k AND x < 0)
Similarly for comparisons like x < k;
if k >= 0, (x < k AND x >= 0)
if k < 0, (x < k OR x >= 0)
Also, you will need to define a custom collation function to sort by your unsigned values if you need to do sorts on those values.
2006-Mar-24 18:04:20 by anonymous:
He could always create functions to do the unsigned comparisions he needs. |
|
1725 |
code
|
closed
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
|
2
|
1
|
sql "HAVING" fails to filter query grouping "UNION ALL" subqueries
|
edit |
Hi,
the following query results empty but
if you replace "UNION ALL" with "UNION" only
sql sqlite works nice meaning that some records are listed.
"HAVING" clause with "UNION ALL" seems to filter too much.
If you need more details on it please ask me
thanks in advance
Federico & Claudio
SELECT date_time as date_time,
Object as object,
SUM(Kpi.shoaddintranodebatt) AS shoaddintranodebatt,
SUM(Kpi.rtwp_max) AS rtwp_max
FROM (
SELECT datetime(strftime('%Y-%m-%d %H:00:00',
G_PMClass4_cell.date_time)) as date_time,
G_PMClass4_cell.object as object,
SUM(shoAddIntraNodeBAtt) AS shoAddIntraNodebAtt,
null as rtwp_max
FROM G_PMClass4_cell
GROUP BY
datetime(strftime('%Y-%m-%d %H:00:00',
G_PMClass4_cell.date_time)),
G_PMClass4_cell.object
UNION ALL
SELECT datetime(strftime('%Y-%m-%d %H:00:00',
G_PMClass7_cell.date_time)) as date_time,
G_PMClass7_cell.object as object,
null as shoaddintranodebatt,
avg(uurectotalwbpwr_3)*0.1-112 AS RTWP_MAX
FROM G_PMClass7_cell
GROUP BY
datetime(strftime('%Y-%m-%d %H:00:00',
G_PMClass7_cell.date_time)),
G_PMClass7_cell.object
) Kpi
GROUP BY date_time,object
HAVING shoaddintranodebatt > 1
|
2006-Mar-25 14:20:26 by drh:
Without additional information on your schema, the content of
your database, and what output you expected, I cannot reproduce
this problem.
If you believe this is a real problem, you will do well to resubmit
this bug with test script that can be fed into the SQLite
command-line client that will demonstrate the problem. Please
be sure to explain how the output of the test script deviates
from what you expected. |
|
1724 |
code
|
closed
|
2006 Mar
|
anonymous
|
Shell
|
2006 Mar
|
anonymous
|
1
|
1
|
sqlite doesn't work with "cifs-mounted-directories"
|
edit |
I mounted a directory an a Windows-2000-Prof. System with cifs. I see that directory and I can edit files and start programs. But: I like to use sqlite. When I start sqlite on the host, it works perfectly.
When I start sqlite from mounted directory, I get the following message:
SQLite version 3.3.4
Enter ".help" for instructions
sqlite> .databases
Error: disk I/O error
What's wrong ? |
2006-Mar-25 14:10:14 by drh:
This sounds like a bug in the CIFS filesystem implementation. |
|
1723 |
code
|
closed
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
|
1
|
1
|
Crash (floating point error) when dealing with BIGINT datatypes
|
edit |
I have a field in one of my tables which has type BIGINT UNSIGNED. Originally I was filling this with the contents of a 32-bit integer, as that's what I was using for a datatype in my software. When I switched that to 64bit integers and started constructing my queries by ulltoa()ing the 64bit values, SQLite crashed unmercifully:
"INSERT INTO BD_functions VALUES (1509960689, 27, 41, 7, 13760289937621738947, 1, 0, 0, 0);"
This gives a rather puzzling floating point exception.
I have tested putting a smaller value in place of the fifth entry, and there is no crash. |
2006-Mar-21 14:28:56 by drh:
Unable to reproduce.
If you still think this problem is in SQLite and not in your own
code, then please provide a specific example that fails. Also tell
us whether you compiled SQLite yourself or used a precompiled binary
and what OS you are running.
2006-Mar-22 12:47:39 by anonymous:
I am running Windows XP, and I have compiled SQLite into my application. I have narrowed down the crash much further and even fixed it in my copy by modifying the SQLite source code.
I noticed that the application only crashes with BIGINT values which are large enough to be signed. I.e. those values >= 0x8000000000000000. To test this I wrote a program that inserted values ranging from 0x7ffffffffffffff0 upwards, and sure enough it crashed once it hit 0x80.....
Given the query in the opening of this ticket, the BIGINT UNSIGNED crash takes place on the following callpath:
applyAffinity calls sqlite3VdbeIntegerAffinity. This is the sixth time applyAffinity is called for this query.
The following line in sqlite3VdbeIntegerAffinity crashes:
pMem->i = pMem->r;
I replaced the following line in vdbeInt.h from 'i64' to 'u64' and the crash went away:
struct Mem {
u64 i; /* Integer value. Or FuncDef* when flags==MEM_Agg */
I'm not entirely sure why the crash is happening, or why this fixes it, but there you go.
While I'm here, is there any way to keep SQLite from losing precision on my BIGINT values? I need the full, lossless representation, not approximated mantissa + exponent.
2006-Mar-22 14:32:46 by anonymous:
What compiler are you using? Can you post this test program?
2006-Mar-22 14:35:02 by drh:
Still unable to reproduce. I tried the following script on
both Linux and WinXP:
CREATE TABLE t1(a INTEGER);
INSERT INTO t1 VALUES(9223372036854775806); -- 0x7ffffffffffffffe
INSERT INTO t1 VALUES(9223372036854775807); -- 0x7fffffffffffffff
INSERT INTO t1 VALUES(9223372036854775808); -- Ox8000000000000000
INSERT INTO t1 VALUES(9223372036854775809); -- Ox8000000000000001
SELECT * FROM t1;
It works fine. I do not know what you could be doing to
get it to fail. There is nothing wrong with the line of
code where the failure occurs. Your fix, however, will break
lots of other things.
2006-Mar-22 14:44:59 by anonymous:
drh, try "BIGINT UNSIGNED" instead of INTEGER?
drh: BIGINT UNSIGNED and INTEGER mean the same thing to SQLite.
2006-Mar-22 14:55:59 by anonymous:
you're trying to reproduce this with the latest cvs head checkout or with 3.3.4 released source ?
2006-Mar-22 14:59:29 by anonymous:
I, the original poster, am using the 3.3.4 released codebase, compiled with gcc 3.4.4 (mingw release). I am in the process of creating a small application to try to demonstrate this issue (my original crashing application is proprietary code, as a plugin to something else, so A) it would be of no use to anybody B) I can't release that).
2006-Mar-22 19:09:03 by anonymous:
I still can't quite figure out what's going on. Below is the sample program. If I compile this standalone, it does work. If I compile this into my plugin, I get the crash, unless I apply the changes to the Mem struct that I described earlier.
/* sqltest.hpp */
#include "sqlite/sqlite3.h"
#include <stdlib.h>
#include <stdio.h>
#define msg printf
class SQLTest
{
private:
sqlite3 *sql_db;
public:
char *exec_query_no_callback(const char *query)
{
if(!sql_db)
{
msg("SQL ERROR! Trying to write to database which is not open.\n");
return "";
}
char *emsg;
if ( sqlite3_exec(sql_db, query, NULL, 0, &emsg) != SQLITE_OK )
{
msg("SQL ERROR!\nQuery: '%s'\nError: '%s'\n", query, emsg);
return emsg;
}
return NULL;
};
bool Initialize()
{
int rc;
char *result;
rc = sqlite3_open("c:\\bd_temp\\bah.db", &sql_db);
if( rc )
{
msg("Can't open database: %s\n", sqlite3_errmsg(sql_db));
sqlite3_close(sql_db);
sql_db = NULL;
return 0;
}
return 1;
}
bool Test()
{
if( !Initialize() )
{
msg("Initialization failed!\n");
return 0;
}
exec_query_no_callback("CREATE TABLE BD_functions ( "
" address BIGINT UNSIGNED UNIQUE NOT NULL, "
" signature_a INTEGER UNSIGNED NOT NULL, "
" signature_b INTEGER UNSIGNED NOT NULL, "
" signature_c INTEGER UNSIGNED NOT NULL, "
" prime_product BIGINT UNSIGNED NOT NULL, "
" usable_name BOOL NOT NULL, "
" is_recursive BOOL NOT NULL, "
" is_thunk BOOL NOT NULL, "
" is_library BOOL NOT NULL); ");
unsigned long address_base = 0x12345678;
for(unsigned long long prime = 0x7ffffffffffffff0LL; prime <= 0x800000000000000FLL; ++prime)
{
char buf[5000], ullbuf[100];
ulltoa(prime, ullbuf, 10);
sprintf(buf, "INSERT INTO BD_functions VALUES (%d, 1, 2, 3, %s, 1, 0, 0, 0);", address_base++, ullbuf);
exec_query_no_callback(buf);
}
}
};
/* test.cpp */
#include "sqltest.hpp"
int main(int, char **)
{
SQLTest sqle;
sqle.Test();
}
2006-Mar-22 23:42:28 by anonymous:
it's looking like your caller program (or another plug-in for your program) is changing the fp87 flags of your fpu unit. the exception is floating point exception, isn't it ? |
|
1715 |
doc
|
closed
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
|
5
|
4
|
int sqlite3_release_memory(int) documented but not implemented
|
edit |
http://sqlite.org/capi3ref.html#sqlite3_release_memory
That function doesn't appear to be implemented anywhere, nor does the SQLITE_ENABLE_MEMORY_MANAGMENT macro (referenced by the docs) appear to be used anywhere:
me@host:src/sqlite-3.2.7 >grep sqlite3_release_memory $(find . -type f)
me@host:src/sqlite-3.2.7 >grep ENABLE_MEMORY_MANAGMENT $(find . -type f)
(no results) |
2006-Mar-13 14:29:38 by drh:
These features added in version 3.3.0. |
|
1712 |
code
|
closed
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
|
1
|
1
|
aggregate function return empty row
|
edit |
select sum(disk_size) from tblStudies
this command returns row on sqlite3_step (empty row, with MEM_Null records) even on zero database.
should return error on fetch |
2006-Mar-25 15:56:08 by drh:
I think sum() an empty set is suppose to return NULL.
I admit that this is a useless return value but it is apparently
what SQL requires. |
|
1710 |
new
|
closed
|
2006 Mar
|
anonymous
|
|
2006 Aug
|
|
1
|
1
|
when order by, performance is low
|
edit |
I have a master table with the create sql "create table mst (num int, pid int, cid int)". which contains 100000 records. (00000-99999 at the "num" field). and I have another table as "create table mm (name varchar(11), num int)". When I execute "select mm.name from mm, mst where mm.num = mst.num", it's quick. BUT when I execute "select mm.name from mm, mst where mm.num = mst.num ORDER BY mst.pid", it's very very slowly. WHY? |
2006-Mar-09 10:03:38 by anonymous:
Have you created an index on pid? Without and index sqlite will
have to do a sequential scan of the whole table.
2006-Mar-09 16:21:59 by anonymous:
This is not a bug report. It is a request for help using SQLite, and therefore it should be directed to the mailing list (see http://www.sqlite.org/support.html).
2006-Mar-11 08:12:32 by anonymous:
The same sql with same data on other db is execute quickly, so I thought there maybe a bug on ORDER BY.
When I use index, it's so useful, tks! |
|
1708 |
code
|
closed
|
2006 Mar
|
anonymous
|
Unknown
|
2006 Mar
|
anonymous
|
4
|
3
|
Spurious warning: no such table: faculty(1) at dbdimp.c line 269
|
edit |
This was discovered using the Perl module DBD::SQLite V 1.11, which I believe, from its change log, ships with V 3.2.7 of SQLite.
The error msg is:
DBD::SQLite::db do failed: no such table: faculty(1) at dbdimp.c line 269 at /perl/site/lib/CGI/Appl
ication/Demo/Create.pm line 201.
What follows is from an email I wrote to a Perl user who reported this problem to the (Perl module) CGI::Session mailing list:
I tested SQLite with my module CGI::Application::Demo, which is designed to probe strange environments, by patching the config file cgi-app-four.conf.
And I get the same error!
It's caused by a bug in SQLite, which emits this error when you create the database file (as in dsn=dbi:SQLite:dbname=/temp/cgi-app-demo.db) for the first time, and then try a command such as
eval{$$self{'_dbh'} -> do("drop table $table_name")};
The program I was running to prove this (under Win2K) is create.pl, which ships with CGI::Application::Demo
The error msg is emitted despite the eval.
By running create.pl repeatedly, with and without first deleting
/temp/cgi-app-demo.db, proves that if the database file is present, SQLite does not emit this msg, but if the database file is absent, so that running the program must create it, then the error msg is emitted by the drop table statement. In your case, some other stmt causes the error, but it's the same problem. I believe that the problem arises with the very first SQL command executed after the database file is created. |
2006-Mar-07 11:49:36 by anonymous:
this bug should be addressed to DBD::SQLite developers, not to SQLite developers. Or ask the mailing list.
2006-Mar-07 14:41:52 by drh:
I concur with the anonymous poster above.
This ticket should be moved to the DBD::SQLite page
at cpan. http://search.cpan.org/dist/DBD-SQLITE/ |
|
1707 |
code
|
closed
|
2006 Mar
|
anonymous
|
Unknown
|
2006 Mar
|
|
4
|
4
|
Internal data are not naturaly aligned, which could affect perfomance
|
edit |
The code arrange internal data not naturally aligned. This effects performance on some arches (Alpha in my case). For example:
build.c around line number 2359 there is a code -
pIndex = sqliteMalloc(
sizeof(Index) + /* Index structure */
sizeof(int)*nCol + /* Index.aiColumn */
sizeof(int)*(nCol+1) + /* Index.aiRowEst */
sizeof(char *)*nCol + /* Index.azColl */
sizeof(u8)*nCol + /* Index.aSortOrder */
nName + 1 + /* Index.zName */
nExtra /* Collation sequence names */
);
if( sqlite3MallocFailed() ) goto exit_create_index;
pIndex->aiColumn = (int *)(&pIndex[1]);
pIndex->aiRowEst = (unsigned *)(&pIndex->aiColumn[nCol]);
pIndex->azColl = (char **)(&pIndex->aiRowEst[nCol+1]);
pIndex->aSortOrder = (u8 *)(&pIndex->azColl[nCol]);
The alignment of azColl structure member is determined by allocation of previous members. But alignment of azColl should be equal to sizeof(char *) because it is array of pointers.
There should be padding used or some other alignment techniques.
Thank you, |
2006-Mar-06 14:55:20 by drh:
Already fixed in 3.3.4. See check-in [3079]
. |
|
1706 |
code
|
closed
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
|
1
|
2
|
Group operations like ORDER BY don't work after renaming a table
|
edit |
Once a table is renamed, group operations like ORDER BY do not work on that table anymore. |
2006-Mar-06 12:00:47 by drh:
Unable to reproduce.
If you want to reopen this ticket, please provide a specific example
of a sequence of SQL statements that exhibits the alleged malfunction.
Reopening this with how-to-reproduce instructions.
Open the attached db using sqlite3 (3.3.4) and run the query "SELECT * FROM Undo_Data;". This shows that there are rows in the table and when you run the query "SELECT * FROM Undo_Data ORDER BY EntryId;", it returns 0 rows. EntryId is of type INTEGER affinity.
Since the tracking system doesn't allow us to attach a file at the same time as we edit the ticket, will attach the file in the next update...
Thanks,
Subhash
2006-Mar-06 15:15:27 by drh:
I can clearly see that the database you provide is corrupt.
The question is, how did it get that way. The only hint you
have provided is that you did some "rename table" actions.
I am unable to reproduce the problem here.
If you want me to fix this, please provide details of how you
generated the error. Showing me the database after the error
is some help, but not much. What I really need to know is what
you did you to get the database into its current state. For me
to learn this, you need to communicate it to me in the trouble
ticket because I cannot read your mind.
As a temporary workaround, you can clear the problem using either
of the following commands:
REINDEX;
VACUUM;
|
|
1705 |
code
|
closed
|
2006 Mar
|
anonymous
|
Unknown
|
2006 Mar
|
|
4
|
4
|
Default column constant doesn't assign value on NULL insert
|
edit |
Running on Windows XP with sqlite 3.3.4, I create a table with one column having a default value of CURRENT_TIMESTAMP. But when inserting into this table with a NULL for that column, I get an error instead of the column getting the default value. Here is the output:
sqlite3 test.db
SQLite version 3.3.4
Enter ".help" for instructions
sqlite> CREATE TABLE undo (
idx INTEGER NOT NULL,
date_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
sql TEXT NOT NULL,
PRIMARY KEY (idx),
UNIQUE (idx)
);
sqlite> insert into undo values (NULL,NULL,'test string');
SQL error: undo.date_time may not be NULL
So I tried again with a constant for the default with the same results.
sqlite> CREATE TABLE redo (
idx INTEGER NOT NULL,
date_time TIMESTAMP NOT NULL DEFAULT 'ABC',
sql TEXT NOT NULL,
PRIMARY KEY (idx),
UNIQUE (idx)
);
sqlite> insert into redo values (NULL,NULL,'insert into etc');
SQL error: redo.date_time may not be NULL
sqlite>
It appears that the not null constraint is processed first and prevents the default from being assigned. |
2006-Mar-03 19:33:52 by drh:
I am told that the SQLite's current behavior is correct.
If you want to insert the default value, omit the column
from the VALUES clause completely. If you explicitly say
NULL then a NULL will be inserted. |
|
1694 |
code
|
closed
|
2006 Feb
|
anonymous
|
Parser
|
2006 Feb
|
|
3
|
3
|
SELECT count(distinct vnum) FROM table generates syntax error.
|
edit |
Problem:
SELECT count(distinct arg1) from table gives a syntax error.
Output:
sqlite> SELECT count(distinct VNUM) from objects_number_to_extra_flags;
SQL error: near "distinct": syntax error
Schema:
CREATE TABLE OBJECT_NUMBER_TO_EXTRA_FLAGS
(
vnum,
extra_flag
); |
2006-Feb-27 23:22:15 by drh:
Works fine when I try it. Perhaps you could post a actual
script that fails.
2006-May-15 12:13:45 by anonymous:
I am experiencing the same problem with sqlite 2.8.16 and sqlite 3.2.2
sqlite> SELECT COUNT(sku), COUNT(DISTINCT sku) FROM products;
SQL error: near "DISTINCT": syntax error
"SELECT COUNT(sku)" and "SELECT DISTINCT sku" work fine.
2006-May-15 12:50:28 by drh:
count(DISTINCT ...) is not supported in SQLite 2.x. |
|
1692 |
code
|
closed
|
2006 Feb
|
anonymous
|
|
2006 Mar
|
|
1
|
2
|
Collation dont work in functions
|
edit |
If a columns is defined with a collation:
SELECT .... WHERE a='kalle';
works fine.
But
SELECT ..... WHERE COALESCE(a,'xxx')='kalle';
or
SELECT ..... WHERE LOWER(a)='kalle';
dont call the userdefined collate-function.
No function seems to result is a call to the collation-function, |
2006-Feb-28 07:40:45 by anonymous:
Using:
CAST(col AS TEXT COLLATE 'swedish')
dont work either.
2006-Mar-03 19:47:11 by drh:
This is how SQLite is documented to work. A collating function
is only used for comparisons if either the left or right operand
is a column that has a collating function. If you think there
should be a design change so that collating functions are used
for comparisons of arbitrary expressions, then make your case on
the SQLite mailing list.
Your work-around is to to sqlite3_create_function() to create a
suitable comparison function at the same time you register your
collating sequence. For example:
SELECT ... WHERE compare_swedish( coalesce(a,'xxx'), 'kalle');
|
|
1691 |
code
|
closed
|
2006 Feb
|
anonymous
|
Unknown
|
2006 Mar
|
|
3
|
3
|
sqlite3_sleep not built
|
edit |
I just compiled 3.3.4 on windows using mingw. The sleep function is not included in the library. It looks like the file experimental.c is not included in the build. I don't know yet if anything else is affected by this. |
2006-Mar-03 20:07:01 by drh:
The functions in experimental.c are experimental. They are
not an official part of the build. You can add them to the
build if you want to use them. They are not needed by any
other part of the system. |
|
1687 |
todo
|
closed
|
2006 Feb
|
dougcurrie
|
|
2006 Mar
|
|
3
|
3
|
tclsqlite.c crashes MinGW/MSYS gcc 3.4.5 on WIndows
|
edit |
The macro EXTERN is used by tclsqlite but not defined (properly). This causes build on WinXP with MinGW/MSYS to crash.
Suggestion: change all occurances of EXTERN to extern in tclsqlite.c
Also, this code in tclsqlite.c is unused and should be removed:
/*
* Windows needs to know which symbols to export. Unix does not.
* BUILD_sqlite should be undefined for Unix.
*/
#ifdef BUILD_sqlite
#undef TCL_STORAGE_CLASS
#define TCL_STORAGE_CLASS DLLEXPORT
#endif /* BUILD_sqlite */
e |
2006-Mar-06 22:04:33 by dougcurrie:
Unfortunately, check-in [3119]
doesn't work. The problem is that EXTERN is defined in tcl.h, and in such a way as to make MinGW 3.4.5 crash. So, conditionally re-defining it doesn't help.
Either every EXTERN has to become extern , or check-in [3119]
has to be reverted, and the preprocessor symbol BUILD_sqlite needs to be defined in every target that uses tclsqlite.c.
2006-Jul-10 21:00:14 by anonymous:
[Jeff Hobbs]: That is not the correct solution.
It must be just the msys build that isn't configured correctly. Make sure that you define -DBUILD_sqlite for all Windows-based builds (mingw or MSVC). Aside from that, it should work fine. The tcl.h handles DLLEXPORT for both MSVC and GNUC variants on Windows.
You can define BUILD_sqlite for all builds and it wouldn't harm anything either. |
|
1686 |
code
|
closed
|
2006 Feb
|
anonymous
|
Pager
|
2006 Feb
|
|
2
|
4
|
File locking and concurrency problems under Windows
|
edit |
Hi,
I have some problems with sqlite and concurrent access on Windows. I use sqlite3_exec from a few processes (2-3) to insert data into a table and read from this table. No transactions are used, only single-record inserts in autocommit mode.
What I found out is that you can not be sure that an insert is executed when there is a concurrent inserter or concurrent reader in another process. It is very likely that the insert fails with code 5 (database locked). Sleeping and re-trying is not really a solution as it is also unreliable (one can not tell when the statemen will finally succeed).
I read carefully the documentation about locking and concurrency and I think the main reason for this problem is that if a process is unable to lock the database, the statement FAILS. The documentation reads:
"If the process that wants to write is unable to obtain a RESERVED lock, it must mean that another process already has a RESERVED lock. In that case, the write attempt fails and returns SQLITE_BUSY."
In my opinion, the statement should not FAIL but BLOCK until the lock is released by the process that held the lock, like all relational databases (commercial or open source) that I know do.
If a statement can fail because another process has locked the database, this makes the database unsuitable for concurrent use.
The only workaround I could think of is using a system-wide mutex to ensure serial access to the database, which would make your locking system totally obsolete.
I'm looking forward to your opinion on this issue, especially if you think that a blocking mode could be implemented.
with kind regards
Christoph |
2006-Feb-21 18:32:17 by drh:
See sqlite3_busy_timeout()
2006-Feb-22 13:56:10 by anonymous:
sqlite3_busy_timeout() is sleep-and-retry solution which I consider a hack and not a real solution.
I would prefer a global mutex-solution over this one.
2006-Feb-22 23:29:20 by anonymous:
Its pretty to implement your global mutex outside of the database by just using flock on an external file. Really it seems you should just do that rather then attempting to add complexity to SQLite. |
|
1681 |
code
|
closed
|
2006 Feb
|
anonymous
|
Unknown
|
2006 Mar
|
|
1
|
3
|
After upgrading from 3.2.7 to 3.3.4, problems with umlauts
|
edit |
After upgrading from 3.2.7 to 3.3.4, all umlauts in queries cause syntax errors. |
2006-Feb-16 19:44:46 by anonymous:
I can confirm this problem. We've been experiencing the same after the upgrade to 3.3.4. Here's an example query:
amarok: [CollectionDB] [ERROR!] near "1": syntax error
amarok: [CollectionDB] [ERROR!] on insert: INSERT INTO tags_temp ( url, dir, createdate, modifydate, album, artist, genre, year, title, composer, comment, track, discnumber, sampler, length, bitrate, samplerate, filesize, filetype ) VALUES ('/home/tester/Shared/Röyksopp - What Else Is There?.mp3','/home/tester/Shared',1121115569,1121115569,19,24,14,'1','What Else Is There?',NULL,'', 7, 0 , 0,317,256,44100,10141380,1)
2006-Mar-03 19:15:54 by drh:
I am guessing that this problem is in a wrapper or interface to
SQLite and not in SQLite itself. If you disagree, please submit
a script that demonstrates the problem when run through the
standard SQLite command-line shell.
2006-Mar-13 21:58:29 by anonymous:
The problem turned out to be that sqlite3_prepare() expects the length as the number of bytes, not characters, and we were passing the latter. This worked with the ASCII subset of UTF-8, but broke otherwise. (Not sure why it worked with previous versions). Solution was to pass -1 so it reads until the null at the end.
Just mentioning this here in case others stumble on the same problem. |
|
1678 |
code
|
closed
|
2006 Feb
|
anonymous
|
Unknown
|
2006 Feb
|
|
1
|
1
|
error select like
|
edit |
select * from tResult where tex like '%ra%'
(result = 0)
select tex from tResult where id = 3229
(tex = "...Oracle...")
http://www.aidagw.com/files/dba.zip |
2006-Feb-15 03:24:37 by drh:
The query works correctly on the command-line shell.
This is probably a bug in sqlite3explorer. |
|
1677 |
new
|
closed
|
2006 Feb
|
anonymous
|
|
2007 Aug
|
|
4
|
3
|
No way to know if library was compiled with threadsafety
|
edit |
There is no way to know if library was compiled with threadsafety enabled. Here is a patch I made that adds both a compile-time define and a function that can be called runtime to check.
http://0x63.nu/patches/sqlite-threadsafe-check.patch
(I hereby give up all claim of copyright for the patch and put it in the public domain) |
See Check-in [4350]
|
|
1676 |
code
|
closed
|
2006 Feb
|
anonymous
|
|
2006 Feb
|
|
2
|
2
|
When binding the wrong type sqlite3 bails out but retuns an SQLITE_OK
|
edit |
I'm not using sqlite api directly but please, bear with me :)
Using Qt 4.1.0 version of sqlite driver ( sqlite 3.2.7 according to sqlite3.h )
When I do a prepared insert and bind a QByteArray to a field that is of type varchar in the create table, Qt will call a bind to blob instead of bind to text. The query isn't executed, but Qt still receives an SQLITE_OK instead of a more proper SQLITE_MISMATCH.
I was going to report this to Trolltech, but it seams to me this really is a bug with sqlite, I can't find anything wrong with their code. |
2006-Feb-11 21:08:07 by drh:
SQLite allows you to insert any data type into any column
(except, of course for INTEGER PRIMARY KEY columns which must
be an integer.) This is a feature, not a bug. See
http://www.sqlite.org/faq.html#q3
2006-Feb-13 02:46:32 by anonymous:
As I have said, it does not get executed!
It says it was OK but the database contains no new rows.
2006-Feb-13 02:52:12 by anonymous:
Sorry for submitting so fast, I got really frustrated that the report wasn't carefully read, I hope you can understand.
I did some small amount of step into the sqlite library to debug the code, and I don't know why it fails to execute ( even thought it says it did ). I do know that when the bind_blob call was replaced by a bind_text, it worked just fine, and I could later on load the data back.
2006-Feb-13 12:37:09 by drh:
If you want anybody to look into this, you are going to have
to supply some additional clues, such as:
- The exact SQL text of the INSERT statement that fails.
- The schema of the database you are running the statement against.
- The text you are binding against the SQL statement.
- What you are doing to determine that the INSERT is not working.
2006-Feb-14 02:14:24 by anonymous:
I'm unable to reproduce anymore, sorry that I wasted your time. Tried to build a small test case for several hours but nothing seams to make it fail. Maybe it was some typo of my part. |
|
1673 |
code
|
closed
|
2006 Feb
|
anonymous
|
Shell
|
2006 Feb
|
|
3
|
3
|
constraint using "in" -- bug 1645 revisited
|
edit |
create table junk(x text check(x in ( 'abc' )));
insert into junk values( 'x' );
SQL error: constraint failed
also the error message must identify
which constraint failed: #1648 |
2006-Feb-11 05:48:05 by anonymous:
that was supposed to be
insert into junk values( 'a' );
which also fails
2006-Feb-11 08:55:47 by anonymous:
create table junk(x text check(x in ( 'a', 'b', 'c' ))); ?
2006-Feb-11 14:06:50 by anonymous:
Oops, I must have been thinking of a different programming language.
Thanks, please close this. |
|
1668 |
event
|
closed
|
2006 Feb
|
anonymous
|
Shell
|
2006 Feb
|
drh
|
2
|
3
|
datetime modifiers "enf of *" and "group * by" do not work
|
edit |
datetime('now','localtime','group hours by 8');
results in an empty string, not the result as explained in the wiki page
datetime('now','end of day');
the same unexpected empty result. It seems that "end of" and "group by" modifiers do not work with version "3.3.3 stable". |
2006-Feb-09 23:00:09 by drh:
Those keywords are extensions that were added by an anonymous
poster. You can find his patches further down on the web page.
The keywords described have never been a part of the core
SQLite. |
|
1667 |
code
|
closed
|
2006 Feb
|
anonymous
|
BTree
|
2006 Feb
|
danielk1977
|
1
|
1
|
Database corruption when db file hits 1 GB with auto_vacuum (3.3.3)
|
edit |
After a few inserts sqlite3_step fails with the error "database disk image is malformed".
I noticed that this problem only occurs if I have the pragma "auto_vacuum = 1".
The db size on disk is about 1GB at the time.
The thing is that after this occurs, the db doesn't seem to be corrupted (I can add/remove things from the table from the command line utility on the same db).
I reproduced this on windows and linux.
I replicated this problem in a test case (it takes a a minute or so to hit 1 GB). |
2006-Feb-09 01:11:18 by anonymous:
I forgot to mention that I reproduced this problem on Linux Fedora Core 3 and Windows XP Pro SP2 (I don't think it maters, but who knows...).
2006-Feb-10 08:33:19 by danielk1977:
As far as I can see, this bug should not have actually
corrupted any databases. Any attempt to create an
auto-vacuum database bigger than 1GB will have caused
the transaction to fail with an SQLITE_CORRUPT error.
Should be fixed in cvs now.
Thanks for taking the time to write the test case. |
|
1659 |
event
|
closed
|
2006 Feb
|
anonymous
|
Shell
|
2006 Feb
|
anonymous
|
1
|
2
|
Sqlite.exe .import stopped working in latest 3.3.3 release (Win32)
|
edit |
The .import function in SQLite.exe (Win32) does not work.
In Previous 3.3.2b it worked fine. I am using the same batch scripts in a cmd prompt on WinXP as before.
sqlite3.exe test.db ".import data.txt table1 ;" |
2006-Feb-06 12:41:14 by drh:
Duplicate of #1651. Already fixed by [3047]
. |
|
1642 |
code
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
4
|
4
|
single time leaks in sqlite3_prepare()
|
edit |
In 3.3.2 the first call to sqlite3_prepare() leaks exactly 42 memory blocks per application session, regardless of number of opened/closed databases or statements executed. Next calls to sqlite3_prepare() don't leak.
In 3.3.1 there was leak in sqlite3_execute() but it disappeared in new version. I use BCB 6.4, my own allocator based on dlmalloc and preprocessed sources.
There's slight chance it is caused by my code since I do:
#define free my_free
and taking pointer to original free() is still possible. |
The extra allocations in the first call to sqlite3_prepare()
likely occur as the database schema is being loaded. These
blocks should be freed when the database handle is closed.
Please post the code that produces the memory leak.
2006-Jan-30 23:06:30 by drh:
No code was ever posted to demonstrate the problem.
We will assume, there for, that this is not really a bug. |
|
1641 |
doc
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
5
|
4
|
Very minor documentation thing
|
edit |
http://www.sqlite.org/datatype3.html
In the datatype documentation for COLLATE, it states that the "left operand determines the collation sequence used".
But, in the examples, the "right operand" is used.
Column a is defined as BINARY, coloumn d is defined as NOCASE, and the example states:
-- Text comparison is performed using the NOCASE collation sequence.
SELECT (a = d) FROM t1;
The same holds for the other examples. I assume, because of their consistency, the examples are right and the docs are wrong? |
In this case the examples were wrong. Cvs is now corrected, the live website will catch up next release. |
|
1640 |
code
|
closed
|
2006 Jan
|
anonymous
|
VDBE
|
2006 Jan
|
|
3
|
2
|
Can't get error message from sqlite3_result_error
|
edit |
sqlite3_errmsg doesn't return proper error message from sqlite3_result_error if query is executed by sqlite3_step.
For example,
#include <stdio.h>
#include "sqlite3.h"
int main(void) {
const char *sql = "select 'a' like 'b' escape 'cd'";
sqlite3 *db;
sqlite3_stmt *stmt;
int ret;
char *err;
sqlite3_open(":memory:", &db);
ret = sqlite3_exec(db, sql, NULL, NULL, &err);
printf("exec=%d\n", ret);
printf("exec:err=%s\n", err);
printf("exec:errmsg=%s\n", sqlite3_errmsg(db));
sqlite3_prepare(db, sql, -1, &stmt, NULL);
ret = sqlite3_step(stmt);
printf("step=%d\n", ret);
printf("step:errmsg=%s\n", sqlite3_errmsg(db));
sqlite3_close(db);
return 0;
}
$ ./testprogram
exec=1
exec:err=ESCAPE expression must be a single character
exec:errmsg=ESCAPE expression must be a single character
step=1
step:errmsg=SQL logic error or missing database
$
Maybe derived from check-in [2982]
. |
The error message is available via sqlite3_errmsg() only after
sqlite3_finalize() or sqlite3_reset() is called on the statement
handle. |
|
1639 |
code
|
closed
|
2006 Jan
|
anonymous
|
Unknown
|
2006 Mar
|
|
3
|
3
|
pkgconfig file in 3.3.1 says version is 3.3
|
edit |
The pkgconfig file included in the 3.3.1 alpha release says the version is "3.3". This means it's not possible to check for 3.3.1 specifically, which is needed to ensure that the threading fixes that went in that release are available. |
2006-Jan-31 07:06:30 by anonymous:
This is causing http://bugzilla.gnome.org/show_bug.cgi?id=329280
2006-Jan-31 12:49:18 by drh:
Version 3.3.0 failed to work in many ways. It was out less than
one week before 3.3.1 arrived to replace it. I suggest you change
your script to check for SQLite version 3.3 or greater and ignore
3.3.0.
2006-Jan-31 18:06:33 by anonymous:
At least one of our users was running 3.3.0 and was hitting MISUSE errors due to the changes in the threading code, so I don't think I can ignore it. I realize the 3.3.x series is alpha; if anything that makes the need to put micro version numbers in the pkgconfig file more important, so that we can depend on versions after bugs have been fixed.
2006-Jan-31 19:28:27 by drh:
I do not know what a pkgconfig file is. I do not know where it
comes from. I do not know what it is used for.
It is not something that I ever wrote.
I do not know how to change it.
If you want to see this fixed, please submit a patch. |
|
1631 |
code
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
2
|
3
|
Sqlite3 reports fdatasync type referenced symbol not found on Solaris
|
edit |
Recently I built and installed SQLite 3.2.8 for our Trac 0.9.3 upgrade. I have started using !StarOffice 8 (Product Update 1) with unixODBC 2.2.11 to interface to SQLite 3.2.8.
Unfortunately, although 3.2.7 "Now compiles on Solaris and OpenBSD and other Unix variants that lack the fdatasync() function" it doesn't appear to be cleanly worked around between applications.
When adding a new table using the !StarOffice 8 design view, on saving the new table and modifying the database schema the response is the crash of the application and the following on the console:
anthony@mayhem:/home/anthony>ld.so.1: soffice.bin: fatal: relocation error: file /opt/local/lib/libsqlite3.so.0: symbol fdatasync: referenced symbol not found
Killed
What can be done to work around this missing function more gracefully? |
2006-Jan-19 04:45:49 by anonymous:
I found that fdatasync is actually supported in Solaris. The build should use libposix4.so under Solaris 8/9
#ls -la /usr/lib | grep libposix4.so
lrwxrwxrwx 1 root root 16 Nov 25 2003 libposix4.so -> ./libposix4.so.1*
lrwxrwxrwx 1 root root 12 Nov 25 2003 libposix4.so.1 -> ./librt.so.1*
#nm /usr/lib/libposix4.so |grep fdatasync
[283]
| 9712| 12|FUNC |GLOB |0 |9 |fdatasync
[54]
| 0| 0|FILE |LOCL |0 |ABS |fdatasync.c
2006-Jan-23 00:27:36 by drh:
See tickets #1604, #1580, #1548, #1545, #1467, and #1465. |
|
1624 |
code
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
drh
|
1
|
1
|
OSMALLOC(int n) implementation does not allow OOM testing
|
edit |
util.c, "static void * OSMALLOC(int n)" function.
If the "Out of memory" condition is simulated at operating system level, without using the sqlite tools for that, OSMALLOC() asserts if the allocation fails:
if( !failMalloc() ){
u32 *p;
p = (u32 *)sqlite3OsMalloc(n + TESTALLOC_OVERHEAD);
assert(p);
sqlite3_nMalloc++;
applyGuards(p);
linkAlloc(p);
return (void *)(&p[TESTALLOC_NGUARD + 2*sizeof(void *)/sizeof(u32)]);
}
This makes impossible the "Out of memory" testing. |
2006-Jan-17 15:36:36 by danielk1977:
Can you compile without the SQLITE_MEMDEBUG macro defined for the purposes of this OOM testing?
This will get you around the problem in ticket #1618 too. |
|
1623 |
code
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
drh
|
1
|
1
|
ThreadData instance never gets freed
|
edit |
The test code is:
(SQLITE_ENABLE_MEMORY_MANAGEMENT macro defined)
sqlite3* dbHandle = NULL;
int err = sqlite3_open16("c:\\a.db", &dbHandle);
sqlite3_close(dbHandle);
sqlite3_close() invokes sqlite3OsThreadSpecificData() with "-1" argument. But the memcmp() call returns non-zero value, because some
ThreadData data members are not 0. For example:
nMaxAlloc = 9140
mallocDisalloved = 1
zFile = "legacy.c"
iLine = 71
Because memcmp() returns non-zero value, the code inside the "if" statement is never called and the tls block - never freed. |
|
1620 |
todo
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
1
|
1
|
error database or disk is full
|
edit |
Hello,
here is another sqlite 3.3.1 disk full error.
I am using a 2GB genotype database with approx 75 Million records and 4x 10-char-columns where I am trying to add another chunk of the same size with ".import FILE TABLE". Breaks after the same time used for importing the first chunk.
I expected that under XP up to 100 GB should be possible. Previous suggestions at the mailing list do not work. I have
- full read/write access rights
- no autoincrement index
- no problem with disk space (>10GB free)
- no problem with memory (always >150 MB free)
- no indication for any hardware failure according to sysinternal tools
Thanks for all, Matthias |
2006-Jan-17 17:02:54 by anonymous:
solved - seemed that an FAT formatted partition prohibited adequate growth - maybe this could be added to the FAQ? |
|
1618 |
code
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
drh
|
1
|
1
|
Problematic ENTER_MALLOC() macro definition
|
edit |
sqliteInt.h file, the macro definition is:
#define ENTER_MALLOC (\
sqlite3ThreadData()->zFile = __FILE__, sqlite3ThreadData()->iLine = __LINE__ \
)
But if that's the first sqlite3ThreadData() call, the function will try to allocate a block of memory. If the allocation fails, sqlite3ThreadData() returns NULL and "NULL->File" will crash the application. |
2006-Jan-16 14:35:48 by danielk1977:
True statement. But the ENTER_MALLOC macro is only enabled when
memory-debugging is turned on during testing. Under these
circumstances we don't expect a "real" malloc() failure - just the
ones that we engineer for testing purposes. |
|
1617 |
code
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
drh
|
1
|
1
|
Memory allocation routines always return non-zero value
|
edit |
os_common.h file, functions:
void *sqlite3GenericMalloc(int n){
char *p = (char *)malloc(n+8);
assert(n>0);
assert(sizeof(int)<=8);
if( p ){
*(int *)p = n;
}
return (void *)(p + 8);
}
void *sqlite3GenericRealloc(void *p, int n){
char *p2 = ((char *)p - 8);
assert(n>0);
p2 = (char*)realloc(p2, n+8);
if( p2 ){
*(int *)p2 = n;
}
return (void *)((char *)p2 + 8);
}
It is obvious that even if the memory allocation fails these functions won't return 0! In this case they return 0x00000008 which makes impossible usual "if(!p)" testing for failed memory allocation. |
|
1613 |
new
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
4
|
4
|
"between" doesn't take advantage of indexes
|
edit |
"x > min AND x < max" is the same speed as "x BETWEEN min AND max" normally, but considerably faster (impromptu benchmark says 5x) after indexing -- For now I'm using "less and greater" as I need the speed, but would like "between" to work as it looks nicer in context... |
2006-Jan-15 17:16:12 by drh:
Support for optimizing the BETWEEN operator was added to
version 3.2.3. There are no plans to back-port these enhancements to
the 2.x series. |
|
1612 |
code
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
1
|
3
|
"malformed database schema" when opening 3.2.8 database with SQLITE_OM
|
edit |
Please compile the following code with SQLITE_OMIT_UTF16 defined. It opens a database file created with SQLite3 3.2.8 and fails when preparing the statement, returning "malformed database schema". There are no problems when SQLITE_OMIT_UTF16 is not defined.
The database file in question is attached to this ticket.
#include <stdio.h>
#include "sqlite3.h"
//---------------------------------------------------------------------------
sqlite3 *db = 0;
void ExecSql (char *sql)
{
sqlite3_stmt *stmt;
int rc;
rc = sqlite3_prepare (db, sql, -1, &stmt, 0);
if (rc != SQLITE_OK) {
printf(sqlite3_errmsg (db));
return;
};
rc = sqlite3_step(stmt);
while (rc == SQLITE_ROW){
printf("Data\n");
rc = sqlite3_step(stmt);
}
rc = sqlite3_finalize (stmt);
if (rc != SQLITE_OK) printf("%d\n", rc);
}
//---------------------------------------------------------------------------
#pragma argsused
int main(int argc, char* argv[])
{
sqlite3_stmt *stmt;
int rc;
char * c;
sqlite3_open("SQLite_328.db3", &db);
ExecSql("SELECT * FROM Files;");
sqlite3_close(db);
scanf ("*%c"); return 0;
}
|
2006-Jan-15 14:27:08 by anonymous:
It is a utf-16 database. The error message is not
particularly good I suppose.
2006-Jan-16 09:53:54 by anonymous:
I was not (and still I am not) aware of the fact that there are UTF-16 and non-UTF-16 databases in SQLite.
I was always under the impression that SQLITE_OMIT_UTF16 excludes only the interface to UTF-16. But even not using the UTF-16 interface, SQLite still stores all data UTF-8 internally IMO.
So I don't see why there should be problems opening a database created without SQLITE_OMIT_UTF16 with an aplication compiled with SQLITE_OMIT_UTF16.
I anyone can shed some light on this issue, please do so.
2006-Jan-16 11:53:28 by anonymous:
My sincere appologies for this ticket - it is not a bug. For anybody having the same problem, below follows a description of what I did wrong and how I changed it to the better.
I created the attached database file with sqlite3_open16. My error was not to notice that sqlite3_open16 sets the database's encoding to UTF-16 by default, an important little detail which I generously overlooked in the documentation:
"If the database file does not exist, then a new database will be created as needed. The encoding for the database will be UTF-8 if sqlite3_open() is called and UTF-16 if sqlite3_open16 is used."
Obviously, SQLite3 can not read UTF-16 with support for UTF-16 excluded by SQLITE_OMIT_UTF16.
As a solution, I change the database's encoding to UTF-8 with calling
PRAGMA encoding = "UTF-8";
before creating any tables. It now opens perfectly even with SQLITE_OMIT_16 defined. |
|
1610 |
code
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
1
|
2
|
SQLITE_OMIT_SUBQUERY can cause access violation
|
edit |
The following code creates a scenario which, when compiled with SQLITE_OMIT_SUBQUERY, causes an access violation with Borland's C++ Builder.
#include <stdio.h>
#include "sqlite3.h"
//---------------------------------------------------------------------------
sqlite3 *db = 0;
void ExecSql (char *sql)
{
sqlite3_stmt *stmt;
int rc;
rc = sqlite3_prepare (db, sql, -1, &stmt, 0);
if (rc != SQLITE_OK) {
printf(sqlite3_errmsg (db));
return;
};
rc = sqlite3_step(stmt);
while (rc == SQLITE_ROW){
printf("Data\n");
rc = sqlite3_step(stmt);
}
rc = sqlite3_finalize (stmt);
if (rc != SQLITE_OK) printf("%d\n", rc);
}
#pragma argsused
int main(int argc, char* argv[])
{
sqlite3_stmt *stmt;
int rc;
/* Create a new, empty database. */
sqlite3_open("test.db3", &db);
ExecSql (
"CREATE TABLE IF NOT EXISTS Files ("
"ID integer primary key,"
"Name Text,"
"Parent Integer,"
"Type Integer,"
"Size Integer,"
"Time Double,"
"Attr Integer,"
"Desc Text,"
"Hash Integer);");
ExecSql ("CREATE INDEX IF NOT EXISTS Files_Parent_Type ON Files (Parent, Type);");
/*
The following line creates an access violation in vdbemem.c, line 116:
memcpy(z, pMem->z, n );
Cause: Write of address 000008.
Apparently, pMem->z is NULL and has not been properly initialized.
!!!! The problem only shows only if compiled with SQLITE_OMIT_SUBQUERY !!!!
*/
ExecSql (
"SELECT \"ID\" FROM \"Files\" WHERE \"Parent\"=? "
"AND \"Type\" IN (0,1) ORDER BY \"Type\" DESC, \"Name\" COLLATE NOCASE;");
sqlite3_close(db);
return 0;
}
|
Could this error have been caused by building part
of the library with OMIT_SUBQUERY defined and part
without?
I would have expected all three statements to
fail, because neither the EXISTS nor IN keywords are
defined when OMIT_SUBQUERY is defined. The fix for this,
and a few other things for OMIT_SUBQUERY mode is in [2943]
.
As a general rule, anyone using any of the SQLITE_OMIT_
compilation symbols should be running the test suite if
at all possible. |
|
1609 |
code
|
closed
|
2006 Jan
|
anonymous
|
Unknown
|
2006 Jan
|
|
2
|
3
|
ALTER TABLE ADD COLUMN failed if table name has multibyte character
|
edit |
ALTER TABLE ADD COLUMN is failed if table name has multibyte character.
$ sqlite3
SQLite version 3.2.8
Enter ".help" for instructions
sqlite> create table "<alpha>" (X); -- <alpha> is GREEK ALPHA
sqlite> alter table "<alpha>" add column(Y);
alter table "<alpha>" add column Y text;
SQL error: malformed database schema - near ",": syntax error
In alter.c, nested SQL uses 'substr' and 'length' functions which count
characters, but p->addColOffset is counted by bytes in build.c. |
|
1606 |
code
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
1
|
1
|
sqlite3_prepare16 broken
|
edit |
Example: The following SQL
PRAGMA table_info ("TableName");
compiles with UTF-16 sqlite3_prepare16, but calling sqlite3_step next returns SQLITE_DONE instead of SQLITE_ROW even though the table is present in the database. There seems to be no problems with ANSI sqlite3_prepare. |
2006-Jan-13 01:25:20 by drh:
Works fine when I try it.
2006-Jan-13 02:20:16 by anonymous:
This is a result of a code change in prepare16 between version 3.2.8 and the 3.3.0 alpha. 3.2.8 converted the utf16 to utf8 with this code:
pTmp = sqlite3GetTransientValue(db);
sqlite3ValueSetStr(pTmp, -1, zSql, SQLITE_UTF16NATIVE, SQLITE_STATIC);
zSql8 = sqlite3ValueText(pTmp, SQLITE_UTF8);
3.3.0 uses:
zSql8 = sqlite3utf16to8(zSql, nBytes);
The problem is that many people are/were passing the length of the UTF16 string in characters instead of bytes. It worked (even if it was wrong) in previous versions, but now it doesn't.
2006-Jan-13 09:40:51 by anonymous:
Thanks for pointing out the important difference between characters and bytes in UTF-16 mode! I was indeed one of those who passed the wrong length, and it always worked because previous versions apparently payed no attention to the length parameter. I remember that this subject came up on the mailing list some time ago. Fortunately, this appears to be fixed with 3.3.0. Looking forward to adapting my code ... |
|
1602 |
code
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
4
|
5
|
likely typo in shell.c
|
edit |
shell.c, line 834, function resolve_backslashes():
The statement
c =- '0';
should be perhaps
c -= '0'; |
Duplicate of #1575. Already fixed. |
|
1599 |
doc
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
5
|
5
|
Typo in FAQ not quite fixed
|
edit |
[2912]
changed "leter let you puts," which had two typos, into "later let you puts" which has only one :) |
|
1595 |
doc
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
4
|
1
|
tcl-devel is required to build. This requirement is not listed
|
edit |
tcl-devel is an unlisted prerequisite |
2006-Jan-10 17:33:29 by drh:
TCL is required to build the TCL langauge bindings and to
run the regression tests. It is not required to build the
SQLite library. |
|
1594 |
code
|
closed
|
2006 Jan
|
anonymous
|
BTree
|
2006 Jan
|
danielk1977
|
2
|
2
|
Schema pointer is freed twice
|
edit |
Introduced in checkin #2859 ?
btree.c
@@ -1556,6 +1719,9 @@
/* Close the pager and free the shared-btree structure */
assert( !pBt->pCursor );
sqlite3pager_close(pBt->pPager);
+ if( pBt->xFreeSchema && pBt->pSchema ){
+ pBt->xFreeSchema(pBt->pSchema);
+ }
During sqlite3_close() the above function is called which frees the schema. Afterwards, in build.c, sqlite3ResetInternalSchema() is called which attempts to free the same schema pointer again. The pointers inside are often no longer valid so it results in a fault. |
|
1592 |
code
|
closed
|
2006 Jan
|
anonymous
|
Unknown
|
2006 Mar
|
|
1
|
2
|
[patch] fixes for mbcs in os_win.c
|
edit |
The recent changes in os_win.c were definitely a step in the right direction for support of non-ASCII file names.
However, there's still a problem under the following conditions:
- you are running on a Win9x system
- the system locale is not English, but something that uses a lot of multibyte characters (e.g. Japanese).
With the current code, a file name with a multibyte character in it cannot be opened. The UTF-8 filename that is passed via sqlite3_open (or indirectly via sqlite3_open16) is passed directly to the xxxA() functions of Win32. However, the Ansi APIs expect a string encoded with the current codepage.
To fix this, the UTF-8 strings have to be converted to mbcs before being passed to the xxxA() functions.
The patch appended to this ticket does exactly this. Now multibyte characters are fully supported on Win32. |
2006-Mar-25 16:15:05 by drh:
Issues:
- I have no way to test any of this
- The patch is huge (492 lines) and basically rewrites large
sections of os_win.c
- I do not know the author of the patch.
- The author of the patch does not have a copyright release on file.
- The author appears to live in Germany which is a country (I am
told) that does not recognize the public domain. Hence
German citizens are prohibited from contributing code to SQLite.
For these reasons, I cannot directly apply this patch. But if
someone can make a case that this really is an issue that needs
to be addressed and can suggest less radical changes, I will be
attentive. |
|
1582 |
code
|
closed
|
2006 Jan
|
anonymous
|
Shell
|
2006 Jan
|
anonymous
|
1
|
1
|
the sqlite328.exe generates Application error -memory cold not be read
|
edit |
both DLL (sqlite3_exec())and EXE generates application error "memory cold not be read" (the type of error for the dll depends on the compiler) in case of wrong query (a missed table is used).
scenario:(under WIN XP)
the database contains:
CREATE TABLE logs(msg TEXT, timestamp INTEGER, dbtime TEXT);
and when i apply:
SELECT * FROM logs WHERE logs.id >= (SELECT head FROM logs_base)
UNION ALL SELECT * FROM logs LIMIT (SELECT lmt FROM logs_base) ;
(the table "logs_base" is omit)
... the application error is generated (instead of warning for the shell and errorcode for DLL). |
|
1581 |
code
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
4
|
3
|
incompatible pointer types lead to compilation errors
|
edit |
When compiling SqLite 3.2.8 on MacOSX using CodeWarrior 9.x a couple of files cannot be compiled because of implicit pointer conversions
Example: file alter.c line 445
sqlite3StrNDup_ is defined as: char sqlite3StrNDup_(const char, int,char*,int);
But in alter.c line 445 pColDef->z is used as the first argument which is not a const char*.
Hartwig |
2006-Jan-04 23:50:58 by drh:
That would be a bug in CodeWarrior, not in SQLite. In ANSI C, a
function that takes const char* should also be able to accept a
char* argument. Going the other way is a problem: A
function that takes char* should not be able to accept a const char*
argument. But the way that SQLite is doing it here is correct. |
|
1580 |
code
|
closed
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
4
|
2
|
3.2.8 does not compile under Solaris 10
|
edit |
After running
./configure --enable-threadsafe
make
in the base directory, compilation stops and complains of the unresolved symbol fdatasync.
Looking at the man page for fdatasync(), it seems like -lrt is needed as an extra library for fdatasync() to be available.
Adding -lrt to the list of libraries to link agains solves the problem. |
2006-Jan-04 12:28:26 by drh:
Duplicate of #1467. Already fixed. |
|
1579 |
code
|
closed
|
2006 Jan
|
anonymous
|
Shell
|
2006 Jan
|
anonymous
|
1
|
1
|
database locked
|
edit |
I'm using JSP to connect sqlite and it works fine.but in the middle the database gets locked.Can you tell me at what instances the database gets locked. |
2006-Jan-02 12:47:42 by drh:
That would be a question for the mailing list. Tickets are
for reporting bugs. |
|
1574 |
event
|
closed
|
2005 Dec
|
anonymous
|
Shell
|
2005 Dec
|
|
1
|
3
|
corrupt database due to .dump process
|
edit |
/*problem with sqlite shell .dump*/
/*sinario*/
create table t1 (f);
create table t2 (f_id,g);
/*triggers to validate foreign key constraints are not included here*/
insert into t1 (f) values ('bob'); /*record 1*/
insert into t1 (f) values ('jo'); /*record 2*/
insert into t1 (f) values ('peter'); /*record 3*/
insert into t1 (f) values ('smith'); /*record 4*/
delete from t1 where f='bob'; /*remove record 1*/
insert into t2 (f_id,g) values ((select rowid from t1 where f='smith'),'sara');
insert into t2 (f_id,g) values ((select rowid from t1 where f='jo'),'mat');
/*viewing the contents of the database*/
> select rowid,* from t1;
rowid | f
2 | 'jo'
3 | 'peter'
4 | 'smith'
> select rowid,* from t2;
rowid | f_id | g
1 | 4 | 'Sara'
2 | 2 | 'Mat'
/*so far, consistent database*/
/*dumping the database gives*/
create table t1 (f);
create table t2 (f_id,g);
insert into t1 (f) values ('jo'); /*old record 2, but record 1 now*/
insert into t1 (f) values ('peter'); /*old record 3, but record 2 now*/
insert into t1 (f) values ('smith'); /*old record 4* but record 3 now/
insert into t2 (f_id,g) values (4,'sara'); /*should be illegal, caught by the trigger and not inserted*/
insert into t2 (f_id,g) values (2,'mat'); /* thats now refering to the wrong person, jo is now number 1 not number 2*/
/*conclusion*/
/*a valid database has now been corrupted due to our dumping procedure
*1 record was not inserted due to our foreign key constraint,
*and one record has been corrupted because it is refering to a different record than the intended one.
*proposed solution:
*the dump statements should include the rowid, so that when the information is inserted into
*the new database, the links will still be valid
*if i'm not too mistaken, this problem will occur with auto-incremented keys too
*(afterall rowid is just a such field)*/
/*Hope this example clarifies the issue i'm trying to illustrate.*/ |
This is not a problem with SQLite but a case of SQLite being
misused. The "rowid" column is not included with a ".dump" by
design. If you want the equivalent of a rowid to be visible
to ".dump" then use an INTEGER PRIMARY KEY. |
|
1571 |
code
|
closed
|
2005 Dec
|
anonymous
|
|
2005 Dec
|
|
1
|
1
|
SQLiteCC crashes when you rollback create table
|
edit |
I started a transaction and then created a table 'test' in SQliteCC v0.06 (i have SQLite3.exe v3.0.8). It appeared in the table-list. Nothing wrong there.
When i execute a 'rollback transaction' command the table remains in the list. When i select the table in the list, SQLiteCC crashes. This seems to happen every time i rollback a 'create table' statement and select the (no longer created) table. |
SQLiteCC is an independent project located on a different
website. http://bobmanc.home.comcast.net/sqlitecc.html |
|
1568 |
code
|
closed
|
2005 Dec
|
anonymous
|
Unknown
|
2006 Mar
|
|
1
|
1
|
sqlite3_column_decltype( ) returning BadPointer with "UNION"
|
edit |
I am using VC++7 as building and given below the code piece in brief that is creating problem
char DBName[] = "D:\\MySQLiteDatabase.db";
sqlite3* pDB;
sqlite3_open(DBName, &pDB);
sqlite3_stmt* pstmt;
sqlite3_prepare(pDB, "Select NAME From tblEmp UNION Select NAME From tblEmp", -1, &pstmt, NULL);
int iColCount = sqlite3_column_count(pstmt);
const char* pColName;
pColName = sqlite3_column_name(pstmt, 0);
const char* pColType = sqlite3_column_decltype(pstmt, 0);
sqlite3_finalize(pstmt);
sqlite3_close(pDB);
The given SQL is just a example only. The "NAME" column is of VARCHAR type. Each and every line is executing fine, except sqlite3_column_decltype( ) one. It is returning bad pointer (0x00000) for UNION type SQL, but returning column type for other SQLs including "UNION ALL". In our application we have query for each column type.
Please treat it urgent and give me some useful tips. Is that a bug?
Regards,
Pradip
Email: pradipkumardas@hotmail.com
Phone: +91 (0657) 5573240 (Office) |
2006-Mar-03 21:15:09 by drh:
sqlite3_column_name() returns NULL when it does not know the name
of the column. Works as designed and documented. |
|
1563 |
code
|
closed
|
2005 Dec
|
anonymous
|
|
2006 Mar
|
|
1
|
1
|
The system crash when creating a database!
|
edit |
in file os_win.c,there is a function: utf8ToUnicode. It seem that the function is error. There is a Call for MultiByteToWideChar, with the code page parameter "CP_UTF8". In fact, our os code page is usually "CP_ACP". So the function return an error result.
We are in China, and the os is win2000/2003, the codepage is 936 or 950. |
2005-Dec-16 07:44:50 by anonymous:
error: When calling sqlite3_open to open or create a database,if the path of the database is Chinese, the function will return a "file cannot open" error. Cause that sqlite looks on the path string as a UTF-8 string.
Our Modify:
1. os_win.c sqlite3OsFullPathname function
commented: Ln813 //zWide = utf8ToUnicode(zRelative);
added: zWide = NULL;
focus: Don't translate it.The system will do with it well.
2. os_win.c utf8ToUnicode function
Modified Ln 90:
nByte = MultiByteToWideChar(CP_UTF8, 0, zFilename, -1, NULL, 0)*sizeof(WCHAR);
To:
nByte = MultiByteToWideChar(CP_ACP, 0, zFilename, -1, NULL, 0)*sizeof(WCHAR);
Modified Ln 95:
using the same modify above.
2005-Dec-16 11:57:26 by anonymous:
This appears to be a duplicate of #1499.
2006-Mar-25 16:20:47 by drh:
sqlite3_open() must be called with a UTF-8 filename, not a CP_ACP
codepage string. |
|
1561 |
build
|
closed
|
2005 Dec
|
anonymous
|
|
2005 Dec
|
|
3
|
1
|
compile sqlite 3.2.7 failed on Unix
|
edit |
config passed. and then:
bash-2.05$ make
sed -e s/--VERS--/3.2.7/ ./src/sqlite.h.in | \
sed -e s/--VERSION-NUMBER--/3002007/ >sqlite3.h
gcc -g -O2 -o lemon ./tool/lemon.c
cp ./tool/lempar.c .
cp ./src/parse.y .
./lemon -DSQLITE_OMIT_CURSOR parse.y
cat parse.h ./src/vdbe.c | awk -f ./mkopcodeh.awk >opcodes.h
awk: syntax error near line 36
awk: illegal statement near line 36
awk: syntax error near line 37
awk: illegal statement near line 37
awk: syntax error near line 42
awk: illegal statement near line 42
awk: syntax error near line 103
awk: illegal statement near line 103
*** Error code 2
make: Fatal error: Command failed for target `opcodes.h' |
2005-Dec-14 19:24:31 by drh:
Dup of ticket #1161 |
|
1560 |
code
|
closed
|
2005 Dec
|
anonymous
|
Unknown
|
2005 Dec
|
|
4
|
4
|
"make test" fails in conflict-6.2, conflict-6.3, and -6.7 upto -6.13
|
edit |
System: Ubuntu Linux 5.04 (i386)
Pentium-III 1.0GHz, 256MB RAM
gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2)
Tcl version 8.4
Running "make test" on this system results in several errors
in the conflict-6.x tests:
conflict-6.1... Ok
conflict-6.2...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
conflict-6.3...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.4... Ok
conflict-6.5... Ok
conflict-6.6... Ok
conflict-6.7...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.8...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
conflict-6.9...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.10...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
conflict-6.11...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.12...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.13...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
conflict-6.14... Ok
[...]
9 errors out of 21665 tests
Failures on these tests: conflict-6.2 conflict-6.3 conflict-6.7 conflict-6.8 conflict-6.9 conflict-6.10 conflict-6.11 conflict-6.12 conflict-6.13
make: *** [test] Error 1
If I interpret the Tcl script correctly, this is only a minor glitch,
as it complains that the test should have created a temporary file but in fact didn't. |
Duplicate of ticket #1453. Already fixed. |
|
1559 |
new
|
closed
|
2005 Dec
|
anonymous
|
Unknown
|
2005 Dec
|
|
4
|
4
|
SQLite file is corrupt
|
edit |
When a sqlite file has been currupted (e.g file was truncated during a file transmission like HTTP POST), there is no way to detect this, as sqlite3_open() may succeed.. A VACCUM may be a solution but unfortunately, this requires to write to the file.
A way to (quick) ANALYIZE a sqlite3 file may be more than appreciated.
Christian |
2005-Dec-14 11:14:05 by anonymous:
You have a pragma command that does this: http://www.sqlite.org/pragma.html
PRAGMA integrity_check;
The command does an integrity check of the entire database. It looks for out-of-order records, missing pages, malformed records, and corrupt indices. If any problems are found, then a single string is returned which is a description of all problems. If everything is in order, "ok" is returned. |
|
1557 |
event
|
closed
|
2005 Dec
|
anonymous
|
Parser
|
2006 Mar
|
|
1
|
1
|
sqlite core dumps in exprNodeIsConstant
|
edit |
Solaris 8.0, Sun C++ 5.6, SQLite 3.2.2 (multi-threaded)
Stack trace follows:
core 'core' of 7235:
----------------- lwp# 3 / thread# 7 --------------------
ff2b5ad4 exprNodeIsConstant (fda0b4c0, 70, 109b60, 7bf260, 63, ff307450) + 4c
ff2b57cc walkExprTree (70, ff2b5a88, fda0b4c0, 0, 0, 27) + 3c
ff2b5938 walkExprList (7b6d08, ff2b5a88, fda0b4c0, fe3fc000, fda0ba29, 10dbf4) + 68
ff2b5870 walkExprTree (7b5f68, ff2b5a88, fda0b4c0, b, 313fc, ff3ba3c0) + e0
ff2b5800 walkExprTree (7b6d08, ff2b5a88, fda0b4c0, 0, fda0ba30, b) + 70
ff2b5800 walkExprTree (7b5f70, ff2b5a88, fda0b4c0, ff2e5894, 0, 0) + 70
ff2b5bd4 sqlite3ExprIsConstant (7b5f70, 7b50f0, 8, 2, 1, 0) + 44
ff2b7f60 sqlite3ExprCode (fda0b898, 7bf188, 0, 0, ff31b4e0, 109b69) + 708
ff2e5208 sqlite3Update (17, 109b18, 109b60, 7bf260, 63, ff307450) + 1258
ff2cd9e0 yy_reduce (7be9a0, 9e, 83, fda0b794, 3144c, 0) + 11e0
ff2cfa48 sqlite3Parser (7be9a0, a, fda0b800, fda0b898, 3f, fec26ae8) + 168
ff2e10bc sqlite3RunParser (fda0b898, fda0b9f8, fda0b894, fffffff8, 0, fda0b94d) + 394
ff2d3810 sqlite3_prepare (10a590, fda0b9f8, ffffffff, fda0bd28, 0, 0) + c0
feb9ea88 __1cKECSddStoreGupdate6MrnKECSQdDLiteDB_rnDSdd__v_ (fec45cf8, fda0bd20, 7b7400, fec45c98, 3000, fec45c80) + 7b8
feb9d4fc sdd_read_thread (0, fec45d30, ffffffff, 7b7400, fec45cc0, 1) + f48
fe3eb01c _thread_start (fec45cf8, 0, 0, 0, 0, 0) + 40
Another more detailed stack trace:
t@7 (l@3) terminated by signal SEGV (no mapping at the fault address)
Current function is nameResolverStep
1039 if( ExprHasAnyProperty(pExpr, EP_Resolved) ) return 1;
(dbx 1) where
current thread: t@7
=>[1] nameResolverStep(pArg = 0xfda0b5ec, pExpr = 0x70), line 1039 in "expr.c"
[2] walkExprTree(pExpr = 0x70, xFunc = 0xff2b6a48 = &`libsqlite3.so.0`expr.c`nameResolverStep(void *pArg, struct Expr *pExpr), pArg = 0xfda0b5ec), line 615 in "expr.c"
[3] walkExprList(p = 0x675610, xFunc = 0xff2b6a48 = &`libsqlite3.so.0`expr.c`nameResolverStep(void *pArg, struct Expr *pExpr), pArg = 0xfda0b5ec), line 632 in "expr.c"
[4] walkExprTree(pExpr = 0x67c538, xFunc = 0xff2b6a48 = &`libsqlite3.so.0`expr.c`nameResolverStep(void *pArg, struct Expr *pExpr), pArg = 0xfda0b5ec), line 619 in "expr.c"
[5] nameResolverStep(pArg = 0xfda0b5ec, pExpr = 0x685df0), line 1136 in "expr.c"
[6] walkExprTree(pExpr = 0x685df0, xFunc = 0xff2b6a48 = &`libsqlite3.so.0`expr.c`nameResolverStep(void *pArg, struct Expr *pExpr), pArg = 0xfda0b5ec), line 615 in "expr.c"
[7] sqlite3ExprResolveNames(pNC = 0xfda0b5ec, pExpr = 0x685df0), line 1188 in "expr.c"
[8] sqlite3Update(pParse = 0xfda0b898, pTabList = 0x67a4f0, pChanges = 0x67a2c0, pWhere = 0x685ec8, onError = 99), line 165 in "update.c"
[9] yy_reduce(yypParser = 0x6855c0, yyruleno = 158), line 549 in "parse.y"
[10] sqlite3Parser(yyp = 0x6855c0, yymajor = 10, yyminor = RECORD, pParse = 0xfda0b898), line 3270 in "parse.c"
[11] sqlite3RunParser(pParse = 0xfda0b898, zSql = 0xfda0b9f8 "UPDATE SDDSTORE SET SDD = ?, TIMESTAMP = DATETIME('NOW','LOCALTIME') WHERE ECORDERID = ?", pzErrMsg = 0xfda0b894), line 399 in "tokenize.c"
[12] sqlite3_prepare(db = 0x10a590, zSql = 0xfda0b9f8 "UPDATE SDDSTORE SET SDD = ?, TIMESTAMP = DATETIME('NOW','LOCALTIME') WHERE ECORDERID = ?", nBytes = -1, ppStmt = 0xfda0bd28, pzTail = (nil)), line 435 in "prepare.c"
[13] 0xfeb9ea88(0xfec45cf8, 0xfda0bd20, 0x67f0f0, 0xfec45c98, 0x3000, 0xfec45c80), at 0xfeb9ea87
[14] 0xfeb9d4fc(0x0, 0xfec45d30, 0xffffffff, 0x67f0f0, 0xfec45cc0, 0x1), at 0xfeb9d4fb
The schema when this occurs is:
CREATE TABLE AMENDS (KEY VARCHAR PRIMARY KEY, VALUE INTEGER);
CREATE TABLE EXECID (KEY VARCHAR PRIMARY KEY, VALUE INTEGER);
CREATE TABLE PERSISTEDID (NAME VARCHAR, VALUE VARCHAR);
CREATE TABLE QUOTES (KEY VARCHAR PRIMARY KEY, VALUE INTEGER);
CREATE TABLE SDDSTORE (ECORDERID VARCHAR PRIMARY KEY, TIMESTAMP DATE, SDD BLOB);
The statement being prepared with sqlite3_prepare is:
"UPDATE SDDSTORE SET SDD = ?, TIMESTAMP = DATETIME('NOW','LOCALTIME') WHERE ECORDERID = ?"
|
No other reports of this and unable to reproduce.
2006-Mar-04 14:57:57 by anonymous:
This was previously fixed. I've detected this bug in Win32 version and it's already fixed.
2006-Apr-03 12:42:47 by anonymous:
This was actually caused by heap corruption prior to the sqlite api invocation. |
|
1556 |
event
|
closed
|
2005 Dec
|
anonymous
|
Unknown
|
2005 Dec
|
anonymous
|
1
|
1
|
database locked if used on mounted nfs shares (linux)
|
edit |
gentoo linux, ebuild sqlite-3.2.7:
The FAQ states:
"SQLite uses reader/writer locks to control access to the database. [...] But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. [...] You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time."
This seems to indicate that it could work, but that there's no guarantee. In my case, the database is ALWAYS locked (even if there is only one process accessing it) -- which is kind of a drawback since our network is NFS based ...
Mounted NFS share:
$> sqlite3 -init foo.sql db
Loading resources from foo.sql
CREATE TABLE loci (locus integer primary key, type integer, name varchar(20));
SQL error: database is locked <----------
SQLite version 3.2.7
Enter ".help" for instructions
sqlite> .tables
Error: database is locked <----------
sqlite>
The very same within a local directory:
$> sqlite3 -init foo.sql /tmp/db
Loading resources from foo.sql
SQLite version 3.2.7
Enter ".help" for instructions
sqlite> .tables
loci
sqlite>
Where foo.sql reads:
BEGIN TRANSACTION;
CREATE TABLE loci (locus integer primary key,name varchar(20));
COMMIT;
Any chance to work around this problem? My development just grinded to halt since the database was meant to be used/shared over NFS ... |
2005-Dec-07 14:27:26 by drh:
This is a bug in either Gentoo linux or in your setup. SQLite is
using the fcntl(F_SETLK) interface and linux is telling SQLite that
the file is already locked. Not much SQLite can do about this.
In version 3.3.0 (or perhaps in a release soon to follow that) we
will be offering a version of SQLite that uses lockfiles rather than
fcntl() to control file access. There are disadvantages to the use
of filelocks: slower, courser grain access, and stale lockfiles
that must be manually deleted following a program crash. But
lockfiles will work on network filesystems.
2005-Dec-07 16:20:21 by anonymous:
I submitted this ticket:
It is not a bug in gentoo. Same behaviour on boxes running different versions of SuSE (static build of my binary, executed on different hosts within the same NFS share).
2005-Dec-08 10:56:01 by anonymous:
After realizing that it doesn't mean much if I tranfer a static build from gentoo to SuSE, I rebuild my project from scratch on a SuSE box (sqlite-3.2.7). Again, the results are the same: "database locked". Since the NFS is up for about three years, it is hard to assume that there's a config error left?! Any hints are highly appreciated!
Regards
2005-Dec-08 13:14:24 by anonymous:
Please close this ticket.
The solution: I hadn't had nfs-utils installed. After merging those and starting rpc.statd, everythings works as expected.
Sorry for the fuss. |
|
1553 |
new
|
closed
|
2005 Dec
|
anonymous
|
|
2006 Mar
|
|
5
|
4
|
API suggestion: sqlite3_has_more_rows()
|
edit |
How about:
int sqlite3_has_more_rows( sqlite3_stmt * );
returns 0 or 1.
???
This would simplify the creation of C++ iterators for walking result sets. i currently don't know how to check this in an iterator implementation without always doing a call to sqlite3_step(). |
2005-Dec-03 17:59:50 by drh:
SQLite itself has no way of knowing if there are more rows. So it
is not clear how such an API could be created. |
|
1551 |
code
|
closed
|
2005 Dec
|
anonymous
|
|
2005 Dec
|
|
1
|
1
|
sqlite3_reset seems not to be exported correctly
|
edit |
compiling a program that contains sqlite3_reset command, I get the linker error:
unresolved external _sqlite3_reset
all the others command work correctly |
2005-Dec-02 15:04:06 by drh:
The bug report does not specify the SQLite version, the compiler
being used, or the operating system and development environment
on which the problem occurs. Nobody else is having this problem
and I cannot reproduce it. So there is not much I can do with
this ticket.
2005-Dec-02 15:12:23 by anonymous:
Sorry for me not to have completely reported the problem.
dll version: 3.2.7
operating system: windows xp
Borland C++ builder.
I've generated the lib files with
implib -a -f sqlite3 sqlite3.dll
generating the .lib file with
implib -a -f sqlite3 sqlite3.def,
none of the functions are linked
2005-Dec-02 17:04:02 by anonymous:
I have encountered the same problem.
impdef -a sqlite3.def sqlite3.dll
implib sqlite3.lib sqlite3.def
2005-Dec-02 17:08:15 by anonymous:
Sorry for the premature posting earlier.
I encountered the same problem. I'm pretty sure it is a bug in the Borland implib command. There is a fairly simple workaround though.
Instead of:
implib -a sqlite3.lib sqlite3.dll
use the following two commnads:
impdef -a sqlite3.def sqlite3.dll
implib sqlite3.lib sqlite3.def
I'm not sure why only the sqlite3_reset function is affected, but this fixed things for me. This fix is already included in the sqlite Makefile. |
|
1548 |
warn
|
closed
|
2005 Dec
|
|
|
2005 Dec
|
|
1
|
1
|
Command failed for target `sqlite3'
|
edit |
gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -I/usr/local/include -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -DHAVE_READLINE=0 -o .libs/sqlite3 ./src/shell.c ./.libs/libsqlite3.so -lncurses -R/usr/local/lib
Undefined first referenced
symbol in file
fdatasync ./.libs/libsqlite3.so
ld: fatal: Symbol referencing errors. No output written to .libs/sqlite3
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `sqlite3' |
Duplicate of #1467. Already fixed. See [2741]
|
|
1545 |
build
|
closed
|
2005 Nov
|
anonymous
|
Shell
|
2007 Feb
|
|
4
|
4
|
Solaris systems require -lrt to link sqlite3
|
edit |
sqlite3 fails to build on solaris 8 with a link error. The name fdatasync is not found. This is because on solaris systems fdatasync requires a -lrt switch on the link command, because the name is declared in librt.so while on linux it's in libc.so |
2005-Dec-28 00:22:56 by anonymous:
I ran in to the same problem on Solaris 8 with version 3.2.8. I have a patch to configure.ac and Makefile.in that fixed the problem, but I'm not sure how best to submit them.
You can contact me via email if you want the patch.
Thanks,
Tim Mooney
Tim.Mooney@ndsu.edu
2005-Dec-28 01:01:27 by anonymous:
Use the "Attach" link above to attach your patch to this ticket.
Here's a direct link to do the same.
2007-Feb-17 14:56:09 by vapier:
this should be fixed in current cvs:
AC_SEARCH_LIBS(fdatasync, [rt]) |
|
1540 |
code
|
closed
|
2005 Nov
|
anonymous
|
Unknown
|
2005 Nov
|
|
2
|
3
|
Failure to create a primary key
|
edit |
The following script does NOT create a primary key.
CREATE TABLE TestTable
(TestField1 INTEGER PRIMARY KEY,
TestField2 VARCHAR)
However, the next one does.
CREATE TABLE TestTable
(TestField1 INTEGER PRIMARY KEY,
TestField2 VARCHAR UNIQUE) |
2005-Nov-28 22:14:10 by drh:
Unable to reproduce.
2005-Nov-29 01:04:06 by anonymous:
When you said 'unable to reproduce' did you mean on Windows or Linux? I am using version 3.2.7 on Windows and it fails to create a primary key.
2005-Nov-29 01:23:20 by drh:
Please bring up the issue on the mailing list if you need more help.
2005-Nov-29 10:02:38 by anonymous:
integer primary key doesn't create a index... it uses the rowid (row unique identifier, which is a integer 64-bit) as the primary key... the automatic index created in the second statement is for the UNIQUE clause |
|
1539 |
code
|
closed
|
2005 Nov
|
anonymous
|
|
2006 Mar
|
|
4
|
4
|
sqlite3Realloc is a trap for the unwary
|
edit |
(I realize this is probably going to sound less like a bug report and more like the ravings of a crackpot, but as I was just bitten by this I thought I should file a bug report. I'd suggest reading it quickly, and deleting it if it doesn't seem like a useful change.)
sqlite3Realloc() has a dual personality: if called with a size arg n of 0, it delegates to sqlite3Malloc() which sets the allocated memory to zero, but if called with n > 0, it calls realloc() directly which does not zero the memory. In one sense this behaviour makes sense, because unless provided with more information realloc doesn't know the size of the original allocation, but in another sense it's misleading because having the allocation zeroed in the initial call creates code that works until a reallocation is necessary.
Solution 1: rename sqlite3Realloc() to sqlite3ReallocRaw(), and have it call sqlite3ReallocRaw for the initial allocation. For if the caller is already setting the memory to zero, having sqlite3Realloc() sometimes do it for you is superfluous work; and if the caller is not setting the memory to zero, having it done automatically is either unnecessary or potentially masking bugs that will occur only when a reallocation is done.
Solution 2: change sqlite3Realloc() to accept three arguments:
sqlite3Realloc(ptr, old_size, new_size) and have it zero the memory between old_size and new_size if new_size is greater. This would produce greater symmetry with sqliteMalloc(), and be less hazardous to the unwary. If desired, also create a parallel function sqlite3ReallocRaw() as described above. |
2005-Nov-28 17:29:05 by drh:
One wonders what mischief you were up to when you encountered this
problem. ;-)
2006-Mar-25 16:40:05 by drh:
As goofy as the behavior of sqliteRealloc() seems, there is actually
a good reason for it. We sometimes want to use sqliteRealloc()
allocate or reallocate a structure with an array appended. After
each call to sqliteRealloc() we zero out the new parts of the array.
But the structure itself is never zeroed. We depend on
sqliteRealloc() to zero the initial allocation for us.
See sqlite3_set_auxdata() as an example. |
|
1538 |
code
|
closed
|
2005 Nov
|
anonymous
|
|
2005 Nov
|
|
1
|
1
|
Access Violation error
|
edit |
I get an Access violation error when the pair sqllite3_open and sqlite3_close functions are caled by two different functions.
The code
void ppp (void) {
sqlite3 *db;
sqlite3_open(dbname.c_str(), &db);
sqlite3_close(db);
}
works well
this code doesn't work:
sqlite3 *db;
void f1(void) {
sqlite3_open(dbname.c_str(), &db);
}
void f2 (void) {
sqlite3_close(db);
}
void ppp (void){
f1();
f2();
}
the error is:
access violatione at address xxx read of address 000000000
I'm working with c++ builder 6 |
2005-Nov-28 13:52:50 by drh:
Unable to reproduce.
2005-Nov-28 21:26:06 by anonymous:
There was a problem generating the .lib file from the .def
Passing to implib the .dll file, seems to be working.
The only problem now is the _sqlite3_reset function seems not to be exported:
I get the linker error: unresolved external '_sqlite3_reset' referenced from...
all the others functions I'm using are correctly linked. |
|
1535 |
code
|
closed
|
2005 Nov
|
anonymous
|
Unknown
|
2005 Nov
|
|
2
|
3
|
Segmentation fault on query
|
edit |
create table test (a);
select count(a) as b from test where b>1;
Segmentation fault occurs. |
2005-Nov-23 15:57:59 by drh:
Already fixed. See ticket #1514. |
|
1534 |
code
|
closed
|
2005 Nov
|
anonymous
|
|
2005 Nov
|
|
1
|
1
|
error:
|
edit |
create table user(ID,name,sex,bday,priv);
insert into user(ID,name,sex,bday,priv) values(01,300,400,1997-2-2,4);
insert into user(ID,name,sex,bday,priv) values(01,300,400,1999-2-2,4);
select * from user;
the result as below:
1|300|400|1993|4
1|300|400|1995|4 |
2005-Nov-22 14:10:15 by anonymous:
Not an error. Since those date "values" are unquoted, they're treated as expressions; the -s are interpreted as subtraction operators. |
|
1531 |
code
|
closed
|
2005 Nov
|
anonymous
|
|
2005 Nov
|
|
4
|
3
|
Crash when evaluating SELECT ... HAVING NOT EXISTS
|
edit |
I came across a segfault in SQLite while running the query:
SELECT a, COUNT(*) AS frequency
FROM test
GROUP BY a
HAVING NOT EXISTS
(SELECT COUNT(*) AS f2
FROM test
WHERE f2 > frequency GROUP BY a);
I'm aware that this is probably broken SQL, but I'd expect it to give a parse error rather than a segfault.
System is
Linux timm 2.6.8-24-smp #1 SMP Wed Oct 6 09:16:23 UTC 2004 i686 i686 i386 GNU/Linux
SQLite 3.2.7 compiled from source with
gcc (GCC) 3.3.4 (pre 3.3.5 20040809)
I've attached the output of a sample run in valgrind.
==15153== Memcheck, a memory error detector.
==15153== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==15153== Using LibVEX rev 1313, a library for dynamic binary translation.
==15153== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==15153== Using valgrind-3.0.0, a dynamic binary instrumentation framework.
==15153== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==15153== For more details, rerun with: -v
==15153==
--15153-- DWARF2 CFI reader: unhandled CFI instruction 0:50
--15153-- DWARF2 CFI reader: unhandled CFI instruction 0:50
SQLite version 3.2.7
Enter ".help" for instructions
sqlite> CREATE TABLE test (a INTEGER NOT NULL, b INTEGER NOT NULL);
sqlite> INSERT INTO test VALUES (1, 1);
sqlite> INSERT INTO test VALUES (2, 1);
sqlite> INSERT INTO test VALUES (2, 2);
sqlite> INSERT INTO test VALUES (3, 2);
sqlite> SELECT a, COUNT(*) AS frequency FROM test GROUP BY a HAVING NOT EXISTS (SELECT COUNT(*) AS f2 FROM test WHERE f2 > frequency GROUP BY a);
==15153== Invalid read of size 4
==15153== at 0x1B93CF93: sqlite3ExprCode (expr.c:1618)
==15153== by 0x1B93CCDC: sqlite3ExprCode (expr.c:1707)
==15153== by 0x1B93D5C2: sqlite3ExprIfFalse (expr.c:1986)
==15153== by 0x1B963252: sqlite3WhereBegin (where.c:1871)
==15153== by 0x1B951261: sqlite3Select (select.c:2964)
==15153== by 0x1B93D977: sqlite3CodeSubselect (expr.c:1407)
==15153== by 0x1B93CBE2: sqlite3ExprCode (expr.c:1655)
==15153== by 0x1B93D35B: sqlite3ExprIfTrue (expr.c:1912)
==15153== by 0x1B93D6F1: sqlite3ExprIfFalse (expr.c:1977)
==15153== by 0x1B951188: sqlite3Select (select.c:2940)
==15153== by 0x1B948C09: sqlite3Parser (parse.y:365)
==15153== by 0x1B953827: sqlite3RunParser (tokenize.c:388)
==15153== Address 0x20 is not stack'd, malloc'd or (recently) free'd
==15153==
==15153== Process terminating with default action of signal 11 (SIGSEGV)
==15153== Access not within mapped region at address 0x20
==15153== at 0x1B93CF93: sqlite3ExprCode (expr.c:1618)
==15153== by 0x1B93CCDC: sqlite3ExprCode (expr.c:1707)
==15153== by 0x1B93D5C2: sqlite3ExprIfFalse (expr.c:1986)
==15153== by 0x1B963252: sqlite3WhereBegin (where.c:1871)
==15153== by 0x1B951261: sqlite3Select (select.c:2964)
==15153== by 0x1B93D977: sqlite3CodeSubselect (expr.c:1407)
==15153== by 0x1B93CBE2: sqlite3ExprCode (expr.c:1655)
==15153== by 0x1B93D35B: sqlite3ExprIfTrue (expr.c:1912)
==15153== by 0x1B93D6F1: sqlite3ExprIfFalse (expr.c:1977)
==15153== by 0x1B951188: sqlite3Select (select.c:2940)
==15153== by 0x1B948C09: sqlite3Parser (parse.y:365)
==15153== by 0x1B953827: sqlite3RunParser (tokenize.c:388)
==15153==
==15153== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 22 from 1)
==15153== malloc/free: in use at exit: 167005 bytes in 444 blocks.
==15153== malloc/free: 1087 allocs, 643 frees, 260270 bytes allocated.
==15153== For counts of detected errors, rerun with: -v
==15153== searching for pointers to 444 not-freed blocks.
==15153== checked 334640 bytes.
==15153==
==15153== LEAK SUMMARY:
==15153== definitely lost: 96 bytes in 6 blocks.
==15153== possibly lost: 0 bytes in 0 blocks.
==15153== still reachable: 166909 bytes in 438 blocks.
==15153== suppressed: 0 bytes in 0 blocks.
==15153== Use --leak-check=full to see details of leaked memory.
Segmentation fault
|
This appears to be a duplicate of ticket #1514, which has already
been fixed. |
|
1530 |
code
|
closed
|
2005 Nov
|
anonymous
|
Parser
|
2005 Nov
|
xdong
|
2
|
1
|
error on where clause with serial-type.
|
edit |
$ CREATE TABLE test ( idno serial unique, id varchar(32) primary key, cont text ); # OKAY!
# Inserted data:
# 0|purewell|hello, world!
# 1|3wish|hello, world!
$ SELECT * FROM test WHERE idno = 0;
or
$ SELECT * FROM test WHERE idno = '0';
No result. -_-); |
Works as designed. See the mailing list for help. |
|
1529 |
code
|
closed
|
2005 Nov
|
anonymous
|
|
2006 May
|
|
1
|
1
|
can not uses japanese as table name to create table
|
edit |
I am using the sqlite under japanese xp system. I want to create a
Japanese name table, below are two create sql script.
the First was create correctly, but second was failed.I do not know why.
, because the wiki can not display japanese correctly, I will append the sql as attachment.
Create TABLE お昼( F1 );(sucess)
Create TABLE カード( F1 );(failed)
by the way , I use the sqlite3 commandline utility to execute the sql.
|
2005-Nov-19 07:37:45 by anonymous:
sorry I can not find how to attach the sql to the ticket. how to do it?
2005-Nov-19 12:10:32 by anonymous:
Please use bracket quote.
CREATE TABLE [Card] (c);
2005-Nov-19 12:54:50 by anonymous:
looks like bracket does not work as expected?
Create TABLE [お昼]( F1 );(sucess)}
Create TABLE [カード]( F1 );(failed)
2005-Nov-20 00:39:29 by anonymous:
I'm japanse and using japanese w2k.
but i can't give you an advice any more because your information is too few. If you really wish to solve the problem, please write more in detail.
2005-Nov-20 04:47:21 by anonymous:
hi, thank you for your help.
my sqls are very simple
the first successful sql is
create table customer(the japanese spelling is torihikisaki) (F1);
the second failed sql is
create table card(the japansese spelling is ka-do) (F1);
2005-Nov-20 12:19:23 by anonymous:
Don't forget bracket quote.
I tried the sql statement in hiragana, katakata and hankaku by shiftjis, euc-jp and utf-8 encodings from interactive sqlite3 command shell and pipe connection. But I could not make the problem reappear at all. If you got a error message, you must write it. How did the sql fail?
2005-Nov-20 13:09:20 by anonymous:
Thank you very much for your help!
now I can create the table successfully
please close this ticket |
|
1526 |
new
|
closed
|
2005 Nov
|
anonymous
|
|
2005 Nov
|
|
1
|
1
|
Unused data structure fields when trace support is omitted.
|
edit |
When compiling with the option SQLITE_OMIT_TRACE defined, there are four fields in the "sqlite3" data structure which are not used.
Index: src/sqliteInt.h
===================================================================
RCS file: /sqlite/sqlite/src/sqliteInt.h,v
retrieving revision 1.428
diff -u -r1.428 sqliteInt.h
--- src/sqliteInt.h 14 Nov 2005 22:29:05 -0000 1.428
+++ src/sqliteInt.h 17 Nov 2005 23:59:45 -0000
@@ -429,10 +429,12 @@
} init;
struct Vdbe *pVdbe; /* List of active virtual machines */
int activeVdbeCnt; /* Number of vdbes currently executing */
+#ifndef SQLITE_OMIT_TRACE
void (*xTrace)(void*,const char*); /* Trace function */
void *pTraceArg; /* Argument to the trace function */
void (*xProfile)(void*,const char*,u64); /* Profiling function */
void *pProfileArg; /* Argument to profile function */
+#endif
void *pCommitArg; /* Argument to xCommitCallback() */
int (*xCommitCallback)(void*);/* Invoked at every commit. */
void(*xCollNeeded)(void*,sqlite3*,int eTextRep,const char*);
|
2005-Nov-18 13:12:30 by drh:
I am adverse to adding #ifdefs in places where they are not
absolutely necessary. And they do not seem necessary here.
The extra 16 bytes of memory used by each database connection
is not significant. |
|
1523 |
code
|
closed
|
2005 Nov
|
anonymous
|
Shell
|
2005 Nov
|
danielk1977
|
5
|
1
|
size of database dose not change smaller after delete records
|
edit |
Hi:
I use SQLite to create a database and create several tables in it, i check the size of the database and found it's only 3~4KB, then i insert 100,000 rows records into one of these tables, and i check the size of the database again found it grows upto 7~8MB, then i delete all of the records and check the size again, i found the size does not change smaller.
i do several experiments such as insert or delete operations, i found the size of database changed biger when records were added but kept the same when records were deleted even i drop the table, i don't why, i think this is a serious problem because i use SQLite to develop application program on PDA,
if the SQLite does not release memory when records are deleted it will eats up my flash.
i need your help!
BEST REGARDS! |
2005-Nov-14 10:49:12 by anonymous:
This is correct behaviour as described in the documentation.
2005-Nov-14 11:27:27 by anonymous:
VACCUM is your friend :-) |
|
1520 |
new
|
closed
|
2005 Nov
|
anonymous
|
|
2006 Jul
|
|
4
|
4
|
sqlite3_column_type do not work for empty table
|
edit |
for expty table can not resolve the type of the field. |
2006-Jul-18 07:14:38 by anonymous:
This is also the case for calling sqlite3_column_type on columns from a table that failed to join (such as with a LEFT JOIN). sqlite3_column_type() returns 0 for that column index.
2006-Jul-18 10:09:58 by drh:
sqlite3_column_type() returns the data type of a specific element
of a table. An empty table has no elements, so clearly
sqlite3_column_type() will not work. Perhaps you want the
results of sqlite3_column_decltype() instead.
For the second (unrelated) problem mentioned above, please provide
example code so that I can reproduce it.
2006-Jul-19 19:00:57 by anonymous:
Please disregard the second case. I determined I was trying to get the column type using an invalid index (out of bounds). |
|
1518 |
code
|
closed
|
2005 Nov
|
anonymous
|
Unknown
|
2005 Nov
|
|
4
|
4
|
can not vacuum an empty db-file
|
edit |
i created a big test-db (>150mb) with the c-api.
after dropping everything in this db the vaccum has no effect: the filesize remains >150mb.
here are the first bytes of the database ("create table logs (id)" with sqlite3.exe is enough to restore a 150mb but empty database !
begin 644 big.zip
M4$L#!!0``@`(`+)@:C--QT4A:04````E```'````8FEG+G-D8NV9:VP4513'
MS^SLSLZ^YBZEI5WZV`L1W9(-M%"P8&-H:8624@N4IAB4;MEMN[*/9KLE6ZF&
M(@0E$`B41PPJ1`R8``4A!I$@1*0%41%042&44I-&(#0$'T!)G-GIW.T0KC%\
MGG^S=\Z9^YO_/??DSH=)Y\TI\T=]N"X<"7JB>"+8@6%@&L8`.@Z(.FZ*PT3Q
MQR3NJ>+_E$V"T05`%ZSCA_Y9;O]?!TV:-&G2I$F3)DV:-#V-BC)3V`7^D-<7
M"X3KF_S>V`3I"NO3I\\M*:PLP:7EQ2756)G#X5`\QJY@V-L<\&4#L#\X';JV
M,7$+3\`3"4J@',QH49F06<E%3K`K?G5CO[<TY,9>3]0G7?W>EYNC<AH/FD/^
MJ+147:K#P;S]:M13&_#)!O)H&ERGLK"HK$1MC?VAJ*_>%Y&74#+<&/$'/9$6
MO,37HBP[E!173:2#921N2.5@,8F)I05S\6`P00DF*D&>$DQ2@LE*\+P2Y"O!
M%"7(S2$1\<Z5S<4>Z&K'.)G%\6[7!SQ-3?Y075AL*8EY5<N'(E+728Y=?J_D
MEISJ=#)MP7A'R20)C*J^JAY^K!LD:VJN5=^0G_(J_8JG38'&".E@(!Q5IL6*
MF!5.Q^#^&CT13_R\R`&GVAF9E+8E)U)9;ASR!*5C"57B46ECXQN3I^71H-I2
MXL%$P9)!(EOJ"33[!JM#K5"3GL*T.8:^+])%/V@ZO[QTSOS'WIG$*R-5)YTE
M-XZV-(KC8C&N#T?$`TA>)EB9FB(NX(N7+3TE_72JDA4O]?E,9)*W6'5D<8,G
MXLK-=F,WPXFF[!25)ZR]]D37;(-8Q#CAN#BN6XWNH[OH)NI%5]%/Z'O4A4ZB
MH^@0VHL^1A^@K6@#>A>M0,M0%`51'5J$JM$<-`M-1P5H$AJ'GD,8.5`2LB"]
M\$CX2[@C]`G7A5^%B\(YX>OX`IHT:=*D29,F39HT:=*D2=-3:\VROSMF`:P.
M_[EQNO@Y[;U[NA*@K?K._3<`WII]>Q\&6%;X1_=+`+')?9L"`,UC?^],`HAD
M]3S(!P@G=>][#2#`7;VN!V@8^*U]+("O_W)G!4!M[X\/E@(LNGQQ?P;`PF_/
M7R\"6/#E=^T-`%6'OND2`.;M[GJ8!U#Q_NG]KP"4O_E5CUA2><O)S<\"S+YR
MO*L,@-WYQ<,(@*G[\XXT`'OF9STO`HQ8<'BS%R"C_>`9,\#H2_L'<@"R[7L[
MJ@#&EWW2TPHP:<WN+:,!7NC<=68F0)%^YT`(8.:T#P\D`Q2NVGYC*H!A_'M;
M:@`LH[>>Y0"&I;0_<@.D&C<>F"M:#ZR_$1.M^]=MS0)P]:PY6RQ^Z/^\^M'K
M`'F=JP[:`:8>7=$[6?K?_!*X!^@*.H+:42,J0R[Q"[Y;."9L$Z)"A>`6>%NO
M[81MNRUFJ[3EV*S6/NLIZPYKJ[7:FF>U6VY9NBR[+,LM"RWYEF1SO_F<>8]Y
MI;G&7&!.,]TSG3?M-;UC\IJFF3+X?_A+_`%^+=_`%_/8.&"\;#QLW&`,&&<:
MGS$"=X4[PK5SC5P9Y^+TAF[#,<,V0]1087`;>'VO_H1^NSZFK]3GZ*UL'WN*
MW<&VLM5L'FO7W=)UZ7;IENL6ZO)UR4P_<X[9PZQD:I@")DW<UA.%/_ITE)'E
M$.-P\+^,@AD%-=<V7[I6S)075I96E<BCR"8"KC)(R3RF01)HO*9!(FD\ID
M$":#RJ03)IW*C"3,2"KC((R#RJ01)HW*I!(FE<J,(,P(*I-"F!0JDTR89"HS
MG###J4P289*HS##"#*,R=L+8J0PB#*(R`F$$*F,CC(W*6`ECI3(6PEBHC)DP
M9BIC(HR)RO"$X:F,D3!&*L,1AJ,R!L(8U,R_4$L!`A0`%``"``@`LF!J,TW'
M12%I!0```"4```<````````````@`````````&)I9RYS9&)02P4&``````$`
,`0`U````C@4`````
`
end
sum -r/size 18545/1497
|
2005-Nov-10 15:17:14 by anonymous:
This is a duplicate bug report. This issue was raised and fixed here: http://www.sqlite.org/cvstrac/tktview?tn=1512
2005-Nov-10 16:59:53 by drh:
Anonymous is correct. |
|
1517 |
code
|
closed
|
2005 Nov
|
anonymous
|
|
2005 Nov
|
|
1
|
1
|
unable to drop a temporary table when database is locked
|
edit |
if the database is locked when I create a temporary table, I'm unable to drop the temporary table. |
2005-Nov-16 12:39:03 by drh:
Actually, the reason you cannot drop the table is because you
still have an unfinalized SELECT pending. And that SELECT might
be reading the table you are trying to DROP. It isn't in your
case, but it might be and SQLite doesn't know so it takes the
safe way out and refuses to drop the table.
2005-Nov-17 03:29:35 by anonymous:
I thought that database level locks are used, is this not the case? |
|
1516 |
code
|
closed
|
2005 Nov
|
anonymous
|
|
2005 Nov
|
|
1
|
2
|
comparison error in WHERE clause
|
edit |
CREATE TABLE X (ItemAttributeID int, ItemID int, AttributeID int, Value TEXT NULL);
INSERT INTO X VALUES (1, 1, 22, '11111.11111');
INSERT INTO X VALUES (2, 1, 29, NULL);
SELECT ItemID,
[End], '22222.22222' AS Now, cast([End] as double) < cast('22222.22222' AS double) AS Compare
FROM (
SELECT ItemID,
cast(max(CASE WHEN [End] IS NULL OR [End] < Start THEN Start ELSE [End] END, coalesce([End], 0)) AS double) AS [End]
FROM (
SELECT IA.ItemID AS ItemID,
IABD.Value + coalesce(IABT.Value, 0) AS Start,
IAED.Value + coalesce(IAET.Value, 0) AS [End]
FROM X IA
JOIN X IABD ON IABD.ItemID = IA.ItemID AND IABD.AttributeID = 22 AND IABD.Value IS NOT NULL
LEFT JOIN X IABT ON IABT.ItemID = IA.ItemID AND IABT.AttributeID = 23
LEFT JOIN X IAED ON IAED.ItemID = IA.ItemID AND IAED.AttributeID = 27
LEFT JOIN X IAET ON IAET.ItemID = IA.ItemID AND IAET.AttributeID = 28
WHERE IA.AttributeID = 29
) V
WHERE cast([End] AS double) < cast('22222.22222' as double)
);
The query returns no rows, but if you comment out the WHERE clause, the resultset shows that the comparison returns 1 so the row should be returned when using the WHERE criteria... I don't know what is causing this so I haven't identified a workaround. |
2005-Nov-09 03:07:01 by drh:
You have two different expressions named [End], one on the middle
query and another on the inner-most query. Change one or the other
to [End2] (or anything else that isn't already in use) and your
query works. |
|
1511 |
event
|
closed
|
2005 Nov
|
anonymous
|
|
2005 Nov
|
|
1
|
1
|
how to use the index with "order by"
|
edit |
i have the following table layout:
CREATE TABLE Xlogs (id integer primary key, date integer, type varchar(1), category integer, module ntext, message ntext);
CREATE INDEX Xlogsidx on Xlogs (date, id);
now i inserted about 100000 of lines (with unique id values):
insert into Xlogs values (12345, 20051103165049583, 'I', 1, 'test module', 'test message');
...
...
...
when i select from this table, it takes some time (> 5 sec).
select id, date, type, message, module from logs where date>=20041103161601558 and date<=20091103161601856 order by id, date asc LIMIT 30 OFFSET 10000;
when i do a select without "order by" its really fast.
how can i create an index which is used by "order by" too ? |
2005-Nov-04 10:10:10 by anonymous:
- after playing some time with the index and "order by" if found the following:
if i use only "order by id" it is still slow, if i use "order by date" its getting much faster (but "date" is not unique and the result set is not sorted properly for my purpose)
- the time ">5 sec" was with 300000 entries and not 100000 (im using a laptop with a slow 2.5" hd (with xp-sp2))
- sorry for the "Priority 1" and the "Severity 1", but i really know no workaround (except for creating a new table every 10000 entries and writing my own "index" logic) and i really have not much more time !
(and i dont want to switch to another database system :-)
2005-Nov-04 12:15:19 by drh:
Please use the mailing list to ask questions.
Tickets are for reporting bugs. |
|
1510 |
build
|
closed
|
2005 Nov
|
anonymous
|
|
2005 Nov
|
|
3
|
2
|
Can't seem to get autoincrement to work no matter what I try
|
edit |
Downloaded SQLite 3 and pysqlite for python running on windows.
I cannot get autoincrement to work. Everything else seems fine.
I have found absolutely no mention of this problem anywhere and am stumped. |
2005-Nov-04 10:00:17 by anonymous:
There's no way anyone can help you unless you explain to us what you've done, what you expect it to do, and what it's actually doing. Ideally, in your case you should include a cut-and-pasteable copy of the shortest Python program that you can come up with which displays the undesired behavior.
2005-Nov-04 12:14:21 by drh:
Please use the mailing list to ask questions. Tickets are
for reporting bugs. |
|
1509 |
code
|
closed
|
2005 Nov
|
anonymous
|
|
2005 Nov
|
|
3
|
2
|
Different performance - SELECT COUNT(*) AND SELECT *
|
edit |
sqlite> SELECT COUNT(*) FROM t1 WHERE Name LIKE '%not_exists%';
0
sqlite> SELECT * FROM t1 WHERE Name LIKE '%not_exists%';
sqlite>
The first query (SELECT COUNT(*)...) takes about 5 seconds, the second (SELECT *...) - 15 seconds. Why different? There are about 3.5 milion records in t1. |
2005-Nov-03 13:41:11 by drh:
The second query has to do more work.
2005-Nov-03 14:29:20 by anonymous:
Have you noticed that the second query returns nothing?
2005-Nov-03 15:04:11 by drh:
Apparently nothing matched the LIKE pattern.
This is as designed and the way all other SQL
database engines work.
2005-Nov-03 16:14:44 by anonymous:
OK. Thank you for promptly answers. However I am still suprised why the second query is 3 times slower then first. I always thought that "SELECT NULL FROM t1 WHERE (conditions) LIMIT 1" is better method to check if there is any record that meets conditions than "SELECT COUNT(*) FROM ...".
2005-Nov-03 18:26:09 by anonymous:
It looks to me like the execution path of the inner loop when the condition doesn't match is identical (the same 5 VM instructions) for both queries. |
|
1507 |
code
|
closed
|
2005 Nov
|
anonymous
|
VDBE
|
2005 Nov
|
|
2
|
2
|
Embarassing buffer overflow in sqlite3VdbeMemPrettyPrint( )
|
edit |
In the following function, the "nBuf" parameter is never actually used:
/*
** Write a nice string representation of the contents of cell pMem
** into buffer zBuf, length nBuf.
*/
void sqlite3VdbeMemPrettyPrint(Mem *pMem, char *zBuf, int nBuf){
...
}
This function is called in several places, typically like this:
char zBuf[100];
sqlite3VdbeMemPrettyPrint(pMem, zBuf, 100);
fprintf(stderr, "OUTPUT: %s\n", zBuf);
|
2005-Nov-03 01:26:43 by drh:
If you will look more carefully at sqlite3VdbeMemPrettyPrint
you will see that there is no way for it to write more than about
70 characters into its output buffer and every place that calls
it (it is a debugging routine after all) hands it a 100-character
buffer. So there is no overflow.
And the routine does not even exist unless you compile with
-DSQLITE_DEBUG=1. |
|
1505 |
code
|
closed
|
2005 Nov
|
anonymous
|
TclLib
|
2005 Nov
|
|
2
|
3
|
Sqlite3 tcl bindings return "{}" instead of {} for the empty result
|
edit |
Queries from Tcl that should return the empty string sometimes return "{}" instead. "{}" is not the empty set in Tcl, {} is. Here's where I find this happening:
I have a table declared as:
CREATE TABLE processes(
hostRowID INTEGER REFERENCES hosts,
pid INTEGER,
fileName VARCHAR(255) /* Main exec file or command name */,
timestamp TIMESTAMP,
owner VARCHAR(255),
permissions INTEGER,
cpuTime INTEGER,
PRIMARY KEY(hostRowID, pid, fileName))
This table is empty. Now in Tcl when I say:
% set t [d2 eval {select timestamp from processes}]
% if {$t == {}} {puts "Empty"} else {puts "not Empty"}
Empty
This is as expected, but when I want to find the minimum timestamp in the table:
% set t [d2 eval {select min(timestamp) from processes}]
{}
% if {$t == {}} {puts "Empty"} else {puts "not Empty"}
not Empty
So I get something that looks like the empty string to casual observation, but it is not the empty string. |
2005-Nov-02 01:08:58 by drh:
This behavior is correct and is as intended and documented. The
return value is a list containing a single element which is an
empty string. You probably want to do this:
set t [d2 one {SELECT min(timestampe) from processes}]
or this:
set t [lindex [d2 eval {SELECT min(timestamp) from processes}]]
|
|
1499 |
code
|
closed
|
2005 Oct
|
anonymous
|
|
2006 Mar
|
anonymous
|
3
|
1
|
Sqlite 3.2.7 does not support Chinese path.
|
edit |
sqlite 3.2.7 does not support Chinese path.
function:
sqlite3_open
unable to open database file
But sqlite 3.2.2 support Chinese path. |
2005-Dec-19 00:10:27 by anonymous:
This bug is caused by the change made in os_win.c version 1.24. See also ticket #1533.
Brodie |
|
1496 |
code
|
closed
|
2005 Oct
|
anonymous
|
|
2005 Oct
|
|
4
|
3
|
No index creation possible on :memory: DB
|
edit |
When I tried to create an index on a table in a :memory: database attached as "tmp" I wasn't able to insert new values after a first "insert ... select ..." statement. The create statement read as follows:
create index tmp.idx_Keywords_TextSU on Keywords (Text_SU);
This was true for two indices on separate tables. If I skip the index creation all works fine. This behaviour should at least be mentioned in the docs.
Martin |
2005-Oct-20 17:16:58 by drh:
Works fine when I try it. |
|
1495 |
code
|
closed
|
2005 Oct
|
anonymous
|
|
2005 Oct
|
|
2
|
4
|
SELECT DISTINCT "col_name" from "TablName fails on first & last fields
|
edit |
SELECT DISTINCT "col_name" from "TablName fails on first or last fields. The result will give multiple entries of the same data for column 1 and the last column.
For example if your table "Table1" is:
Sales|Location|Date
1000|Los Angeles|Jan-05-2005
1000|San Diego|Jan-26-2005
The result of the query:
SELECT DISTINCT Sales from Table1; should be:
1000
It will actually give:
1000
1000
The data result is not distinctive for the first column. The same will happen on the last column. All other columns will work correctly. |
2005-Oct-19 21:52:16 by anonymous:
I can't duplicate this with your data. It would help if you could show the
CREATE TABLE statement you used, along with any CREATE INDEX statements. Ideally, you should provide a complete SQL script that can be executed by the shell and that demonstrates the problem.
2005-Oct-20 01:46:17 by drh:
It is probably the case that one of the "1000"s is a string and
the other one is an integer. Those are two different values, so
of course they show up distinct. To test my hypothesis, do this:
SELECT DISTINCT typeof(Sales) FROM Tablname
2005-Oct-20 21:10:53 by anonymous:
Not a Bug. After looking closely at the data it became apparent that one of the Fields had a CR/LF character at the end of the field were the others did not. This caused the field to become unique. Sorry to have bothered you with my data problems.
In Summary - This is not a bug. The data had a Carriage Return/Line Feed character at the end of the field. |
|
1492 |
code
|
closed
|
2005 Oct
|
anonymous
|
|
2005 Nov
|
|
1
|
4
|
CURRENT_TIMESTAMP bad for PM times.
|
edit |
Default timestamps don't insert correctly.
sqlite> create table events (When datetime default CURRENT_TIMESTAMP, What char(40));
/* If the time is something like 3:12 PM */
sqlite> insert into events(What) values('hello');
sqlite> select * from events;
2005-10-17 05:12:39|hello
/* Note, that the hours are 05 and not 15 as they should be */
Does this happen on Windows (XP Pro) only? Is there some locale setting I may need to check?
|
CURRENT_TIMESTAMP would be more useful if it did take locale into account, i.e. 'SELECT CURRENT_TIMESTAMP;' equiv of 'SELECT DATETIME('now','localtime');'
2005-Oct-17 05:55:28 by anonymous:
Or for an even simpler test . . .
sqlite> select CURRENT_TIMESTAMP;
2005-Oct-17 18:05:53 by anonymous:
There is no bug. You are expecting current_datetime to return a local time when it actually returns the time in UCT (or GMT). The difference it the number of hours (or time zones) you are away from Greenwich. You can use he localtime modifier to convert the standard time to localtime taking your timezone into account.
sqlite> select current_timestamp;
2005-10-17 17:55:59
sqlite> select datetime('now', 'localtime');
2005-10-17 11:58:36
sqlite> select datetime((select current_timestamp), 'localtime');
2005-10-17 11:59:23
|
|
1490 |
code
|
closed
|
2005 Oct
|
anonymous
|
|
2005 Nov
|
|
1
|
1
|
Create Temp Index has problem
|
edit |
reproduce Steps:
1 Create temp Table Test3, the SQL is "CREATE Temp TABLE 'Test3'(
A PRIMARY KEY
, B Text)"
2 CREATE INDEX TempIndex3 On Test3 (
A ,B ) will successfully a temp index.
then drop the TempIndex3.
3 Create non-temp Table Test3 the SQL is CREATE TABLE 'Test3'(
A PRIMARY KEY
, B Text)
4 this time run SQL "CREATE INDEX TempIndex3 On Test3 (
A ,B )" , it will create a non-temp index on physical table test3.
5 now I want to create a temp index on Temp.Test3 again.
Run the sql "CREATE INDEX TempIndex3 On Temp.Test3 (
A ,B )
sqlite will throw a error message " near ".": syntax error "
How to create a temp index when temp and physical table have same name? |
2005-Nov-16 14:04:17 by drh:
CREATE INDEX temp.tempindex3 ON temp3(a,b);
|
|
1482 |
code
|
closed
|
2005 Oct
|
anonymous
|
|
2005 Oct
|
|
1
|
1
|
Cannot finish a transaction if a previous transaction was rolled back;
|
edit |
The following sequence of statements fails:
BEGIN TRANSACTION;
... some statements ...
ROLLBACK TRANSACTION;
BEGIN TRANSACTION;
... other statements ...
[COMMIT|ROLLBACK] TRANSACTION;
The error msg is:
cannot [commit|rollback] transaction - SQL statements in progress
However you can still execute statements with auto-commit, like:
BEGIN TRANSACTION;
... some statements ...
ROLLBACK TRANSACTION;
... other statements ... |
2005-Oct-12 18:04:20 by drh:
It works fine when I try it.
Perhaps you are forgetting to call sqlite3_finalize on one of the
previous statements. The ROLLBACK statement seems a likely place to
look.
Indeed I forgot to reset a prepared statement if an error occured. Obviously I did misinterpret the documentation, and was not
aware you MUST either finalize or reset all statements before commiting/rolling back.
Thx for the prompt reply. |
|
1481 |
code
|
closed
|
2005 Oct
|
anonymous
|
VDBE
|
2006 Sep
|
|
4
|
4
|
sqlite 3.2.7 does not report column names properly in joined queries
|
edit |
it seems, that ver 2.3.7 does not report the column names properly if one use joined select. Documntation says:
... Normally, such result columns are named <table-name/alias>.<column-name> if the SELECT statement joins two or more tables
together, or simply <column-name> if the SELECT statement queries a single table. ...
but if I try this:
sqlite> pragma short_column_names=0;
sqlite> pragma full_column_names=0;
sqlite> .header on
sqlite> create table t1 (id);
sqlite> insert into t1 values (1);
sqlite> insert into t1 values (2);
sqlite> insert into t1 values (3);
sqlite> select * from t1;
id
1
2
3
sqlite> select * from t1 left join t1 as t2 on t1.id=t2.id;
id|id
1|1
2|2
3|3
sqlite>
column headers are id|id and not t1.id|t2.id |
2005-Oct-12 18:06:07 by drh:
Your work-around it to us an AS clause to specify any column
header you want.
2006-Sep-27 18:13:18 by anonymous:
Duplicate of #1142. |
|
1477 |
code
|
closed
|
2005 Oct
|
anonymous
|
Unknown
|
2006 Sep
|
|
1
|
2
|
first "select count(*) from mytable" takes a very long time
|
edit |
i have a very big database file (>3.5GB).
when i open it, the first "select count(*) from mytable" takes a very long time (> 15 minutes), then the time is reduces to 3-4 seconds...
result: my application hangs on startup !
(the table has an index, thats maybe not the problem)
example statements:
create table params (id integer, name integer, value ntext)
create index paramsidx on params (id, name)
insert into params (id, name, value) values (1, 0, 'abc1')
insert into params (id, name, value) values (1, 1, 'abc2')
insert into params (id, name, value) values (2, 0, 'xyz1')
insert into params (id, name, value) values (2, 1, 'xyz2')
insert into params (id, name, value) values (2, 2, 'xyz3')
...
insert into params (id, name, value) values (10000000, 0, 'foo1')
insert into params (id, name, value) values (10000000, 1, 'bar2')
it looks like the complete database file is scanned on the first access... even if i access a table with only 1 row it takes a very long time |
2005-Oct-14 03:34:24 by anonymous:
Have you done an EXPLAIN on your query and looked at the results?
2005-Oct-14 08:21:56 by anonymous:
SQLite version 3.2.7
Enter ".help" for instructions
sqlite> explain select count(*) from sequence;
0|MemNull|0|0|
1|Goto|0|13|
2|Integer|0|0|
3|OpenRead|0|431334|
4|SetNumColumns|0|1|
5|Rewind|0|8|
6|AggStep|0|0|count(0)
7|Next|0|6|
8|Close|0|0|
9|AggFinal|0|0|count(0)
10|MemLoad|0|0|
11|Callback|1|0|
12|Halt|0|0|
13|Transaction|0|0|
14|VerifyCookie|0|9|
15|Goto|0|2|
16|Noop|0|0|
or
sqlite> explain select count(*) from logs;
0|MemNull|0|0|
1|Goto|0|13|
2|Integer|0|0|
3|OpenRead|0|2|
4|SetNumColumns|0|6|
5|Rewind|0|8|
6|AggStep|0|0|count(0)
7|Next|0|6|
8|Close|0|0|
9|AggFinal|0|0|count(0)
10|MemLoad|0|0|
11|Callback|1|0|
12|Halt|0|0|
13|Transaction|0|0|
14|VerifyCookie|0|9|
15|Goto|0|2|
16|Noop|0|0|
sqlite>
... i dont understand this "sql-assembler", but it looks not very time-consuming.
2005-Oct-14 09:28:21 by anonymous:
In both your cases, steps 6 and 7 indicate a full-table scan. Which is what I suspected; it would be rather hard to implement COUNT(*) any other way.
2005-Oct-17 08:41:49 by anonymous:
i thougt it is very fast to get the count of rows if the table is indexed... now i tried a "count(id)" instead of a "count(*)" (id is in the index), but it is even slower !!!
ok, i'll try to reorganize some tables and queries...
thanx a lot for your fast answers !
2005-Oct-21 10:10:11 by anonymous:
i discovered the following:
if i do just a select on the id-column its veeeeeeery fast !
if i have for example the column 'date' in my query (in the where clause or in the order-by clause) its getting veeeery slow !!!
i expect some million rows, and i think it will be unusable then
any ideas ?
Here is a sample of my database:
BEGIN TRANSACTION;
CREATE TABLE logs (id integer primary key, date integer, type varchar(1), category integer, module ntext, message ntext);
INSERT INTO "logs" VALUES(1, 20051021101843460, 'E', 1, 'SYSTEM', 'SYSTEM_EXCEPTION');
INSERT INTO "logs" VALUES(2, 20051021101843491, 'I', 1, 'SYSTEM', 'CREATED_LOGDB');
INSERT INTO "logs" VALUES(3, 20051021101843491, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(4, 20051021101843491, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(5, 20051021101843491, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(6, 20051021101843507, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(7, 20051021101843507, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(8, 20051021101843507, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(9, 20051021101843569, 'D', 1, 'SYSTEM', 'SETTING_CURRENT_LANGUAGE');
INSERT INTO "logs" VALUES(10, 20051021101843632, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(11, 20051021101843788, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(12, 20051021101844585, 'D', 3, 'DEBUG', 'CREATED_EXCEPTION');
INSERT INTO "logs" VALUES(13, 20051021101844601, 'E', 1, 'OPC', 'SYSTEM_EXCEPTION');
INSERT INTO "logs" VALUES(14, 20051021101844616, 'D', 3, 'DEBUG', 'CREATED_EXCEPTION');
INSERT INTO "logs" VALUES(15, 20051021101844632, 'E', 1, 'OPC', 'SYSTEM_EXCEPTION');
INSERT INTO "logs" VALUES(16, 20051021101844647, 'D', 3, 'DEBUG', 'CREATED_EXCEPTION');
INSERT INTO "logs" VALUES(17, 20051021101844663, 'E', 1, 'OPC', 'SYSTEM_EXCEPTION');
INSERT INTO "logs" VALUES(18, 20051021101844679, 'D', 3, 'DEBUG', 'CREATED_EXCEPTION');
INSERT INTO "logs" VALUES(19, 20051021101844694, 'E', 1, 'OPC', 'SYSTEM_EXCEPTION');
INSERT INTO "logs" VALUES(20, 20051021101844694, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(21, 20051021101844835, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(22, 20051021101844835, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(23, 20051021101844882, 'I', 1, 'SYSTEM', 'CONFIG');
INSERT INTO "logs" VALUES(24, 20051021101844897, 'I', 1, 'SYSTEM', 'CONFIG');
INSERT INTO "logs" VALUES(25, 20051021101844897, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(26, 20051021101844897, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(27, 20051021101845882, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(28, 20051021101845897, 'D', 3, 'DEBUG', 'DEBUG');
... many more lines ...
INSERT INTO "logs" VALUES(454204, 20051021111458816, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454205, 20051021111458816, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454206, 20051021111458847, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454207, 20051021111458847, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454208, 20051021111458847, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454209, 20051021111458863, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454210, 20051021111458863, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454211, 20051021111458863, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454212, 20051021111458879, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454213, 20051021111458879, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454214, 20051021111458879, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454215, 20051021111458894, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454216, 20051021111458894, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454217, 20051021111458894, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454218, 20051021111458910, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454219, 20051021111458910, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454220, 20051021111458910, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454221, 20051021111458926, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454222, 20051021111458926, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454223, 20051021111458926, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454224, 20051021111458941, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454225, 20051021111458941, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454226, 20051021111458957, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454227, 20051021111458957, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454228, 20051021111458957, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454229, 20051021111458973, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454230, 20051021111458973, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454231, 20051021111458973, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454232, 20051021111458988, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454233, 20051021111458988, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454234, 20051021111459004, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454235, 20051021111459004, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454236, 20051021111459004, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454237, 20051021111459020, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454238, 20051021111459020, 'I', 1, 'SYSTEM', 'STOPPING');
INSERT INTO "logs" VALUES(454239, 20051021111459035, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454240, 20051021111459035, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454241, 20051021111459035, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454242, 20051021111459129, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454243, 20051021111459129, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454244, 20051021111459145, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454245, 20051021111459161, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454246, 20051021111459161, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454247, 20051021111459176, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454248, 20051021111459176, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454249, 20051021111459192, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454250, 20051021111459192, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454251, 20051021111459208, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454252, 20051021111459208, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454253, 20051021111459239, 'D', 3, 'DEBUG', 'DEBUG');
INSERT INTO "logs" VALUES(454254, 20051021111509703, 'D', 3, 'DEBUG', 'DEBUG');
CREATE TABLE params (id integer, name integer, value ntext);
INSERT INTO "params" VALUES(1, 0, 'System.UnauthorizedAccessException');
INSERT INTO "params" VALUES(1, 1, 'Der Zugriff auf den Pfad d:\src\Triton\LG2\config\EventCategories.xml wurde verweigert.');
INSERT INTO "params" VALUES(2, 0, 'Data Source=d:\src\Triton\LG2\log\2005-10-21\..\log.MCPRunner.sdb;Version=3;UTF8Encoding=True;Cache Size=10000;Synchronous=Full;New=True');
INSERT INTO "params" VALUES(2, 1, 'NBAZ1297');
INSERT INTO "params" VALUES(3, 0, 'adding command ''ListCommands'' (delegate)');
INSERT INTO "params" VALUES(4, 0, 'adding command ''Logger.RebuildCategories'' (delegate)');
INSERT INTO "params" VALUES(5, 0, 'loaded 853 translations');
INSERT INTO "params" VALUES(6, 0, ' loaded 223 translations for language ''de'' (missing 223 translations)');
INSERT INTO "params" VALUES(7, 0, ' loaded 446 translations for language ''en''');
INSERT INTO "params" VALUES(8, 0, ' loaded 184 translations for language ''ko'' (missing 262 translations)');
INSERT INTO "params" VALUES(9, 0, 'en');
INSERT INTO "params" VALUES(10, 0, 'file ''d:\src\Triton\LG2\McpStart.cmd'' not found');
INSERT INTO "params" VALUES(11, 0, 'adding command ''Logging.BackupEvent'' (delegate)');
INSERT INTO "params" VALUES(12, 0, 'OPC_ITEM_ERROR');
INSERT INTO "params" VALUES(12, 1, 'OPC item error: Main.S7.PCIfc.States.Communication: OPCError([0x80004005])');
INSERT INTO "params" VALUES(12, 2, '
d:\src\triton\mcprunner\mcprunnerform.cs:92
d:\src\triton\mcprunner\mcprunnerform.cs:1232
');
INSERT INTO "params" VALUES(13, 0, 'SDevLib.OPC.OPCException');
INSERT INTO "params" VALUES(13, 1, 'OPC item error: Main.S7.PCIfc.States.Communication: OPCError([0x80004005])');
INSERT INTO "params" VALUES(14, 0, 'OPC_ITEM_ERROR');
INSERT INTO "params" VALUES(14, 1, 'OPC item error: Main.S7.PCIfc.States.Control: OPCError([0x80004005])');
INSERT INTO "params" VALUES(14, 2, '
d:\src\triton\mcprunner\mcprunnerform.cs:92
d:\src\triton\mcprunner\mcprunnerform.cs:1232
');
INSERT INTO "params" VALUES(15, 0, 'SDevLib.OPC.OPCException');
INSERT INTO "params" VALUES(15, 1, 'OPC item error: Main.S7.PCIfc.States.Control: OPCError([0x80004005])');
INSERT INTO "params" VALUES(16, 0, 'OPC_ITEM_ERROR');
INSERT INTO "params" VALUES(16, 1, 'OPC item error: Main.S7.PCIfc.States.Equipment: OPCError([0x80004005])');
INSERT INTO "params" VALUES(16, 2, '
d:\src\triton\mcprunner\mcprunnerform.cs:92
d:\src\triton\mcprunner\mcprunnerform.cs:1232
');
INSERT INTO "params" VALUES(17, 0, 'SDevLib.OPC.OPCException');
INSERT INTO "params" VALUES(17, 1, 'OPC item error: Main.S7.PCIfc.States.Equipment: OPCError([0x80004005])');
INSERT INTO "params" VALUES(18, 0, 'OPC_ITEM_ERROR');
INSERT INTO "params" VALUES(18, 1, 'OPC item error: Main.S7.PCIfc.States.Process: OPCError([0x80004005])');
INSERT INTO "params" VALUES(18, 2, '
d:\src\triton\mcprunner\mcprunnerform.cs:92
d:\src\triton\mcprunner\mcprunnerform.cs:1232
');
INSERT INTO "params" VALUES(19, 0, 'SDevLib.OPC.OPCException');
INSERT INTO "params" VALUES(19, 1, 'OPC item error: Main.S7.PCIfc.States.Process: OPCError([0x80004005])');
INSERT INTO "params" VALUES(20, 0, 'using MCP-TestCase ''LG2.alarmperf''');
INSERT INTO "params" VALUES(21, 0, 'adding command ''InvokeCmdOnMCPGuiThread'' (class = ''MCPRunner.InvokeCmdOnMCPGuiThreadCommand'')');
INSERT INTO "params" VALUES(22, 0, 'adding command ''UnitManager.ShowUnitManagerInfoForm'' (class = ''Framework.MCP.Manager.Unit.ShowUnitManagerInfoFormCommand'')');
INSERT INTO "params" VALUES(23, 0, 'MCP-baseDir');
INSERT INTO "params" VALUES(23, 1, 'd:\src\Triton\LG2\');
INSERT INTO "params" VALUES(24, 0, 'MCP-settingsFilename');
INSERT INTO "params" VALUES(24, 1, 'MCPConfig.xml');
INSERT INTO "params" VALUES(25, 0, 'adding command ''MCP.IsStarted'' (delegate)');
INSERT INTO "params" VALUES(26, 0, 'MCP: RemoteCommandServerC.Create');
INSERT INTO "params" VALUES(27, 0, 'loaded FSM ''CommunicationState'', set initstate to ''DISABLED''');
INSERT INTO "params" VALUES(28, 0, 'loaded FSM ''ControlState'', set initstate to ''OFFLINE''');
... many more lines ...
INSERT INTO "params" VALUES(454204, 0, 'MCP: Framework.MCP.Manager.Alarm.AlarmManagerC.stop');
INSERT INTO "params" VALUES(454205, 0, 'Framework.MCP.Manager.Alarm.AlarmManagerC');
INSERT INTO "params" VALUES(454206, 0, 'MCP: Framework.MCP.ProcessStateC.stop');
INSERT INTO "params" VALUES(454207, 0, 'Framework.MCP.ProcessStateC');
INSERT INTO "params" VALUES(454208, 0, 'MCP');
INSERT INTO "params" VALUES(454209, 0, 'MCP: SDevLib.Commands.RemoteCommandServerC.stop');
INSERT INTO "params" VALUES(454210, 0, 'SDevLib.Commands.RemoteCommandServerC');
INSERT INTO "params" VALUES(454211, 0, 'MCP: SDevLib.Commands.CommandPoolC.stop');
INSERT INTO "params" VALUES(454212, 0, 'SDevLib.Commands.CommandPoolC');
INSERT INTO "params" VALUES(454213, 0, 'MCP: CommManager.MCP.CommManagerC.stop');
INSERT INTO "params" VALUES(454214, 0, 'CommManager.MCP.CommManagerC');
INSERT INTO "params" VALUES(454215, 0, 'MCP: APCMgr.CommManagerAPCC.stop');
INSERT INTO "params" VALUES(454216, 0, 'APCMgr.CommManagerAPCC');
INSERT INTO "params" VALUES(454217, 0, 'MCP: ComponentTree.ComponentTreeC.stop');
INSERT INTO "params" VALUES(454218, 0, 'ComponentTree.ComponentTreeC');
INSERT INTO "params" VALUES(454219, 0, 'MCP: Framework.MCP.Manager.Persistence.PersistenceManagerC.stop');
INSERT INTO "params" VALUES(454220, 0, 'Framework.MCP.Manager.Persistence.PersistenceManagerC');
INSERT INTO "params" VALUES(454221, 0, 'MCP: Framework.MCP.Manager.Recipe.RecipeManagerC.stop');
INSERT INTO "params" VALUES(454222, 0, 'Framework.MCP.Manager.Recipe.RecipeManagerC');
INSERT INTO "params" VALUES(454223, 0, 'MCP: Framework.MCP.Manager.Unit.UnitManagerC.stop');
INSERT INTO "params" VALUES(454224, 0, 'Framework.MCP.Manager.Unit.UnitManagerC');
INSERT INTO "params" VALUES(454225, 0, 'MCP: Framework.MCP.Manager.Unit.ECSUnitManagerC.stop');
INSERT INTO "params" VALUES(454226, 0, 'Framework.MCP.Manager.Unit.ECSUnitManagerC');
INSERT INTO "params" VALUES(454227, 0, 'MCP: Framework.MCP.EquipmentStateC.stop');
INSERT INTO "params" VALUES(454228, 0, 'Framework.MCP.EquipmentStateC');
INSERT INTO "params" VALUES(454229, 0, 'MCP: Framework.MCP.Manager.TransportManagerC.stop');
INSERT INTO "params" VALUES(454230, 0, 'Framework.MCP.Manager.TransportManagerC');
INSERT INTO "params" VALUES(454231, 0, 'MCP: Framework.MCP.Manager.Lot.LotManagerC.stop');
INSERT INTO "params" VALUES(454232, 0, 'Framework.MCP.Manager.Lot.LotManagerC');
INSERT INTO "params" VALUES(454233, 0, 'MCP: Framework.MCP.Manager.Glass.GlassManagerC.stop');
INSERT INTO "params" VALUES(454234, 0, 'Framework.MCP.Manager.Glass.GlassManagerC');
INSERT INTO "params" VALUES(454235, 0, 'MCP: Framework.MCP.Manager.Alarm.AlarmManagerC.stop');
INSERT INTO "params" VALUES(454236, 0, 'Framework.MCP.Manager.Alarm.AlarmManagerC');
INSERT INTO "params" VALUES(454237, 0, 'MCP: Framework.MCP.ProcessStateC.stop');
INSERT INTO "params" VALUES(454238, 0, 'Framework.MCP.ProcessStateC');
INSERT INTO "params" VALUES(454239, 0, 'MCP: SDevLib.Commands.RemoteCommandServerC.Dispose');
INSERT INTO "params" VALUES(454240, 0, 'MCP: SDevLib.Commands.CommandPoolC.Dispose');
INSERT INTO "params" VALUES(454241, 0, 'MCP: CommManager.MCP.CommManagerC.Dispose');
INSERT INTO "params" VALUES(454242, 0, 'MCP: APCMgr.CommManagerAPCC.Dispose');
INSERT INTO "params" VALUES(454243, 0, 'MCP: ComponentTree.ComponentTreeC.Dispose');
INSERT INTO "params" VALUES(454244, 0, 'MCP: Framework.MCP.Manager.Persistence.PersistenceManagerC.Dispose');
INSERT INTO "params" VALUES(454245, 0, 'MCP: Framework.MCP.Manager.Recipe.RecipeManagerC.Dispose');
INSERT INTO "params" VALUES(454246, 0, 'MCP: Framework.MCP.Manager.Unit.UnitManagerC.Dispose');
INSERT INTO "params" VALUES(454247, 0, 'MCP: Framework.MCP.Manager.Unit.ECSUnitManagerC.Dispose');
INSERT INTO "params" VALUES(454248, 0, 'MCP: Framework.MCP.EquipmentStateC.Dispose');
INSERT INTO "params" VALUES(454249, 0, 'MCP: Framework.MCP.Manager.TransportManagerC.Dispose');
INSERT INTO "params" VALUES(454250, 0, 'MCP: Framework.MCP.Manager.Lot.LotManagerC.Dispose');
INSERT INTO "params" VALUES(454251, 0, 'MCP: Framework.MCP.Manager.Glass.GlassManagerC.Dispose');
INSERT INTO "params" VALUES(454252, 0, 'MCP: Framework.MCP.Manager.Alarm.AlarmManagerC.Dispose');
INSERT INTO "params" VALUES(454253, 0, 'MCP: Framework.MCP.ProcessStateC.Dispose');
INSERT INTO "params" VALUES(454254, 0, 'file ''d:\src\Triton\LG2\McpStop.cmd'' not found');
CREATE TABLE glassinfo (id integer, unit integer, subunit integer, glassid ntext, glassslprt ntext, lotid ntext);
CREATE TABLE alarms (alarm integer, idIn integer, dateIn integer, idOut integer, dateOut integer, unit ntext, m1 text, m2 text, m3 text, m4 text, m5 text, m6 text, m7 text, m8 text, m9 text, m10 text, m11 text, m12 text);
CREATE INDEX logsidx on logs (id, date, type, category, module, message);
CREATE INDEX paramsidx on params (id, name);
CREATE INDEX glassinfoidx on glassinfo (id);
CREATE INDEX alarmsidx on alarms (alarm, idIn, dateIn, idOut, dateOut, unit);
COMMIT;
... sample queries ...
select id, date, type, message, module from logs where date>=20051021102732476 and date<=29991231235959999 and type<>'D' and type<>'I' order by id, date asc LIMIT 30 OFFSET 0
select id, date, type, message, module from logs where date>=20000000000000000 and date<=29991231235959999 and type<>'D' and type<>'I' order by id, date asc LIMIT 30 OFFSET 52988
2005-Oct-21 18:52:22 by anonymous:
It would probably be more productive to take this to the mailing list.
2006-Sep-27 18:32:56 by anonymous:
Creating index on date might help. |
|
1472 |
build
|
closed
|
2005 Oct
|
anonymous
|
|
2005 Oct
|
|
1
|
5
|
Borland command line compiler v 5.5 and SQLite
|
edit |
Does someone have Make files to create exe and dll for Borland command line compiler v 5.5?
Thanks in advance. |
2005-Oct-06 13:29:40 by drh:
Please use the SQLite mailing list to ask questions. Tickets
are for reporting bugs. |
|
1470 |
new
|
closed
|
2005 Oct
|
anonymous
|
Unknown
|
2005 Oct
|
anonymous
|
2
|
4
|
International support
|
edit |
I tried to implement collating function (case insensitive) for windows box. It worked with comparison operators except with LIKE operator. Then I checked the sqlite sources and found out that "patternCompare" function blindly scans input stream and converts only ASCII characters into lowercase.
Now, I guess that sqlite doesn't know a thing about input UTF8 stream which could be representing characters from any encoding. This makes the job of "patternCompare" function impossible.
Then I also checked the "upper" and "lower" functions. They also don't work except for ASCII characters.
I guess that I would like to see a better support for internationalization. An ability to define the encoding for the entire database or table to make the work of such functions (upper, lower, like) possible.
Right now I must work around this by including an extra column with precalculated UPPERCASE data which is then used for searching/sorting. This has a side effect: it works faster because there are no conversions when doing queries but it also uses more storage. Anyhow, it would be nice to have a support for native charcter sets. |
2005-Oct-05 20:54:55 by drh:
You can override the like, upper, and lower functions to do anything
you want and to support any character set you want.
Anybody who is using international character sets in their
program probably already has the necessary string comparison and
conversion functions in their program. There is no point in
duplicating these functions in SQLite. For this reason,
built-in support for comparisons of international characters is
deliberately omitted from SQLite. SQLite gives you the ability
to add international support yourself. We have no intention of
taking this further. |
|
1463 |
code
|
closed
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
|
3
|
1
|
can't see views in browser 1.0
|
edit |
After creating a view in the database using php the db browser does not show the view. However, queries that use the view are working. |
2005-Sep-30 00:20:07 by anonymous:
I'm not sure what "db browser" you're using, but if it is anything other then official SQLite command line utility then this is not the right place to report such problem. If you are using official sqlite utility then please provide more details about the problem, such as version of sqlite, SQL statement used to create view etc.
If you're using some other utility then please contact its authors for support.
2005-Sep-30 00:20:48 by anonymous:
Which PHP browser program? Which version of PHP? For that matter, which version of SQLite?
The PHP wrappers for SQLite, as well as any interface tools, aren't developed or maintained here. |
|
1462 |
code
|
closed
|
2005 Sep
|
anonymous
|
VDBE
|
2005 Sep
|
drh
|
1
|
2
|
sqlite3_bind_parameter_name() always return nulls
|
edit |
<body>
calling sqlite3_bind_parameter_name() with parameter index 1
always returns NULL with the following SQL command:
insert into voidtable (intfield, integerfield, numericfield, textfield, charfield) values (?, ?, ?, ?, ?)
looking inside vdbeapi.c, routine sqlite3_bind_parameter_name(), I found that the routine createVarMap is being called to generate parameter names. But debugging the code, I realized that pOp->p3 is always NULL, and the createVarMap() routine is using it to generate parameter names. Look below:
static void createVarMap(Vdbe *p){
if( !p->okVar ){
int j;
Op *pOp;
for(j=0, pOp=p->aOp; jnOp; j++, pOp++){
if( pOp->opcode==OP_Variable ){
assert( pOp->p1>0 && pOp->p1<=p->nVar );
p->azVar[pOp->p1-1] = pOp->p3; <font color=red><<== HERE: pOp->p3 is NULL!!!
}
}
p->okVar = 1;
}
}
Is this correct or a bug ??
|
2005-Sep-28 22:32:05 by anonymous:
From the documentation at http://www.sqlite.org/capi3ref.html#sqlite3_bind_parameter_name:
const char *sqlite3_bind_parameter_name(sqlite3_stmt*, int n);
Return the name of the n-th parameter in the precompiled statement. Parameters of the form ":AAA" or "$VVV" have a name which is the string ":AAA" or "$VVV". In other words, the initial ":" or "$" is included as part of the name. Parameters of the form "?" have no name.
If the value n is out of range or if the n-th parameter is nameless, then NULL is returned. The returned string is always in the UTF-8 encoding.
As you can see, it's supposed to return NULL for these ? parameters.
I suspect you are looking for the names of the columns the parameters will be inserted into. That is something entirely different then the parameter name.
2005-Sep-29 10:05:03 by anonymous:
sorry, I didn't read this carefully. sorry for this big mistake!! :) |
|
1460 |
code
|
closed
|
2005 Sep
|
anonymous
|
VDBE
|
2008 Jan
|
drh
|
2
|
2
|
sqlite3_clear_bindings not implemented in sources
|
edit |
after searching inside source files, the routine sqlite3_clear_bindings() was not found.
But this is in sqlite3.h and documentation.
Is there routine deprecated ?? |
2005-Sep-28 15:23:22 by drh:
This routine is in the source file experimental.c.
http://www.sqlite.org/cvstrac/getfile/sqlite/src/experimental.c
2008-Jan-24 02:19:38 by anonymous:
This routine may be in experimental.c but some distributions (Centos 4.4, Fedora Core 6-64 bit to name 2) seem to provide .so's that do not contain the routine. Is there some compilation flag that eliminates "experimental" code.
Regardless, it remains defined in the header file, which results in a linker error and great user confusion, judging by the # of bugs opened on this issue.
2008-Jan-24 02:29:03 by anonymous:
Example program:
#include <sqlite3.h>
int main(void)
{
sqlite3_stmt* stmt;
sqlite3_clear_bindings(stmt);
return 0;
}
Compile:
gcc test1.c -lsqlite3
/tmp/ccsrGxAt.o(.text+0x23): In function `main':
: undefined reference to `sqlite3_clear_bindings'
collect2: ld returned 1 exit status
However, just to prove that -lsqlite3 is the sqlite3 library:
#include <sqlite3.h>
int main(void)
{
printf("SQLITE header version %d, library version %s", SQLITE_VERSION_NUMBER, sqlite3_libversion());
return 0;
}
# gcc test2.c -lsqlite3
# ./a.out
SQLITE header version 3003006, library version 3.3.6
2008-Jan-24 12:37:33 by drh:
The sqlite3_clear_bindings() routine is now located in the vdbeapi.c source file
and is a part of all builds. |
|
1459 |
code
|
closed
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
|
1
|
1
|
Division operation
|
edit |
hi,
i am a user of sqlite 2.8 and i have detected an error with Aritmetic operations
Select (10/20) returns 0 not 0.5 |
2005-Sep-28 10:07:27 by anonymous:
when i do select (10.0/20) then the result is correct
2005-Sep-28 10:35:32 by drh:
Integer division gives an integer result, just like in C.
Works as designed. |
|
1456 |
code
|
closed
|
2005 Sep
|
anonymous
|
Unknown
|
2005 Sep
|
|
4
|
4
|
get_table16 ?
|
edit |
I'm using the UNICODE version of the Sqlite3 commands (e.g. open16, etc) to store widestring in the database. However, get_table returns an array of Pchar instead an array of PWchar, which would be more appropriate. What about providing a UNICODE-version get_table16 of this function? |
2005-Sep-26 16:37:55 by drh:
The sqlite3_get_table() API is provided to support legacy applications
and to ease the transition from version 2. The use of get_table()
by new application is discouraged. New application should use
sqlite3_step(). We do not want to unnecessarily encourage the
use of get_table() by providing get_table16().
If desired, the application can define its own get_table16() function
using the more general sqlite3_step() API. The existing
sqlite3_get_table() can be used as a model. |
|
1452 |
code
|
closed
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
|
3
|
2
|
segmentation fault on OS X tiger
|
edit |
sqlite3 test.db
SQLite version 3.2.7
Enter ".help" for instructions
sqlite> sqlite3(9291) malloc: *** error for object 0x1805c00: incorrect checksum for freed
object - object was probably modified after being freed, break at szone_error to debug
sqlite3(9291) malloc: *** set a breakpoint in szone_error to debug
Segmentation fault
Reproducible with or without database argument |
2005-Sep-24 23:07:50 by drh:
I take the 3.2.7 tarball, untar it, run configure and make, all on
Tiger, and it works fine for me. |
|
1450 |
code
|
closed
|
2005 Sep
|
anonymous
|
Shell
|
2005 Sep
|
|
1
|
1
|
Unable to compile on SCO Openserver(gcc)
|
edit |
Unable to compile on SCO Openserver(gcc) |
2005-Sep-24 10:43:08 by drh:
Trouble report gives us nothing to go on. Unable to fix. |
|
1448 |
code
|
closed
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
|
1
|
4
|
Parse Error In sqlite.c While Compiling PHP-5.0.5
|
edit |
Compiling PHP-5.0.5 on SCO Openserver.
gcc -I/d/cdev/php-5.0.5/ext/sqlite/libsqlite/src -Iext/sqlite/ -I/d/cdev/php-5.0
.5/ext/sqlite/ -DPHP_ATOM_INC -I/d/cdev/php-5.0.5/include -I/d/cdev/php-5.0.5/ma
in -I/d/cdev/php-5.0.5 -I/u/libxml2/include/libxml2 -I/usr/local/include -I/d/my
sql/include/mysql -I/u/libxslt/include -I/d/cdev/php-5.0.5/TSRM -I/d/cdev/php-5.
0.5/Zend -g -O2 -c /d/cdev/php-5.0.5/ext/sqlite/sqlite.c -o ext/sqlite/sqlit
e.o && echo > ext/sqlite/sqlite.lo
/d/cdev/php-5.0.5/ext/sqlite/sqlite.c:2751: parse error before `13'
make: *** [ext/sqlite/sqlite.lo] Error 1
I'm not using sqlite but thought you might need to know about this.
Thanks,
Dean |
2005-Sep-23 17:31:23 by drh:
The PHP developers need to know about this, not us.
PHP bundles their own private copy of SQLite.
We do not have access to the PHP source tree and have no
means of fixing the problem, whatever it is. |
|
1446 |
todo
|
closed
|
2005 Sep
|
|
|
2005 Sep
|
|
4
|
4
|
Milestones are not tagged in CVS
|
edit |
When trying to compare Apples 3.1.3 based changes to base 3.1.3, I noticed milestones are not tagged, thus making it difficult to create a sandbox of the desired milestone. Milestones should be tagged with a consistent format, such that the tag is intuitive and easy to guess. If SQLite were ever to move to another source control system, such as SVN, these tags may be vital to reproduce releases in the future. I'd suggest tags such as RELEASE_SQLite_3_1_3 for release milestones. |
2005-Sep-21 14:16:36 by drh:
Use the -D option to CVS to get code from a milestone. If you
click on the milestone to bring up its description page, there is
a hyperlink on the right-hand side of the page that says
"Tagginig And Branching Hints" that will tell you exactly
what you need to do.
For milestone 3.1.3, for example, see
http://www.sqlite.org/cvstrac/taghints?cn=2356
2005-Sep-21 15:26:47 by anonymous:
Using "cvs rtag" to create the milestones should make them appear in both CVS and CVSTrac and they'd survive conversion from CVS to something else. |
|
1443 |
code
|
closed
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
drh
|
3
|
3
|
pragma full_column_names and short_column_names seems not working.
|
edit |
sqlite> create table foo (c1 char, c2 char, c3 char);
sqlite> create table bar (c1 char, c2 char, c3 char);
sqlite> insert into foo values ('1','2','3');
sqlite> insert into bar values ('4','5','6');
sqlite> .mode column
sqlite> .header on
sqlite> select * from foo,bar;
c1 c2 c3 c1 c2 c3
---------- ---------- ---------- ---------- ---------- ----------
1 2 3 4 5 6
sqlite> pragma full_column_names=1;
sqlite> select * from foo,bar;
c1 c2 c3 c1 c2 c3
---------- ---------- ---------- ---------- ---------- ----------
1 2 3 4 5 6
sqlite> select foo.*, bar.* from foo, bar;
c1 c2 c3 c1 c2 c3
---------- ---------- ---------- ---------- ---------- ----------
1 2 3 4 5 6
sqlite> select f.*, b.* from foo as f, bar as b;
c1 c2 c3 c1 c2 c3
---------- ---------- ---------- ---------- ---------- ----------
1 2 3 4 5 6
sqlite> pragma full_column_names=0;
sqlite> select * from foo,bar;
c1 c2 c3 c1 c2 c3
---------- ---------- ---------- ---------- ---------- ----------
1 2 3 4 5 6
sqlite> select foo.*, bar.* from foo, bar;
c1 c2 c3 c1 c2 c3
---------- ---------- ---------- ---------- ---------- ----------
1 2 3 4 5 6
sqlite> select f.*, b.* from foo as f, bar as b;
c1 c2 c3 c1 c2 c3
---------- ---------- ---------- ---------- ---------- ----------
1 2 3 4 5 6
sqlite> pragma shor_column_names=0;
sqlite> pragma full_column_names=1;
sqlite> select * from foo,bar;
c1 c2 c3 c1 c2 c3
---------- ---------- ---------- ---------- ---------- ----------
1 2 3 4 5 6
sqlite> select foo.*, bar.* from foo, bar;
c1 c2 c3 c1 c2 c3
---------- ---------- ---------- ---------- ---------- ----------
1 2 3 4 5 6
sqlite> select f.*, b.* from foo as f, bar as b;
c1 c2 c3 c1 c2 c3
---------- ---------- ---------- ---------- ---------- ----------
1 2 3 4 5 6
sqlite>
|
You have to turn SHORT_COLUMN_NAMES off first.
pragma short_column_names=0;
pragma full_column_names=1;
Please note that these pragmas are not officially supported. |
|
1442 |
code
|
closed
|
2005 Sep
|
anonymous
|
Parser
|
2005 Sep
|
|
1
|
1
|
sqlite3 3.2.6/3.2.2/3.2.1 reproductible crash
|
edit |
Hi
I am unable to successfully run the following SQL section (using the sqlite3 command line for example, the bug also happens from an application I have that uses sqlite3).
$ cat test.sql
CREATE TABLE table1 (uid int NOT NULL PRIMARY KEY default '0');
ALTER TABLE table1 ADD uid int NOT NULL PRIMARY KEY DEFAULT '0';
ALTER TABLE table1 ADD username varchar(32) DEFAULT NULL;
ALTER TABLE table1 ADD username2 varchar(32) DEFAULT NULL;
UPDATE table1 SET username2 = lower(username);
ALTER TABLE table1 ADD userid int DEFAULT NULL;
ALTER TABLE table1 ADD passhash1 varchar(128) DEFAULT NULL;
ALTER TABLE table1 ADD email varchar(128) DEFAULT NULL;
ALTER TABLE table1 ADD admin varchar(16) DEFAULT 'false';
ALTER TABLE table1 ADD normallogin varchar(16) DEFAULT 'true';
ALTER TABLE table1 ADD changepass varchar(16) DEFAULT 'true';
ALTER TABLE table1 ADD changeprofile varchar(16) DEFAULT 'true';
ALTER TABLE table1 ADD botlogin varchar(16) DEFAULT 'true';
ALTER TABLE table1 ADD operator varchar(16) DEFAULT 'false';
$ cat test.sql | valgrind --num-callers=10 sqlite3 te
st.db 2> sqlite-valgrind.log
ALTER TABLE table1 ADD uid int NOT NULL PRIMARY KEY DEFAULT '0';
SQL error: duplicate column name: uid
Segmentation fault
$ cat sqlite-valgrind.log
==10073== Memcheck, a memory error detector for x86-linux.
==10073== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==10073== Using valgrind-2.4.0, a program supervision framework for x86-linux.
==10073== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==10073== For more details, rerun with: -v
==10073==
==10073== Invalid write of size 4
==10073== at 0x1B925784: sqlite3AddColumn (build.c:844)
==10073== by 0x1B93B686: yy_reduce (parse.y:136)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB6F544 is 0 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid write of size 1
==10073== at 0x1B925789: sqlite3AddColumn (build.c:851)
==10073== by 0x1B93B686: yy_reduce (parse.y:136)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB6F556 is not stack'd, malloc'd or (recently) free'd
==10073==
==10073== Invalid write of size 4
==10073== at 0x1B92578D: sqlite3AddColumn (build.c:845)
==10073== by 0x1B93B686: yy_reduce (parse.y:136)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB6F544 is 0 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid write of size 4
==10073== at 0x1B92579A: sqlite3AddColumn (build.c:852)
==10073== by 0x1B93B686: yy_reduce (parse.y:136)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB6F550 is 12 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid write of size 4
==10073== at 0x1B925960: sqlite3AddColumnType (build.c:943)
==10073== by 0x1B93B6DB: yy_reduce (parse.y:201)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB6F54C is 8 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid write of size 1
==10073== at 0x1B92598E: sqlite3AddColumnType (build.c:951)
==10073== by 0x1B93B6DB: yy_reduce (parse.y:201)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB6F556 is not stack'd, malloc'd or (recently) free'd
==10073==
==10073== Invalid read of size 4
==10073== at 0x1B925A60: sqlite3AddDefaultValue (build.c:973)
==10073== by 0x1B93B7AD: yy_reduce (parse.y:214)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB6F548 is 4 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid write of size 4
==10073== at 0x1B925A76: sqlite3AddDefaultValue (build.c:974)
==10073== by 0x1B93B7AD: yy_reduce (parse.y:214)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB6F548 is 4 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid read of size 4
==10073== at 0x1B91B989: sqlite3AlterFinishAddColumn (alter.c:397)
==10073== by 0x1B93D66D: yy_reduce (parse.y:986)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB6F548 is 4 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid read of size 1
==10073== at 0x1B91B9BF: sqlite3AlterFinishAddColumn (alter.c:413)
==10073== by 0x1B93D66D: yy_reduce (parse.y:986)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB6F555 is not stack'd, malloc'd or (recently) free'd
==10073==
==10073== Invalid read of size 1
==10073== at 0x1B91B9D4: sqlite3AlterFinishAddColumn (alter.c:421)
==10073== by 0x1B93D66D: yy_reduce (parse.y:986)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB6F554 is not stack'd, malloc'd or (recently) free'd
==10073==
==10073== Invalid read of size 4
==10073== at 0x1B924D04: sqliteResetColumnNames (build.c:397)
==10073== by 0x1B924DA8: sqlite3DeleteTable (build.c:450)
==10073== by 0x1B946FC3: sqlite3RunParser (tokenize.c:425)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB6F544 is 0 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid read of size 4
==10073== at 0x1B924D0F: sqliteResetColumnNames (build.c:398)
==10073== by 0x1B924DA8: sqlite3DeleteTable (build.c:450)
==10073== by 0x1B946FC3: sqlite3RunParser (tokenize.c:425)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB6F548 is 4 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid read of size 4
==10073== at 0x1B924D1A: sqliteResetColumnNames (build.c:399)
==10073== by 0x1B924DA8: sqlite3DeleteTable (build.c:450)
==10073== by 0x1B946FC3: sqlite3RunParser (tokenize.c:425)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB6F54C is 8 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid write of size 4
==10073== at 0x1B91BD26: sqlite3AlterBeginAddColumn (alter.c:530)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB7B894 is 0 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid read of size 4
==10073== at 0x1B91BD4B: sqlite3AlterBeginAddColumn (alter.c:533)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB7B894 is 0 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid write of size 4
==10073== at 0x1B91BD55: sqlite3AlterBeginAddColumn (alter.c:533)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB7B894 is 0 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid write of size 4
==10073== at 0x1B91BD57: sqlite3AlterBeginAddColumn (alter.c:534)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB7B89C is 8 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid write of size 4
==10073== at 0x1B91BD5E: sqlite3AlterBeginAddColumn (alter.c:535)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB7B898 is 4 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid read of size 4
==10073== at 0x1B925745: sqlite3AddColumn (build.c:828)
==10073== by 0x1B93B686: yy_reduce (parse.y:136)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x1BB7B894 is 0 bytes after a block of size 180 alloc'd
==10073== at 0x1B903368: malloc (vg_replace_malloc.c:130)
==10073== by 0x1B949C84: sqlite3Malloc (util.c:262)
==10073== by 0x1B91BCC5: sqlite3AlterBeginAddColumn (alter.c:525)
==10073== by 0x1B93D689: yy_reduce (parse.y:989)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== Invalid read of size 4
==10073== at 0x1B91BBC9: sqlite3AlterFinishAddColumn (alter.c:476)
==10073== by 0x1B93D66D: yy_reduce (parse.y:986)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==10073==
==10073== Process terminating with default action of signal 11 (SIGSEGV)
==10073== Access not within mapped region at address 0x0
==10073== at 0x1B91BBC9: sqlite3AlterFinishAddColumn (alter.c:476)
==10073== by 0x1B93D66D: yy_reduce (parse.y:986)
==10073== by 0x1B93D951: sqlite3Parser (parse.c:3303)
==10073== by 0x1B946E62: sqlite3RunParser (tokenize.c:387)
==10073== by 0x1B9350CF: sqlite3_prepare (main.c:1056)
==10073== by 0x1B958E5E: sqlite3_exec (legacy.c:56)
==10073== by 0x804CA04: process_input (shell.c:1503)
==10073== by 0x804D09A: main (shell.c:1795)
==10073==
==10073== ERROR SUMMARY: 79 errors from 21 contexts (suppressed: 29 from 1)
==10073== malloc/free: in use at exit: 20339 bytes in 216 blocks.
==10073== malloc/free: 2234 allocs, 2018 frees, 475061 bytes allocated.
==10073== For counts of detected errors, rerun with: -v
==10073== searching for pointers to 216 not-freed blocks.
==10073== checked 144496 bytes.
==10073==
==10073== LEAK SUMMARY:
==10073== definitely lost: 2681 bytes in 32 blocks.
==10073== possibly lost: 0 bytes in 0 blocks.
==10073== still reachable: 17658 bytes in 184 blocks.
==10073== suppressed: 0 bytes in 0 blocks.
==10073== Use --leak-check=full to see details of leaked memory.
|
2005-Sep-19 11:29:32 by anonymous:
Duh... please close this... When I run sqlite3 -version I found out I was using a source installed "/usr/local/bin/sqlite3" binary of version 3.2.0 instead of the /usr/bin/sqlite3 (of version 3.2.6). Sorry for the trouble :( |
|
1439 |
code
|
closed
|
2005 Sep
|
anonymous
|
Unknown
|
2005 Sep
|
|
3
|
3
|
Format String inserting a text
|
edit |
I think there is a format string when i try to insert a text with "\"\:\:\""
sqlite> CREATE TABLE news (id INTEGER PRIMARINTEGERY KEY, titulo TEXT, date TEXT, texto TEXT);
sqlite> INSERT INTO news (titulo, date, texto) values ("Many files to transfer", "18/09/05", "\"\:\:\"");
Segmentation fault
I hope this help...
Regards
Rafael |
2005-Sep-19 10:30:32 by anonymous:
you mean "::"?
just try to use ' not ". this case '"::"' is ok.
2005-Sep-19 12:40:51 by drh:
Only MySQL uses backslashes to quote characters in a string
literal. The SQL standard is to double the string delimiter.
No segfault occurs in 2.8.16. |
|
1438 |
code
|
closed
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
|
4
|
4
|
UPDATE bug
|
edit |
UPDATE 'online' SET 'timestamp' = 66 WHERE 'usern' = 'cvcncfanatic'; does not have any effect on sqlite (no error either, just nothing but also won't update), workaround: remove the 's arround the table names
makes: UPDATE 'online' SET timestamp = 66 WHERE usern = 'cvcncfanatic'; |
2005-Sep-18 11:15:10 by anonymous:
i missed in version: its 2.8.16
2005-Sep-18 11:26:14 by drh:
The expression 'usern'='cvcncfanatic' is always false. It is a
comparison between two string constants. Because it is always
false, the UPDATE is applied to no rows.
Works as designed and in accordance with SQL standards. |
|
1436 |
code
|
closed
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
|
1
|
1
|
cvs HEAD does not return rows for a query that works on older versions
|
edit |
CVS HEAD fails to return the one row result that previous versions (including 3.2.5) returned. |
2005-Sep-17 15:52:46 by drh:
The change in behavior is actually a consequence of fixing
ticket #1413. A SUM() of all NULL values is a NULL. If you
think this is a goofy idea, you will get no argument from me,
but it is the SQL standard so I suppose I have to go with it.
Your workaround is to say:
SUM(coalesce(FlavorScores.value,0)) as flavorScore
in place of
SUM(FlavorScores.value) AS flavorScore
|
|
1434 |
code
|
closed
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
|
1
|
1
|
.dump dumps sqlite_stat1, which makes it impossible to load dump
|
edit |
.dump dumps sqlite_stat1, which makes it impossible to load into sqlite to re-create the database.
test case:
rm -f /tmp/db /tmp/db2
sqlite3 /tmp/db "create table foo(bar); analyze;"
sqlite3 /tmp/db .dump | sqlite3 /tmp/db2
results:
CREATE TABLE sqlite_stat1(tbl,idx,stat);
SQL error: object name reserved for internal use: sqlite_stat1 |
See prior ticket #1419 and check-in [2687]
|
|
1430 |
event
|
closed
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
|
3
|
3
|
pragma index_list(table) doesn' twork correct with integer PKs
|
edit |
I have created a table with the following SQL statement:
CREATE TABLE foo (fookey varchar(10), foodesc varchar(255), primary key (fookey))
When I do a pragma index_list("foo"), the engine returns a index named
"sqlite_autoindex_foo_1".
But if I create the table with the following SQL statement:
CREATE TABLE bar (barkey integer, bardesc varchar(255), primary key (barkey))
When I do a pragma index_list("bar"), the engine does not return a index named ""sqlite_autoindex_bar_1". Looking at the code in build.c, in routine sqlite3AddPrimaryKey, I found the following code:
if( zType && sqlite3StrICmp(zType, "INTEGER")==0 ){
pTab->iPKey = iCol;
pTab->keyConf = onError;
pTab->autoInc = autoInc;
}else if( autoInc ){
#ifndef SQLITE_OMIT_AUTOINCREMENT
sqlite3ErrorMsg(pParse, "AUTOINCREMENT is only allowed on an "
"INTEGER PRIMARY KEY");
#endif
}else{
sqlite3CreateIndex(pParse, 0, 0, 0, pList, onError, 0, 0);
pList = 0;
}
The engine is creating a index ONLY if the field of the primary key is not a integer. I think that is the desing of the SQLite engine, but how much is complicated for you to return a "sqlite_autoindex_bar_1" in the result of the command
pragma index_list("bar")
I know that is a not-important problem, but would be nice if the engine return this result as the other tables with non-integer primary keys returns. |
2005-Sep-15 17:21:26 by anonymous:
There is no index created when the PK is an integer. You don't want the engine to tell you about indexes that don't exist, do you?
2005-Sep-15 17:49:58 by drh:
Anonymous remark above is correct. The current operation is
as intended.
2005-Sep-15 23:55:17 by anonymous:
Just use "int" term not "integer" in that case.
2005-Sep-16 10:46:52 by anonymous:
but in this case, the engine does use a special in memory index for doing this ? I don't have read entire code, but in my mind, the btree engine will mantain a in-memory index or something like this ?
2005-Sep-16 12:16:40 by anonymous:
Every table is an index, and every index has a unique row identifier within the index (that you normally don't see). When you specify an INTEGER column as the PK, the engine uses the values in that column as the unique row identifiers for the Btree that stores the table data rather than adding its own hidden unique-value column. As such no index is needed.
2005-Sep-16 15:38:22 by anonymous:
ok. it´s exatcly I was in mind. Thanks for the answer.
The SQLite is a GREAT db engine. |
|
1422 |
code
|
closed
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
|
1
|
1
|
incorrect error codes from sqlite3_errCode
|
edit |
when a sqlite3_Step call fails, say on a unique key violation of an INSERT statement, the returned error code is SQLITE_ERROR, which is documented. calling sqlite3_errcode at this point, however, also gives the same error, which is not. the correct error, which is SQLITE_CONSTRAINT, is only returned when calling sqlite3_finalize, which may happen at a much later stage in the code. I believe the error code should be returned right at the point where the error happens, because if it is not, the structure of the code suffers. |
2005-Sep-12 23:13:49 by drh:
You are probably right, it should do this. But it does not. And
to change it now would break backwards compatibility. I wish someone
had brought this problem to my attention during the beta period. |
|
1421 |
code
|
closed
|
2005 Sep
|
anonymous
|
BTree
|
2005 Sep
|
|
2
|
2
|
Assertion when I try to create a index
|
edit |
When I tried to create an index on a table I have created 400,000 records for I get an Assertion:
Assertion failed: pRoot->pgno==1, file c:\program files\microsoft visual studio\myprojects\sqlite\btree.c, line 2018
This happend on several tries but seemed to go away after the third attempt. |
2005-Sep-12 03:22:53 by anonymous:
Contact Info.
Bill Langlais
Bill_Langlais@percussion.com
Great SQL Engine, I have been very happy with it.
Thanks!
2005-Sep-12 23:16:51 by drh:
Unable to reproduce. There have been 86 separate check-ins to
btree.c since version 3.0.3 was released - many of them significant.
Try upgrading to the latest version. |
|
1416 |
code
|
closed
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
xdong
|
1
|
1
|
database is same size as before when we do clearing operation.
|
edit |
hi,all, I encoutered a problem that the database is same size as before when we have done db clearing operation, as following:
1.our machine was shutdown by the failure of power,
2.after it restartings, we want to insert some data item to db,but can't ,
3.then we clean this database with DELETE ,and we do this to see whether it's valid or not:
sqlite3 ./matrix_admin.db "select count(id) from tbl_admin"
the result is:0
4.now we ls to show its size:
-rw-r--r-- 1 yihe yihe 52277248 Sep 9 10:12 matrix_admin.db
5.ok,the size is same as before.
6.we use vi to see ./matrix_admin.db, some data items are there.
could you help to explain this situation or how to resolve it, thanks all |
2005-Sep-09 03:35:42 by anonymous:
Read the documentation for the VACUUM command and the auto-vacuum pragma. Under normal circumstances, database files don't automatically shrink as rows are deleted.
2005-Sep-09 09:59:02 by drh:
Anonymous above is right. This is not a bug. |
|
1411 |
code
|
closed
|
2005 Sep
|
anonymous
|
Shell
|
2005 Sep
|
anonymous
|
3
|
1
|
how to change database name
|
edit |
I don't know how to change database name, thank you! |
2005-Sep-08 10:33:31 by anonymous:
The file name should be a db name.
2005-Sep-08 10:48:35 by drh:
Please ask usage questions on the mailing list and reserve trouble
tickets for reporting bugs. |
|
1410 |
code
|
closed
|
2005 Sep
|
anonymous
|
Unknown
|
2005 Sep
|
|
2
|
3
|
count(*) confused by newlines in data
|
edit |
I was having some strange behavior in a join where the count(*)
varried in a way that really confused me. It turns out some records
had a newline or carriage return in them, and this caused count(*) to
count them as two records! I saw this in the recent release of
sqlite3. |
2005-Sep-07 17:44:00 by drh:
This is impossible because count(*) does not look at the
content of individual fields in the database (other than to
determine whether or not they are NULL) and so it cannot
possibly produce a different result depending on the presence
or absences of newlines or carriage returns. Something else
is going on.
If a specific test case can be generated that demonstrates a
problem, please insert that test case in the description of
a new ticket and I will investigate it thoroughly.
2005-Nov-17 15:37:05 by anonymous:
I am not able to insert Carriage return in a record.i am using sqlite3.exe to insert data .its not accepting carriage return . iam replacing the carriage return in the data by some special character and then inserting it.
is there any other way to insert data with carriage return.
2005-Nov-17 16:14:40 by anonymous:
Carriage returns work fine for me as shown below:
SQLite version 3.2.7
Enter ".help" for instructions
sqlite> create table t (a,b);
sqlite> insert into t values (1,'some
...> more text
...> spread accross
...> ');
sqlite> select * from t;
1|some
more text
spread accross
sqlite>
|
|
1408 |
code
|
closed
|
2005 Sep
|
anonymous
|
Parser
|
2005 Sep
|
|
1
|
1
|
ATTACH DATABASE doesn't support *.db files
|
edit |
It seems for SQLite 3.2.5 (Official Windows Build) that doesn't support attaching database files, which have any extensions (I tried with .db)...
Example:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\>sqlite3 :memory:
SQLite version 3.2.5
Enter ".help" for instructions
sqlite> ATTACH DATABASE data.db;
SQL error: near ".": syntax error
sqlite>
|
2005-Sep-05 15:10:00 by drh:
You are using incorrect syntax on the ATTACH command.
See the documentation or post on the mailing list for
help. |
|
1406 |
code
|
closed
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
|
1
|
1
|
no result with order by
|
edit |
hi
i have the following tables:
CREATE TABLE Rohstoff (
Nummer INTEGER PRIMARY KEY NOT NULL,
Bezeichnung VARCHAR(35) NOT NULL DEFAULT '',
Gruppe SMALLINT NOT NULL DEFAULT 0,
Art SMALLINT NOT NULL DEFAULT 0,
Erstellt DATE DEFAULT CURRENT_DATE,
Mutation DATE DEFAULT CURRENT_DATE)
CREATE TABLE Ressource (
Id SMALLINT NOT NULL DEFAULT 0,
Nr SMALLINT NOT NULL DEFAULT 0,
Text VARCHAR(35) NOT NULL DEFAULT '')
CREATE TABLE Artikel (
RezeptNr INTEGER NOT NULL DEFAULT 0,
Zeile SMALLINT NOT NULL DEFAULT 0,
Artikel INTEGER NOT NULL DEFAULT 0,
Menge NUMERIC(18, 3) NOT NULL DEFAULT 0,
Stk SMALLINT NOT NULL DEFAULT 0)
I have a select command to find out, which rows in the table 'artikel' are not in the table 'rohstoff' with some
details from the table 'ressource'.
The select:
SELECT T1.NUMMER, T1.BEZEICHNUNG, T2.TEXT AS ART, T1.MUTATION
FROM ROHSTOFF T1, RESSOURCE T2 LEFT JOIN ARTIKEL T3
ON T1.NUMMER = T3.ARTIKEL
WHERE T1.ART = T2.NR AND T2.ID = 8 AND T3.ARTIKEL IS NULL
returns some rows. this is correct.
when i add a order by => "ORDER BY T1.BEZEICHNUNG"
no rows are returned.
in earlier versions (for example 3.2.2) it has worked fine.
any idea? |
2005-Sep-05 02:31:50 by drh:
Please provide some data that can be used to reproduce the problem.
2005-Sep-05 20:27:14 by drh:
Using sample data provided by the person who submitted this ticket
(and sent to me directly by email) I get the same results with and
without the ORDER BY clause (though in a different order, naturally).
Unable to reproduce. |
|
1404 |
event
|
closed
|
2005 Sep
|
anonymous
|
Unknown
|
2005 Sep
|
|
1
|
1
|
pragma case_sensitive_like is broken?
|
edit |
when execute pragma case_sensitive_like command , no result return, reproduce steps is below
D:\Temp>sqlite3 test.db3
SQLite version 3.2.5
Enter ".help" for instructions
sqlite> create table tbl1(one varchar(10), two smallint);
sqlite> pragma case_sensitive_like;<<---no case_sensitive_like result return
sqlite> pragma count_changes;
0
sqlite>
|
2005-Sep-08 10:54:07 by drh:
The user is able to override the LIKE() function and change the
behavior of the LIKE command. So there is no way for a PRAGMA
to reliably determine whether or not LIKE is case sensitive. |
|
1402 |
code
|
closed
|
2005 Sep
|
anonymous
|
Unknown
|
2005 Sep
|
|
1
|
2
|
(Windows 2K) file handle on file not released after use
|
edit |
Using sqlite3 in wrapper for Delphi6 (Aucom). Files are created OK. On closure of connection, file being addressed still locked by Windows (according to procexp). On connection to file being dropped, all handles referred to through connection should be released (and they are not). Will be logging with Aucom as well. |
2005-Sep-05 20:13:57 by drh:
The regression test suite for SQLite checks for unclosed file
handles and it finds none. So until I hear otherwise, I'm going
to assume this is an Aucom problem. |
|
1383 |
code
|
closed
|
2005 Aug
|
anonymous
|
VDBE
|
2005 Aug
|
|
1
|
1
|
Whole doubles get a dot zero when promoted to string
|
edit |
e.g. in C:
double foo = 45;
printf("%.15g\n", foo);
shows 45.
sqlite makes this "45.0"
Problem seems to be in :
sqlite3VdbeMemStringify calling
sqlite3_snprintf(NBFS, z, "%!.15g", pMem->r)
This is incompatible with previous versions of sqlite3 and it makes for more space wasted too e.g. if someone keeps many doubles which are really whole numbers. |
2005-Aug-26 22:10:23 by drh:
This was changed to fix ticket #1362. |
|
1377 |
warn
|
closed
|
2005 Aug
|
anonymous
|
|
2005 Aug
|
dwong
|
1
|
1
|
can't connect to database
|
edit |
how can i connect with my database?
Warning: sqlite_open() [function.sqlite-open]: file is encrypted or is not a database in c:\Inetpub\wwwroot\project\index.php on line 8
Warning: sqlite_single_query() expects parameter 1 to be resource, string given in c:\Inetpub\wwwroot\project\index.php on line 14 |
2005-Aug-24 10:58:46 by drh:
Please use the mailing list for help with usage questions and
reserve tickets for actual bugs. |
|
1369 |
new
|
closed
|
2005 Aug
|
anonymous
|
Shell
|
2005 Aug
|
drh
|
5
|
5
|
Inefficient restoration of indexed dumps
|
edit |
When dumping the database (or table) by means of the .dump shell command, all indices etc. appears after the INSERT statements. Such
ordering can prevent a database engine (not necessary SQLite) from efficient utilization of the indices (for example, in constraints checking) when recreating a database from dumps, thus slowing down
all process.
Unfortunately, to correct this behaviour (that is, issue CREATE INDEX just after CREATE TABLE) at least two functions should be changed, namely do_meta_command() and dump_callback(), so I can't provide reasonable patches now. |
2005-Aug-19 17:13:15 by drh:
I do not know about other database engines, but in SQLite it is
much faster to create the indices as a separate step after all
data has been inserted rather than creating the indices before
inserting the data. The current implementation of ".dump" was
designed with this fact in mind. The current .dump output
format helps SQLite reload a database about 2 times faster than
if the indices were created early. |
|
1367 |
new
|
closed
|
2005 Aug
|
anonymous
|
Shell
|
2005 Aug
|
peter
|
1
|
1
|
connection string for SQLite with some examples
|
edit |
I couldnt find a connection string for sqlite.I am not able to find connection string for connecting C# with SQLite in google.I need some examples code which could be helpfull.
Aline in reply would be appreciated .
Thanks
prabhu |
2005-Aug-17 19:07:29 by drh:
This is a usage question, not a bug report. Please send questions
on how to use SQLite to the SQLite mailing list.
http://www.sqlite.org/support.html |
|
1366 |
code
|
closed
|
2005 Aug
|
anonymous
|
VDBE
|
2005 Aug
|
|
3
|
3
|
not getting SQLITE_CORRUPT when corruption detected in a SELECT
|
edit |
We use sqlite in a desktop software application and have had problem reports from a small number of users that we've traced back to their database file being corrupted. I had one user send me his database file, and the return from the integrity check was:
sqlite> PRAGMA INTEGRITY_CHECK;
*** in database main ***
On page 3 at right child: invalid page number 22
ok
(The version of sqlite in our current app is 3.0.8, but we're in the process of upgrading to 3.2.2).
When I ran our code against his file the first error happens when we do a "SELECT count(*) FROM <table>" query. The error that gets returned from sqlite3_step() is SQLITE_ERROR, but when I call sqlite3_errcode() for extended information it just returns SQLITE_ERROR as well.
I was curious why I didn't get SQLITE_CORRUPT returned instead. In the debugger (against sqlite 3.2.2) I stepped through sqlite3_step() to see what's happening, and inside sqlite3VdbeExec() I found that in the OP_Next case the error SQLITE_CORRUPT is returned by sqlite3BtreeNext(). This gets stored into rc, and the for loop exits and we fall down into the vdbe_halt: labeled code. That code stashes SQLITE_CORRUPT into p->rc, and returns SQLITE_ERROR. Then back in sqlite3_step() the call to sqlite3Error() ends up saving SQLITE_ERROR into db->errCode, and that's what I get when I call sqlite3_errcode().
For my case at least, I think the right thing would be for sqlite3_step() to pass p->rc instead of rc to sqlite3Error(), but I see some cases in sqlite3VdbeExec() where it returns an error code other than SQLITE_ERROR, and doesn't stash it in p->rc. (These cases seem to violate the comment at the top of sqlite3VdbeExec() which states "If an error occurs...The error code is stored in p->rc and this routine returns SQLITE_ERROR".) |
2005-Aug-17 18:28:04 by drh:
SQLITE_CORRUPT gets returned when you call sqlite3_reset() or
sqlite3_finalize().
This is unfortunate, I know. We should have designed the API so
that the specific error was returned directly from sqlite3_step().
But we didn't. And nobody commented on the problem during the
beta period. We cannot change it now without breaking backwards
compatibility. So we are stuck with the current mode of operation. |
|
1364 |
code
|
closed
|
2005 Aug
|
anonymous
|
|
2005 Aug
|
|
3
|
3
|
variable Timeout does not exist anymore in main.c
|
edit |
While porting SQLite 3.2.2 to BeOS I noticed that in the main.c (function sqliteDefaultBusyCallback, line 301) the variable Timeout ist used, when SQLITE_MIN_SLEEP_MS is set to 1000. But Timeout does not exist anymore.
I found that in a former version (2.8.11), Timeout was a parameter value that is not used in the newer version. |
2005-Aug-16 11:00:38 by drh:
Duplicate of #1284. Already fixed. |
|
1361 |
code
|
closed
|
2005 Aug
|
anonymous
|
Unknown
|
2005 Sep
|
|
1
|
1
|
sqlite3_mprintf function(s) don't account for commas with %q flag
|
edit |
Commas are also not accounted for when using the sqlite3_mprintf() function(s). I'm guessing the %q flag should also escape these.
Ticket #1312 has a related issue.
[Update: I reopened this one because I think I found the root of what I mistook as the problem of not handling commas properly. Thanks for your help.]
[Update again: I reopened this again for the issue regarding the website's search feature.] |
2005-Aug-12 23:24:26 by drh:
%q only escapes characters that are meaningful within SQL
string literals. Commas are not in that category. Commas
might be meaningful to CSV files, but not to SQL in the
context of a string literal.
2005-Aug-12 23:43:36 by anonymous:
Thanks for the remarks. I think I've found what is the root of this issue. When using the %q flag it seems to be working differently when I use a lower-case %q and a capital %Q. In fact, it only works properly when I use capital %Q flags. Is this by design? In the documentation, it references the use of the lower-case version.
Here's an example of what is happening:
( Using the C++ wrapper from here http://www.codeproject.com/database/CppSQLite.asp )
Creating the table like this (which works fine):
CppSQLite3Buffer CreateBuffer;
CreateBuffer.format("CREATE TABLE TESTING (UserNumber INTEGER PRIMARY KEY, LastName CHAR(30), FirstName CHAR(20), Comments CHAR(40), ExtraStuff CHAR(60));");
theApp.m_MemberDatabase.execDML(CreateBuffer);
Then if I do an insert like this, it results in the following error "SQLITE_ERROR[1]: near "line": syntax error"
CppSQLite3Buffer InsertBuffer;
InsertBuffer.format("INSERT INTO TESTING values(%d, %q, %q, %q, %q);",
123,
"Jones",
"Bob",
"This line has a comma, in it.",
"more stuff");
theApp.m_MemberDatabase.execDML(InsertBuffer);
If I do the insert like this, it works fine:
CppSQLite3Buffer InsertBuffer;
InsertBuffer.format("INSERT INTO TESTING values(%d, %Q, %Q, %Q, %Q);",
123,
"Jones",
"Bob",
"This line has a comma, in it.",
"more stuff");
theApp.m_MemberDatabase.execDML(InsertBuffer);
2005-Aug-13 00:27:16 by drh:
%q and %Q are different by design. Please see the documentation.
2005-Aug-13 00:38:55 by anonymous:
Okay, thanks for the information, and sorry to be quick to submit this as a possible bug.
Could you please point me to the proper documentation for this? The only thing I could find is this page, and it doesn't specity that %q and %Q are different as it only mentions %q:
http://www.sqlite.org/capi3ref.html#sqlite3_vmprintf
Also, using a search phrase of "%Q" (without the quotes) produces an error on this page:
http://www.sqlite.org/cvstrac/search?w=1
Searching for "%q" does not fail, however.
2005-Aug-13 00:49:49 by anonymous:
how about using like this?
CppSQLite3Buffer InsertBuffer; InsertBuffer.format("INSERT INTO TESTING values(%d, '%q', '%q', '%q', '%q');", 123, "Jones", "Bob", "This line has a comma, in it.", "more stuff");
see sqlite3_vmprintf document(http://www.sqlite.org/capi3ref.html#sqlite3_vmprintf).
2005-Aug-13 01:11:32 by anonymous:
Yes, putting the %q flags in single quotes ... '%q' ... does work, thanks for pointing that out. But the Q% flag does this automatically, so I'm still not quite sure what the difference between %q and %Q actually is.
Can someone please kindly point to the documentation that explains the difference? For some reason, it is very hard for me to find via searching. Thanks!
2005-Aug-13 22:59:03 by anonymous:
Just look at printf.c in the source files. you will see as follows:
/*
** Conversion types fall into various categories as defined by the
** following enumeration.
*/
#define etRADIX 1 /* Integer types. %d, %x, %o, and so forth */
#define etFLOAT 2 /* Floating point. %f */
#define etEXP 3 /* Exponentional notation. %e and %E */
#define etGENERIC 4 /* Floating or exponential, depending on exponent. %g */
#define etSIZE 5 /* Return number of characters processed so far. %n */
#define etSTRING 6 /* Strings. %s */
#define etDYNSTRING 7 /* Dynamically allocated strings. %z */
#define etPERCENT 8 /* Percent symbol. %% */
#define etCHARX 9 /* Characters. %c */
#define etERROR 10 /* Used to indicate no such conversion type */
/* The rest are extensions, not normally found in printf() */
#define etCHARLIT 11 /* Literal characters. %' */
#define etSQLESCAPE 12 /* Strings with '\'' doubled. %q */
#define etSQLESCAPE2 13 /* Strings with '\'' doubled and enclosed in '',
NULL pointers replaced by SQL NULL. %Q */
#define etTOKEN 14 /* a pointer to a Token structure */
#define etSRCLIST 15 /* a pointer to a SrcList */
#define etPOINTER 16 /* The %p conversion */ |
|
1360 |
code
|
closed
|
2005 Aug
|
anonymous
|
|
2005 Aug
|
|
4
|
4
|
Unsafe casting in table.c
|
edit |
In table.c there are two unsafe casts:
line 146:
res.azResult[0] = (char*)res.nData;
line 191:
n = (int)azResult[0];
This is unsafe because it makes the false assumption that an int and a pointer are the same size. This is not true on some platforms, and data will be lost. However, it seems unlikely that for this partiular API that there will ever be a table big enough to overflow an int or pointer and cause problems so this is not a major issue. On some compilers/platforms a warning will be generated. |
2005-Aug-12 23:21:25 by anonymous:
I just found bug 848 (http://www.sqlite.org/cvstrac/tktview?tn=848), this seems to overlap that somewhat. For some reason 848 was marked fixed even though there are some problems remaining.
2005-Aug-13 00:59:44 by drh:
You are correct that this is not a major issue.
I do not see how this could cause a problem on any reasonable
query (any query that returns less than 2 billion elements).
And I do not want to encourage the use of sqlite3_get_table()
which is really there only to support legacy applications anyhow.
I do not think this issue is worth fixing. |
|
1355 |
code
|
closed
|
2005 Aug
|
anonymous
|
|
2005 Sep
|
|
4
|
4
|
mixing GROUP and non-GROUP queries in a query should be an error
|
edit |
Say I have a table defined and populated as follows:
CREATE TABLE test (a TEXT);
INSERT INTO test (a) VALUES ('hello');
INSERT INTO test (a) VALUES ('hello');
INSERT INTO test (a) VALUES ('hello');
And I perform the following query:
SELECT rowid,count(a) FROM test;
In SQLite I get back:
3|3
But in MySQL I get back an error:
#1140 - Mixing of GROUP columns (MIN(),MAX(),COUNT()...) with no GROUP columns is illegal if there is no GROUP BY clause
I think this should probably be an error in SQLite as well. |
2005-Sep-08 10:49:58 by drh:
Thank you for the suggestion.
I think I am going to leave the SQLite behavior as it is for now. |
|
1352 |
code
|
closed
|
2005 Aug
|
anonymous
|
Pager
|
2005 Aug
|
|
3
|
3
|
Databases created via ATTACH do not respect page_size pragma
|
edit |
- Start the sqlite3 CLI, specifying a non-existent database file as the target database (ex. foo1.db)
- Set the page_size pragma to 4096
- Create a table
- Attach to another non-existent database file (ex. foo2.db)
- Create a table in the attached database file
Exiting the CLI utility and re-opening the first database file (foo1.db) will show that the page_size is 4096 (which is correct). Exiting and opening the previously-attached database file (foo2.db) will show that the page_size is 1024.
Like the encoding pragma, we need the page_size to carry over to attached databases. |
2005-Aug-11 01:56:09 by drh:
In between steps 4 and 5, add the statement:
PRAGMA foo2.page_size=4096
If you always want to use a page size of 4096, you can recompile
using -DSQLITE_DEFAULT_PAGE_SIZE=4096.
2005-Aug-12 01:33:15 by anonymous:
Ahh, thanks. Can/should the documentation be extended to include that information in the description of the PRAGMA command? |
|
1350 |
code
|
closed
|
2005 Aug
|
|
|
2005 Aug
|
|
3
|
3
|
sqlite gives errors with valgrind
|
edit |
Programs using sqlite give errors from valgrind. The easiest way to reproduce is to run the "sqlite3" interactive tool under valgrind:
db $ valgrind sqlite3 does-not-exist.db
==16800== Memcheck, a memory error detector for x86-linux.
==16800== Using valgrind-2.4.0, a program supervision framework for x86-linux.
SQLite version 3.2.2
Enter ".help" for instructions
sqlite> .dump
==16800== Syscall param write(buf) points to uninitialised byte(s)
==16800== at 0x1B923A3B: write (in /lib/libpthread-0.10.so)
...
==16800== by 0x1B98D438: sqlite3OsOpenReadWrite (in /usr/lib/libsqlite3.so.0.8.6)
==16800== by 0x1B98FFE7: sqlite3pager_open (in /usr/lib/libsqlite3.so.0.8.6)
...
==16800== Address 0x52BF8D00 is on thread 1's stack
BEGIN TRANSACTION;
COMMIT;
sqlite>
(this is only an excerpt, there are a buch of those errors for this simple test.)
This does not stricly mean, that there is a bug in sqlite, but it means, that sqlite sometimes writes uniinitiaesed stuff somewhere. (as the stack could have sensible information from a previous function call, this might have issues)
valgrind is available from http://valgrind.org/ |
2005-Aug-08 13:55:11 by drh:
The function sqlite3OsOpenReadWrite() never calls write(), so it
is difficult to understand how this could be a real issue. I note
also that valgrind version 2.2.0 (which is the default on my
SuSE 9.2 installation) finds no problems. I think this is an
instrumentation problem, not an SQLite problem.
2005-Aug-08 21:45:43 by anonymous:
After recompiling sqlite with -g and testing around, I finally found out the trouble maker: pthreads in glibc.
--disable-threadsafe and valgrind is silent.
Otherwise, it's really grumbling here:
#5 0x0804f64f in testThreadLockingBehavior (fd_orig=3) at src/os_unix.c:300
300 pthread_create(&t[0], 0, threadLockingTest, &d[0]);
Excuse me for annoying you with this. |
|
1349 |
code
|
closed
|
2005 Aug
|
anonymous
|
Unknown
|
2005 Aug
|
anonymous
|
4
|
4
|
NULL handling UNIQUE indexes is not consistent
|
edit |
NULL handling for UNIQUE indexes is not consistent and depends on when the index is created.
When a UNIQUE index exists already, inserted or updated NULLs are handled as being distinct values (just like UNIQUE columns), but when the NULL values already exist in a table and an index is created later the values are interpreted as indistinct and the creation of the index fails.
example script:
-- this one works
CREATE TABLE testnull (value);
CREATE UNIQUE INDEX idxtestnull ON testnull (value);
INSERT INTO testnull VALUES (NULL);
INSERT INTO testnull VALUES (NULL);
DROP TABLE testnull;
-- and this one fails
CREATE TABLE testnull (value);
INSERT INTO testnull VALUES (NULL);
INSERT INTO testnull VALUES (NULL);
CREATE UNIQUE INDEX idxtestnull ON testnull (value);
DROP TABLE testnull;
|
2005-Aug-11 02:38:55 by drh:
This is a duplication of ticket #1301 which has already been
fixed. |
|
1344 |
code
|
closed
|
2005 Jul
|
anonymous
|
BTree
|
2005 Aug
|
anonymous
|
3
|
1
|
sqlite does 40 times allocations for a single sql statement
|
edit |
1. sqlite is very slow. It takes more than 50 ms for an update operation in ARM9 system.
2. sqlite needs a lot of dynamic memory operations (sometimes more than 40 malloc) to execute each sql statement that would issues serious heap fragments |
2005-Aug-02 17:49:28 by drh:
Is this a bug, or a comment? |
|
1343 |
code
|
closed
|
2005 Jul
|
anonymous
|
|
2005 Jul
|
|
1
|
1
|
segmentation fault on select on view
|
edit |
when i submit a query like 'SELECT id,title,cathegory FROM version_view GROUP BY cathegory' the shell crashes with 'segmentation fault'.
version view is a view constructed as
CREATE VIEW version_view AS
SELECT version.id AS 'id',
tempo.name AS 'tempo',
cathegory.name AS 'cathegory',
genre.name AS 'genre',
language.name AS 'language',
version.title AS 'title',
version.basic_key AS 'basic_key',
version.version_type AS 'version_type',
version.text AS 'text',
version.comment AS 'comment'
FROM version,tempo,cathegory,genre,language WHERE version.id_tempo = tempo.id AND cathegory.id = version.id_cathegory and genre.id = version.id_genre and language.id = version.id_language;
Complete database schema is attached |
2005-Jul-30 16:35:06 by drh:
This is probably a duplicate of #1039 which has long since
been fixed. |
|
1341 |
code
|
closed
|
2005 Jul
|
anonymous
|
Parser
|
2005 Aug
|
|
3
|
2
|
sqlite_exec() returns always 1 on error
|
edit |
sqlite_exec() always returns 1 on error, although it fills the last var (error string) correctly.
For example, this:
<?php
$idx = sqlite_open(':mem:');
sqlite_query($idx, 'SELECT * ');
var_dump(sqlite_last_error($idx));
?>
it prints '1', althought the warning generated is ok ('no tables specified') |
2005-Aug-13 17:27:22 by drh:
sqlite_exec() return SQLITE_ERROR (which equals 1) when the input
SQL is incorrect. This is as designed.
2005-Aug-14 15:15:55 by anonymous:
But then, I pass the result of sqlite_exec() to sqlite_error_string() and I don't receive any helpfull error.
Can't this behaviour be changed? The problem is that in PHP I don't have any way to retrieve the error message. The result of sqlite_exec() is stored in a variable and when I call sqlite_last_error() it will return the value of that variable. And thats it.
2005-Aug-14 17:31:16 by drh:
The SQLite interface cannot be changed because that would break
backwards compatibility. Perhaps the PHP interface should be
enhanced to provide access to the error message. |
|
1339 |
code
|
closed
|
2005 Jul
|
anonymous
|
|
2005 Jul
|
|
1
|
1
|
Table Create in exists db with exists table = MemoryLeak
|
edit |
Hello Operators !
I am open a exists SQLite.db, and the first call into the
static lib is a crate table. I am ignore if a table exists
or not, result.. i produce memory leaks if the table exists.
here my call to lib with create a easy table, the string is correct
use linebrakes in C listing
CString sqlin("CREATE TABLE ProcFilter (Name VARCHAR(80) PRIMARY KEY DEFAULT \ 'Name',Addicator INTEGER DEFAULT '64', \
Bias INTEGER DEFAULT '1', \
M0 CHAR(48) DEFAULT '0,0,0,0,0,0,0,0,0', \
M1 CHAR(48) DEFAULT '0,0,0,0,0,0,0,0,0', \
M2 CHAR(48) DEFAULT '0,0,0,0,0,0,0,0,0', \
M3 CHAR(48) DEFAULT '0,0,0,0,0,0,0,0,0', \
M4 CHAR(48) DEFAULT '0,0,0,0,1,0,0,0,0', \
M5 CHAR(48) DEFAULT '0,0,0,0,0,0,0,0,0', \
M6 CHAR(48) DEFAULT '0,0,0,0,0,0,0,0,0', \
M7 CHAR(48) DEFAULT '0,0,0,0,0,0,0,0,0', \
M8 CHAR(48) DEFAULT '0,0,0,0,0,0,0,0,0')");
sqlite3_exec(m_pSQLite,sqlin,0,0,0,0);
after terminate my app i got this process results
Detected memory leaks!
Dumping objects ->
{358} normal block at 0x0101C348, 60 bytes long.
Data: <Z > 5A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{357} normal block at 0x0101C2D0, 60 bytes long.
Data: <Z > 5A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{356} normal block at 0x0101C258, 60 bytes long.
Data: <Z > 5A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{355} normal block at 0x0101C1E0, 60 bytes long.
Data: <Z > 5A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{354} normal block at 0x0101C168, 60 bytes long.
Data: <Z > 5A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{353} normal block at 0x0101C0F0, 60 bytes long.
Data: <Z > 5A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{352} normal block at 0x0101C078, 60 bytes long.
Data: <Z > 5A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{351} normal block at 0x0101C000, 60 bytes long.
Data: <Z > 5A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{350} normal block at 0x0101B960, 60 bytes long.
Data: <Z > 5A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{349} normal block at 0x0101B8E8, 60 bytes long.
Data: <Z > 5A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{348} normal block at 0x0101B870, 60 bytes long.
Data: <Z > 5A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{347} normal block at 0x0101B7F8, 60 bytes long.
Data: <Z > 5A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.
|
2005-Jul-29 15:44:22 by drh:
Unable to reproduce. I do not believe that the memory leak is coming
from SQLite. It must be in some other part of your code. |
|
1336 |
code
|
closed
|
2005 Jul
|
anonymous
|
|
2005 Jul
|
|
2
|
3
|
cannot find the symbol Timeout
|
edit |
The function sqliteDefaultBusyCallback() has redfined in sqlite3.2.2 to
static int sqliteDefaultBusyCallback(
void ptr, / Database connection /
int count / Number of times table has been busy /
);
but in main.c line 301 it stil remains these code:
int timeout = (int)Timeout;
in which Timeout is passed by the previous version define:
static int sqliteDefaultBusyCallback(
void *Timeout, / Maximum amount of time to wait /
int count / Number of times table has been busy */
);
This problem cause compilation error:Timeout undeclared.
To fix this problem, we should change these code as follows:
int timeout = ((sqlite3 *)ptr)->busyTimeout; |
2005-Jul-29 15:37:54 by drh:
Duplicate of #1324, which is already fixed. |
|
1335 |
new
|
closed
|
2005 Jul
|
anonymous
|
|
2005 Aug
|
|
5
|
3
|
AllowNull
|
edit |
Would be very usefull to have a function, for example: bool sqlite3_column_allownull(sqlite3_stmt*, int iCol); , that gives the information if a columm allows null or not |
2005-Jul-25 21:58:20 by anonymous:
You can get this information using the pragma table_info command. The documentation from http://www.sqlite.org/pragma.html#schema is copied below.
PRAGMA table_info(table-name);
For each column in the named table, invoke the callback function once with information about that column, including the column name, data type, whether or not the column can be NULL, and the default value for the column. |
|
1333 |
code
|
closed
|
2005 Jul
|
anonymous
|
Shell
|
2005 Jul
|
|
2
|
3
|
sqlite3 command line interfaces segfaults when getpwd() fails
|
edit |
os_unix.c:1293 (sqlite3OsFullPathname)
A call to sqlite3SetString uses the direct result from getpwd, however, if getpwd fails for some reason and thus returns NULL the sqlite shell will segfault before managing to start.
This manifests itself when starting sqlite3 with a db in a relative path. I'm not sure why getcwd is returning EPERM, but it is possible for the function to fail, so this should be handled.
Using an absolute path can be used as a workaround. |
This is a duplicate of #1274. |
|
1330 |
code
|
closed
|
2005 Jul
|
anonymous
|
Shell
|
2005 Aug
|
|
2
|
5
|
The internal function max doesn't work properly
|
edit |
Hello,
I tryed to build up an auto incrementing column like described in your FAQ using the function max(). This works properly for the digits 0-9. After reaching 9 the fuction max() returns 9 every time.
Workaround:
Now I use the function count() for the auto increment. |
2005-Aug-14 12:03:05 by drh:
The INTEGER PRIMARY KEY method works. The max() function also
works fine in version 3.0. |
|
1329 |
code
|
closed
|
2005 Jul
|
anonymous
|
BTree
|
2005 Jul
|
|
5
|
1
|
A bug About select from a table
|
edit |
I have found a bug using sqlite-2.8.15 DLL , I am running under window2000.
My Sql scripts :
create table test(
flno varchar(30) ,
telno varchar(20),
SaleCenter varchar(10),
Sales varchar(10),
status varchar(5),
passwd varchar(20),
succ varchar(2),
ErrCode varchar(10)
);
create index idx_test on test(flno);
The records in table test :
flno|telno|SaleCenter|Sales|status|passwd|succ|ErrCode
55200507180000000004|13330440000|||1|482807|00|00000
55200507180000000005|13330440001|||1|952845|01|00101
then when I make a sql command which is " select * from test where flno ='55200507180000000004'"
,The result return all the rows, it shows:
flno|telno|SaleCenter|Sales|status|passwd|succ|ErrCode
55200507180000000004|13330440000|||1|482807|00|00000
55200507180000000005|13330440001|||1|952845|01|00101
but after I drop the index id_test,it return the right answer:
55200507180000000004|13330440000|||1|482807|00|00000 |
2005-Jul-20 11:23:12 by drh:
The keys are being stored as numbers - the VARCHAR type is ignored
in version 2.8. And integers numbers are only 32 bits, so the keys
have to be stored as doubles - and the difference between the keys is
less than the resolution of a double.
Both these issues are addressed in version 3.X. The changes will
not be back-ported to version 2.8.
As a workaround, you might consider putting a single 'x' character
as a prefix on the text columns that contain pure numeric data. |
|
1326 |
code
|
closed
|
2005 Jul
|
anonymous
|
Unknown
|
2005 Aug
|
|
4
|
1
|
using callbacks with two exact queries duplicate results
|
edit |
When using callbacks for queries that return the same number of columns the results of both queries are joined. In SQLite 2 this error didn't happen. In SQLite 3 there is a need to change the callback procedure in order to know which result (or which query) is being processed, so the appropriate action is taken.
To simulate the problem one should use the example existent in SQlite Quick Start documentation and simply execute two queries that return the same number of columns. If, for instance, one use the same query, the result is the number of records in the table * 2. |
2005-Aug-13 17:22:23 by drh:
It is true that when you use sqlite3_exec() with two queries having
the same number of columns in the result, there is no way to know
when one query ends and the next one begins. But this has always been
the case, all the way back to SQLite version 1.0. This is an
inherent property of the design of sqlite3_exec(). To change it,
you would have to break backwards compatibility.
Use sqlite3_prepare and sqlite3_step instead. |
|
1324 |
code
|
closed
|
2005 Jul
|
anonymous
|
|
2005 Aug
|
anonymous
|
3
|
3
|
main.c (line 301): 'Timeout' meant to be ptr->busyTimeout ?
|
edit |
must compile with SQLITE_MIN_SLEEP_MS != 1, as apparently is done in Qt4.0. Using the example in the '#if' section, the code should be changed from:
int timeout = (int)Timeout;
to:
int timeout = ((sqlite3 *)ptr)->busyTimeout;
Thanks |
2005-Aug-13 18:58:00 by drh:
Duplicate of ticket #1284. |
|
1322 |
code
|
closed
|
2005 Jul
|
anonymous
|
|
2005 Aug
|
|
4
|
4
|
after "select * from sqlite_master;" ".databases" command doesnt work
|
edit |
1) On a windows command line prompt I typed "sqlite ex1" (following the tutorial web pages on this site)
2) I then typed "select * from sqlite_master;"
output was:
----------
table|tbl1|tbl1|3|create table tbl1(one varchar(10),two smallint)
table|tbl2|tbl2|5|create table tbl2(
f1 varchar(30) primary key,
f2 text,
f3 real
)
index|(tbl2 autoindex 1)|tbl2|4|
3) then I do a .databases and nothing |
2005-Jul-14 15:17:54 by anonymous:
Works for me. See trace below (repeated twice once to create tables, and again to duplicate your test):
C:\Documents and Settings\DennisC>sqlite3 ex1
SQLite version 3.2.2
Enter ".help" for instructions
sqlite> create table tbl1(one varchar(10),two smallint);
sqlite> create table tbl2(
...> f1 varchar(30) primary key,
...> f2 text,
...> f3 real
...> );
sqlite> select * from sqlite_master;
table|tbl1|tbl1|2|CREATE TABLE tbl1(one varchar(10),two smallint)
table|tbl2|tbl2|3|CREATE TABLE tbl2(
f1 varchar(30) primary key,
f2 text,
f3 real
)
index|sqlite_autoindex_tbl2_1|tbl2|4|
sqlite> .databases
seq name file
--- --------------- -----------------------------------------------
0 main C:\Documents and Settings\DennisC\ex1
sqlite> .q
C:\Documents and Settings\DennisC>sqlite3 ex1
SQLite version 3.2.2
Enter ".help" for instructions
sqlite> select * from sqlite_master;
table|tbl1|tbl1|2|CREATE TABLE tbl1(one varchar(10),two smallint)
table|tbl2|tbl2|3|CREATE TABLE tbl2(
f1 varchar(30) primary key,
f2 text,
f3 real
)
index|sqlite_autoindex_tbl2_1|tbl2|4|
sqlite> .databases
seq name file
--- --------------- -----------------------------------------------
0 main C:\Documents and Settings\DennisC\ex1
sqlite>
2005-Jul-14 16:19:20 by anonymous:
Note that this bug was reported for version 2.8.16. This has been fixed in version 3.
See ticket #973. |
|
1317 |
code
|
closed
|
2005 Jul
|
anonymous
|
|
2005 Aug
|
|
3
|
3
|
Aggregate aliases result in assert() failure
|
edit |
Queries such as:
SELECT count(*) as foo FROM bar GROUP BY baz ORDER BY foo;
Result in:
src/auth.c:117: sqlite3AuthRead: Assertion `pExpr->op==7' failed.
Changing the query to use count(*) instead of "foo" in the order by makes the error go away. |
2005-Jul-05 18:17:10 by drh:
Unable to reproduce. Works fine when I try it. And the particular
assert() has nothing to do with aggregates or aliases so it is not
at all clear how this could be happening.
2005-Jul-06 15:51:51 by anonymous:
This problem was only "once-in-a-while" repeatable with PHP's pdo_sqlite using 3.2.2 library. I suspect it may be the result of some other memory corruption, so it may not be an SQLite issue at all. |
|
1310 |
event
|
closed
|
2005 Jun
|
anonymous
|
|
2005 Aug
|
|
2
|
4
|
Problem after create a new table
|
edit |
Hello, at first, thank you for your great database engine.
I think there is a little problem. I work with Borland C++ Builder 6.
No problem for this example :
Process 1 : SELECT * FROM TPARAMETERS => OK
Process 1 : CREATE TABLE TPARAMETERS_SESSION (PARAM CHAR(32) NOT NULL, VAL VARCHAR(255), PRIMARY KEY(PARAM)) => OK
Process 1 : SELECT * FROM TPARAMETERS => OK
But if another process share the database :
Process 2 : SELECT * FROM TPARAMETERS => OK
Process 1 : CREATE TABLE TPARAMETERS_SESSION (PARAM CHAR(32) NOT NULL, VAL VARCHAR(255), PRIMARY KEY(PARAM)) => OK
Process 2 : SELECT * FROM TPARAMETERS => SQL Error or missing database
Process 2 : SELECT * FROM TPARAMETERS => OK |
Yes, I've noticed the same thing.
More general: When the database schema has changed, the first command on a connection that is not aware yet of this change will fail. After that it work again.
2005-Aug-07 02:24:51 by drh:
Check your return codes. You are overlooking an SQLITE_SCHEMA
error.
When another process modifies the database schema, the next
call to sqlite3_step() will return SQLITE_SCHEMA. The
calling function must recompile the statement and try again.
2005-Aug-07 15:38:03 by anonymous:
Actually, I'm pretty sure sqlite3_step() just returns a generic error and its not until you call sqlite3_reset() that you get a more specific schema error.
2005-Aug-08 12:01:43 by anonymous:
The return code is SQLITE_ERROR. But it's not a problem.
2005-Oct-04 23:13:45 by anonymous:
Is this behavior documented in the API? If so, where?
-John (n00spam-developer@yahoo.com) |
|
1309 |
build
|
closed
|
2005 Jun
|
anonymous
|
|
2005 Sep
|
|
1
|
1
|
make problem
|
edit |
gcc -shared -Wl,-h -Wl,libsqlite.so.0 -o .libs/libsqlite.so.0.8.6 .libs/attach.o .libs/auth.o .libs/btree.o .libs/build.o .libs/copy.o .libs/date.o .libs/delete.o .libs/encode.o .libs/expr.o .libs/func.o .libs/hash.o .libs/insert.o .libs/main.o .libs/opcodes.o .libs/os.o .libs/pager.o .libs/parse.o .libs/pragma.o .libs/printf.o .libs/random.o .libs/select.o .libs/table.o .libs/tokenize.o .libs/update.o .libs/util.o .libs/vacuum.o .libs/vdbe.o .libs/vdbeaux.o .libs/where.o .libs/trigger.o .libs/btree_rb.o -lc
(cd .libs && rm -f libsqlite.so.0 && ln -s libsqlite.so.0.8.6 libsqlite.so.0)
(cd .libs && rm -f libsqlite.so && ln -s libsqlite.so.0.8.6 libsqlite.so)
false cru .libs/libsqlite.a attach.o auth.o btree.o build.o copy.o date.o delete.o encode.o expr.o func.o hash.o insert.o main.o opcodes.o os.o pager.o parse.o pragma.o printf.o random.o select.o table.o tokenize.o update.o util.o vacuum.o vdbe.o vdbeaux.o where.o trigger.o btree_rb.o
make: *** [libsqlite.la] Error 1 |
2005-Sep-08 11:01:10 by drh:
No version number given. No information about the host platform
given. I have no way to investigate or reproduce this problem. |
|
1307 |
new
|
closed
|
2005 Jun
|
anonymous
|
|
2005 Aug
|
|
1
|
1
|
BLOBs and Tcl library (again)
|
edit |
consider the following Tcl code
set b1 \xaa\xaa
set b2 [db eval {select cast($b1 as blob)}]
In the end, $b1 and $b2 will not contain identical contents.
In Tcl, transformation is done to represent binary data correctly when using the functions Tcl_Get/SetByteArrayxxx and conversion is made from/to string values.
In Sqlite, they are considered the same thing.
One possible way to fix this is to do the same conversion from/to utf-8 and binary data when converting between TEXT and BLOB values in sqlite.
Since TEXT is supposed to be a valid UTF-8 encoded string, and a BLOB value can contain arbitrary byte sequences it makes sense to do the same transformation that is performed in Tcl (not a very good analogy, but i think it is good enough in this case). |
2005-Jun-29 19:38:30 by anonymous:
Is this problem being considered or being looked at as a minor issue that won't get much attention anytime soon?
2005-Aug-13 18:20:34 by drh:
The TCL transform from UTF to bytearray strips off the high-order
bytes of each UTF characters. This loses information. I do not
think it is desirable to replication this behavior in SQLite.
2005-Aug-13 21:36:10 by anonymous:
From what i could understand from the TCL implementation it doesn't actually lose information.
From what i understood, bytearrays are converted to UTF strings when needed. This convertion will only make bytes with values > 127 to be converted to the correct UTF-8 format, which means, it will take 2 bytes for such character after the UTF-8 convertion. When it it converted back from a string to a bytearray it will simply 'join' (when needed) the UTF-8 character representation. ASCII strings will remain unchanged.
Strings with characters > 255 will however lose information when converting them into a bytearray although this isn't a real problem because if we are working with actual binary data it will never happen.
Hope my attempt to explain the situation isn't confusing.
2005-Aug-17 08:36:33 by anonymous:
One other thing that i would like to ask regarding the CAST operator which i believe it is also related to this subject is this:
If you cast a BLOB to a STRING will the string be a valid UTF-8 string? If not, will it actually break things when performing operations on the string?
Not only a TCL related issue but it can also happen with other implementations (but that would be mostly the programmer's fault i guess while in TCL i don't have much control over it). |
|
1299 |
new
|
closed
|
2005 Jun
|
anonymous
|
|
2005 Jun
|
|
3
|
3
|
need NOT EXISTS
|
edit |
In a "SELECT" clause, "EXISTS" works.
"NOT EXISTS" does not work.
Your documentation and my testing agree on this point,
but I think "NOT EXISTS" is part of standard SQL,
and I could use it. |
2005-Jun-23 18:10:27 by anonymous:
Cancel this bug. Further testing shows that I did not examine the results thoroughly. "NOT EXISTS" works. |
|
1296 |
new
|
closed
|
2005 Jun
|
anonymous
|
Unknown
|
2006 Feb
|
|
5
|
5
|
Nested Transactions needed
|
edit |
Nested transactions are essential in several places. |
2005-Jun-29 08:39:13 by anonymous:
Here is another one who needs nested transactions!
2005-Jun-29 21:23:52 by anonymous:
Me too. One more. This would be very helpful.
2006-Feb-11 23:07:14 by anonymous:
Isn't this pretty easy to implement? Just a simple nest counter? It'd be very nice if SQLite would support this.
2006-Feb-11 23:44:01 by drh:
It is easy enough to add it in a wrapper. This is not something
that belongs in the core. |
|
1290 |
new
|
closed
|
2005 Jun
|
anonymous
|
VDBE
|
2005 Jun
|
drh
|
1
|
1
|
optimize VBDE, reordening ID numbers of OP_????? codes
|
edit |
Is possible otimize VBDE main function: sqlite3VdbeExec.
But, first is necessary answer a question: It is possible, modify the numbers orders of TK_ defines and OP_defines?
The C compiler can otimize switch command with JUMPS, sice that CASE either positive ascendent order!
exemple:
switch (opcode) {
1:
2:
3:
}
This generate code optmized with JUMPS in constrast TABLE LOOKUP for numbers it are of the order.
Solution:
Reorganize the TK_ defines for physical order cases OP_xxxxx in the vbde.c (begins line 600).
Modify script mkopcodeh.awk, for generate defines OP_ in ascendent order 1, 2, 3...150. |
2005-Jun-15 18:03:16 by drh:
I doubt that. How exactly do you think the generated code would work?
And what compiler do you think will perform such optimizations?
2005-Jun-15 20:03:18 by anonymous:
Any modern C compiler can performe such optimization. But, first is necessary code supplies conditions.
Some examples:
1. http://www.keil.com/support/docs/1557.htm
"Case/Switch Optimizing: Code involving switch and case statements is optimized as jump tables or jump strings."
2. http://www.gamedev.net/community/forums/topic.asp?topic_id=293036
"...Most compilers can easily generate a jump table. If you switch on a 32-bit value with sparse values (1, 5003, 31355454) it wouldn't be practical with a jump table (as it would need more RAM than you probably have in your system)..."
3. http://www.deanesmay.com/archives/001176.html
"(2) If your data is dense (e.g. 1, 2, 3, rather than 1, 17, 1005, 20000202032), it can be implemented by a jump table, rather than a series of conditionals, and a jump table is much faster."
4. http://weblogs.asp.net/justin_rogers/archive/2004/03/25/95806.aspx
5. http://archives.neohapsis.com/archives/freebsd/2000-01/0593.html
"Because a 'switch' table lookup is often more expensive then a sequence of conditionals."
6. http://www.devx.com/amd/Article/21314
"But if the case expression aren't contiguous, the compiler may likely translate the code into a comparison chain instead of a jump table, and that can be slow:"
The script mkopcodeh.awk, generate order numbers out of order.
The order is physical in code (vdbe.c):
case OP_Goto: /* case 0: /
case OP_Gosub: / case 1: /
case OP_Return: / case 2: /
...
case OP_Expire: / case n: */
I believe that modification will result in more speed, but i´dont know how much.
2005-Jun-15 22:13:06 by drh:
The opcode numbers in SQLite are dense (there are very few holes in
the numbering sequence) but they are not consecutive. There is very
good reason for this - performance and optimization reasons. Any
C compiler ought to be able to organize such a switch statement into
an efficient table-lookup and jump. The compiler should not need
to have the opcodes numbered consecutively. If your compiler does
require consecutive numbering in order to code a switch statement
efficiently, then I suggest you need to get a new compiler. |
|
1288 |
code
|
closed
|
2005 Jun
|
anonymous
|
|
2005 Jun
|
|
1
|
1
|
Win32 Resource leak - InitializeCriticalSection(...)
|
edit |
Bounds Checker report resource leak for InitializeCriticalSection(...) in sqlite3_open()...
i found that where is no DeleteCriticalSection call to free cs. |
2005-Jun-15 14:48:11 by drh:
Windows deletes the critical section automatically when the
process terminates. This is not a leak. |
|
1281 |
code
|
closed
|
2005 Jun
|
anonymous
|
Unknown
|
2005 Jun
|
|
1
|
1
|
Errors testing sqlite 3.2.1
|
edit |
[...]
date-3.15... Ok
date-3.16... Ok
date-3.17... Ok
/tmp/sqlite-3.2.1/.libs/lt-testfixture: invalid command name "clock"
while executing
"clock seconds"
invoked from within
"clock format [clock seconds] -format "%Y-%m-%d" -gmt 1"
invoked from within
"set now [clock format [clock seconds] -format "%Y-%m-%d" -gmt 1]"
(file "./test/date.test" line 142)
invoked from within
"source $testfile"
("foreach" body line 4)
invoked from within
"foreach testfile [lsort -dictionary [glob $testdir/*.test]] {
set tail [file tail $testfile]
if {[lsearch -exact $EXCLUDE $tail]>=0} continue
so..."
(file "./test/quick.test" line 45)
make: *** [test] Error 1 |
This is a problem with Tcl version 8.5. SQLite will not support
Tcl 8.5 until it goes final. Tcl 8.5 is currently in alpha. |
|
1280 |
new
|
closed
|
2005 Jun
|
anonymous
|
|
2005 Jun
|
|
5
|
4
|
Make tests can be run as root
|
edit |
[...]
attach-6.2...
**** Tests do not work when run as root ****
make: *** [test] Error 1
It would be great if it could work. |
2005-Jun-12 23:28:41 by drh:
Building things as root is a very bad idea. And for that reason,
we are not going to expend any effort to make it work. |
|
1276 |
code
|
closed
|
2005 Jun
|
anonymous
|
Pager
|
2005 Jun
|
|
1
|
1
|
Failing assertion in pager.c
|
edit |
Hello.
I'm getting the following assertion error when using SQLite 3.2.1:
src/pager.c:3213: sqlite3pager_stmt_begin: Assertion `pPager->dbSize>=0' failed
Any idea what's the problem here?
(It it's relevant: I'm using SQLite from Python through the latest pysqlite version.)
TIA,
Johannes Beigel. |
2005-Jun-07 10:23:09 by drh:
We have no idea what the problem is because you have given us no
hints. Please tell us what you were doing in order to get the
assertion fault. A reproducible script would be ideal.
2005-Jun-07 15:38:02 by anonymous:
Hello.
I'm sorry, but I don't have a minimal script that can reproduce the failure.
I'm using SQLite as persistence for some integers and strings (not very large). It's all stored in in one table which doesn't grow very big until the crash (about 20.000 rows). The database access happens in a separate thread, but everything related to the db access happens there and all db commands are serialized.
I was wondering why there is an assert at the beginning of that function. Maybe it's there because there is already some experience with wrong data at this point of execution (but why is it an assert then and not an "if"-statement?).
TIA,
Johannes Beigel.
2005-Jun-07 17:12:49 by drh:
This is probably a threading violation - the user is probably trying
to use the same database connection from more than one thread at the
same time. That is the only way that we can see to get the assertion
failure mentioned. In any event, the poster is unable or unwilling
to provide us with any clues for reproducing the problem - no schema,
no SQL statements, nothing - so we are unable to debug the problem. |
|
1273 |
code
|
closed
|
2005 Jun
|
anonymous
|
Unknown
|
2005 Jun
|
|
3
|
3
|
Numeric affinity problem with views + coalesce (maybe all functions?)
|
edit |
create temp table x(numVal integer, textVal text);
create temp view viewX as select numVal, textVal, coalesce(numVal, textVal) AS VirtualVal from x;
insert into x values (null, 1);
/* this won't find any rows */
select * from viewx where virtualval = 1;
/* this will find the rows */
select * from viewx where virtualval+0 = 1;
/* my understanding is that this manual affinity assignment shouldn't be necessary, maybe I'm wrong, I know it used to not be necessary with prior versions */
|
2005-Jun-06 15:40:01 by drh:
The value in x.textVal is always stored as text because of the
way that column is defined. Hence, the result of
coalesce(null,x.textVal) will be a text value. If you want to
compare that value with its numeric equivalent, you have to
coerce the type by adding 0.
Works as designed. |
|
1269 |
code
|
closed
|
2005 May
|
anonymous
|
|
2005 Jul
|
|
1
|
1
|
Bus Error during import
|
edit |
Got a Bus error while importing a ";-delimited" file in a 3 columns table (columns data type: text, number, number).
The file is about 58000 rows, the error arise after 3100 row.
The system is a SunOs 5.8 |
The problem is resolved in 3.2.2.
Thank you. |
|
1268 |
build
|
closed
|
2005 May
|
anonymous
|
|
2017 Apr
|
|
1
|
1
|
/usr/include/sys/context.h:155: parse error before "sigset64_t"
|
edit |
Inability to compile without errors |
2005-May-27 15:46:15 by drh:
/usr/include/sys/context.h is a file on your computer. It has
nothing to do with SQLite. SQLite does not #include this file.
2005-Aug-30 15:24:21 by anonymous:
context.h is included from other files that are included. The error message was from someone trying to compile on an AIX box using gcc. Rather than dismissing it as "not a bug", you might want to see if others who use AIX know how to get around this problem.
2017-Apr-14 09:13:22 by anonymous:
I am getting an error of
"/usr/include/sys/context.h:188:2: error: unknown type name 'sigset64_t'
sigset64_t sc_mask; /* signal mask to restore */"
while trying to compile ntpv4 tests with gcc.
I copied sigset64_t declaration to ntp_types.h source file however, then I get conflict error for sigset64_t.
Need guidance on resolving "unknown type name" kind of errors. |
|
1267 |
code
|
closed
|
2005 May
|
anonymous
|
|
2005 May
|
|
5
|
4
|
exists and case don't work together on an empty table
|
edit |
Hi guys, this may well be a deficiency in my SQL understanding, however I think not. If I use an exists statement on an empty table inside a case statement, I get an empty response back, rather than a result.
sqlite> create table data (name varchar);
sqlite> select case when exists (select * from data where name = "foo") then 1 else 0 end from data;
# No result, expecting a zero.
sqlite> insert into data values ("bar");
qlite> select case when exists (select * from data where name = "foo") then 1 else 0 end from data;
0 # As expected.
sqlite> select case when exists (select * from data where name = "bar") then 1 else 0 end from data;
1 # As expected.
|
2005-May-24 12:21:49 by drh:
Omit the "FROM data" clause in the first query and it will do
what you want. |
|
1266 |
code
|
closed
|
2005 May
|
anonymous
|
VDBE
|
2005 May
|
|
2
|
2
|
crash when using instead of update triggers on views
|
edit |
Sorry, this is not reproducible with the latest CVS version (of May 24), checked out after I reported this.
Reproduced on: Linux: 3.2.1, 3.1.6 Windows: 3.2.0, 3.1.6
using the sql below, as file 'bug.sql':
$ sqlite3 bug.db
sqlite3> .read bug.sql
[...]
lt-sqlite3: ../src/vdbe.c:484: sqlite3VdbeExec: Assertion
`pTos<=&p->aStack[pc]' failed.
Aborted (core dumped)
Here, the crash only occurs when 14 or more rows are
inserted into base. If you can not reproduce it, try adding more rows.
CREATE TABLE base
(foreign_id INTEGER,
id INTEGER,
PRIMARY KEY (foreign_id, id));
CREATE VIEW view AS SELECT foreign_id, id FROM base;
CREATE TRIGGER update_base INSTEAD OF UPDATE ON view
FOR EACH ROW --WHEN OLD.foreign_id IS NULL
BEGIN
UPDATE base SET foreign_id = NEW.foreign_id
-- WHERE id = OLD.id
--and foreign_id = OLD.foreign_id
;
END;
/***
CREATE TRIGGER update_base_already INSTEAD OF UPDATE ON view
FOR EACH ROW WHEN OLD.foreign_id IS NOT NULL
AND (SELECT COUNT(*) FROM base
WHERE foreign_id IS NOT NULL
AND foreign_id = NEW.foreign_id) = 0
BEGIN
INSERT INTO base (foreign_id, id) VALUES
(NEW.foreign_id, OLD.id);
END;
***/
INSERT INTO base (foreign_id, id) VALUES
(NULL,IFNULL((SELECT MAX(id)+1 FROM base),0));
INSERT INTO base (foreign_id, id) VALUES
(NULL,IFNULL((SELECT MAX(id)+1 FROM base),0));
INSERT INTO base (foreign_id, id) VALUES
(NULL,IFNULL((SELECT MAX(id)+1 FROM base),0));
INSERT INTO base (foreign_id, id) VALUES
(NULL,IFNULL((SELECT MAX(id)+1 FROM base),0));
INSERT INTO base (foreign_id, id) VALUES
(NULL,IFNULL((SELECT MAX(id)+1 FROM base),0));
INSERT INTO base (foreign_id, id) VALUES
(NULL,IFNULL((SELECT MAX(id)+1 FROM base),0));
INSERT INTO base (foreign_id, id) VALUES
(NULL,IFNULL((SELECT MAX(id)+1 FROM base),0));
INSERT INTO base (foreign_id, id) VALUES
(NULL,IFNULL((SELECT MAX(id)+1 FROM base),0));
INSERT INTO base (foreign_id, id) VALUES
(NULL,IFNULL((SELECT MAX(id)+1 FROM base),0));
INSERT INTO base (foreign_id, id) VALUES
(NULL,IFNULL((SELECT MAX(id)+1 FROM base),0));
INSERT INTO base (foreign_id, id) VALUES
(NULL,IFNULL((SELECT MAX(id)+1 FROM base),0));
INSERT INTO base (foreign_id, id) VALUES
(NULL,IFNULL((SELECT MAX(id)+1 FROM base),0));
INSERT INTO base (foreign_id, id) VALUES
(NULL,IFNULL((SELECT MAX(id)+1 FROM base),0));
INSERT INTO base (foreign_id, id) VALUES
(NULL,IFNULL((SELECT MAX(id)+1 FROM base),0));
select 'prepare yourself!';
--PRAGMA vdbe_listing=ON;
PRAGMA vdbe_trace=ON;
.explain ON
UPDATE view set foreign_id = 111;
|
2005-May-24 12:17:19 by drh:
This is probably the same bug as #1169 which is already fixed. |
|
1265 |
new
|
closed
|
2005 May
|
anonymous
|
Pager
|
2005 May
|
|
3
|
3
|
10% speed improvement for huge inserts
|
edit |
Attached is a patch that improves performance by 10% for huge inserts.
The SQL statement that's benchmarked is:
create temp table foo as select * from t1 a, t1 b, t1 c
where t1 is a single column table with 60 random numbers.
Before: 0m1.599s 0m1.560s 0m1.581s 0m1.565s 0m1.604s
After: 0m1.367s 0m1.363s 0m1.384s 0m1.361s 0m1.375s |
2005-May-23 13:54:09 by drh:
I'm getting mixed results - some operations are faster and others
are slower. I implemented the optimization in 3 different ways but
was unable to get consistently faster times on any of them.
The
speed-comparison.html
attachment shows timing results.
sqlite321c is before any changes. sqlite321d, sqlite321d2, and
sqlite321d2 are the three different implementations.
Because the results are mixed and because the change increases the
library footprint, I will omit this change for now. |
|
1261 |
new
|
closed
|
2005 May
|
anonymous
|
VDBE
|
2005 May
|
|
5
|
3
|
Optimization
|
edit |
in sqlite3VdbeSerialGet():
Change:
pMem->r = *(double*)&x;
into:
*(u64*)&pMem->r = x;
This speeds up SELECT statements on tables with many floating point values. For a particular SELECT, I got a speedup of 6%.
It's more efficient to use integer operations on x86. For the old case, the compiler has to temporarily store x into memory to load it into the floating point register. |
2005-May-22 20:37:59 by drh:
This sounds like a compiler issue. I note in particular that GCC
does not make use of the FPU when moving a double from one
location to another. I am unwilling to obfuscate the code in
order to work around optimization issues in other compilers.
2005-May-22 21:35:24 by anonymous:
I don't really agree that it's an obfuscation.
I think either way clearly shows that you are copying 8 bytes of data from one location to the other.
The least obfuscated way would be to use memcpy.
Why not change the code to this. Then at least it's consistient.
if( serial_type==6 ){
*(u64*)&pMem->i = x;
pMem->flags = MEM_Int;
}else{
*(u64*)&pMem->r = x;
pMem->flags = MEM_Real;
}
|
|
1245 |
code
|
closed
|
2005 May
|
anonymous
|
|
2005 Jun
|
|
3
|
1
|
Query causes 'unable to open database' after ~1000 operations
|
edit |
In ruby with sqlite-ruby, using the query operation for update, insert, and delete causes an "unable to open database" error after ~1000 operations. I am iterating in a loop doing inserts, selects, updates, and deletes of the same database which has only a single table. I found a workaround to this by replacing the calls with execute rather than query but since I don't need the data back it doesn't seem like I should need to do an execute. |
2005-May-16 18:03:33 by drh:
Until presented with evidence to the contrary, I'm going to assume
this is a Ruby problem and not an SQLite problem. |
|
1238 |
code
|
closed
|
2005 May
|
anonymous
|
Unknown
|
2005 Jun
|
|
1
|
3
|
Failure to compile with SQLITE_OMIT_... macros enabled
|
edit |
SQLite3 3.2.1 does not compile with all SQLITE_OMIT_... macros enabled. The following changes to sqliteInt.h were necessary for me to make it work:
*** D:\sqliteInt.h Tue Mar 29 08:33:50 2005
--- D:\sqliteInt.h Mon May 09 20:46:00 2005
***************
*** 1370,1376 ****
--- 1370,1382 ----
void sqlite3ExprListDelete(ExprList*);
int sqlite3Init(sqlite3*, char**);
int sqlite3InitCallback(void*, int, char**, char**);
+
+ #ifndef SQLITE_OMIT_PRAGMA
void sqlite3Pragma(Parse*,Token*,Token*,Token*,int);
+ #else
+ # define sqlite3Pragma(A,B,C,D,E)
+ #endif
+
void sqlite3ResetInternalSchema(sqlite3*, int);
void sqlite3BeginParse(Parse*,int);
void sqlite3RollbackInternalChanges(sqlite3*);
***************
*** 1390,1395 ****
--- 1396,1402 ----
void sqlite3CreateView(Parse*,Token*,Token*,Token*,Select*,int);
int sqlite3ViewGetColumnNames(Parse*,Table*);
#else
+ # define sqlite3CreateView(A,B,C,D,E,F) 0
# define sqlite3ViewGetColumnNames(A,B) 0
#endif
***************
*** 1422,1428 ****
--- 1429,1439 ----
WhereInfo *sqlite3WhereBegin(Parse*, SrcList*, Expr*, ExprList**, Fetch*);
void sqlite3WhereEnd(WhereInfo*);
void sqlite3ExprCode(Parse*, Expr*);
+ #ifndef SQLITE_OMIT_TRIGGER
void sqlite3ExprCodeAndCache(Parse*, Expr*);
+ #else
+ # define sqlite3ExprCodeAndCache(A,B)
+ #endif
int sqlite3ExprCodeExprList(Parse*, ExprList*);
void sqlite3ExprIfTrue(Parse*, Expr*, int, int);
void sqlite3ExprIfFalse(Parse*, Expr*, int, int);
***************
*** 1489,1499 ****
void sqlite3DeleteTrigger(Trigger*);
void sqlite3UnlinkAndDeleteTrigger(sqlite3*,int,const char*);
#else
# define sqlite3TriggersExist(A,B,C,D,E,F) 0
# define sqlite3DeleteTrigger(A)
- # define sqlite3DropTriggerPtr(A,B,C)
# define sqlite3UnlinkAndDeleteTrigger(A,B,C)
- # define sqlite3CodeRowTrigger(A,B,C,D,E,F,G,H,I) 0
#endif
int sqlite3JoinType(Parse*, Token*, Token*, Token*);
--- 1500,1519 ----
void sqlite3DeleteTrigger(Trigger*);
void sqlite3UnlinkAndDeleteTrigger(sqlite3*,int,const char*);
#else
+ # define sqlite3BeginTrigger(A,B,C,D,E,F,G,H,I,J)
+ # define sqlite3FinishTrigger(A,B,C)
+ # define sqlite3DropTrigger(A,B)
+ # define sqlite3DropTriggerPtr(A,B,C)
# define sqlite3TriggersExist(A,B,C,D,E,F) 0
+ # define sqlite3CodeRowTrigger(A,B,C,D,E,F,G,H,I) 0
+ # define sqliteViewTriggers(A,B,C,D,E)
+ # define sqlite3DeleteTriggerStep(A)
+ # define sqlite3TriggerSelectStep(A) 0
+ # define sqlite3TriggerInsertStep(A,B,C,D,E) 0
+ # define sqlite3TriggerUpdateStep(A,B,C,D) 0
+ # define sqlite3TriggerDeleteStep(A,B) 0
# define sqlite3DeleteTrigger(A)
# define sqlite3UnlinkAndDeleteTrigger(A,B,C)
#endif
int sqlite3JoinType(Parse*, Token*, Token*, Token*);
***************
*** 1556,1577 ****
int sqlite3ValueBytes(sqlite3_value*, u8);
void sqlite3ValueSetStr(sqlite3_value*, int, const void *,u8, void(*)(void*));
void sqlite3ValueFree(sqlite3_value*);
! sqlite3_value *sqlite3ValueNew();
sqlite3_value *sqlite3GetTransientValue(sqlite3*db);
int sqlite3ValueFromExpr(Expr *, u8, u8, sqlite3_value **);
void sqlite3ValueApplyAffinity(sqlite3_value *, u8, u8);
extern const unsigned char sqlite3UpperToLower[];
void sqlite3RootPageMoved(Db*, int, int);
void sqlite3Reindex(Parse*, Token*, Token*);
void sqlite3AlterFunctions(sqlite3*);
void sqlite3AlterRenameTable(Parse*, SrcList*, Token*);
int sqlite3GetToken(const unsigned char *, int *);
void sqlite3NestedParse(Parse*, const char*, ...);
void sqlite3ExpirePreparedStatements(sqlite3*);
void sqlite3CodeSubselect(Parse *, Expr *);
int sqlite3SelectResolve(Parse *, Select *, NameContext *);
void sqlite3ColumnDefault(Vdbe *, Table *, int);
void sqlite3AlterFinishAddColumn(Parse *, Token *);
void sqlite3AlterBeginAddColumn(Parse *, SrcList *);
#endif
--- 1576,1616 ----
int sqlite3ValueBytes(sqlite3_value*, u8);
void sqlite3ValueSetStr(sqlite3_value*, int, const void *,u8, void(*)(void*));
void sqlite3ValueFree(sqlite3_value*);
! sqlite3_value *sqlite3ValueNew(void);
sqlite3_value *sqlite3GetTransientValue(sqlite3*db);
int sqlite3ValueFromExpr(Expr *, u8, u8, sqlite3_value **);
void sqlite3ValueApplyAffinity(sqlite3_value *, u8, u8);
extern const unsigned char sqlite3UpperToLower[];
void sqlite3RootPageMoved(Db*, int, int);
+
+ #ifndef SQLITE_OMIT_REINDEX
void sqlite3Reindex(Parse*, Token*, Token*);
+ #else
+ # define sqlite3Reindex(A,B,C)
+ #endif
+
void sqlite3AlterFunctions(sqlite3*);
+
+ #ifndef SQLITE_OMIT_ALTERTABLE
void sqlite3AlterRenameTable(Parse*, SrcList*, Token*);
+ #else
+ # define sqlite3AlterRenameTable(A,B,C)
+ #endif
+
int sqlite3GetToken(const unsigned char *, int *);
void sqlite3NestedParse(Parse*, const char*, ...);
void sqlite3ExpirePreparedStatements(sqlite3*);
void sqlite3CodeSubselect(Parse *, Expr *);
int sqlite3SelectResolve(Parse *, Select *, NameContext *);
void sqlite3ColumnDefault(Vdbe *, Table *, int);
+
+
+ #ifndef SQLITE_OMIT_ALTERTABLE
void sqlite3AlterFinishAddColumn(Parse *, Token *);
void sqlite3AlterBeginAddColumn(Parse *, SrcList *);
+ #else
+ # define sqlite3AlterFinishAddColumn(A,B)
+ # define sqlite3AlterBeginAddColumn(A,B)
+ #endif
#endif
|
2005-Jun-06 15:43:44 by drh:
You have to compile from original sources in order to use
the OMIT macros. It does not work to compile from the proprocessed
source files. |
|
1237 |
code
|
closed
|
2005 May
|
anonymous
|
|
2005 May
|
anonymous
|
1
|
1
|
I like to use SQLite in php
|
edit |
I feel sqlite is effecient and fast.so,i like to use sqlite in my PhP what i have to do? any guidlines avalible for me. |
2005-May-09 11:02:30 by anonymous:
PHP 5.x ??
2005-May-09 12:25:59 by drh:
This is a support question not a bug report. Please use the
mailing list for support questions. |
|
1233 |
code
|
closed
|
2005 May
|
anonymous
|
BTree
|
2005 May
|
|
1
|
1
|
Triggers assert
|
edit |
I'm getting an assert(pCur->isValid) in the following function for some reason when deleting from the database (v3.2.1). This happens with only one of the tables - the rest are fine (it seems?). There are triggers on this table, but there're triggers on some other tables as well and they seem to work fine. Could you please tell me why pCur->isValid could be 0?
int sqlite3BtreeData(BtCursor *pCur, u32 offset, u32 amt, void *pBuf)
{
assert( pCur->isValid );
assert( pCur->pPage!=0 );
assert( pCur->idx>=0 && pCur->idx<pCur->pPage->nCell );
return getPayload(pCur, offset, amt, pBuf, 1); }
The strange thing is that it doesn't happen all the time, I'm trying to work out a pattern, but the schema and statement (taken out of C++ code and I had to remove the field names, because of privacy, each table contains from 4 to 60 fields) are those:
"CREATE TABLE TABLE1 (\
UID INTEGER PRIMARY KEY,\
fieldsHere\
)\
";
"CREATE TABLE SUBTABLE1 (\
UID INTEGER PRIMARY KEY,\
fieldsHere\
PARENTENVELOPEID,\
VMSGID\
)\
";
"CREATE TABLE SUBTABLE2 (\
UID INTEGER PRIMARY KEY,\
fieldsHere\
ENVELOPEID,\
VMSGID\
)\
";
"CREATE TABLE SUBTABLE3 (\
fieldsHere\
DATAID NOT NULL\
)\
";
"CREATE TABLE SUBTABLE4 (\
fieldsHere\
DATAID NOT NULL\
)\
";
"CREATE TABLE SUBTABLE5 (\
fieldsHere\
DATAID NOT NULL\
)\
";
"CREATE TABLE SUBTABLE6 (\
fieldsHere\
DATAID NOT NULL\
)\
";
"CREATE TRIGGER DeleteTable\
BEFORE DELETE ON TABLE1 FOR EACH ROW\
BEGIN\
DELETE FROM SUBTABLE2 WHERE VMSGID=OLD._ROWID_;\
DELETE FROM SUBTABLE1 WHERE VMSGID=OLD._ROWID_;\
END\
";
"CREATE TRIGGER DeleteSubtable1\
BEFORE DELETE ON SUBTABLE1 FOR EACH ROW\
BEGIN\
DELETE FROM SUBTABLE2 WHERE ENVELOPEID=OLD._ROWID_;\
DELETE FROM SUBTABLE1 WHERE
PARENTENVELOPEID=OLD._ROWID_;\
END\
";
"CREATE TRIGGER DeleteSubtable2\
BEFORE DELETE ON SUBTABLE2 FOR EACH ROW\
BEGIN\
DELETE FROM SUBTABLE5 WHERE DATAID=OLD._ROWID_;\
DELETE FROM SUBTABLE4 WHERE DATAID=OLD._ROWID_;\
DELETE FROM SUBTABLE3 WHERE DATAID=OLD._ROWID_;\
DELETE FROM SUBTABLE6 WHERE DATAID=OLD._ROWID_;\
END\
";
DELETE FROM TABLE1 WHERE UID='1'
Please note that at the point when the DELETE is called, some of the subtables (probably most) will be empty, if that makes any difference.
Thank you. |
2005-May-03 12:43:53 by drh:
When I enter the SQL code above, it works correctly. No errors.
I tired entering data into the tables. Still no errors.
Please provide example SQL that demonstrates the error. Or,
since you are building a commercial product, consider taking out
a support contract such as described at
http://www.hwaci.com/sw/sqlite/prosupport.html.
2005-May-05 06:28:22 by anonymous:
Well, when I remove triggers from my code everything works fine, when I put them back in - it fails. I will try and debug SQLite further from my code to see whether I can get the exact source of this problem.
2005-May-05 22:52:35 by anonymous:
Ok, I was able to isolate and fix this problem - it was in this trigger:
"CREATE TRIGGER DeleteSubtable1\
BEFORE DELETE ON SUBTABLE1 FOR EACH ROW\
BEGIN\
DELETE FROM SUBTABLE2 WHERE ENVELOPEID=OLD._ROWID_;\
DELETE FROM SUBTABLE1 WHERE PARENTENVELOPEID=OLD._ROWID_;\
END\
";
I had to change the last line to be "=OLD.UID", because otherwise it went in an infinite loop, from what I could see or would behave incorrectly otherwise. |
|
1231 |
code
|
closed
|
2005 May
|
anonymous
|
BTree
|
2005 May
|
|
1
|
1
|
Solaris9: Bus error, alignment issues
|
edit |
t@1 (l@1) signal BUS (invalid address alignment) in balance_nonroot at line 3925 in file "btree.c"
3925 p->aData = &((u8*)p)[-pBt->psAligned];
(dbx) print &((char*)p)[-pBt->psAligned] &((char *) p)[-pBt->psAligned] = 0x100207edc ""
(dbx) where
=>[1] balance_nonroot(pPage = 0x100201708), line 3925 in "btree.c"
[2] balance_deeper(pPage = 0x100200de8), line 4443 in "btree.c"
[3] balance(pPage = 0x100200de8, insert = 1), line 4458 in "btree.c"
[4] sqlite3BtreeInsert(pCur = 0x1001d6a00, pKey = (nil), nKey = 4LL, pData = 0x1001fef30, nData = 224), line 4569 in "btree.c"
[5] sqlite3VdbeExec(0x100205770, 0x0, 0x0, 0x1b, 0x1b, 0xffffffff7fffd889), at 0xffffffff7c102480
[6] sqlite3_step(0x100205770, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7c0f22dc
An what about this line 3927. Shouldn't that just be removed? |
2005-May-01 22:51:44 by drh:
Unable to reproduce. Please resubmit your bug report together with
a short SQL example that will trigger the problem. |
|
1230 |
event
|
closed
|
2005 Apr
|
anonymous
|
TclLib
|
2005 May
|
|
1
|
1
|
coredump in tclsqlite on HPUX 11.11 64 bit
|
edit |
I am building SQLite on an HPUX 11.11 64 bit machine with TCL version 8.4.9. I am able to compile and link, but when I try to create a simple table in SQLite from either dymically linking from a tclsh or using the tclsqlite3 executable, I get coredumps. Sometimes they are memory memory faults, sometimes bus errors. make test fails on test autovacuum-1.1.1.
I have not had the same problems with the sqlite3 executable. I can create tables, insert and select.
I have successfully built and deployed in dev and test environments on Redhat, HPUX 11.11 32 bit. However these problems have arisen when deploying on a production 64 bit machine.
I have tried many different compiler and linker flags and get the same results. We are compiling using gcc64 3.4.3, the same compiler used to build tcl, expect, perl and various other shared libraries.
I also tried version 2.8.16 with the same results.
I really need some help tracking this done because the production schedule is now going to slip. I posted to the mailing list but received no response.
example:
$ tclsh
% info patchlevel
8.4.9
% load .libs/libtclsqlite3.sl
% sqlite db :memory:
0x8000000000045dd0
% db eval "create table x (z)"
Memory fault(coredump) |
this appeared to be a linking issue. There was an unresolved symbol "__umoddi3" and I needed to add -lgcc to the TCLLIB flags. Also needed to put the gcc library in path in my LD_LIBRARY_PATH prior to make.
Found another issue with page_size, which I will research. |
|
1226 |
code
|
closed
|
2005 Apr
|
anonymous
|
|
2005 Apr
|
|
2
|
3
|
Problem when several processes attempt inserts within on the same base
|
edit |
I made an algorithm that does the following things :
When a query returns SQLITE_BUSY, I put it into a vector<string>.
Before closing the database :
- I build another vector which receives the contents of the first vector.
- I clear the first vector.
- Begin transaction.
- I take the queries in the second vector and I execute them. If a query returns SQLITE_BUSY, I put it into the first vector.
I do this untill the first vector is empty.
- Commit transaction.
This algorithm works great with version 3.0.6, and it works also certainly with other versions. But with version 3.2.1, it works only for 2 processes accesing the database at the same time. If I start 3 processes accessing the same database with inserts, only 2 succeed. The third keeps stuck on the first sqlite3_exec() it encounters. |
2005-Apr-27 12:00:26 by drh:
This is a support request, not a bug report. Please use the
mailing list to have questions such as this answered. |
|
1225 |
code
|
closed
|
2005 Apr
|
anonymous
|
Unknown
|
2005 Apr
|
|
3
|
3
|
Empty resultset when unreferenced empty "table AS name" is given.
|
edit |
While I was experimenting with SQLite3, I noticed resultset become
empty when I have empty table in one of "table AS name" expressions.
This happens even when that table is not referenced anywhere.
As a result of following SELECT statement in attached script, I get
empty resultset with following statement:
SELECT max(p.n) FROM foo AS p, bar AS q;
This only happens when "bar" table is empty. If I insert any row into
"bar" table, above statement returns max(p.n) as expected.
Is this a bug, or a defined behavior?
I have verified this behavior with both 3.1.6 and 3.2.1, on Debian GNU/Linux.
I tried to subscribe to the list and post it there, but
couldn't for some reason. So I'm just submitting this as a
bug report.
#!/bin/sh
rm -f test.db
sqlite3 test.db <<EOF
CREATE TABLE foo (n INT);
CREATE TABLE bar (n INT);
INSERT INTO foo VALUES (1);
INSERT INTO foo VALUES (2);
SELECT max(n) FROM foo;
-- This returns "2" as expected
SELECT max(p.n) FROM foo AS p;
-- This returns "2" as expected
SELECT max(p.n) FROM foo AS p, bar AS q;
-- This returns empty - unexpected result - bug?
INSERT INTO bar VALUES (100);
SELECT max(p.n) FROM foo AS p, bar AS q;
-- This returns "2" as expected
EOF
exit 0
|
2005-Apr-26 23:36:27 by drh:
The observed behavior is what SQL is suppose to do. |
|
1218 |
code
|
closed
|
2005 Apr
|
anonymous
|
Unknown
|
2005 Apr
|
|
2
|
1
|
'select rowid' does not return 'rowid' as column title
|
edit |
'select rowid from t' does not return 'rowid' as column header if table 't' has 'integer primary key'.
Example:
E:\Temp>sqlite3.exe -header db.dat
SQLite version 3.2.1
Enter ".help" for instructions
sqlite> create table t(i integer primary key);
sqlite> insert into t values (0);
sqlite> select rowid from t;
i
0 |
2005-Apr-24 17:22:10 by anonymous:
use
SELECT rowid AS 'rowid' FROM t
2005-Apr-26 17:07:04 by drh:
The column names are as you expect if you do
PRAGMA short_column_names=off;
See the ColumnNames wiki page for additional information. |
|
1215 |
code
|
closed
|
2005 Apr
|
anonymous
|
|
2005 Apr
|
|
1
|
1
|
PRAGMA table_info and INTEGER UNSIGNED - sqlite3 client
|
edit |
If I retrieve the results of PRAGMA table_info('user_policy')the type column in the array that is returned is mangled. It
appears to me that spaces are sucked out.
Notice the user_policy_no data type below, and the output PRAGMA table_info() below. "INTEGER UNSIGNED" is turned
into "INTEGERUNSIGNED"
Here is my SQL:
CREATE TABLE user_policy (
user_policy_no INTEGER UNSIGNED NOT NULL ,
name VARCHAR(80) NOT NULL,
manager_zone_access_level CHAR(1) NULL,
manager_active_yn CHAR(1) NOT NULL DEFAULT '1',
manager_gui_access_level_lkup CHAR(1) NULL,
active_yn CHAR(1) NULL,
creation_dte DATETIME NULL,
last_modified_dte DATETIME NULL,
PRIMARY KEY(user_policy_no)
)
Here is the results from PRAGMA table_info
sqlite> PRAGMA table_info('user_policy');
0|user_policy_no|INTEGERUNSIGNED|99||1
1|name|VARCHAR(80)|99||0
2|manager_zone_access_level|CHAR(1)|0||0
3|manager_active_yn|CHAR(1)|99|1|0
4|manager_gui_access_level_lkup|CHAR(1)|0||0
5|active_yn|CHAR(1)|0||0
6|creation_dte|DATETIME|0||0
7|last_modified_dte|DATETIME|0||0 |
2005-Apr-22 16:33:30 by drh:
Yes, when you have a data type consisting of multiple words
all if the spaces between the words get removed and the datatype
is stored as a single word. This is by design; it is not a bug.
There is a good reason for doing it this way. I just don't recall
what that reason is right now. If I remember, I'll post another
update to this ticket.
2005-Apr-27 19:28:29 by anonymous:
I would be very interested the rationale, because I can't see a good reason for it. Frankly, if I can't retrieve the actual data type, what good is storing the datatype to begin with?
This ticket marks the problem as fixed for a previous version: #1038
Did something change? |
|
1207 |
code
|
closed
|
2005 Apr
|
anonymous
|
|
2005 Apr
|
anonymous
|
2
|
1
|
How to Install SQLite
|
edit |
I am working in Windows. I followed this link :-
http://www.sqlite.org/download.html
and i downloaded sqlite-3_2_1.zip, which gave just sqlite.exe on unzipping.
And when i downloaded the source code i am unable to compile it. Please tell me the steps to install it.
Kindly, help me.
regards,
Mahendra Batra |
2005-Apr-15 10:52:43 by anonymous:
Unless you are a programmer, "sqlite.exe" is all you need.
Please look around at the website! ("documentation", "SQLite In 5 Minutes Or Less"). |
|
1197 |
code
|
closed
|
2005 Apr
|
anonymous
|
|
2005 Apr
|
|
1
|
1
|
race condition in sqlite3_close
|
edit |
There is a potential race condition in main.c when closing a database (main.c, line 529):
The original code is:
sqlite3 *pPrev= pDbList;
sqlite3OsEnterMutex();
while( pPrev && pPrev->pNext!=db ){
Here, the mutex lock occurs only after the global variable pDbList has been read. If another thread closes the database pointed to by pDbList exactly in between the assignment and the mutex lock, pPrev will be a stale pointer.
The fix is to do the assignment after the mutex lock:
sqlite3 *pPrev;
sqlite3OsEnterMutex();
pPrev = pDbList;
while( pPrev && pPrev->pNext!=db ){
|
This is a duplicate of ticket #1185. |
|
1196 |
build
|
closed
|
2005 Apr
|
anonymous
|
|
2005 Apr
|
|
1
|
1
|
out-of memory on powerpc on linux
|
edit |
i am using SQlite 2.8.x vertion
basically i am using Mototrola MPC860 Processor POwerPC
in host PC i can able to get Sqlite> prompt
on the board if i say make its telling out-of memory in the board i am using 16 MB ram
sqlite is running on top of my kernel |
SQLite uses as much memory as it uses. The fact that it uses more
memory than you want it to is not a bug. There are
techniques for reducing memory consumption. Visit the mailing list
archives or use google to find them. |
|
1195 |
code
|
closed
|
2005 Apr
|
anonymous
|
Unknown
|
2005 Apr
|
|
3
|
3
|
memory leak
|
edit |
I think, there is a memory leak in the code. I have set SQLITE_MEMDEBUG and found an allocation difference after closing the data base. Some checks of malloc and free calls let me assume that not all calls of sqliteMalloc in line 225/hash.c has a corresponding free. |
2005-Apr-01 10:51:38 by drh:
The os_unix.c module allocates 2 hash tables to handle threading
issues. These hash tables are never freed. But no more than two
hash tables are every allocated so this is not a leak. |
|
1193 |
new
|
closed
|
2005 Mar
|
anonymous
|
|
2005 Mar
|
|
1
|
2
|
umask not respected... please change 644 to 666 in src/os_unix.c
|
edit |
in src/os_unix.c:
s/644/666/g;
Otherwise, you're not respecting the user's umask.
This is killing me, on a project, because there's no workaround. |
2005-Mar-31 01:25:39 by anonymous:
Dunno why merlyn@stonehenge.com isn't attached to this, so I'll put this as a comment. Randal Schwartz, Just Another Perl Hacker.
2005-Mar-31 18:15:41 by drh:
The contact information on a bug report is not visible
to anonymous users. This is done to prevent spammers from
harvesting email addresses from past bug reports.
I am reluctant to change the file creation mask from 0644
to 0666 due to security concerns. If you really want the
database to have 0666 permissions, you can either do a
chmod() after the database is created, or create the database
yourself (leaving the file empty) with any permissions you
want prior to opening it with SQLite.
2005-Mar-31 22:01:52 by drh:
To amplify my previous remarks: The workaround for the problem is
to do this:
close(open(zDatabaseName, O_CREAT, 0666));
prior to opening the database using sqlite3_open. |
|
1192 |
code
|
closed
|
2005 Mar
|
anonymous
|
Unknown
|
2005 Mar
|
|
2
|
3
|
Defaults not Respected by View Triggers
|
edit |
When I have a table with a column that has a default value, and use a trigger on a view to insert into that table, the default is seen or used by SQLite. For example, given this DDL:
CREATE TABLE _simple (
id INTEGER NOT NULL PRIMARY KEY,
name TEXT,
state INTEGER NOT NULL DEFAULT 1
);
CREATE VIEW simple AS
SELECT _simple.id AS id, _simple.name AS name, _simple.state AS state
FROM _simple;
CREATE TRIGGER insert_simple
INSTEAD OF INSERT ON simple
FOR EACH ROW BEGIN
INSERT INTO _simple (name, state)
VALUES (NEW.name, NEW.state);
END;
This is what happens when I do an insert on the view:
sqlite> insert into simple (name) values ('foo');
SQL error: _simple.state may not be NULL
Things work fine when I insert directly into the table, however:
sqlite> insert into _simple (name) values ('foo');
sqlite>
|
2005-Mar-31 06:07:52 by anonymous:
I think it is the same proble as ticket #1191.
VIEWs are read-only so you can not INSERT into them.
See: http://www.sqlite.org/omitted.html
Regards,
Bartosz.
2005-Mar-31 18:13:29 by anonymous:
And as I said in ticket #1191, if you add a trigger to a view, you can insert on it--and the example above allows for that.
2005-Mar-31 21:58:35 by drh:
The default value is on the table, not on the view. The default
values for views cannot be specified and so are NULL. If you want
to automatically convert NULLs into a different value in the view,
then do so using the coalesce function like this:
CREATE TRIGGER insert_simple
INSTEAD OF INSERT ON simple
FOR EACH ROW BEGIN
INSERT INTO _simple (name, state)
VALUES (NEW.name, coalesce(NEW.state,1));
END;
2005-Mar-31 23:44:58 by anonymous:
Ah, I see that it's the same in PostgreSQL:
testing=# CREATE TABLE _simple (
testing(# name TEXT,
testing(# state INTEGER NOT NULL DEFAULT 1
testing(# );
CREATE TABLE
testing=# CREATE VIEW simple AS
testing-# SELECT _simple.name AS name, _simple.state AS state
testing-# FROM _simple;
CREATE VIEW
testing=# CREATE RULE insert_simple AS
testing-# ON INSERT TO simple DO INSTEAD (
testing(# INSERT INTO _simple (name, state)
testing(# VALUES (NEW.name, NEW.state);
testing(# );
CREATE RULE
testing=# INSERT INTO simple (name) VALUES ('foo');
ERROR: null value in column "state" violates not-null constraint
testing=#
Apologies for the distraction. :-) |
|
1185 |
code
|
closed
|
2005 Mar
|
anonymous
|
|
2005 Mar
|
|
1
|
3
|
Race condition causing crash in busily-threaded application
|
edit |
I have been trying to track down a crasher in my multi-threaded sqlite 3.2.0 application. I was seeing crashes in highly contentious situations where many threads are opening and closing a database frequently. The crash was consistently in the following bit of code:
src/main.c in sqlite_close starting on line 527
#ifndef SQLITE_OMIT_GLOBALRECOVER
{
sqlite3 *pPrev = pDbList;
sqlite3OsEnterMutex();
while( pPrev && pPrev->pNext!=db ){
pPrev = pPrev->pNext;
}
if( pPrev ){
pPrev->pNext = db->pNext;
}else{
assert( pDbList==db );
pDbList = db->pNext;
}
sqlite3OsLeaveMutex();
}
#endif
The problem is that pPrev can be left dangling since the pDbList pointer is saved off before entering the mutex. It is possible that another thread already in the mutex at that time ends up sqliteFree'ing what was the pDbList head, invalidating pPrev for the other thread, causing the crash.
Swapping these two lines fixes the problem:
sqlite3 *pPrev = pDbList;
sqlite3OsEnterMutex();
change to:
sqlite3 *pPrev = NULL;
sqlite3OsEnterMutex();
pPrev = pDbList;
Once I made this change, the crash vanished.
I just looked in the 3.2.1 source and this bit of code is the same.
-Kyle Jessup |
|
1183 |
code
|
closed
|
2005 Mar
|
anonymous
|
Unknown
|
2005 Mar
|
danielk1977
|
3
|
2
|
Memory coruption related to syntax errors
|
edit |
Hi
Thanks for all the work arround sqlite, is a great product. However I just started to add support for sqlite to a project I'm working on and I have found memory coruption bugs (resulting in segmention fault).
I am trying to execute the following SQL statements (yes, I know "ALTER TABLE <tab> ALTER" is not support by sqlite yet, still it should not crash):
CREATE TABLE BNET (uid int NOT NULL PRIMARY KEY default '0');
ALTER TABLE BNET ADD uid int NOT NULL PRIMARY KEY;
ALTER TABLE BNET ADD acct_username varchar(32);
ALTER TABLE BNET ALTER acct_username SET DEFAULT NULL;
ALTER TABLE BNET ADD acct_userid int;
ALTER TABLE BNET ALTER acct_userid SET DEFAULT NULL;
ALTER TABLE BNET ADD acct_passhash1 varchar(128);
ALTER TABLE BNET ALTER acct_passhash1 SET DEFAULT NULL;
ALTER TABLE BNET ADD acct_email varchar(128);
ALTER TABLE BNET ALTER acct_email SET DEFAULT NULL;
ALTER TABLE BNET ADD auth_admin varchar(16);
ALTER TABLE BNET ALTER auth_admin SET DEFAULT 'false';
ALTER TABLE BNET ADD auth_normallogin varchar(16);
ALTER TABLE BNET ALTER auth_normallogin SET DEFAULT 'true';
ALTER TABLE BNET ADD auth_changepass varchar(16);
ALTER TABLE BNET ALTER auth_changepass SET DEFAULT 'true';
ALTER TABLE BNET ADD auth_changeprofile varchar(16);
ALTER TABLE BNET ALTER auth_changeprofile SET DEFAULT 'true';
ALTER TABLE BNET ADD auth_botlogin varchar(16);
ALTER TABLE BNET ALTER auth_botlogin SET DEFAULT 'true';
ALTER TABLE BNET ADD auth_operator varchar(16);
ALTER TABLE BNET ALTER auth_operator SET DEFAULT 'false';
ALTER TABLE BNET ADD new_at_team_flag int;
I have this statements in test.sql file, I have compiled sqlite 3.2.0 on linux x86 and x86_64 (does the same thing on both platforms) with no stripping. I am using valgrind (www.valgrind.org) to debug memory errors so I hope this helps you:
$ valgrind --tool=memcheck --num-callers=1 /usr/local/bin/sqlite3 -init test.sql test.db
(removed valgrind startup messages)
Loading resources from test.sql
ALTER TABLE BNET ADD uid int NOT NULL PRIMARY KEY;
SQL error: duplicate column name: uid
ALTER TABLE BNET ALTER acct_username SET DEFAULT NULL;
SQL error: near "ALTER": syntax error
ALTER TABLE BNET ALTER acct_userid SET DEFAULT NULL;
SQL error: near "ALTER": syntax error
ALTER TABLE BNET ALTER acct_passhash1 SET DEFAULT NULL;
SQL error: near "ALTER": syntax error
ALTER TABLE BNET ALTER acct_email SET DEFAULT NULL;
SQL error: near "ALTER": syntax error
ALTER TABLE BNET ALTER auth_admin SET DEFAULT 'false';
SQL error: near "ALTER": syntax error
ALTER TABLE BNET ALTER auth_normallogin SET DEFAULT 'true';
SQL error: near "ALTER": syntax error
ALTER TABLE BNET ALTER auth_changepass SET DEFAULT 'true';
SQL error: near "ALTER": syntax error
ALTER TABLE BNET ALTER auth_changeprofile SET DEFAULT 'true';
SQL error: near "ALTER": syntax error
==14238==
==14238== Invalid write of size 4
==14238== at 0x1B921784: sqlite3AddColumn (build.c:844)
==14238== by 0x1B937686: yy_reduce (parse.y:136)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB5E104 is 0 bytes after a block of size 180 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945C84: sqlite3Malloc (util.c:262)
==14238== by 0x1B917CC5: sqlite3AlterBeginAddColumn (alter.c:525)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238==
==14238== Invalid write of size 1
==14238== at 0x1B921789: sqlite3AddColumn (build.c:851)
==14238== by 0x1B937686: yy_reduce (parse.y:136)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB5E116 is not stack'd, malloc'd or (recently) free'd
==14238==
==14238== Invalid write of size 4
==14238== at 0x1B92178D: sqlite3AddColumn (build.c:845)
==14238== by 0x1B937686: yy_reduce (parse.y:136)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB5E104 is 0 bytes after a block of size 180 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945C84: sqlite3Malloc (util.c:262)
==14238== by 0x1B917CC5: sqlite3AlterBeginAddColumn (alter.c:525)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238==
==14238== Invalid write of size 4
==14238== at 0x1B92179A: sqlite3AddColumn (build.c:852)
==14238== by 0x1B937686: yy_reduce (parse.y:136)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB5E110 is 12 bytes after a block of size 180 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945C84: sqlite3Malloc (util.c:262)
==14238== by 0x1B917CC5: sqlite3AlterBeginAddColumn (alter.c:525)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238==
==14238== Invalid write of size 4
==14238== at 0x1B921960: sqlite3AddColumnType (build.c:943)
==14238== by 0x1B9376DB: yy_reduce (parse.y:201)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB5E10C is 8 bytes after a block of size 180 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945C84: sqlite3Malloc (util.c:262)
==14238== by 0x1B917CC5: sqlite3AlterBeginAddColumn (alter.c:525)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238==
==14238== Invalid write of size 1
==14238== at 0x1B92198E: sqlite3AddColumnType (build.c:951)
==14238== by 0x1B9376DB: yy_reduce (parse.y:201)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB5E116 is not stack'd, malloc'd or (recently) free'd
==14238==
==14238== Invalid read of size 4
==14238== at 0x1B917989: sqlite3AlterFinishAddColumn (alter.c:397)
==14238== by 0x1B93966D: yy_reduce (parse.y:986)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB5E108 is 4 bytes after a block of size 180 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945C84: sqlite3Malloc (util.c:262)
==14238== by 0x1B917CC5: sqlite3AlterBeginAddColumn (alter.c:525)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238==
==14238== Invalid read of size 1
==14238== at 0x1B9179BF: sqlite3AlterFinishAddColumn (alter.c:413)
==14238== by 0x1B93966D: yy_reduce (parse.y:986)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB5E115 is not stack'd, malloc'd or (recently) free'd
==14238==
==14238== Invalid read of size 1
==14238== at 0x1B9179D4: sqlite3AlterFinishAddColumn (alter.c:421)
==14238== by 0x1B93966D: yy_reduce (parse.y:986)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB5E114 is not stack'd, malloc'd or (recently) free'd
==14238==
==14238== Invalid read of size 4
==14238== at 0x1B920D04: sqliteResetColumnNames (build.c:397)
==14238== by 0x1B920DA8: sqlite3DeleteTable (build.c:450)
==14238== by 0x1B942FC3: sqlite3RunParser (tokenize.c:425)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB5E104 is 0 bytes after a block of size 180 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945C84: sqlite3Malloc (util.c:262)
==14238== by 0x1B917CC5: sqlite3AlterBeginAddColumn (alter.c:525)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238==
==14238== Invalid read of size 4
==14238== at 0x1B920D0F: sqliteResetColumnNames (build.c:398)
==14238== by 0x1B920DA8: sqlite3DeleteTable (build.c:450)
==14238== by 0x1B942FC3: sqlite3RunParser (tokenize.c:425)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB5E108 is 4 bytes after a block of size 180 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945C84: sqlite3Malloc (util.c:262)
==14238== by 0x1B917CC5: sqlite3AlterBeginAddColumn (alter.c:525)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238==
==14238== Invalid read of size 4
==14238== at 0x1B920D1A: sqliteResetColumnNames (build.c:399)
==14238== by 0x1B920DA8: sqlite3DeleteTable (build.c:450)
==14238== by 0x1B942FC3: sqlite3RunParser (tokenize.c:425)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB5E10C is 8 bytes after a block of size 180 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945C84: sqlite3Malloc (util.c:262)
==14238== by 0x1B917CC5: sqlite3AlterBeginAddColumn (alter.c:525)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB5E10C is 8 bytes after a block of size 180 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945C84: sqlite3Malloc (util.c:262)
==14238== by 0x1B917CC5: sqlite3AlterBeginAddColumn (alter.c:525)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
ALTER TABLE BNET ALTER auth_botlogin SET DEFAULT 'true';
SQL error: near "ALTER": syntax error
==14238==
==14238== Invalid write of size 4
==14238== at 0x1B917D26: sqlite3AlterBeginAddColumn (alter.c:530)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB6A084 is 0 bytes after a block of size 180 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945C84: sqlite3Malloc (util.c:262)
==14238== by 0x1B917CC5: sqlite3AlterBeginAddColumn (alter.c:525)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238==
==14238== Invalid read of size 4
==14238== at 0x1B917D4B: sqlite3AlterBeginAddColumn (alter.c:533)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB6A084 is 0 bytes after a block of size 180 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945C84: sqlite3Malloc (util.c:262)
==14238== by 0x1B917CC5: sqlite3AlterBeginAddColumn (alter.c:525)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238==
==14238== Invalid write of size 4
==14238== at 0x1B917D55: sqlite3AlterBeginAddColumn (alter.c:533)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB6A084 is 0 bytes after a block of size 180 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945C84: sqlite3Malloc (util.c:262)
==14238== by 0x1B917CC5: sqlite3AlterBeginAddColumn (alter.c:525)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238==
==14238== Invalid write of size 4
==14238== at 0x1B917D57: sqlite3AlterBeginAddColumn (alter.c:534)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB6A08C is 8 bytes after a block of size 180 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945C84: sqlite3Malloc (util.c:262)
==14238== by 0x1B917CC5: sqlite3AlterBeginAddColumn (alter.c:525)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238==
==14238== Invalid write of size 4
==14238== at 0x1B917D5E: sqlite3AlterBeginAddColumn (alter.c:535)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB6A088 is 4 bytes after a block of size 180 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945C84: sqlite3Malloc (util.c:262)
==14238== by 0x1B917CC5: sqlite3AlterBeginAddColumn (alter.c:525)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238==
==14238== Invalid read of size 4
==14238== at 0x1B921745: sqlite3AddColumn (build.c:828)
==14238== by 0x1B937686: yy_reduce (parse.y:136)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB6A084 is 0 bytes after a block of size 180 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945C84: sqlite3Malloc (util.c:262)
==14238== by 0x1B917CC5: sqlite3AlterBeginAddColumn (alter.c:525)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
ALTER TABLE BNET ALTER auth_operator SET DEFAULT 'false';
SQL error: near "ALTER": syntax error
==14238==
==14238== Invalid write of size 4
==14238== at 0x1B921960: sqlite3AddColumnType (build.c:943)
==14238== by 0x1B9376B5: yy_reduce (parse.y:200)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB761DC is 4 bytes before a block of size 5 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945CE1: sqlite3MallocRaw (util.c:276)
==14238== by 0x1B945DE3: sqlite3StrDup (util.c:318)
==14238== by 0x1B917CD8: sqlite3AlterBeginAddColumn (alter.c:526)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238==
==14238== Invalid write of size 1
==14238== at 0x1B92198E: sqlite3AddColumnType (build.c:951)
==14238== by 0x1B9376B5: yy_reduce (parse.y:200)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x1BB761E6 is 1 bytes after a block of size 5 alloc'd
==14238== at 0x1B904C2D: malloc (vg_replace_malloc.c:131)
==14238== by 0x1B945CE1: sqlite3MallocRaw (util.c:276)
==14238== by 0x1B945DE3: sqlite3StrDup (util.c:318)
==14238== by 0x1B917CD8: sqlite3AlterBeginAddColumn (alter.c:526)
==14238== by 0x1B939689: yy_reduce (parse.y:989)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238==
==14238== Invalid read of size 4
==14238== at 0x1B917BC9: sqlite3AlterFinishAddColumn (alter.c:476)
==14238== by 0x1B93966D: yy_reduce (parse.y:986)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
==14238== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==14238==
==14238== Process terminating with default action of signal 11 (SIGSEGV)
==14238== Access not within mapped region at address 0x0
==14238== at 0x1B917BC9: sqlite3AlterFinishAddColumn (alter.c:476)
==14238== by 0x1B93966D: yy_reduce (parse.y:986)
==14238== by 0x1B939951: sqlite3Parser (parse.c:3303)
==14238== by 0x1B942E62: sqlite3RunParser (tokenize.c:387)
==14238== by 0x1B9310CF: sqlite3_prepare (main.c:1056)
==14238== by 0x1B954E5E: sqlite3_exec (legacy.c:56)
==14238== by 0x804CA04: process_input (shell.c:1503)
==14238== by 0x804CC41: process_sqliterc (shell.c:1602)
==14238== by 0x804CF4C: main (shell.c:1713)
Please fix this, thanks! :) |
2005-Mar-27 00:40:19 by anonymous:
Ok, it seems you got a real problem in there because it also shows up with syntax sqlite3 accepts:
CREATE TABLE BNET (uid int NOT NULL PRIMARY KEY default '0');
ALTER TABLE BNET ADD acct_username varchar(32) DEFAULT NULL;
ALTER TABLE BNET ADD acct_userid int DEFAULT NULL;
ALTER TABLE BNET ADD acct_passhash1 varchar(128) DEFAULT NULL;
ALTER TABLE BNET ADD acct_email varchar(128) DEFAULT NULL;
ALTER TABLE BNET ADD auth_admin varchar(16) DEFAULT 'false';
ALTER TABLE BNET ADD auth_normallogin varchar(16) DEFAULT 'true';
ALTER TABLE BNET ADD auth_changepass varchar(16) DEFAULT 'true';
ALTER TABLE BNET ADD auth_changeprofile varchar(16) DEFAULT 'true';
ALTER TABLE BNET ADD auth_botlogin varchar(16) DEFAULT 'true';
This SQL sample crashes sqlite3 on linux/x86_64, doesn't crash on x86 but valgrind is reporting the same long list of bugs, so it is just some luck that it does not crash, if I add more ALTERs I would expect it to crash in the end.
Please someone look into this, thanks! |
|
1182 |
code
|
closed
|
2005 Mar
|
anonymous
|
|
2005 Mar
|
danielk1977
|
2
|
3
|
ALTER TABLE...ADD COLUMN fails if table has user-defined collation
|
edit |
Create a table with user-defined collation on a column then use ALTER TABLE...ADD COLUMN to add a new column. This results in an SQLITE_ERROR, the message is 'malformed database schema - near ",": syntax error'. There is no problem if a built-in collation (i.e. NOCASE) is used.
Here's a summary of actions:
int mycallback( void*, int len1, const void* sz1, int len2, const void* sz2 ) {...}
...
sqlite3_create_collation( pSqlite, "MYCOLLATION", ... mycallback );
...
"CREATE TABLE t (a TEXT COLLATE MYCOLLATION);"
...
"ALTER TABLE t ADD COLUMN b;"
The ALTER TABLE...RENAME TO works fine however. I'm using the original method (INSERT INTO...SELECT) of adding columns for now. |
2005-Mar-27 18:16:29 by drh:
Unable to reproduce.
Note also that the built-in NOCASE
collation is no different logically from any other user-defined
collation. The fact that the originator of this ticket got
different results using NOCASE than with their on collation
suggests that their collation was somehow not registered properly.
2005-Mar-27 20:04:21 by anonymous:
After reading your respons I investitaged further. I now have a few lines of SQL that will reproduce the error in the sqlite shell. It seem to be the text encoding that is significant here (and not collation as originally thought). Here's a log
S:\Testing>sqlite3 :memory:
SQLite version 3.2.0
Enter ".help" for instructions
sqlite> PRAGMA encoding='UTF-16';
sqlite> create table t (a);
sqlite> alter table t add column b;
SQL error: malformed database schema - near ",": syntax error
sqlite>
2005-Mar-27 20:05:36 by anonymous:
Here's the log again, correctly formatted...
S:\Testing>sqlite3 :memory:
SQLite version 3.2.0
Enter ".help" for instructions
sqlite> PRAGMA encoding='UTF-16';
sqlite> create table t (a);
sqlite> alter table t add column b;
SQL error: malformed database schema - near ",": syntax error
sqlite>
|
|
1181 |
code
|
closed
|
2005 Mar
|
anonymous
|
|
2005 Mar
|
|
2
|
3
|
Field types problem with INSERT
|
edit |
CREATE TABLE Test(a integer(3));
INSERT INTO Test VALUES(1);
INSERT INTO Test VALUES(10);
INSERT INTO Test VALUES(1000);
INSERT INTO Test VALUES(1000000000000000000);
INSERT INTO Test VALUES('Testing');
INSERT INTO Test VALUES(5.8);
SELECT * FROM Test;
Result:
1
10
1000
1000000000000000000
Testing
5.8
As field type is small integer, grater value should return overflow error. Inserting other content than integer should return an error. |
2005-Mar-26 02:01:56 by anonymous:
Please read the FAQ, this is addressed in questions 2 and 3.
2005-Mar-26 02:36:31 by drh:
Here again, the anonymous comment above is correct. This is
a deliberate and thoughtful feature, not a bug.
2005-Mar-26 06:44:17 by anonymous:
Sorry, maybe I'm not been quite clear.
I do not conider this as naive issue. In some cases "Typelessness" is
useful (at least realization is quite simple). However, side effects is logically corrupted database. Next example clearly shows another problem:
CREATE TABLE Test(a integer);
INSERT INTO Test VALUES(1);
INSERT INTO Test VALUES(10);
INSERT INTO Test VALUES(2.8);
INSERT INTO Test VALUES(5.8);
SELECT * FROM Test;
SELECT sum(a) FROM Test;
19.6
Whith strictly following integer logic, this shold be 18 (1+10+2+5). Or useding rounding within INSERT, this should be 20 (1+10+3+6). |
|
1180 |
code
|
closed
|
2005 Mar
|
anonymous
|
|
2005 Mar
|
|
2
|
3
|
Field types problem with .import
|
edit |
CREATE TABLE Test(a integer);
INSERT INTO Test VALUES(5);
INSERT INTO Test VALUES(10);
.import i.txt Test
SELECT * FROM Test;
Result:
5
10
text
20
125L
John
213
File "i.txt" contains mixed text and numbers:
text
20
125L
John
213
As field type of the field is integer value, importing different content should return an error. |
2005-Mar-26 02:03:01 by anonymous:
Please read the FAQ. This is addressed in question 3.
2005-Mar-26 02:33:26 by drh:
The anonymous responder above has it right. This is a feature not
a bug. |
|
1179 |
code
|
closed
|
2005 Mar
|
anonymous
|
TclLib
|
2005 Mar
|
|
2
|
1
|
Unable to use NULL for an AUTOINCREMENT field in TclSQLite
|
edit |
sqlite3 db test.db
db eval {CREATE TABLE test(id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT, status INTEGER)}
db eval {INSERT INTO test (name,status) values('Bob',0)}
puts "Bob ROWID: [db last_insert_rowid]"
Erroneous:
set ID {}
db eval {INSERT OR REPLACE INTO test (id,name,status) values($ID,'Joe',1)}
error> datatype mismatch
set ID NULL
db eval {INSERT OR REPLACE INTO test (id,name,status) values($ID,'Joe',1)}
error> datatype mismatch
Successful:
set ID NULL
db eval "INSERT OR REPLACE INTO test (id,name,status) values($ID,'Joe',1)"
db eval {INSERT OR REPLACE INTO test (id,name,status) values(NULL,'Joe',1)}
Summary:
- TclSQLite (or SQLite) interprets the contents of the "ID" variable as a string, instead of "NULL" type on an AUTOINCREMENT field.
- This behavior is inconsistent with the behavior outlined here, when enclosing the query in braces.
Workaround:
- Quoting the query statement forces TCL to evaluate it before passing it to TclSQLite.
|
2005-Mar-25 01:49:14 by drh:
When the SQL statement is in {...} you set a value to NULL by unsetting the
corresponding variable. Example:
unset -nocomplain id
db eval {INSERT INTO test VALUES($id,'Joe',1)}
2005-Mar-25 03:00:20 by anonymous:
Great, that works perfectly.
Although, I could not find this behavior documented on the "Tcl API" page, perhaps it is worth mentioning.
Thanks for the help and outstanding work towards SQLite. |
|
1178 |
code
|
closed
|
2005 Mar
|
anonymous
|
VDBE
|
2005 Mar
|
|
1
|
1
|
sqlite 3 returns SQLITE_ERROR instead of SQLITE_SCHEMA
|
edit |
I've got a reproducible case where SQLITE_ERROR is returned instead of SQLITE_SCHEMA for a retryable "schema changed" error. The test case is kind of convoluted (involves a lot of Mozilla code), but basically:
- sqlite3VdbeExec gets called at vdbeapi.c:211
- OP_VerifyCookie gets executed, and we get p->zErrMsg set to "database schema has changed", and set "rc" to SQLITE_SCHEMA (note: not p->rc) in vdbe.c:2331
- p->rc = rc; rc = SQLITE_ERROR; gets executed in vdbe_halt: at vdbe.c:4653
At this point, p->rc = SQLITE_SCHEMA, rc = SQLITE_ERROR, p->zErrMsg = "database schema has changed"
- sqlite3VdbeExec returns to vdbeapi.c; the rc returned is SQLITE_ERROR
- sqlite3Error is called with p->db, rc (SQLITE_ERROR), p->zErrMsg ("database schema has changed")
- rc is returned (SQLITE_ERROR)
The actual error code should be SQLITE_SCHEMA -- what's the best way to get this back? It seems that you really want rc = p->rc and special-handling for the SQLITE_MISUSE case, but I don't really know what the different sematnics of rc and p->rc are there. |
2005-Mar-24 21:53:31 by drh:
sqlite3_step() returns SQLITE_ERROR. Then you do either
sqlite3_reset() or sqlite3_finalize() and that function gives
you the SQLITE_SCHEMA.
You can argue that it might be more convenient to get back
SQLITE_SCHEMA directly from sqlite3_step(). And you might be
right. But the time to have made that argument was during alpha
or beta testing of 3.0.0. The interface is now fixed and to change
it would break backwards compatibility.
I will, however, make a mental note to clarify the documentation on
this point because this is a common mistake.
2005-Dec-19 15:05:27 by ghaering:
I stumbled upon the same problem when implementing transparent statement caching for pysqlite. And said WTF to myself a few times when I was sure I would need to get a SQLITE_SCHEMA error when in fact I did not.
The workaround in the code looks like this:
if (rc != SQLITE_DONE && rc != SQLITE_ROW) {
/* for some reason, we don't get SQLITE_SCHEMA when we expect it, and
* get SQLITE_ERROR instead, so let's handle the changed schema
* case the complicated way */
if (strcmp(sqlite3_errmsg(self->connection->db), "database schema has changed") == 0) {
And this is the only way I see to cope with schema errors.
I'd argue the current behaviour is broken and should be fixed. Any code that relies on the current behaviour should still work, as it needs to rely on parsing sqlite3_errmsg().
2006-Sep-08 11:40:00 by drh:
Please do not do a strcmp() on the error message text, Gerhard.
The error message text might change in the future.
The right way to handle this is to call sqlite3_reset() after
receiving an SQLITE_ERROR from sqlite3_step(). The sqlite3_reset()
will return the correct error code: SQLITE_SCHEMA or whatever
else the error might be.
Yes, yes. I know this is goofy. But it is impossible to change
now without breaking huge amounts of legacy code. |
|
1175 |
code
|
closed
|
2005 Mar
|
anonymous
|
Unknown
|
2005 Mar
|
|
1
|
1
|
busy handler is not being called
|
edit |
In sqlite3SafetyOn(), db->magic==SQLITE_MAGIC_BUSY causes the database to go into an error state (SQLITE_MAGIC_ERROR). No attempt is made to interact with the user-provided or internal busy handler.
In fact, searching the source code for references to the user-provided busy handler only shows where the function pointer is being stored...there is no reference to the function pointer being used. |
2005-Mar-23 19:04:18 by drh:
Even though both features have "busy" in their name, the busy
handler and SQLITE_MAGIC_BUSY have nothing to do with each other.
The sqlite3SafetyOn() function is designed to catch misuse of the
SQLite library where two or more threads try to use the same
database handle at the same time. It has nothing to do with
locked database files. |
|
1174 |
build
|
closed
|
2005 Mar
|
anonymous
|
Parser
|
2005 Mar
|
|
4
|
4
|
Link problem using SQLITE_OMIT_xxx
|
edit |
Using some of the SQLITE_OMIT_xxx features will cause error message at link time:
ex:
BUILD/INDY/parse.y:863: undefined reference to `sqlite3FinishTrigger'
BUILD/INDY/parse.y:869: undefined reference to `sqlite3BeginTrigger'
BUILD/INDY/parse.y:907: undefined reference to `sqlite3TriggerUpdateStep'
BUILD/INDY/parse.y:912: undefined reference to `sqlite3TriggerInsertStep'
BUILD/INDY/parse.y:915: undefined reference to `sqlite3TriggerInsertStep'
BUILD/INDY/parse.y:919: undefined reference to `sqlite3TriggerDeleteStep'
BUILD/INDY/parse.y:922: undefined reference to `sqlite3TriggerSelectStep'
BUILD/INDY/parse.y:946: undefined reference to `sqlite3DropTrigger'
BUILD/INDY/parse.y:969: undefined reference to `sqlite3Reindex'
BUILD/INDY/parse.y:970: undefined reference to `sqlite3Reindex'
BUILD/INDY/parse.y:976: undefined reference to `sqlite3AlterRenameTable'
i think the SQLITE_OMIT_xxx symbols are not present in the file 'parce.c' which is distibuted in the zip file 'sqlite-source-3_1_6.zip' for WINx user. |
2005-Mar-21 14:39:23 by drh:
You have to build from source code if you use the SQLITE_OMIT_xxx
options. The entire build must be performed with the same options.
The preprocessed source files available on the website are not
built with any SQLITE_OMIT_xxx options and will not work with them. |
|
1173 |
code
|
closed
|
2005 Mar
|
anonymous
|
|
2005 Mar
|
|
1
|
1
|
C : if there is count(*) in a select then bug
|
edit |
hi,
i have a problem with sqlite.
i would like to do a requete in C but it doen't work.
wthe same requete with "sqlite3" works ..
zapoutix@Baka-Pif:~/mwonline/src/GWO$ sqlite3 GWO.db
SQLite version 3.1.6
Enter ".help" for instructions
sqlite> select count(*), ip from servers WHERE (id = 1 and is_log = 1);
1|127.0.0.1
i did exactly the same requete with the same database with the source code in C of the quickstart exemple ahdn i have :
zapoutix@Baka-Pif:~/mwonline/src/GWO$ ./t GWO.db "select count(*), ip from servers WHERE (id = 1 and is_log = 1);"
count(*) = 1
ip = NULL
zapoutix@Baka-Pif:~/mwonline/src/GWO$
the ip colum is not "127.0.0.1" but NULL;
ps : sorry for my bad english. |
2005-Mar-20 23:27:55 by drh:
First off, you SQL is incorrect. You should not mix an aggregate
function and non-aggregate without a GROUP BY clause.
But even so, the two programs should work the same, and do when
I try it. There is probably a typo in your implementation of
the quick start code.
2005-Mar-20 23:46:25 by anonymous:
ok thank, it was just a compilation error.
zapoutix@Baka-Pif:~/mwonline/src/GWO$ gcc -o t t.c -Wl,--rpath -Wl,/usr/local/lib -lsqlite3
zapoutix@Baka-Pif:~/mwonline/src/GWO$ ./t GWO.db "select count(*), ip from servers WHERE (id = 1 and is_log = 1);"
count(*) = 1
ip = 127.0.0.1
zapoutix@Baka-Pif:~/mwonline/src/GWO$ gcc -o t t.c -lsqlite3
zapoutix@Baka-Pif:~/mwonline/src/GWO$ ./t GWO.db "select count(*), ip from servers WHERE (id = 1 and is_log = 1);"
count(*) = 1
ip = NULL
zapoutix@Baka-Pif:~/mwonline/src/GWO$ |
|
1172 |
code
|
closed
|
2005 Mar
|
anonymous
|
|
2005 Mar
|
|
1
|
3
|
sqlite3_step() seems to not reset database lock check
|
edit |
The doc says:
** SQLITE_BUSY means that the database engine attempted to open
** a locked database and there is no busy callback registered.
** Call sqlite3_step() again to retry the open.
...but it seems once a lock been detected, you cannot call
sqlite3_step() until it clears...you have to close, open recompile statment and try again.
It would be much more elegant if you could re-try sqlite3_step().
Thx
Russ |
This functionality is tested by regression tests capi3b-1.3 through capi3b-1.7 and appears to work fine. |
|
1160 |
code
|
closed
|
2005 Mar
|
anonymous
|
CodeGen
|
2005 Mar
|
|
4
|
4
|
GROUP BY is broken
|
edit |
It's possible to GROUP BY on columns that are not in the SELECT-clause as an aggregate function. This is not correct.
For example:
Foo| Bar
---+-------
2 | 1
3 | 1
SELECT Foo FROM Table GROUP BY Bar
Gives:
Foo
---
2
It returns the first value, but it should give an error.
BTW: MySQL has the same problem.
The cause of this is probably ticket [859]
. |
The current behavior is as intended.
The SQL standard requires that all terms in the GROUP BY clause
also be in the result set. But SQLite relaxes this restriction
and allows arbitrary expressions in the GROUP BY clause, at least
for simple queries. The rules are a little differnt for compound
queries. |
|
1157 |
new
|
closed
|
2005 Mar
|
anonymous
|
|
2005 Mar
|
drh
|
1
|
1
|
Is there a roadmap?
|
edit |
I was wondering there is a roadmap of sqlite. |
Please ask questions like this on the mailing list. Tickets are
for reporting bugs. |
|
1156 |
new
|
closed
|
2005 Mar
|
anonymous
|
Unknown
|
2005 Mar
|
|
3
|
1
|
Cant fetch records in between one DATE to another DATE
|
edit |
HI there
im working on a c-based project that performs billing transaction and stores it everyday.Now i want to provide a facility in my application to fetch the records from 'FROM DATE' to 'TO DATE' by the end of every year.I tried to use the normal SQL Commands used in sql server to fetch records based on date fields, namely
select * from table where date in between ('FRM DATE','TO DATE')
select * from table where date>=12-05-2005 and date<=29-11-2005
But it doesnot fetch the contents within this date range. I tried a couple of sql date queries,but it doesnot seem to FETCH the records in between the TWO dates.
For the query i typed i get only two_records,one with the "FRM_DATE" and other with "TO_DATE" but not the ONES IN between.
I think here a string comparision of some sort is done to fetch the records rather than a 'date_fetch'.I even tried changing formats mm--dd-yyyy to many other date formats and tried the query..but it still gets me the same results. all i want to do is to provide a facility in my application to fetch transaction data done from one date to another lets say all the transaction done between Feb 01 to Nov 01.
Im using sqlite 2.8.15
Thankyou |
Use dates in the ISO8601 format to solve this problem.
2005-Mar-16 14:04:30 by anonymous:
The real solution is to use the format 'YYYYMMDD'. Which is also part of the ISO, although not the one that appears more prominently and more generally used.
Please be more specific when stating the resolution for a problem.
Also it would be nice that SQLite supported 'YYYY-MM-DD', since it's now almost a de-facto standard.
2005-Mar-17 17:44:32 by anonymous:
I'm sorry to say that it isn't actually working.
Please, do a test, create a table with a "date" column, insert some registers and then try to fetch a group of them by comparing the date column to some string.
It does not work properly.
2005-Mar-20 23:32:48 by drh:
Your SQL is incorrrect. Dates should be enclosed in single
quotes. Like this: '12-05-2005'. The expression 12-05-2005
not in quotes is 12 minus 5 minus 2005 which evalutes to -1988. |
|
1155 |
doc
|
closed
|
2005 Mar
|
anonymous
|
|
2005 Mar
|
|
1
|
1
|
how i can get a month from a date with a SELECT
|
edit |
i'm use your product, and a i have a problem with some SELECT, for example how i can view a month from a date |
2005-Mar-02 22:26:34 by drh:
Trouble tickets are for reporting bugs, not asking general questions.
Please post your questions on the SQLite users mailing list.
See http://www.sqlite.org/support.html for details. |
|
1154 |
event
|
closed
|
2005 Mar
|
anonymous
|
VDBE
|
2005 Mar
|
|
1
|
1
|
PRIMARY KEY AUTOINCREMENT and TRIGGER problem
|
edit |
Try this:
CREATE TABLE tb1(cod integer PRIMARY KEY AUTOINCREMENT)
CREATE TABLE tb2(cod integer PRIMARY KEY AUTOINCREMENT, tb1cod integer)
CREATE TRIGGER tb1_i insert on tb1
begin
insert into tb2 values(NULL, new.cod);
end
after....
insert into tb1 values(NULL);
Result in tb2 is:
cod=1
tb1cod=-1
and tb1 is:
cod=1
but tb1cod is not 1, thats is the problem. |
2005-Mar-02 02:23:54 by drh:
You specified a BEFORE trigger - a trigger that runs before the
INSERT runs. But the value of tb1.cod is not known until after
the INSERT runs. Change to an AFTER trigger and the problem should
go away.
One might argue that the value of tb1.cod in the BEFORE trigger
should be NULL instead of -1.
2005-Apr-01 11:15:16 by anonymous:
Document have been changed |
|
1150 |
code
|
closed
|
2005 Feb
|
anonymous
|
Parser
|
2005 Feb
|
|
4
|
4
|
'insert' is not a legal transaction name
|
edit |
I'm not even certain this is actually a bug in the code. It may just be that I am just misinterpretting the documentation. Anyway, running from Perl DBI::SQLite I get a syntax error when I try naming a transaction 'insert'.
$dbh->do("BEGIN TRANSACTION insert") produces the $DBI::errstr "near insert": syntax error(1) at dbdimp.c line 263
"BEGIN TRANSACTION foo" works fine, so it appears to be a parsing problem when using an otherwise reserved word as the name.
Now I'm new to transactions, and I don't know how other DBMS's deal with this. And I realize that SQLite doesn't handle nested transactions, so names do nothing. But since the documentation says that the name is ignored, and in this case the name causes a syntax error, I'm reporting it as a bug. As the workaround is pretty simple and obvious (use a different name) it's not a high priority, but I thought it might be something worth fixing or documenting. |
You have to quote reserved words when used as
identifiers. |
|
1148 |
new
|
closed
|
2005 Feb
|
anonymous
|
Shell
|
2005 Mar
|
|
5
|
5
|
patch to print query execute time on shell.c
|
edit |
I patched shell.c to print query execute time.
Please modify this and add this feature to shell.c.
here.
*** shell.c Mon Feb 28 22:29:45 2005
--- shell.c.new Sun Feb 27 15:30:22 2005
***************
*** 48,53 ****
--- 48,55 ----
# define stifle_history(X)
#endif
+ #include <sys/time.h>
+
/* Make sure isatty() has a prototype.
*/
extern int isatty();
*************** static int _is_command_terminator(const
*** 1448,1453 ****
--- 1450,1464 ----
return 0;
}
+ double microtime(){
+ struct timeval tp;
+ double msec = 0.0;
+ gettimeofday(&tp, NULL);
+ msec = (double) (tp.tv_usec / 1000000.00);
+ if (msec >= 1.0) msec -= (long) msec;
+ return msec + tp.tv_sec;
+ }
+
/*
** Read input from *in and process it. If *in==0 then input
** is interactive - the user is typing it it. Otherwise, input
*************** static void process_input(struct callbac
*** 1461,1467 ****
--- 1472,1484 ----
int nSql = 0;
char *zErrMsg;
int rc;
+ double starttime;
+
+
while( fflush(p->out), (zLine = one_input_line(zSql, in))!=0 ){
+
+ starttime = microtime();
+
if( seenInterrupt ){
if( in!=0 ) break;
seenInterrupt = 0;
*************** static void process_input(struct callbac
*** 1515,1521 ****
--- 1532,1540 ----
zSql = 0;
nSql = 0;
}
+ printf("\nTime: %.8f sec\n", microtime() - starttime);
}
+
if( zSql ){
if( !_all_whitespace(zSql) ) printf("Incomplete SQL: %s\n", zSql);
free(zSql);
|
|
1147 |
code
|
closed
|
2005 Feb
|
anonymous
|
Parser
|
2005 Apr
|
|
1
|
1
|
column names do not respect pragma settings
|
edit |
pragma full_column_names (and short_column_names) has no effect. the
reason seems to be this code:
in select.c, generateColumnNames:
for(i=0; i<pEList->nExpr; i++){
Expr *p;
p = pEList->a[i].pExpr;
if( p==0 ) continue;
if( pEList->a[i].zName ){ <----- this line
char *zName = pEList->a[i].zName;
sqlite3VdbeSetColName(v, i, zName, strlen(zName));
continue;
}
I suspect the author is checking for aliases here. However, the expression seens to be true even though column aliases have not been defined, with the result that the following lines, which handle the fullColumnNames setting, never execute.
how to reproduce: just set full_column_names and execute any select |
2005-Mar-09 11:42:50 by anonymous:
Column format returned by version 3.1.3 and version 3.0.2 are different. Version 3.1.3 never returns the table name.
SQLite version 3.1.3
Enter ".help" for instructions
sqlite> create table t1 (v1,v2);
sqlite> insert into t1 values (1,1);
sqlite> insert into t1 values (2,2);
sqlite> .headers on
sqlite> select v1,v2 from t1;
v1|v2
1|1
2|2
sqlite> select t1.v1,t1.v2 from t1;
v1|v2
1|1
2|2
The expected results:
SQLite version 3.0.2
Enter ".help" for instructions
sqlite> create table t1 (v1,v2);
sqlite> insert into t1 values (1,1);
sqlite> insert into t1 values (2,2);
sqlite> .headers on
sqlite> select v1,v2 from t1;
v1|v2
1|1
2|2
sqlite> select t1.v1,t1.v2 from t1;
t1.v1|t1.v2
1|1
2|2
2005-Apr-27 00:32:56 by drh:
See wiki page ColumnNames |
|
1144 |
code
|
closed
|
2005 Feb
|
anonymous
|
Unknown
|
2005 May
|
|
1
|
3
|
Changing page_size causes a GPF on memory databases
|
edit |
I can't test this on any other platform, but here's what crashes for me in Windows:
- Open a :memory: database
- Set pragma page_size=4096
- Create a table, anything will do, CREATE TABLE Foo(ID int, Name varchar(50)) for example
The DLL GP faults immediately. |
2005-Mar-21 01:06:09 by drh:
Unable to reporoduce on 3.1.6 CVS. |
|
1143 |
code
|
closed
|
2005 Feb
|
anonymous
|
|
2005 Feb
|
|
2
|
2
|
prepare/step give incorrect results, compared to the sqlite3 tool
|
edit |
It appears that the prepared/compiled form of the following statement forces the starRating column of the following query to NULL:
SELECT p.starRating FROM Program AS p INNER JOIN Schedule AS s ON s.program = p.id
But executing the same query with an added "WHERE p.starRating IS NOT NULL" clause gives the correct results.
This does not happen when using the sqlite3 tool, presumably because that uses the callback interface to fetch the data.
You can view the PHP PDO code online at:
http://viewcvs.php.net/viewcvs.cgi/pecl/pdo_sqlite/; I don't believe that there are errors in that code, since most queries work fine, so I suspect that this will be trivially reproducable using the prepare/step APIs directly.
The schema for the database in question is:
CREATE TABLE Program (
id VARCHAR(12) NOT NULL,
series VARCHAR(12) NULL,
title VARCHAR(120) NOT NULL,
subtitle VARCHAR(150) NULL,
description VARCHAR(255) NULL,
mpaaRating VARCHAR(5) NULL,
starRating VARCHAR(5) NULL,
runtime VARCHAR(8) NULL,
year VARCHAR(4) NULL,
showType VARCHAR(30) NULL,
colorCode VARCHAR(20) NULL,
originalAirDate VARCHAR(10) NULL,
syndicatedEpisodeNumber VARCHAR(20) NULL
);
CREATE TABLE Schedule (
program VARCHAR(12) NOT NULL,
station INT NOT NULL,
time VARCHAR(20) NOT NULL,
duration VARCHAR(8) NOT NULL,
repeat BOOL NOT NULL,
stereo BOOL NOT NULL,
subtitled BOOL NOT NULL,
HDTV BOOL NOT NULL,
closeCaptioned BOOL NOT NULL,
tvRating VARCHAR(5) NULL,
FOREIGN KEY(station)
REFERENCES Station(id),
FOREIGN KEY(program)
REFERENCES Program(id)
);
CREATE UNIQUE INDEX Program_Id ON Program(id);
CREATE UNIQUE INDEX Schedule_PrimaryKey ON Schedule(program, station, time);
CREATE INDEX Schedule_Program ON Schedule(program);
CREATE INDEX Schedule_Station ON Schedule(station);
CREATE INDEX Schedule_Time ON Schedule(time);
A sample database can found here: http://homepage.ntlworld.com/jared.williams/php5/bug3452.zip
See also: http://pecl.php.net/bugs/bug.php?id=3452 |
2005-Feb-27 12:35:03 by drh:
As of version 3.0, there is no callback interface.
The sqlite3_exec() function that appears to provide
a callback interface is actually implemented using
prepare/step. Perpare/step is the only way of accessing
the core database engine in SQLite 3.
The fact that the query works with the command-line shell,
therefore, throws suspicion back towards PDO.
2005-Feb-28 01:37:08 by anonymous:
You were right; the problem was that I was incorrectly using sqlite3_column_type(): I incorrectly assumed that the type would remain the same for all rows returned by the query, so when the first row of the query came back as NULL, the PDO layer would optimize by not asking for the value.
It would be nice if there was a version of sqlite3_column_decltype() that returned one of the SQLITE_NULL, SQLITE_BLOB etc. integer values that best represented the column declaration type.
Consider the original problem bogus and the feature request as legitimate :-)
2005-Feb-28 01:49:52 by drh:
A routine similar to sqlite3AffinityType() in build.c could be used
to translate the result of sqlite3_column_decltype() into one of
the constants you request. sqlite3AffinityType() itself cannot be
used because it is not an exported interface, and because the integer
codes it returns are not the same as the codes you want. But are
free to copy the implemention of sqlite3AffinityType() into your
application and change the codes around to suit your purposes. |
|
1141 |
code
|
closed
|
2005 Feb
|
anonymous
|
Parser
|
2005 Apr
|
|
4
|
1
|
Select rowid for integer primary key does not return rowid
|
edit |
create table x (id integer primary key, b);
insert into x values (1, 13);
select rowid, b from x;
Returned column names: "id", "b". Never "rowid". |
2005-Mar-16 09:05:37 by anonymous:
This bug breaks existing applications where 'SELECT rowid, * FROM table' was used to open any table and then precompiled statements were used to update the changed record by using 'UPDATE table SET <field1>=?, <field2>=? ... WHERE rowid=?', since the rowid column does not exist any more in the resultset (the primary key's column name replaces the requested rowid).
We cannot update to sqlite v3.1.x because of this.
2005-Mar-29 14:01:09 by anonymous:
how about using "select id as rowid, b from x;"?
2005-Mar-30 13:21:36 by anonymous:
There are a few applications already in production using sqlite. I was hoping that switching to a newer version would mean only compiling with the newer sources and replacing engine.
You suggest we should rewrite queries in our applications because the engine performs differently now, and this is something we cannot accept.
2005-Apr-27 00:34:37 by drh:
Do this:
PRAGMA short_column_names=OFF;
See ColumnNames for additional information. |
|
1139 |
code
|
closed
|
2005 Feb
|
anonymous
|
Unknown
|
2005 Mar
|
|
1
|
1
|
error while loading shared libraries
|
edit |
The file is created as ODBC.c
#include <string.h>
#include "sqlite.h"
#include "sqlext.h"
#include "config.h"
#include "opcodes.h"
int callback( void *p_data, int num_fields,
char **p_fields, char **p_col_names);
main()
{
int ret;
int nrecs = 0;
char *errmsg;
/* Open the database. */
sqlite* p_db = sqlite_open("/root/PABX.db", 0777, 0);
if(p_db == 0)
{
printf("Could not open database.");
exit(1);
}
/* Select everything from the person table. */
ret = sqlite_exec( p_db,
"SELECT * from empdetails limit 10;",
callback,
&nrecs,
errmsg);
if(ret!=SQLITE_OK)
{
printf("Error on SELECT: %s.\n", errmsg);
}
else
{
printf("Retrieved %i records.\n", nrecs);
}
/* Delete everything from the person table. */
// sqlite_exec( p_db,
// "DELETE * FROM person", 0,0,0);
/* On second thought, don't. */
sqlite_exec(p_db, "ROLLBACK", 0, 0, 0);
/* Close the database. */
sqlite_close(p_db);
}
int callback( void *p_data, int num_fields,
char **p_fields, char **p_col_names)
{
int i;
int *p_rn = (int*)p_data;
(*p_rn)++;
/* Print the field values. */
for(i=0; i < num_fields; i++)
{
printf("%s | " ,p_fields[i]);
}
return 0;
and compiled as gcc -o ODBC ODBC.c -lsqlite
but when u do ./ODBC getting an error saying "error while loading shared libraries: libsqlite.so.0: cannot open shared object file: No such file or directory"
Please can anyone help..... |
2005-Mar-21 01:07:55 by drh:
This is a usage question not a bug report. Please submit this
to the mailing list. |
|
1136 |
code
|
closed
|
2005 Feb
|
anonymous
|
Unknown
|
2005 Feb
|
|
3
|
3
|
make test: syntax error in alter-1.8.2
|
edit |
$ make test
...
./testfixture ./test/quick.test
...
alter-1.8.2...
Error: near ".": syntax error
|
Unable to reproduce. |
|
1132 |
code
|
closed
|
2005 Feb
|
anonymous
|
Shell
|
2005 Feb
|
|
1
|
1
|
database migration from sqlite 2.8.12 to sqlite 3.0.8
|
edit |
Using sqlite documentation adivce for migrating to sqlite3, I run the following command:
sqlite sample.db .dump | sqlite3 sample2.db
the resulting database does not carry the exact same data.
In the original database I have tables with char(32) as primary key.
Those primary keys are usually numbers separated by '.'
In one table the format is either [0-9]* or [0-9]*.[0-9]*
which resembles an integer or float respectively.
The problem stems in the fact that sqlite 2.8.12 doesn't enclose
primary keys that resemble integer or flaot numbers.
as a results I will endup with the following errors:
- duplicated primary keys [when there has been leading zeros]
- modified primary key.
becuase these primary keys appear as forign keys elsewhere,
it screws up the whole migration effort. |
2005-Feb-18 21:36:51 by drh:
Here is your workaround. In the original database do this:
UPDATE table1 SET primkey='x'||primkey;
Then transport the data to version 3 using:
sqlite db .dump | sqlite3 db3
Then in the new version 3 database do this:
UPDATE table1 SET primkey=substr(primkey,2,1e10);
|
|
1131 |
new
|
closed
|
2005 Feb
|
anonymous
|
Unknown
|
2005 Feb
|
|
2
|
3
|
triggers don't seem to work across databases
|
edit |
I believe this trigger syntax should work, but it does not:
with a starting case of:
sqlite> select * from keywords
...> ;
1|true
2|Blue
3|White
4|Orange
5|All
6|Cyan
7|Yellow
8|Green
9|Magenta
10|Red
sqlite> ATTACH DATABASE ":memory:" AS CACHE;
CREATE TABLE CACHE.keywords AS select * from keywords;
sqlite> CREATE TEMP TRIGGER keywordupdate AFTER UPDATE ON keywords
...> BEGIN
...> UPDATE CACHE.keywords SET keyword="foozle" WHERE id=1;
...> END;
SQL error: near ".": syntax error
In contrast, this does work:
sqlite> create temp trigger keywordupdate after update on keywords
...> BEGIN
...> update zzz set keyword="foozle" where id="1";
...> end;
sqlite> update keywords set keyword="true" where id=1;
sqlite> select * from zzz;
1|foozle
2|Blue
3|White
4|Orange
5|All
6|Cyan
7|Yellow
8|Green
9|Magenta
10|Red
sqlite>
|
Triggers do not work across databases because that would lead to
severe complications when you started DETACHing the databases that
the triggers reference.
2005-Feb-18 18:32:22 by anonymous:
Actually it does work like you desire with a combination of the sample sql you offered in your question.
Your first example will work with the following changes:
CREATE TABLE CACHE.Keywords_Cache AS SELECT * FROM Keywords; -- the key is to use a different name than an object in the primary db
CREATE TEMP TRIGGER trigKeywords_AU AFTER UPDATE ON Keywords
BEGIN
UPDATE Keywords_Cache SET Keyword = 'foozle' where rowid = 1;
END;
Note: This behaviour is currently in use by applications I have written and I would appreciate it if this capability was NOT removed in a future version of Sqlite 3.x! |
|
1130 |
doc
|
closed
|
2005 Feb
|
anonymous
|
|
2005 Feb
|
|
4
|
4
|
documentation for PRAGMA short-column-names incorrect
|
edit |
The documentation for PRAGMA short-column-names (on the PRAGMA documentation page) incorrectly lists this PRAGMA as "long-column-names", but contains the correct documentation.
Here's the text from the documentation page:
PRAGMA full_column_names;
PRAGMA full_column_names = 0 | 1;
Query or change the short-column-names flag. This flag affects the way SQLite names columns of data returned by SELECT statements when the expression for the column is a table-column name or the wildcard "*". Normally, such result columns are named . if the SELECT statement joins two or more tables together, or simply if the SELECT statement queries a single table. When the short-column-names flag is set, such columns are always named , regardless of whether or not a join is performed.
If both the short-column-names and full-column-names are set, then the behaviour associated with the full-column-names flag is exhibited.
|
|
1129 |
new
|
closed
|
2005 Feb
|
anonymous
|
Unknown
|
2005 Feb
|
drh
|
4
|
3
|
allow having the same object in several open databases
|
edit |
requiring object names uniqueness in all attached database is an annoyance, thus i would ask to allow duplicates, provided they are accessed using the databasename.objectname directive.
the attached database have readonly schema anyway, and creating an object specifies the database: whether main or temp.
of course, current behaviour should be maintained, and the change be conditioned by a pragma.
best regards,
alex |
2005-Feb-17 13:12:25 by drh:
This is fixed in version 3. |
|
1125 |
code
|
closed
|
2005 Feb
|
anonymous
|
Parser
|
2005 Mar
|
|
1
|
2
|
Syntax error: create index with table name qualified by database name
|
edit |
Work on version 3.0.8:
C:\temp>sqlite3_3.0.8.exe test.sqlite
SQLite version *3.0.8*
Enter ".help" for instructions
sqlite> CREATE TABLE main.test (field1, field2);
sqlite> CREATE INDEX ix_test_field1 ON main.test (field1);
sqlite> .exit
Open this database and query the sqlite_master table with version 3.1.2 this error occurs:
C:\temp>sqlite3_3.1.2.exe test.sqlite
SQLite version *3.1.2*
Enter ".help" for instructions
sqlite> select * from main.sqlite_master;
SQL error: malformed database schema - near ".": syntax error
Create the schema with version 3.1.2:
If the table name is qualified by the database name a syntax error occurs when the index is created.
C:\temp>sqlite3_3.1.2.exe test.sqlite
SQLite version *3.1.2*
Enter ".help" for instructions
sqlite> CREATE TABLE main.test (field1, field2);
sqlite> CREATE INDEX ix_test_field1 ON main.test (field1);
*SQL error: near ".": syntax error*
sqlite> CREATE INDEX ix_test_field1 ON test (field1);
sqlite> .exit
Thanks
Zeilo Luna Jr.
Grupo Elogica S/A |
This bug still occurs in version 3.1.5.
2005-Mar-14 16:46:52 by drh:
The bug was in version 3.0.8. Version 3.0.8 allowed incorrect
syntax. The following is the correct form:
CREATE TABLE database.index ON table(a,b,c);
The following is incorrect and is now disallowed:
CREATE TABLE index ON database.table(a,b,c);
|
|
1119 |
code
|
closed
|
2005 Feb
|
anonymous
|
Parser
|
2005 Feb
|
|
4
|
3
|
Field name interpreted as SQL command. (GROUP)
|
edit |
I know this is kind of stupid... but I will put myself out there...
I was trying to create database with the following syntax....
char *sql_schema[] = {
"CREATE TABLE mpcmap ("
"KEY char, "
"PANEL char,"
"CONTROL char,"
"MSGTYPE char,"
"GROUP char,"
"NOTE char,"
"PRIMARY KEY (KEY))"};
I had a field Named "GROUP"... now... I thought that this should not be interpreted out of context...
but when I tried to make this it would failed...
What is bothersome is that sqlite doesn't tell you why this failed... it just give back an error...
So.. either documentation or correction to the parse, or error message explaining that wrong use of reserved word.
Thanks. |
2005-Feb-15 19:30:46 by anonymous:
This is documented, you should use syntax like the following:
CREATE TABLE x ([Group] char);
or
CREATE TABLE x ('Group' char);
or
CREATE TABLE x ("Group" char);
2005-Feb-15 19:50:01 by drh:
Anonymous poster above is correct. I will close out this ticket. |
|
1118 |
build
|
closed
|
2005 Feb
|
anonymous
|
|
2005 Feb
|
|
1
|
1
|
pa
|
edit |
I'm afraid there is a small release problem :-)
The VERSION file inside sqlite-2.8.16 says something like:
3.1.2 |
Duplicate of ticket #1117. |
|
1113 |
code
|
closed
|
2005 Feb
|
anonymous
|
Unknown
|
2005 Feb
|
|
2
|
2
|
Problem with TYPEOF function in triggers
|
edit |
Problem with TYPEOF function in TRIGGER:
sqlite> CREATE TABLE test(a INTEGER);
sqlite> CREATE TRIGGER test_trg BEFORE INSERT ON test FOR EACH ROW
sqlite> BEGIN
sqlite> SELECT CASE WHEN (TYPEOF(NEW.a) != 'numeric') THEN RAISE(ABORT, "Error") END; END;
sqlite> INSERT INTO test(a) VALUES('aaa');
Error
sqlite> INSERT INTO test(a) VALUES(100);
Error |
2005-Feb-11 22:54:57 by anonymous:
TYPEOF returns 'real', 'integer', 'null', 'text' or 'blob'. Not 'numeric'. 'numeric' was in ver. 2.8.x.
So it's not a bug. |
|
1110 |
code
|
closed
|
2005 Feb
|
anonymous
|
Parser
|
2005 Feb
|
|
4
|
4
|
Detection of invalid create table statement
|
edit |
sqlite> create table example (first integer second integer);
sqlite> insert into example (first, second) values (1,2);
SQL error: table example has no column named second
sqlite> insert into example (first) values (1);
sqlite>
The missing comma is not detected, leading to the acceptance of apparently invalid SQL. You can see that the table has been created with a single column. In the SQLite grammar on the web site, "second" is not a valid keyword following the column type. |
2005-Feb-10 19:55:35 by drh:
The first statement creates a table with a single
column named "first" with a datatype of
"integer second integer". SQLite accepts any number
of identifiers as a valid type name.
Works as designed. |
|
1109 |
code
|
closed
|
2005 Feb
|
anonymous
|
BTree
|
2005 Feb
|
|
1
|
1
|
assert in btree
|
edit |
i think there is a bug in parseCellPtr in btree.c
you can reproduce easily with that pseudocode
btreeopen( )
begintrans( )
createtable( ..., intkey|zerodata )
createcursor( )
for( int i=0; i<50000; i++ )
insertKey( cursor, 0, i, 0, 0 )
and you will get the assert...
the call stack is
balance_deeper
balance_nonroot
the error is in parsecellptr and is due to the code
if( nSize<4 )
nSize = 4;
i fix it for try and i can give you the correction... |
This bug report is rejected for several reasons:
- The version number specified ("3.0") is ambiguious. That
could be anything between version 3.0.0 and 3.0.8. There
were 21 changes to btree.c during that interval.
- We are currently on version 3.1.1. There have been massive
changes to btree.c since version 3.0.8.
- It is not clear what the "insertKey()" routine in the
pseudocode is.
- Direct calls to the btree are not supported. If you cannot
reproduce the problem using published APIs (routines that
begin with "sqlite3_") then it is not a bug.
|
|
1107 |
new
|
closed
|
2005 Feb
|
anonymous
|
Unknown
|
2005 Mar
|
|
5
|
3
|
please add function to query endianness match/mismatch for BLOB
|
edit |
Please add a function that allows a SQLite3 using application to query if the database endianness format matches the host endianness. This is interesting for applications handling BLOBs. |
2005-Mar-21 01:25:27 by drh:
You will need to explain why you think you need this in much more
detail in order to convince me to add it. |
|
1106 |
code
|
closed
|
2005 Feb
|
anonymous
|
|
2005 Feb
|
|
2
|
1
|
sqlite3FinishCoding is masking errors during parsing
|
edit |
I've written logic in my application to deal with SQLITE_BUSY errors. Since upgrading to 3.1.1beta, I've seen "database is locked" errors that don't get caught by my logic.
It turns out the error code coming back is SQLITE_ERROR (sqlite3_errcode returns 1), while the message is "database is locked" (that's the string returned by sqlite3_errmsg16).
Digging into it, the function sqlite3FinishCoding is throwing away error information. This clause is new since 3.0.8 (line 55):
if( !pParse->pVdbe ){
pParse->rc = pParse->nErr ? SQLITE_ERROR : SQLITE_DONE;
return;
}
Shouldn't it be something like:
if( !pParse->pVdbe ){
if( pParse->rc == SQLITE_OK ){
pParse->rc = pParse->nErr ? SQLITE_ERROR : SQLITE_DONE;
}
return;
}
I don't understand all the cases that need to be covered here. I do know that pParse->rc was SQLITE_BUSY until it hit this clause, where it was set to the less-useful SQLITE_ERROR. |
|
1105 |
code
|
closed
|
2005 Feb
|
|
|
2005 Feb
|
|
1
|
3
|
SQLite Crashes when do a Correlated subqueries
|
edit |
It looks like a bug in the 3.1.1beta.
I have found a SQL can cause the SQLite version 3.1.1beta to crash:
SELECT TR.ID, (SELECT sum(TRD1.Amount) FROM PB_Transaction TR1 INNER JOIN PB_TransactionDetail TRD1 ON TR1.ID = TRD1.TransactionID WHERE TR1.ID < TR.ID) Balance FROM PB_Transaction TR INNER JOIN PB_TransactionDetail TRD ON TR.ID = TRD.TransactionID GROUP BY TRD.TransactionID
The error message I got from crash as following:
Sqlite3.exe - Application Error
the instruction at "0x0043670b" referenced memory at "0x00000000". The memory could not be "read".
Click on OK to terminate the program
Click on CANCEL to debug the program
Following is my table schema:
CREATE TABLE PB_Transaction(
ID INTEGER PRIMARY KEY,
DateTime DATE NOT NULL,
Approved BOOL NOT NULL,
Memo VARCHAR,
AccountID INTEGER NOT NULL,
PayeeID INTEGER,
MarkID INTEGER NOT NULL,
MergeID INTEGER DEFAULT NULL,
TransferFTID INTEGER DEFAULT NULL,
Last_UPD DATE NOT NULL
);
INSERT INTO "PB_Transaction" VALUES(1, '2005-02-06 21:03:40', 'Y', 'Memo', 1, 1, 1, NULL, NULL, '2005-02-06 21:03:40');
INSERT INTO "PB_Transaction" VALUES(2, '2005-02-06 21:03:49', 'Y', 'Memo', 2, 1, 1, NULL, NULL, '2005-02-06 21:03:49');
INSERT INTO "PB_Transaction" VALUES(3, '2005-02-06 21:03:52', 'Y', 'Memo', 3, 1, 1, NULL, NULL, '2005-02-06 21:03:52');
INSERT INTO "PB_Transaction" VALUES(4, '2005-02-06 21:04:00', 'Y', 'Memo', 4, 1, 1, NULL, NULL, '2005-02-06 21:04:00');
INSERT INTO "PB_Transaction" VALUES(5, '2005-02-06 21:04:03', 'Y', 'Memo', 5, 1, 1, NULL, NULL, '2005-02-06 21:04:03');
INSERT INTO "PB_Transaction" VALUES(6, '2005-02-06 21:04:30', 'Y', 'Memo', 5, 1, 1, NULL, NULL, '2005-02-06 21:04:30');
INSERT INTO "PB_Transaction" VALUES(7, '2005-02-06 21:04:31', 'Y', 'Memo', 5, 1, 1, NULL, NULL, '2005-02-06 21:04:31');
CREATE TABLE PB_TransactionDetail(
ID INTEGER PRIMARY KEY,
TransactionID INTEGER NOT NULL,
Description VARCHAR,
Amount MONEY NOT NULL,
CategoryID INTEGER
);
INSERT INTO "PB_TransactionDetail" VALUES(1, 1, 'Description', 10, 1);
INSERT INTO "PB_TransactionDetail" VALUES(2, 1, 'Description', 12, 1);
INSERT INTO "PB_TransactionDetail" VALUES(3, 1, 'Description', -90, 3);
INSERT INTO "PB_TransactionDetail" VALUES(5, 2, 'Description', 23, 4);
INSERT INTO "PB_TransactionDetail" VALUES(6, 3, 'Description', 23, 3);
INSERT INTO "PB_TransactionDetail" VALUES(7, 3, 'Description', 23, 3);
INSERT INTO "PB_TransactionDetail" VALUES(8, 3, 'Description', 23, 3);
INSERT INTO "PB_TransactionDetail" VALUES(9, 4, 'Description', 76, 4);
INSERT INTO "PB_TransactionDetail" VALUES(10, 4, 'Description', 76, 3);
INSERT INTO "PB_TransactionDetail" VALUES(11, 4, 'Description', 76, 3);
INSERT INTO "PB_TransactionDetail" VALUES(12, 4, 'Description', 76, 3);
INSERT INTO "PB_TransactionDetail" VALUES(13, 4, 'Description', 76, 5);
INSERT INTO "PB_TransactionDetail" VALUES(14, 4, 'Description', 76, 5);
INSERT INTO "PB_TransactionDetail" VALUES(15, 6, 'Description', 76, 5);
INSERT INTO "PB_TransactionDetail" VALUES(16, 6, 'Description', 76, 5);
INSERT INTO "PB_TransactionDetail" VALUES(17, 6, 'Description', 76.54, 5);
INSERT INTO "PB_TransactionDetail" VALUES(18, 6, 'Description', 76.54, 5);
INSERT INTO "PB_TransactionDetail" VALUES(19, 6, 'Description', 76.54, 5);
INSERT INTO "PB_TransactionDetail" VALUES(20, 7, 'Description', -543.54, 5);
INSERT INTO "PB_TransactionDetail" VALUES(21, 7, 'Description', 1543.54, 5);
INSERT INTO "PB_TransactionDetail" VALUES(22, 7, 'Description', 1543.54, 10);
INSERT INTO "PB_TransactionDetail" VALUES(23, 7, 'Description', 1543.54, 10);
INSERT INTO "PB_TransactionDetail" VALUES(24, 7, 'Description', 1543.54, 10);
INSERT INTO "PB_TransactionDetail" VALUES(26, 7, 'Description', 1543.54, 10);
----------
Hope this info could help to fix the problem. |
2005-Feb-07 22:12:57 by anonymous:
Following is the Visual C++ Assertion Message:
Microsoft Visual C++ RunTime Library
Assertion failed!
Program:...
File:.\vdbe.c
Line:1726
Expression: p1<0 || p->apCsr[p1]!=0
....
2005-Feb-07 23:04:22 by anonymous:
I have verified that this is so (mike cariotoglou). However, the
culprit does not seem to be the correlated subqueries, but the final
GROUP BY clause. in 3.0a, this works and gives a SYNTAX ERROR, as it should IMHO, since you dont do "group by" without aggregates in standard sql. however, the 3.1.1b parser crashes instead of giving the error. somebody has been messing with GROUP BY again ? if it aint broke, dont fix it!
2005-Feb-07 23:11:26 by anonymous:
oops! I was too quick to comment. I added a max(tr.id) in 3.1.0a to overcome the syntax check, and the access violation DID appear. so, it seems to be a genuine bug!
2005-Feb-09 04:02:20 by anonymous:
Hello danielk1977,
Thank you for your effort for Sqlite. I don't know how to contact directly, anyway since you check-in this change, the source in cvs no longer work in my computer (windows). I compiled the newly check-out source from cvs. after compile successfully, and run sqlite3.exe, I type in command .table, and I get a error as following:
Unhandled exception at 0x0040e209 in sqlite3.exe: 0xC0000005: Access
violation reading location 0x0000001f.
void sqlite3ExprDelete(Expr *p){
if( p==0 ) return;
if( p->span.dyn ) sqliteFree((char*)p->span.z);
if( p->token.dyn ) sqliteFree((char*)p->token.z);
sqlite3ExprDelete(p->pLeft);
sqlite3ExprDelete(p->pRight);
sqlite3ExprListDelete(p->pList);
sqlite3SelectDelete(p->pSelect);
sqliteFree(p);
}
debug show p = 0xffffffff
Ming |
|
1104 |
code
|
closed
|
2005 Feb
|
anonymous
|
VDBE
|
2005 Feb
|
|
1
|
1
|
Integer overflow
|
edit |
I'm a little unsure about the severities I've given above. I may be misunderstanding the implications of the bug here, but please see below. I can't quite see the effects of this bug, and I'm not familiar with the code enough to be able to properly set up a test case to debug into this. However, using code downloaded as sqlite-source-3_0_8.zip gives the following compilation warning:
cots/sqlite-3.0.8/src/vdbeaux.c: In function `sqlite3VdbeSerialType':
cots/sqlite-3.0.8/src/vdbeaux.c:1496: warning: integer constant is too large for "long" type
cots/sqlite-3.0.8/src/vdbeaux.c:1496: warning: integer constant is too large for "long" type
That line reads as follows:
if( i>=-140737488355328L && i<=140737488355328L ) return 5;
140737488355328 is hex 0000 8000 0000 0000. Any compiler that actually respects the tag 'L' at the end of those constants should compile them as a long, which will be overflowed. This constants in this line should be tagged with LL to avoid this error.
I'm not sure if this problem actually changes the effects of the code or not, as I wasn't able to debug it. However, this should be a simple enough fix that I figured I would submit it, even not debugged.
The GCC I'm using is:
Configured with: ../configure --prefix=/usr/local --target=i586-mingw32 --enable-threads --enable-languages=c,c++ --enable-sjlj-exceptions --enable-hash-synchronization
Thread model: win32
gcc version 3.3.1 (mingw special 20030804-1)
Meanwile, gcc compiled as:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20)
does not throw this warning and does not seem to have problems, and I can't exactly see why. |
Already addressed by check-in [2246]
. |
|
1102 |
code
|
closed
|
2005 Feb
|
anonymous
|
VDBE
|
2005 Feb
|
|
3
|
3
|
uninitialized memory copy in sqlite3VdbeExec
|
edit |
We're using sqlite in a win32 program, built from the 3.0.8 win32 source tarball. The warning shows up in purify, when calling sqlite3_step() on a statement like "SELECT count(*) from TABLENAME".
Here's the warning stack from purify:
[W] UMC: Uninitialized memory copy in sqlite3VdbeExec {1 occurrence}
Copying 52 bytes from 0x0013df98 (4 bytes at 0x0013df98 uninitialized)
Address 0x0013df98 points into a thread's stack
Address 0x0013df98 is 16 bytes past the start of local variable 'ctx' in sqlite3VdbeExec
Thread ID: 0xac8
Error location
sqlite3VdbeExec [vdbe.c:4309]
if( pMem->z && pMem->z!=pMem->zShort ){
sqliteFree( pMem->z );
}
=> *pMem = ctx.s;
if( pMem->flags & MEM_Short ){
pMem->z = pMem->zShort;
}
sqlite3_step [vdbeapi.c:183]
if( p->explain ){
rc = sqlite3VdbeList(p);
}else{
=> rc = sqlite3VdbeExec(p);
}
if( sqlite3SafetyOff(db) ){
|
2005-Feb-05 00:49:49 by drh:
This is not a bug. The ctx.s value is a structure which is only
partially initialized in the case the purify is complaining about.
But this is typical of the ctx.s structure. The ctx.s.flags field
specifies which of the other fields of the structure have been
initialized and which have not been. So as long as ctx.s.flags
contains the correct value, it makes no difference if unused fields
in the ctx.s structure are initialized - they will never be used.
We could eliminate the warning by initializing the ctx.s to zero
using memset() right after the ctx variable comes into scope.
But doing so would reduce the performance of the system slightly.
And we do not want to make SQLite run slower just to stop purify
from nagging. |
|
1101 |
code
|
closed
|
2005 Feb
|
anonymous
|
Parser
|
2005 Feb
|
|
3
|
3
|
uninitialized memory copy in yy_shift (in win32 version of parse.c)
|
edit |
Hi,
We're using sqlite in a Win32 program, and during a run of purify I noticed the following warning about an uninitialized memory copy. I'm not seeing any incorrect behavior as a result, but it's probably still worth fixing. The version of the parse.c file we have is from the 3.0.8 Win32 release, where I believe you've done the work for us to transform parse.y into parse.c. (To get the right line numbers in purify for parse.c, I had to comment out the "#line" preprocessor directives. )
Here's a copy of the relevant trace from purify:
[W] UMC: Uninitialized memory copy in yy_shift {5 occurrences}
Copying 4 bytes from 0x0013e530 (4 bytes at 0x0013e530 uninitialized)
Address 0x0013e530 points into a thread's stack
Address 0x0013e530 is the local variable 'yygotominor' in yy_reduce
Thread ID: 0xac8
Error location
yy_shift [parse.c:1441]
yytos = &yypParser->yystack[yypParser->yyidx];
yytos->stateno = yyNewState;
yytos->major = yyMajor;
=> yytos->minor = *yypMinor;
#ifndef NDEBUG
if( yyTraceFILE && yypParser->yyidx>0 ){
int i;
yy_reduce [parse.c:2930]
yypParser->yyidx -= yysize;
yyact = yy_find_reduce_action(yypParser,yygoto);
if( yyact < YYNSTATE ){
=> yy_shift(yypParser,yyact,yygoto,&yygotominor);
}else if( yyact == YYNSTATE + YYNRULE + 1 ){
yy_accept(yypParser);
}
sqlite3Parser [parse.c:3056]
yymajor = YYNOCODE;
}
}else if( yyact < YYNSTATE + YYNRULE ){
=> yy_reduce(yypParser,yyact-YYNSTATE);
}else if( yyact == YY_ERROR_ACTION ){
int yymx;
#ifndef NDEBUG
sqlite3RunParser [tokenize.c:455]
/* Fall thru into the default case */
}
default: {
=> sqlite3Parser(pEngine, tokenType, pParse->sLastToken, pParse);
lastTokenParsed = tokenType;
if( pParse->rc!=SQLITE_OK ){
goto abort_parse;
sqlite3_prepare [main.c:989]
memset(&sParse, 0, sizeof(sParse));
sParse.db = db;
=> sqlite3RunParser(&sParse, zSql, &zErrMsg);
if( sqlite3_malloc_failed ){
rc = SQLITE_NOMEM;
|
2005-Feb-04 23:53:44 by anonymous:
By the way, if it matters, the statement that was being prepared was "SELECT major, minor, build, qfe FROM version", on a table whose schema is:
CREATE TABLE version (
major INTEGER,
minor INTEGER,
build INTEGER,
qfe INTEGER
);
2005-Feb-05 00:40:01 by drh:
This is not a bug. The copy of initialized memory occurs
when a grammar
rule reduces that does not set the value of its left-hand
nonterminal. This is harmless (in a correct grammar)
and does not result in incorrect behavior.
The memory could be initialized to zero at the beginning of
yy_reduce() using a memset(). But yy_reduce() is a high-runner -
it uses a significant fraction of the CPU cycles needed to
process an SQL statement. Adding a memset() call would likely
cause a measureable decrease in performance of the system.
Therefore, this change request is rejected. |
|
1098 |
code
|
closed
|
2005 Feb
|
anonymous
|
|
2005 Feb
|
|
1
|
1
|
DBs created with PHP and the command line are incompatible
|
edit |
When I create a sqlite database at the command line with: sqlite3 test.db, either in Linux or Windows, then import data, the data is not readable by php. If I create a database and insert data via php, then the database is not usable at the command line - the message is that the database is encrypted or corrupted. |
2005-Feb-04 17:56:56 by drh:
PHP uses sqlite version 2.8. Version 2.8 database files
are not binary compatible with version 3.0 or 3.1. |
|
1097 |
new
|
closed
|
2005 Feb
|
|
|
2005 Feb
|
|
4
|
1
|
Please provide a numeric version number in sqlite3.h
|
edit |
Could you provide a numeric version number in sqlite.h?
For example, in addition to
# define SQLITE_VERSION "3.1.1beta"
you could have:
# define SQLITE_VERSION_NUMBER 3110
This would make it possible to do version comparisons in the C preprocessor. For example, if SQLITE_VERSION_NUMBER > 3100, then ALTER TABLE is available.
I'm a developer in a small team. I upgrade the sqlite code on my development system and run with it for a while before checking it in to share with the other developers. But I can't change the rest of the code to make use of the new features without keeping that code to myself as well. With the numeric version number, I could conditionally compile the new code. |
|
1096 |
new
|
closed
|
2005 Feb
|
|
Unknown
|
2005 Feb
|
|
3
|
3
|
? placeholder not allowed in LIMIT or OFFSET clause
|
edit |
When I attempt to prepare the following statement using sqlite3_prepare:
SELECT id FROM testEntity LIMIT 5 OFFSET ?;
I get the following error back from SQLite:
near "?": syntax error
Is this really not allowed? If so, that seems a bit odd to me. This seems like a classic use-case for prepared statements (re-running the same query with different offsets).
I'm concerned that I will pay a performance penalty for recompiling statements for the sole purpose of having different offset values. (Limit 5 unnaturally small; that's just for testing purposes.)
---
James Berry had the following suggestion on the mailing list:
Dr. Hipp replied that argument substitution is not allowed in those cases, because it's allowed only where any of the datatypes allowed for substitution would be legal (blob, int, string, null). As limit and offset take only integers, the prepared statement parser wouldn't know ahead of time that the syntax was correct.
While I understand that argument, I, too, think this is unfortunate. I wonder if this could be relaxed such the arguments would simply be coerced at execution time into integer, no matter what the actual argument type. |
|
1093 |
doc
|
closed
|
2005 Feb
|
anonymous
|
Unknown
|
2005 Feb
|
|
5
|
4
|
possible mistake in a comment sqlite3_get_table sqlite3.h:~line312
|
edit |
See below:
** .... Because of the way the
** malloc() happens, the calling function must not try to call
** malloc() directly. Only sqlite3_free_table() is able to release
^ I suspect this should say 'free()' <---------------------
** the memory properly and safely.
...
*/
int sqlite3_get_table( |
|
1092 |
code
|
closed
|
2005 Feb
|
anonymous
|
Unknown
|
2005 Feb
|
|
1
|
2
|
wrong result of a query
|
edit |
i have a table with a integer field nr. the values ar 1, 2, 3, 4
the following query:
SELECT NR FROM TABLE WHERE NR <= 3 ORDER BY NR
gives this result: 1, 2, 3
the following query:
SELECT NR FROM TABLE WHERE NR <= 3 ORDER BY NR DESC
gives this result: 2, 1
the query shoud gives the result:
3, 2, 1
this bug is since version 3.1.0 alpha
thanks
k. schdren |
|
1091 |
code
|
closed
|
2005 Jan
|
anonymous
|
|
2005 Jan
|
|
1
|
1
|
not the function of ".export TABLE FILE"
|
edit |
In shell I import the commands as follows:
# sqlite3 test.db ".output out.txt"
# sqlite3 test.db ".dump tablename"
# sqlite3 test.db ".output stdout"
but the export result is NULL
So I hope to have the function of "export TABLE FILE" |
# sqlite3 test.db
sqlite> .output out.txt
sqlite> .dump tablename
sqlite> .output stdout
|
|
1089 |
code
|
closed
|
2005 Jan
|
anonymous
|
Shell
|
2005 Jan
|
|
1
|
1
|
Segmentation fault
|
edit |
Segmentation fault on Mandrake 10.1 |
|
1088 |
code
|
closed
|
2005 Jan
|
anonymous
|
|
2005 Jan
|
|
2
|
3
|
Allow Collations to work in Views
|
edit |
Views don't respect colallations:
sqlite> create table a(b text COLLATE nocase);
sqlite> insert into a values ('this');
sqlite> insert into a values ('This');
sqlite> insert into a values ('THIS');
sqlite> select * from a where b = 'this';
this
This
THIS
sqlite> create view va as select b from a;
sqlite> select * from va where b = 'this';
this
It seems to me that it ought to respect the collation here. The mail list thread in which it was discussed is here:
http://www.mail-archive.com/sqlite-users%40sqlite.org/msg05827.html
Of course, AFIAC, a better long-term solution would be to support functional indexes so that I could just use LOWER() and have it use the index. Better still would be if LOWER() was guaranteed to work with UTF-8 characters. But short-term, just to have views respect collations would be great.
Thanks!
David |
Fixed in 3.1.0 cvs. |
|
1087 |
event
|
closed
|
2005 Jan
|
anonymous
|
Parser
|
2005 Jan
|
|
5
|
1
|
CREATE TRIGGER with SQLite3 --> Error "near "WHEN" : syntaxe error
|
edit |
CREATE TRIGGER 'fki_tblImmeuble_tblCommune_COM_INSEE'
BEFORE INSERT ON 'tblImmeuble'
FOR EACH ROW BEGIN
SELECT CASE (
WHEN ((SELECT COM_INSEE FROM 'tblCommune' WHERE COM_INSEE = NEW.IMM_INSEE_COMMUNE) ISNULL)
THEN RAISE(ABORT, 'insert on table "tblImmeuble" violates foreign key constraint "fk_IMM_INSEE_COMMUNE"')
)
END
END;
ERROR: "near "WHEN" : syntaxe error" |
2005-Jan-28 02:19:24 by anonymous:
The CASE syntax does not support brackets around the WHEN... THEN... part. i.e. Try:
CASE WHEN <expr> THEN <expr> END
Not
CASE WHEN (<expr> THEN <expr>) END
|
|
1086 |
code
|
closed
|
2005 Jan
|
anonymous
|
|
2005 Jan
|
|
2
|
3
|
sqlite crashes while executing query
|
edit |
The following simple looking query crashes sqlite, both the library (DLL) and the shell, using the attached database.
SELECT device_id FROM Device_Property_List
WHERE device_kind_name = 'Master'
AND device_property_name = 'Has Display'
AND device_property_value = 'T';
This query is pulling data from a view that uses a complex join to combine data from several tables.
This query works correctly using SQLite version 3.0.8, so the workaround for now it to stick with the older version of the library. |
Could not reproduce using Windows XP, the attached database and the 3.1.0 alpha shell downloaded from the download page.
2005-Jan-26 15:07:53 by drh:
I am likewise unable to reproduce. The query works fine on Linux.
2005-Jan-26 16:16:12 by anonymous:
I need to repeat the query twice to get it to crash.
2005-Jan-26 17:52:59 by drh:
I can repeat the query multiple times and it works and gives the
same answer each time.
2005-Jan-28 15:50:54 by anonymous:
If I use the sqlite shell 3.1a downloaded from the website, the database I uploaded, and this query under WinXP SP2; I consistantly get a crash the second time this query is executed.
A production build of sqlite 3.1a from source using MinGW (which passes all the tests in the test suite except bind-4.1) causes a crash inside sqlite.dll on the same query when it is called by my application. This happens consistantly.
I have attached a file, crash.txt, showing the assert failure I got using a debug build of sqlite. This version was built using configure --enable-debug. Note, with this version the sqlite shell crashes the first time the query is executed.
I later built a version using the new debug macros SQLITE_DEBUG and SQLITE_MEMDEBUG so that I could use PRAGMA vdbe-trace to trace the execution up to the failure. This version runs the query without a problem as many times as I care to try.
Tracking back through the map files and dumps of the vdbe.o object file shows that when the production build of sqlite is called by my aplication it is failing right after the same assert call that failed in the attached file . It crahes when it tries to write to address 0x0000001D, which is the offset of the nullRow field. This is consistant with the pC pointer being NULL.
Since I am getting (or not getting) failures under slightly different conditions, I strongly suspect that this is an uninitialized variable problem. I suspect that the additional memory checking and guard bands in the full debug build may be what is stopping the preventing the error from triggering a crash.
I will try a build without SQLITE_MEMDEBUG defined and see what happens. |
|
1077 |
code
|
closed
|
2005 Jan
|
anonymous
|
Shell
|
2005 Jan
|
|
1
|
1
|
auto_increment and insert into ~ select
|
edit |
in FAQ;
CREATE TABLE t1(
a INTEGER PRIMARY KEY,
b INTEGER
);
With this table, the statement
INSERT INTO t1 VALUES(NULL,123);
is logically equivalent to saying:
INSERT INTO t1 VALUES((SELECT max(a) FROM t1)+1,123);
First
INSERT INTO t1 VALUES((SELECT max(a) FROM t1)+1,123);
=>
INSERT INTO t1 VALUES(ifnull((SELECT max(a) FROM t1), 0)+1,123);
Next...^^
I must to use auto_increment in statement 'insert into ~select'
CREATE TABLE t2(
a INTEGER PRIMARY KEY,
i INTEGER
);
insert into t2 values (1, 1);
insert into t2 values (2, 2);
insert into t2 values (3, 3);
t2 :
a / i
1 / 1;
2 / 2;
3 / 3;
insert into t1 select ifnull((select max(a) from t1),0)+1 as a, i as b from t2;
SQL error: PRIMARY KEY must be unique
How can I query, please?
Yours Faithfully
hyji |
2005-Jan-14 12:30:50 by drh:
Autoincrement works as designed. If you have questions, use
the SQLite mailing list. Bug reports are not an appropriate
forum for asking questions. |
|
1076 |
todo
|
closed
|
2005 Jan
|
anonymous
|
Unknown
|
2005 Jan
|
|
2
|
3
|
data loss possible with fsync on Mac OS X 10.3
|
edit |
I noticed the following issue that was mentioned in the ChangeLog for MySQL 4.1.9. I am reproducing the comment here in case it afflicts SQLite (I don't really know), in which case it can be addressed. If this is an outstanding issue, then it is serious and should be dealt with soon, I think.
* InnoDB: Use the fcntl() file flush method on Mac OS X versions
10.3 and up. Apple had disabled fsync() in Mac OS X for internal
disk drives, which caused corruption at power outages.
Of course, do cancel this action item if the problem is known to be fixed in SQLite. |
2005-Jan-14 12:24:25 by drh:
See check-in [1799]
. |
|
1074 |
code
|
closed
|
2005 Jan
|
anonymous
|
Unknown
|
2005 Jan
|
drh
|
3
|
3
|
CREATE INDEX and dbl-quoted index names
|
edit |
The original bug #695 makes note of a "corrected" patch. Where sqliteTableNameFromToken is called twice, instead of once. This corrected patch never made it on the CVS source tree (its missing from the 2.8.15 release build). |
2005-Jan-14 00:07:28 by drh:
Fixed by #869, [1907]
. Currently in CVS. Will appear in 2.8.16. |
|
1073 |
code
|
closed
|
2005 Jan
|
anonymous
|
Shell
|
2005 Jan
|
|
2
|
3
|
Windows Shell: .read commands need '/' in filenames to work
|
edit |
SQLite3 Windows Shell: .read commands seem only to work with Unix-style filenames (forward-slashes), not back-slashes as is the Windows platform standard.
Means that any SQLite2 script has to be modified before using with SQLite3. |
2005-Jan-13 23:43:32 by drh:
The version-3 shell uses \ as an escape character so that you can
enter \n or \t where appropriate. To enter a \ character in a
pathname, you have to double it, like this: \\ |
|
1071 |
code
|
closed
|
2005 Jan
|
anonymous
|
Shell
|
2005 Jan
|
|
4
|
3
|
Typo in .help
|
edit |
Help text relating to .mode command should read '...where MODE is one of:' instead of '...where MODE is on of:' |
|
1067 |
code
|
closed
|
2005 Jan
|
anonymous
|
TclLib
|
2005 Jan
|
anonymous
|
2
|
4
|
Tcl parsing failure in SQL statement DELETE?
|
edit |
#Check the following tcl script
#(on windows platform)
package require sqlite3
sqlite3 testdb "C:/testdb"
testdb eval {CREATE TABLE t (a text)}
testdb eval {INSERT INTO t VALUES('1')}
testdb eval {INSERT INTO t VALUES('2')}
set value '2'
#doesn't work
testdb eval {DELETE FROM t WHERE a=$value}
puts [testdb eval {SELECT * FROM t}]
#failure: no delete, we will get output "1 2"
#workaround
set sql_text "DELETE FROM t WHERE a=$value"
testdb eval $sql_text
puts [testdb eval {SELECT * FROM t}]
#delete ok, we will get output "1"
|
2005-Jan-11 16:26:52 by drh:
Your code should read:
set value 2
What you have above is equivalent to:
DELETE FROM t WHERE a='''2''';
Works as designed. |
|
1065 |
new
|
closed
|
2005 Jan
|
anonymous
|
Unknown
|
2005 Jan
|
|
3
|
3
|
Uppercase and foreign chars problems in searches
|
edit |
Problems with foreign chars searches. I'm Spanish and I have developed a web based customers database. When you do searches on the name of the customer if it contains some acute vowels or N tildes you do not obtain matches if the search is done using lowercases and in the database the name is written in uppercases or the other way round. This problem does not appear in MySQL and it is nice to search on it. But anyhow the application works really fine using SQLite. I think if this problem gets solved in the next PHP version of the database I will write almost all my web applications using SQLite.
Thanks in advance and go on, you are doing a good job. |
2005-Jan-10 19:43:18 by drh:
SQLite version 3.0 allows you to specify collating sequences in
order to solve this problem. |
|
1064 |
code
|
closed
|
2005 Jan
|
anonymous
|
CodeGen
|
2005 Jan
|
|
2
|
1
|
problems with queries and aggregate functions
|
edit |
with the changes introduced by check-in [2176]
i noticed some unwanted behaviour.
with that change, the query
select a from t group by a
will not work!
also, i think some better restrictions should be checked for on select code generation, such as:
- columns in the SELECT should appear in the GROUP BY clause or be used in an aggregate function
select a, b from t group by a
should produce error: column b must appear in group by clause or used in aggregate function
- expressions in GROUP BY clause can't use aggregate functions or can't be non-integer constants
- HAVING clause list must be made of grouped columns or aggregate function calls
i did some testing with postgres to see how it handled these cases and confirm the valid cases |
The restrictions mentioned above are probably a good idea some time in the future. |
|
1060 |
code
|
closed
|
2005 Jan
|
anonymous
|
|
2005 Jan
|
anonymous
|
1
|
2
|
result of calcul
|
edit |
with the 3.0.8 API
when i whant to execute this query
select (v1*v2) from ttable the result is always an integer
but v1 is an real and v2 an integer
if v1 = 12.3 and v2 = 2 the result must be 24.6 but the query return 24 |
Unable to reproduce.
The following always generates 24.6 when I try it:
CREATE TABLE ex1(a real, b real);
INSERT INTO ex1 VALUES(12.3,2);
SELECT a*b FROM ex1;
SELECT (a*b) FROM ex1;
SELECT '12.3'*b FROM ex1;
2005-Jan-05 18:19:05 by anonymous:
the probleme come from regionale code
i used delphi in France
the decimal separator is ','
delphi store 2,2 in database but sqlite need 2.2 for real field |
|
1055 |
code
|
closed
|
2004 Dec
|
anonymous
|
Unknown
|
2005 Jan
|
|
3
|
3
|
Please archive files in PACKAGE-VERSION/ directory
|
edit |
The archived since 2.x have used directory structure:
sqlite/
which makes is hard to upgrade and compile new versions. Please
make future releases archived in versioned directories, like:
sqlite-VERSION/
An example:
slite-3.0.8/ |
2005-Jan-03 01:36:06 by drh:
Duplicate of ticket #855. |
|
1050 |
doc
|
closed
|
2004 Dec
|
anonymous
|
|
2004 Dec
|
|
4
|
4
|
Correct front page information - SQLite is not ACID
|
edit |
Hi there,
You claim on the front page of your site;
"Transactions are atomic, consistent, isolated, and durable (ACID) even after system crashes and power failures."
However, SQLite does not isolate updates from other operations (that is, reading must stop), so it cannot satisfy the I in ACID.
You'd need to implement some kind of consistent read and rollback mechanism to be able to truly claim transaction isolation, which would be a year's project to implement and probably a decade of debugging to get right. Please clarify to something like:
"Of the four required transaction processing features of being atomic, consistent, isolated and durable (ACID), SQLite satisfies all but transaction isolation (writing locks the entire database) - even after system crashes and power failures. This is an excellent compromise for many applications, as implementing true transaction isolation is one of the stickiest problems of writing a DBMS. Instead, SQLite focuses on making the other features work well."
Sam. |
2004-Dec-24 03:35:07 by drh:
If I interpret the complaint correctly, what Sam is saying
is that in SQL code like the following:
BEGIN;
UPDATE table1 SET x=x+1;
SELECT x FROM table1;
COMMIT;
The SELECT statement sees the new values of table1.x in SQLite
whereas in a truely "ACID" database, the table1.x values should not
really change until the COMMIT and so the SELECT statement should
see the old values of table1.x, not the new values.
(Do I understand you correctly Sam?)
With SQLite, all threads/processes other than the one thread/process
that is making the change do not see the new values of table1.x
until the commit occurs. The one thread/process that is making
the changes sees all changes immediately, before the commit
occurs.
I do not know what an SQL database engine should do "really".
But I'd be very surprised to learn that other
SQL database engines operate differently than SQLite in
this regard. Readers are welcomed to enlighten me if I am
wrong.
So, pending additional information, I will continue to say
that SQLite is ACID.
2004-Dec-24 07:37:44 by anonymous:
"With SQLite, all threads/processes other than the one thread/process that is making the change do not see the new values of table1.x until the commit occurs. The one thread/process that is making the changes sees all changes immediately, before the commit occurs."
MS SQLServer behaves exactly like this, besides its logical, makes sense.
Mayowa.
2004-Dec-24 08:20:12 by anonymous:
I based my comment on this behaviour as described in your FAQ (and as I was able to verify using the Perl bindings):
http://www.sqlite.org/faq.html#q7
I can see that the situation is not quite as bad as I originally
thought; you have correctly described the property of "consistent read", which is one requirement of transaction isolation. If you have that, then that is a very large step towards full blown transaction isolation.
To complete ACID support you need to do a little more than this; in a nutshell, it should still work if all threads are writers. Probably the biggest payoff in terms of functionality vs. implementation effort is to not allow threads to commit, if any data that they have selected since they started their transaction has since been altered by a committed transaction. You can still serialise the "commit" phase (ie, avoid having to go to the lengths of finely grained locking necessary to break through to high performance in such scenarios), in effect threads would only lock the database for writing when they are committing their changes.
That is something of an oversimplification, as the above (to the extent of my admittedly very limited knowledge) should be roughly enough to get you to the "repeatable read" SQL isolation level. The PostgreSQL documentation has a very good section describing this:
http://www.postgresql.org/docs/7.4/interactive/transaction-iso.html
Until two threads that claim to be writers can open a sqlite database at the same time, you cannot claim any isolation at all. If two threads can, but they will see each other's commits before they occur, then at least you have the "read uncommitted" transaction isolation level. Which would be a start.
I would like to have the opportunity to take up this conversation in a constructive manner; do you have a developer's mailing list, or should I write to the users list?
2004-Dec-24 13:10:58 by drh:
All transactions in SQLite are serializable.
2004-Dec-26 06:27:21 by anonymous:
Your reply is fairly terse and irrelevant so I assume that you don't understand what I am getting at.
Just bear in mind that stating something so blatantly incorrect, which you have admitted to not understanding, on the front page of your site does not look very good those who do know what it means. Not being ACID makes the library insuitable to a range of uses (which almost certainly also complement the extra great applications that SQLite has).
For instance, it is worth considering that the other popular relational library suite - ISAM - was never made ACID (this includes MyISAM and C-ISAM).
Please, I advise you to revise your claim of being ACID with a clause that qualifies such support does not extend to concurrent writers. Or add support for concurrent writers, then really grok what this whole "transaction isolation level" thing is about so that you can truthfully claim ACID compliance.
2005-Mar-30 03:31:31 by anonymous:
SQLite does not allow concurrect writes - it implements a true honest transaction serialization, so it satisfies all the requirements for being ACID.
ACID does not require concurrent writes. On the contrary: the highest possible transaction isolation level is TRANSACTION_SERIALIZABLE which implies an implementation which behavies as if transactions are serialized, which in ths case they actually are.
SQLite is not supposed to scale to many simultaneous writers and it doesn't claim to, but it offers complete correctness with a moderate performance penalty if transactions are kept short. |
|
1045 |
event
|
closed
|
2004 Dec
|
anonymous
|
|
2004 Dec
|
|
1
|
5
|
MAJOR Problem with accessing databases
|
edit |
I am facing very strange problem with sqlite programming interface.
I have written a C++ application that opens a database and does some operations. It works fine on my system (Linux 8.0).
When I log on to some other machine it opens the database without any error but fails to accept any other command with error
"Sql Error: database is locked"
I have built sqlite using --enable-threadsafe.
Also, my home is on my machine and the system is NFS.
The problem happens on any other machine. |
2004-Dec-20 15:18:14 by drh:
Posix advisory locking is broken on many (most?) NFS systems.
You are advised not to access an SQLite database on an NFS filesystem.
Even if it does work, the database runs the risk of being
corrupted.
This is a problem with NFS, not with SQLite. |
|
1044 |
code
|
closed
|
2004 Dec
|
anonymous
|
|
2004 Dec
|
|
3
|
3
|
Insert an integer as a string
|
edit |
Consider the following code:
CREATE TABLE plip (plop INT);
INSERT INTO plip VALUES (12);
INSERT INTO plip VALUES ('42');
INSERT INTO plip VALUES (' 92');
SELECT * FROM plip;
12
42
92
SELECT * FROM plip WHERE plop=12
12
SELECT * FROM plip WHERE plop=42
42
SELECT * FROM plip WHERE plop=92
SELECT sum(plop) FROM plip;
54
I expect the last SELECT to work, and the sum to return 12+42+92 rather than 12+42.
Why SQLite do not cast the INT since the field plop is defined as an integer ?
I think the third INSERT should be casted as an integer, or should not be inserted, but not a mix of those solutions as it is currently (because the first "SELECT *" works, but WHERE clause doesn't).
I know I should not insert an integer with a string, it was an error. But I consider this as a bug, this is not the expected behaviour when you define a field as an INT. |
2004-Dec-20 14:14:46 by drh:
This is a deliberate feature, not a bug.
See http://www.sqlite.org/datatypes.html
and http://www.sqlite.org/datatype3.html. |
|
1042 |
code
|
closed
|
2004 Dec
|
anonymous
|
Unknown
|
2004 Dec
|
|
1
|
2
|
where does not work
|
edit |
SQLite version 3.0.8
Enter ".help" for instructions
sqlite> select a from tt where (a>2);
select a from tt where (a>2);
a
1
4
4
4
4
4
4
4
sqlite> select a from tt where a>2;
select a from tt where a>2;
a
1
4
4
4
4
4
4
4 |
2004-Dec-19 12:22:59 by drh:
Once again, column TT.A is a TEXT or BLOB not an INTEGER.
Please read http://www.sqlite.org/datatype3.html |
|
1041 |
code
|
closed
|
2004 Dec
|
anonymous
|
Unknown
|
2004 Dec
|
|
1
|
1
|
select x<2 from table does not work anymore
|
edit |
I found no documentation of this change. Is it user error, documentation bug, or bug?
select * from t2;
a b
---------- ----------
1 4
2 5
3 6
.show
echo: on
explain: off
headers: on
mode: column
nullvalue: ""
output: stdout
separator: "\t"
width:
SQLite version 3.0.8
Enter ".help" for instructions
sqlite> select a>=2 from t2;
select a>=2 from t2;
a>=2
----------
1
1
1
sqlite> select a=2 from t2;
select a=2 from t2;
a=2
----------
0
0
0
sqlite>
0 19-Sun-03-28-51 ~# db ver sqlite ti
select * from t2;
a b
---------- ----------
1 4
2 5
3 6
.show
echo: on
explain: off
headers: on
mode: column
nullvalue:
output: stdout
separator:
width:
SQLite version 2.8.15
Enter ".help" for instructions
sqlite> select a>=2 from t2;
select a>=2 from t2;
a>=2
----------
0
1
1
sqlite> select a=2 from t2;
select a=2 from t2;
a=2
----------
0
1
0
sqlite>
|
2004-Dec-19 12:20:43 by drh:
If you do
SELECT typeof(a) FROM t2;
I believe you will find that the T2.A column values are all
TEXT or BLOB instead of INTEGER. Such would cause the behavior
you observer. The following works:
create table t2(a,b);
insert into t2 values(1,4);
insert into t2 values(2,5);
insert into t2 values(3,6);
.header on
.mode column
select * from t2;
select a>=2 from t2;
select a=2 from t2;
|
|
1038 |
code
|
closed
|
2004 Dec
|
anonymous
|
|
2004 Dec
|
|
2
|
2
|
multi-word type names confuse pragma table_info
|
edit |
If I create a table and use multi-word types, the type reported by pragma table_info is mangled:
sqlite> create table one (i integer shorter, j int longish);
sqlite> pragma table_info(one);
cid name type notnull dflt_value pk
---------- ---------- -------------- ---------- ---------- ----------
0 i integershorter 0 0
1 j intlon 0 0
sqlite> create table two (i integer really short, j int really really long);
sqlite> pragma table_info(two);
cid name type notnull dflt_value pk
---------- ---------- ------------------------- ---------- ---------- ----------
0 i integerreallyshort,jintre 0 0
1 j intreallyreallylong); 0 0
|
Duplicate of ticket #934. Fixed for version 3.0.8 by
check-in [1990]
. Surely the example above is from 3.0.7, not
3.0.8 as reported. |
|
1037 |
code
|
closed
|
2004 Dec
|
anonymous
|
Unknown
|
2004 Dec
|
|
1
|
1
|
.Net Interop Problem
|
edit |
I wrote a .Net wrapper for sqlite 3.0.8, and everything appeared to work fine. I can create databases, read/write data, etc. Then when switching one of our real applications to sqlite, it would crash randomly while reading data from the database. The prior mdb database, did not have this problem.
After spending a few hours on this, I determined the problem to be in the sqlite3.dll. I tried a different version of the sqlite3.dll, dated back to late september (also roughly 40 or so kb larger than the latest version), and it performs with no problems whatsoever. Everything works great now using that older DLL. |
2004-Dec-17 22:59:05 by drh:
Sounds like an application problem or a .net problem to
me. And even if it is not, the description is way to vague
to do anything that might be considered "debugging". |
|
1028 |
new
|
closed
|
2004 Dec
|
anonymous
|
Unknown
|
2004 Dec
|
|
2
|
2
|
Without COPY: need alt. method to import data (not .import)
|
edit |
I've been using the COPY SQL command to load data from CSV files at run-time from a .NET application. I'm unsure how I would do the same using the sqlite.exe utility's .import command? That would mean I would have to shell out to run the sqlite.exe if it can take commanline params.
I would strongly urge the team to reconsider the decision to remove COPY from 3.0. There needs to be a way to import data without using the sqlite.exe utility.
Thank you. |
2004-Dec-08 15:29:33 by drh:
Write code to do the import yourself.
- BEGIN
- Prepare an INSERT statement with parameters ("?") for all values.
- Open the text file
- Read and parse a single line of text
- Bind parsed fields to parameters in the prepared statement
- Execute the prepared statement
- If there is more text to be read, go back to step 4.
- Finalize the prepared statement.
- Close the text file.
- COMMIT
|
|
1027 |
code
|
closed
|
2004 Dec
|
anonymous
|
|
2004 Dec
|
|
1
|
3
|
Deletion of records that don't meet the condition set
|
edit |
Try this SQL code:
CREATE TABLE Test ( foo TEXT);
INSERT INTO Test VALUES ("bar");
SELECT * FROM Test; -- there is one record
DELETE FROM Test WHERE foo = "foo";
SELECT * FROM Test; -- there are no records
The example should show pretty well the bug I'm experimenting. |
2004-Dec-07 01:22:20 by drh:
A string in double-quotes resolves to a column name if there
is such a column. So your WHERE clause is equivalent to
foo==foo which is always true. You should use single quotes for the
string literal. I didn't make this up. That's the
way SQL works. |
|
1024 |
code
|
closed
|
2004 Dec
|
anonymous
|
|
2004 Dec
|
|
1
|
1
|
trunk blob data
|
edit |
Blob tuncated by by unencoded '\000', why ? |
2004-Dec-01 18:20:21 by drh:
Is this a question or a bug report? Ask questions on the SQLite
mailing list not here. If this is a bug report, I do not understand
the problem. |
|
1023 |
new
|
closed
|
2004 Nov
|
anonymous
|
Unknown
|
2004 Dec
|
|
4
|
4
|
don't link against pthreads if not configured with --enable-threadsafe
|
edit |
Linking against -lpthread when not configured with --enable-threadsafe can, depending on the OS and pthread/c library used, implicitely change the handling of signals for certain c library routines. For sure this happens on linux. Signals are routed then through the included pthread library and EINTR doesn't happen anymore for certain c library calls. This causes non-threaded applications that link against a non-threaded sqlite library to show unexpected behaviour due to the unexpected inclusion of the pthread library.
A nice to have would be something like libsqlite.so for non-threaded applications and libsqlite_r.so for theaded applications but this is really a nice to have feature. |
2004-Dec-01 18:23:26 by drh:
Already fixed in version 3.0.8. |
|
1022 |
code
|
closed
|
2004 Nov
|
anonymous
|
|
2004 Dec
|
|
4
|
4
|
Table column naming differs between versions 2.8.15 and 3.0.8
|
edit |
When migrating my code from version 2.8.15 to 3.0.8 I encountered the following issue and want to know if this is now a feature or a bug.
The following statement:
CREATE TEMP TABLE temp AS SELECT id,title FROM mytable WHERE title LIKE 'Sesame%'
creates a table with columns named 'id' and 'title' in both versions 2.8.15 and 3.0.8
However, the following modified statement:
CREATE TEMP TABLE temp AS SELECT mytable.id,mytable.title FROM mytable WHERE title LIKE 'Sesame%'
will have column names 'id' and 'title' in version 2.8.15 while version 3.0.8 will have column names 'mytable.id' and 'mytable.title'
Furthermore, if I follow the above statement with:
CREATE TEMP TABLE testing AS SELECT X.* FROM temp AS X
then table 'testing' contains rows 'id' and 'title' in version 2.8.15 and 'mytable.id' and 'mytable.title' in version 3.0.8 as expected. However if I change the statement to:
CREATE TEMP TABLE testing AS SELECT X.id FROM temp AS X
then version 2.8.15 works returning a table with only 'id' as a column. Version 3.0.8 fails because it cannot find a column named 'id' in the table 'temp'. So you would think the following should work for version 3.0.8:
CREATE TEMP TABLE testing AS SELECT X.mytable.id FROM temp AS X
But this also fails! So how can I make the second select work in version 3.0.8? |
2004-Dec-01 18:18:57 by drh:
Use the AS keyword after column names.
Works as designed. |
|
1021 |
code
|
closed
|
2004 Nov
|
anonymous
|
|
2004 Dec
|
|
1
|
3
|
LIKE operator % wildcarding broken
|
edit |
Statement,
CREATE TEMP TABLE testing AS SELECT title FROM tableA WHERE title LIKE '%Sesame%'
returns all rows. Changing the match to 'Sesame%' returns the correct rows.
Problem also exists in version 2.8.15 |
2004-Dec-01 18:17:38 by drh:
Unable to reproduce. |
|
1019 |
code
|
closed
|
2004 Nov
|
anonymous
|
Unknown
|
2005 Jan
|
|
1
|
3
|
Improper handling of 8bit data
|
edit |
Import of dumped database with 8bit string data fails with "SQL error: no such column: ..." message.
Eg. (will probably get mangled by the i18n issues):
INSERT INTO words VALUES(8466,'ÀýÓÚÛþÔþ');
leads to
INSERT INTO words VALUES(8446,ÀÑÓ);
SQL error: no such column: ÀÑÓ
|
2004-Nov-27 02:11:06 by anonymous:
Yes, got mangled. I wanted to send the example as a text file (OEM character set), but...I can't see the promissed chance to attach a file :-(
2005-Jan-03 02:28:55 by drh:
Unable to debug without a description of the problem. |
|
1018 |
code
|
closed
|
2004 Nov
|
anonymous
|
Unknown
|
2005 Jan
|
|
1
|
3
|
Some functions not defined for OS_MAC
|
edit |
I'm using Codewarrior 8.3. The OS selected in os.h is OS_MAC.
Version 2.8.15 seems to work. There seem to be problems with 3.0.8.
I chose to assign the log to drh because log 1992 is a related problem and is also assigned to drh.
linking (with a program which calls sqlite3_exec) gives these undefined functions
sqlite3OsFileModTime
sqlite3OsLock
sqlite3OsCheckReservedLock
function which does not match prototype
sqlite3OsUnlock (does not have 2nd argument of int locktype)
possibly related is the fact that these functions have no prototype
sqlite3OsReadLock
sqlite3OsWriteLock
please ask for more details, if required.
many thanks,
Richard Bovey |
2004-Nov-26 21:43:54 by drh:
Classic Mac is not a support platform for SQLite 3.0 because
none of the developers have access to a development system. |
|
1017 |
code
|
closed
|
2004 Nov
|
anonymous
|
Unknown
|
2004 Nov
|
anonymous
|
1
|
1
|
error while loading shared libraries: /lib/libsqlite.so.0
|
edit |
my application uses sqlite as its database.....
my application compiled successfuly...but while executing(./filename),i get this below error...
the file exists in its required location..........
error while loading shared libraries: /lib/libsqlite.so.0: ELF file OS ABI invalid |
2004-Nov-26 13:34:57 by drh:
This space if for reporting bugs in SQLite. If you are having
difficulty creating an application that uses SQLite you should
post messages on the SQLite mailing list. This is not an
appropriate forum for getting help in building applications to
that use SQLite. |
|
1016 |
code
|
closed
|
2004 Nov
|
anonymous
|
|
2004 Nov
|
|
3
|
3
|
UPDATE command with invalid SQL Syntax executes
|
edit |
SQLite shouldn't execute the following command (it's assumed that a table called t3 with attributes a, b and c exists) because it is not a valid SQL Statement.
UPDATE t3 SET a= 'abcd' AND b = 111 WHERE c = 23
SQLite inserts some strange things in the database but reports no error.
the command in a valid SQL Syntax should be:
UPDATE t3 SET a= 'abcd', b = 111 WHERE c = 23 |
2004-Nov-26 15:30:13 by drh:
The syntax is valid. You are setting column A to the result of
the boolean expression ('abcd' AND (b==1)) |
|
1015 |
doc
|
closed
|
2004 Nov
|
a.rottmann
|
|
2005 Mar
|
|
5
|
4
|
Manpage fixes for SQLite3
|
edit |
Attached is a patch that fixes the manual page for version 3, and protects lines starting with a dot (you may want to apply that part to the manpage of SQLite 2.8.x, too). |
2004-Nov-25 10:28:21 by a.rottmann:
http://stud3.tuwien.ac.at/~e9926584/tmp/sqlite3-manpage.patch
2005-Mar-21 01:36:06 by drh:
The manpage has since been revised by another users. |
|
1013 |
build
|
closed
|
2004 Nov
|
anonymous
|
Unknown
|
2004 Nov
|
peter
|
1
|
1
|
undefined reference to sqlite_open
|
edit |
installed sqlite in /home/sudha/sqlite(sqlite.h file is in this location)
database in /home/sudha/sqlite/bank.db
tried to access database for a gtk application using sqlite_open(.......);
header file sqlite.h included in the application
when i tried to compile the file.....
error: undefined reference to 'sqlite_open'
but line sqlite *p_db; does not give any error
has this got something to do with the headerfile location..
there is no sqlite.h file in /usr/include or any default path for that matter
do i have to include more information in my makefile?
my makefile is:
CC = gcc
ne: ne.c
$(CC) -Wall `gtk-config --cflags` ne.c -o ne `gtk-config --libs`
clean:
rm -f *.o ne |
2004-Nov-24 15:40:00 by drh:
Tickets are for reporting bugs. This is not a bug. This is a question
about how to compile a C program that uses SQLite. Such questions
should be sent to the mailing list. |
|
1009 |
code
|
closed
|
2004 Nov
|
anonymous
|
Unknown
|
2004 Nov
|
|
3
|
3
|
sqlite3RunVacuum: "forever" loop exists in error code path.
|
edit |
In sqlite3RunVacuum, an attempt is made to create a unique filename.
10 attempts should be made and the loop should exit.
However, the loop counter 'i' is never incremented and the do-while
will loop forever....
reference: vacuum.c, r1.33, line 136.
Additionally, there was code in there to handle this case where this
error condition was true. I.e. a unique file name could not be produced. Now, it falls through without the "goto end_of_vacuum"
being called and without a message indicating the error condition.
Not sure the repercussions of falling through. I.e, reusing an
existing filename.
Thanks,
Steve |
Removed the loop counter and added a comment to explain why it is
safe to do so without getting into an infinite loop. |
|
1006 |
new
|
closed
|
2004 Nov
|
anonymous
|
Parser
|
2004 Nov
|
|
4
|
3
|
Creation of sqlite3_exec16 ?
|
edit |
Simple request: would it be possible to have a UTF16 equivalent of the sqlite3_exec function.
It would make natively wide-string code less cluttered with conversions to byte-length chars, and would hopefully not take too long to implement.
Cheers all, and thanks,
Bryan |
2004-Nov-20 18:39:53 by drh:
The sqlite3_exec() API is provided for historical compatibility with
SQLite version 2.8. Sqlite3_exec() is implemented entirely using
other published APIs of SQLite. If you want a UTF-16 version of
Sqlite3_exec(), it is easy enough to copy the existing sqlite3_exec()
implementation and make appropriate modifications for yourself. |
|
1005 |
code
|
closed
|
2004 Nov
|
anonymous
|
Unknown
|
2004 Nov
|
|
1
|
1
|
No error from sqlite3_exec
|
edit |
Hi,
I've written following code. Why the sqlite3_exec returns SQLITE_OK ?
When the memory is exhausted sqlite doesn't execute code and always returns SQLITE_OK.
#include <stdlib.h>
#include <stdio.h>
#include "sqlite3.h"
static int LiteCallback(void *vp_NotUsed, int vi_Argc, char **vppc_Argv, char **vppc_ColName)
{
int i_Cnt;
for(i_Cnt = 0; i_Cnt < vi_Argc; i_Cnt++)
{
fprintf(stderr, "%s = %s\n", vppc_ColName[i_Cnt], vppc_Argv[i_Cnt] ? vppc_Argv[i_Cnt] : "NULL");
}
fprintf(stderr,"\n");
return 0;
} /* LiteCallback */
void LiteExec(sqlite3 *vpx_DB, const char *vpc_Stmt)
{
char *pc_Msg = NULL;
if(sqlite3_exec(vpx_DB, vpc_Stmt, LiteCallback, 0, &pc_Msg) != SQLITE_OK)
{
fprintf(stderr, "SQL error: %s\n", pc_Msg);
exit(1);
}
} /* LiteExec */
int main(int vi_Argc, char **vpc_Argv)
{
sqlite3 *px_DB;
if (sqlite3_open(":memory:", &px_DB))
{
fprintf(stderr, "Can't open database: %s\n", sqlite3_errmsg(px_DB));
return 1;
}
while(malloc(1024*1024) != NULL);
while(malloc(1024) != NULL);
while(malloc(1) != NULL);
LiteExec(px_DB, "create table Ala (pole number) ");
LiteExec(px_DB, "insert into ala(pole) values(10); ");
LiteExec(px_DB, "select * from ala");
if (sqlite3_close(px_DB) != SQLITE_OK)
{
fprintf(stderr, "Can't close database: %s\n", sqlite3_errmsg(px_DB));
return 1;
}
fprintf(stderr, "End of test\n");
return 0;
} /* main */
|
Unable to reproduce. When I compile and run the code given above
I get SQLITE_NOMEM errors. |
|
1000 |
code
|
closed
|
2004 Nov
|
anonymous
|
Unknown
|
2004 Nov
|
anonymous
|
1
|
1
|
use popen function and sqlite3_open is dummy..
|
edit |
my email address is rokmn3309 at hotmail.com
my program is only gnu C, i used popen and i make "sqlit3_open" call function, but not response.
so i delete popen function and re testing.. ,"sqlit3_open" call function is response..
i think that popen function or sqlit3_open function problem..
popen function is this..
//-----------------------------------------------------------------//
int process_alive(char *process_name){
FILE *pfp;
char readbuf[bufMaxLen];
char readbuf2[bufMaxLen];
memset(readbuf, 0, bufMaxLen);
snprintf(readbuf,bufMaxLen,"ps -ax | grep java | awk '{ if ($6 ~ /^%s/) print $6 }'",process_name);
if (( pfp = popen(readbuf, "r")) == NULL){
return 0;
}
if(fgets(readbuf,bufMaxLen, pfp)){
pclose(pfp);
snprintf(readbuf2,strlen(readbuf),"%s",readbuf);
if(!strcmp(readbuf2,process_name))
return 1;
else
return 0;
}
else{
pclose(pfp);
return 0;
}
pclose(pfp);
return 0;
}
//-----------------------------------------------------------------//
and "sqlit3_open" call function is this
int Query_Exec(char *dbname,char *tablename,char *sqlquery){ sqlite3 *db;
char *zErrMsg = 0;
char dbbuf[bufMaxLen];
int rc;
memset(dbbuf, 0, bufMaxLen);
snprintf(dbbuf,bufMaxLen,"%s/%s",DB_LOCATION,dbname);
printf("Query_Exec db: %s\n",dbbuf);
//-------- this position is stop ---------//
rc = sqlite3_open(dbbuf, &db);
printf("db open: %d\n",rc);
if(rc != SQLITE_OK){
printf("Can't open database: %s\n", sqlite3_errmsg(db));
sqlite3_close(db);
exit(0);
}
rc = sqlite3_exec(db, sqlquery, callback, 0, &zErrMsg);
printf("db exec: %d\n",rc);
if( rc!=SQLITE_OK ){
printf("SQL error: %s-%d\n", zErrMsg,rc);
}
sqlite3_close(db);
return 0;
}
|
2004-Nov-20 19:35:02 by drh:
The trouble report above gives insufficient information to
recreate the problem. Attempts to reconstruct the problem using
the sketchy information above have been unsuccessful. |
|
999 |
build
|
closed
|
2004 Nov
|
anonymous
|
|
2005 Jan
|
|
5
|
4
|
CVS conflict files left in the source
|
edit |
Just a really stupid minority; please delete the following files from
the distributed source:
sqlite/src/.#btree.c.1.189
sqlite/src/.#os_win.c.1.16
sqlite/src/.#expr.c.1.164
Thanks,
Laszlo/GCS |
|
998 |
event
|
closed
|
2004 Nov
|
anonymous
|
Unknown
|
2004 Nov
|
anonymous
|
2
|
1
|
Database table is locked accessing SQLite through QT library.
|
edit |
Hello,
I try to update a QSqlite database table with QSqlCursor::update() method and I obtain the following error message:
Call to:
// (my class inherits from QSqlCursor)
qDebug("pb cursor après update : " + this->lastError().driverText() + ", " + this->lastError().databaseText());
results in:
pb cursor après update : Unable to fetch results, database table is
locked
What kind of mistake can generate this error?
I realise a lot of update operations on many tables and on this special table it always goes wrong. Anywere else it works fine.
I try exactly the same code whith an MSAccess database and it works ?!
Does this refer to a known problem of SQLite?
We have neither another process running which is locking the
table, nor a separate thread on the database, nor another application that could be accessing the database.
Thanks for your help,
Damien |
2004-Nov-12 13:31:04 by drh:
Please report this bug to QSQLite. This forum is for SQLite
bugs only.
2004-Dec-10 11:45:26 by anonymous:
Hello,
The mentioned problem was in my code ;-)
I tried to launch a DB transaction before ending the first one.
Damien |
|
997 |
code
|
closed
|
2004 Nov
|
anonymous
|
|
2004 Nov
|
|
2
|
4
|
Returned column names include table name or alias.
|
edit |
In a query in which the selected field(s) include the table name or alias, the table name or alias is included in the column name in the returned data.
In Oracle and MySQL, the returned column name would be simply "recpId" (unless, perhaps, the query asked for both R.recpId and RT.recpId). |
2004-Nov-12 00:08:45 by anonymous:
Encountered on Windows 2000.
2004-Nov-20 19:21:27 by drh:
Us the AS clause to name columns any way you want.
Changing SQLite at this point would break backwards compatibility
and is thus not an option.
2005-Feb-03 08:04:14 by anonymous:
This is definitely a bug and I'd suggest a pragma or something like that. You are unable to use sqlite as a backend anywhere where mysql, postgresql etc is supported. |
|
996 |
code
|
closed
|
2004 Nov
|
anonymous
|
Unknown
|
2004 Nov
|
anonymous
|
2
|
4
|
Error in primary key fields for temp tables
|
edit |
How to reproduce the problem:
First I create this table.
create table texts(id INTEGER PRIMARY KEY,file TEXT, text TEXT);
Then I create a temporary table like this
create temp table texts_temp as select * from texts.
Now if I try to insert a new record in texts_temp
insert into texts_temp values(NULL,'a file','a text')
the value NULL is inserted and not a new primary key. When I call LastInsertID though, the value is correct for the last insert ID.
WORKAROUND:
create temp table texts_temp(id INTEGER PRIMARY KEY,file TEXT,text TEXT) |
2004-Nov-20 19:39:42 by drh:
When creating a table using CREATE TABLE AS, SQLite has never
put a primary key on the created table. To change that now would
break backwards compatibility. |
|
994 |
code
|
closed
|
2004 Nov
|
anonymous
|
Unknown
|
2004 Nov
|
|
3
|
3
|
Brackets in JOIN statements break <table>.<column> SELECT syntax
|
edit |
With the following database:
CREATE TABLE l (
Id INTEGER
);
CREATE TABLE r (
Id INTEGER
);
This query works:
SELECT r.Id
FROM l LEFT JOIN r ON l.Id = r.Id;
But this one doesn't:
SELECT r.Id
FROM (l LEFT JOIN r ON l.Id = r.Id);
It returns:
SQL error: no such column: r.Id
Obviously this is a trivial case but with a complex join, where order is important, the brackets may be required. |
2004-Nov-20 19:45:31 by drh:
Parentheses (and they are "parentheses", not brackets) in the FROM
clause of a statement in SQLite are expanded into a subquery. So
SELECT * FROM z LEFT JOIN (x LEFT JOIN y)
is rewritten as
SELECT * FROM z LEFT JOIN (SELECT * FROM x LEFT JOIN y)
Column names are expanded accordingly. SQLite is unlikely to do
anything more sophisticated in the near-term because the behavior
above provides everything you need to do most any query you could
want. To add the feature requested by this ticket would not
provide any new capability. It would only provide syntactic
sugar. |
|
993 |
new
|
closed
|
2004 Nov
|
anonymous
|
|
2004 Nov
|
|
3
|
4
|
Plug-in codec support.
|
edit |
I know there is a non-public encryption implementation, but it would be really useful if there was some way to plug in a codec at runtime, possibly through a callback mechanism. Something like:
void sqlite3_encode_method (encode_func e);
void sqlite3_decode_method (decode_func d);
where e and d are the encode and decode functions to be used by sqlite. |
There are no plans to support codecs in the public release of SQLite. |
|
992 |
code
|
closed
|
2004 Nov
|
anonymous
|
Unknown
|
2004 Nov
|
|
3
|
3
|
sqliteStrRealloc: Return early under malloc failure.
|
edit |
If malloc fails, an impending crash is awaiting.
Add a return to the 'if' clause when malloc fails.
This may be from an old (unmaintained) version
but thought I would pass it along.
Thanks,
Steve
** $Id: util.c,v 1.74 2004/02/22 17:49:34 drh Exp $
void sqliteStrRealloc(char **pz){
char *zNew;
if( pz==0 || *pz==0 ) return;
zNew = malloc( strlen(*pz) + 1 );
if( zNew==0 ){
sqlite_malloc_failed++;
sqliteFree(*pz);
*pz = 0;
return; <<<<<<<< RETURN REQUIRED >>>>>>>>>>>>
}
strcpy(zNew, *pz);
sqliteFree(*pz);
*pz = zNew;
} |
2004-Nov-09 17:44:45 by anonymous:
Routine appears to be deprecated/removed from the latest
version.... IGNORE ticket... |
|
990 |
code
|
closed
|
2004 Nov
|
anonymous
|
|
2005 Jan
|
|
1
|
1
|
PRAGMA empty_result_callbacks in tclsqlite-3.0.8.so eliminated?
|
edit |
PRAGMA empty_result_callbacks not working in tclsqlite-3.0.8.so
Referencing ticket # 967, I stated that it was the tclsqlite code that was not functioning properly, not the ./sqlite3 executable.
Still awaiting a response on this - 11/05/2004.
I would be happy to look over the tclsqlite shared library code if it is posted. I does not appear to be included in the sqllite source (or I can't determine it).
Thanks
Here is a script that you can use to reproduce the issue. As you can see the results are quite different.
#----------->
load ./lib/tclsqlite-3.0.8.so sqlite3
puts [info patchlevel]
sqlite3 db :memory:
db eval "create table t1(a,b);"
puts "before 3.0.8 select, no pragma"
db eval "select * from t1;" x {
puts "x(*) = $x(*)"
}
db eval "PRAGMA empty_result_callbacks=1"
puts "before 3.0.8 select, yes pragma"
db eval "select * from t1;" x {
puts "x(*) = $x(*)"
}
db close
load ./lib/tclsqlite-2.8.15.so Tclsqlite
sqlite db2 :memory:
db2 eval "create table t1(a,b);"
puts "before 2.8.15 select, no pragma"
db2 eval "select * from t1;" x {
puts "x(*) = $x(*)"
}
db2 eval "PRAGMA empty_result_callbacks=1"
puts "before 2.8.15 select, yes pragma"
db2 eval "select * from t1;" x {
puts "x(*) = $x(*)"
}
db2 close
puts "done"
# <-------------------
and the results:
$ tclsh test_sqlite.tcl
8.4.3
before 3.0.8 select, no pragma
before 3.0.8 select, yes pragma
before 2.8.15 select, no pragma
before 2.8.15 select, yes pragma
x(*) = a b
done
|
2004-Nov-05 22:50:28 by anonymous:
I would be happy to look over the tclsqlite shared library code if it is posted.
Take a look at
this
2005-Jan-03 02:41:02 by drh:
Duplicate of ticket #969. |
|
989 |
code
|
closed
|
2004 Nov
|
anonymous
|
Unknown
|
2004 Nov
|
|
3
|
3
|
Followup to #984, same issue with hexToInt
|
edit |
hexToInt should be defined if SQLITE_HAS_CODEC is defined.
$ diff sqlite/src/util.c.ORIG sqlite/src/util.c
902c902
< #if (!defined(SQLITE_OMIT_BLOB_LITERAL) && !defined(SQLITE_HAS_CODEC)) \
---
> #if !defined(SQLITE_OMIT_BLOB_LITERAL) || defined(SQLITE_HAS_CODEC) \
918c918
< #endif /* (!SQLITE_OMIT_BLOB_LITERAL && !SQLITE_HAS_CODEC) || SQLITE_TEST */
---
> #endif /* !SQLITE_OMIT_BLOB_LITERAL || SQLITE_HAS_CODEC || SQLITE_TEST */
|
2004-Nov-20 19:56:08 by drh:
SQLITE_HAS_CODEC is not supported in the public release. |
|
988 |
code
|
closed
|
2004 Nov
|
anonymous
|
Unknown
|
2004 Nov
|
|
4
|
4
|
column type "int primary key" doesn't autoincrement
|
edit |
When I use short form for column type - "int" instead of "integer", combined with "primary key", autoincrement on this column doesn't work (NULLs are inserted instead):
SQLite version 3.0.8
Enter ".help" for instructions
sqlite> create table u1 (i1 int primary key);
sqlite> insert into u1 values (NULL);
sqlite> insert into u1 values (NULL);
sqlite> insert into u1 values (NULL);
sqlite> select * from u1;
sqlite> create table u2 (i2 integer primary key);
sqlite> insert into u2 values (NULL);
sqlite> insert into u2 values (NULL);
sqlite> insert into u2 values (NULL);
sqlite> select * from u2;
1
2
3
Not sure if this is a bug or feature, but unexpected behavior - at least. Strange thing is that it is possible to insert more than one non-unique value into table, even if this value is NULL. |
2004-Nov-05 03:44:51 by drh:
Works as designed. |
|
986 |
code
|
closed
|
2004 Nov
|
anonymous
|
Unknown
|
2004 Nov
|
|
3
|
4
|
indexed "between" is slower than manually typing out constraints
|
edit |
"select * from blah where x > 10 and x < 20" is way faster than
"select * from blah where x between 10 and 20" when x is indexed.
Otherwise I love sqlite! PowerDNS supports it as well. |
2004-Nov-20 20:54:34 by drh:
SQLite does not currently optimize the BETWEEN operator. |
|
983 |
code
|
closed
|
2004 Nov
|
anonymous
|
|
2004 Nov
|
|
1
|
1
|
assert()'s broken on both (some) 32 bit and (most) 64 bit platforms
|
edit |
Exceptions on lines like this:
assert( sizeof(ptr)==sizeof(char*) );
(btree.c, line 1043: sizeof ptr is 8)
See this:
http://bugs.kde.org/show_bug.cgi?id=92563 |
2004-Nov-03 21:10:38 by anonymous:
The assert is correct. SQLite is being miscompiled.
See the discussion on the mailing list for details. |
|
982 |
code
|
closed
|
2004 Nov
|
anonymous
|
|
2004 Nov
|
|
2
|
2
|
COPY command does not work in 3.0.8 as it does in 2.8.13
|
edit |
I've attached a zip file with 'zip-bad.sql' and zip.csv. The purpose is to read in a CSV file into a table.
It works fine with SQLite 2.x:
sqlite v2.db < sql-bad.sql
It fails with:
COPY allzips from 'zip.csv' USING DELIMITERS ',';
SQL error: near "COPY": syntax error
when you try w/ sqlite3:
sqlite3 v3.db < sql-bad.sql
|
2004-Nov-02 21:51:17 by drh:
The COPY command was deliberately removed from 3.0 because
it is not standard SQL and we could not figure out how it
should deal with UTF-16.
Works as designed.
2004-Nov-02 22:10:05 by anonymous:
Arrgh! Then the DOCUMENTATION needs to be changed, please! |
|
981 |
code
|
closed
|
2004 Nov
|
anonymous
|
|
2005 Jan
|
|
1
|
1
|
UTF8 characters in database directory or filename not supported
|
edit |
sqlite_open does not support UTF8 encoded characters.
String used is a multibyte string. |
2004-Nov-04 13:17:58 by anonymous:
Additional comments:
SQLite built on Windows (XP and/or 2000) as a DLL. Used as a DLL in a C++ application that is built with UNICODE support. Run on Windows XP and 2000.
Can be reproduced by doing the following:
CString aDatabaseFilename= _T("c:\temp\Dndrad.db");
char* pDatabaseFilename = new char[(aDatabaseFilename.GetLength() * 4) + 1];
WideCharToMultiByte (CP_UTF8, 0, aDatabaseFilename, -1, pDatabaseFilename, (aDatabaseFilename.GetLength() * 4) + 1, NULL, NULL);
m_pDatabase = sqlite_open(pDatabaseFilename, 0, &pErrMsg);
The database is opened successfully , but has the name Cndrad.db, which means when it is later referred to as Dndrad.db, it is not found.
[Note the characters didn't come out properly in the text here - the D of Dndrad should be an A with two dots]
2005-Jan-13 23:59:59 by drh:
This is a new feature request. New features go into version 3.0.
Version 2.8 is in maintenance. |
|
978 |
code
|
closed
|
2004 Oct
|
anonymous
|
BTree
|
2004 Oct
|
anonymous
|
3
|
3
|
bug in sql_step related to INTEGER PRIMARY INDEX values.
|
edit |
sql_step in sql_exec started crashing after I entered 2 rows with custom values in the INTEGER PRIMARY INDEX column, then a row with none defined (to get an automatical one). |
2004-Oct-31 17:24:43 by drh:
Unable to reproduce. |
|
977 |
code
|
closed
|
2004 Oct
|
anonymous
|
Unknown
|
2004 Nov
|
|
3
|
3
|
View Bug
|
edit |
if you select "*" or fields from a view it will return each FieldType as a Numeric Value.
I work with SQLite 2.8x in a Delphi/ZEOSLib Enviroment. could possible the Bug is in the ZEOSLib... but Table selects works fine.
PS: I really like SQLite and so ive written a Free German Administrator Tool for SQLite 2.8 if you like check it out :) http://hellsystems.pscript.de |
2004-Oct-28 14:04:56 by anonymous:
to check out (to be sure) you could try a little sample application with the sqlite delphi components found on the bindings page.
2004-Nov-20 20:49:31 by drh:
This is not considered a bug in 2.8. Version 3.0 behaves
differently and more in line with what users familiar with
statically-typed databases expect. |
|
976 |
code
|
closed
|
2004 Oct
|
anonymous
|
|
2004 Oct
|
|
1
|
1
|
Locale & upper/lower
|
edit |
Upper/lower functions use "C" locale default. I need to use "Russian" locale. Setting locale in my prog influence to all upper/lower fuctions in it, but don't influence to this functions in sqlite.dll.
Can I change locale for this fuctions whithout editing and recompiling sqlite.dll? |
2004-Oct-27 11:16:23 by drh:
Register your own upper/lower functions using
sqlite3_create_function().
Works as designed. No changes to code. |
|
970 |
code
|
closed
|
2004 Oct
|
anonymous
|
Parser
|
2005 Jan
|
|
2
|
3
|
Crush in authorization procedure
|
edit |
assertion in auth.c line 128
When
db->xAuth!=0 (authorization callback is set)
Incorrect query like,
SELECT f('sth'.'sth');
results in assertion (in next step access violation exception is thrown). |
This is a duplicate of ticket #896 that was fixed by check-in [1953]
. |
|
968 |
code
|
closed
|
2004 Oct
|
anonymous
|
Unknown
|
2004 Oct
|
anonymous
|
5
|
5
|
Access overrun (sometimes) with use of SELECT DISTINCT
|
edit |
When I execute this command:
'SELECT DISTINCT(NAME) FROM TPEOPLE' ('SELECT NAME FROM TPEOPLE' is ok)
in file btree.c:
-> static void insertCell(...)
-> memcpy(&data[idx], pCell, sz);
-> Borland C++ Builder's CodeGuard make an exception (Access overrun) sometimes.
It's difficult to reproduce and maybe it's not very important. The software continues without visible problems. |
2004-Oct-19 16:49:39 by anonymous:
I tested with SQLite version 3.0.2. It doesn't seem to have this problem.
2004-Oct-19 17:07:55 by drh:
I carefully instrumented the code and could find no buffer overruns
over the entire test suite.
In the absence of additional information, I will assume this is
a problem with Borlands bounds checking tool. |
|
967 |
event
|
closed
|
2004 Oct
|
anonymous
|
TclLib
|
2004 Oct
|
|
3
|
2
|
PRAGMA empty_result_callbacks not working in tclsqlite-3.0.8.so
|
edit |
I am attempting to use the PRAGMA empty_result_callbacks=1 in tclsqlite-3.0.8.so. It is not recognized as a valid pragma option in Version 3.
I am not sure if this was discontinued in version 3.x (it is no longer referenced in the documentation) by design, but there was no mention in the change log that I could find as to why it's been ommitted.
Has this pragma been eliminated? I have had to go back to verion 2.8 to continue using SQLite.
Thanks |
2004-Oct-19 17:12:31 by drh:
EMPTY_RESULT_CALLBACKS still works as it always has.
Witness:
[drh@sarah bld]$ ./sqlite3 :memory:
SQLite version 3.0.8
Enter ".help" for instructions
sqlite> create table t1(a,b);
sqlite> .header on
sqlite> select * from t1;
sqlite> pragma empty_result_callbacks=on;
sqlite> select * from t1;
a|b
sqlite>
|
|
964 |
code
|
closed
|
2004 Oct
|
anonymous
|
Pager
|
2004 Oct
|
|
3
|
1
|
Possible segfault from bad call
|
edit |
I have a user who is experiencing segfaults running DSPAM with sqlite; i ran sqlite under valgrind and found:
==1088== Syscall param write(buf) contains uninitialised or unaddressable byte(s)
==1088== at 0x1B9F5FB3: __write_nocancel (in /lib/tls/libc-2.3.3.so)
==1088== by 0x8080AE3: pager_write_pagelist (pager.c:1262)
==1088== by 0x8081BA1: sqlitepager_commit (pager.c:2020)
==1088== by 0x8071A6E: fileBtreeCommit (btree.c:911)
==1088== Address 0x1BACAE36 is 86 bytes inside a block of size 1364 alloc'd
==1088== at 0x1B904A90: malloc (vg_replace_malloc.c:131)
==1088== by 0x80617CB: sqliteMallocRaw (util.c:268)
==1088== by 0x8080BEA: sqlitepager_get (pager.c:1387)
==1088== by 0x8071C65: fileBtreeCursor (btree.c:1056)
which looks pretty bad. Any idea what might cause this or how to fix? |
2004-Oct-18 14:21:49 by drh:
Without additional information about how this situation was
reached, I am unable to analyze or repair the problem.
Note also that valgrind is notorious for complaining about things
that are not really bugs. I suspect this situation is benign. |
|
963 |
code
|
closed
|
2004 Oct
|
anonymous
|
Unknown
|
2004 Oct
|
|
3
|
3
|
PRIMARY KEY
|
edit |
CREATE TABLE T1(id int AUTO_INCREMENT NOT NULL, x int);
INSERT INTO T1 (x) VALUES(3);
INSERT INTO T1 (x) VALUES(4);
SELECT * FROM T1;
This script is working with a normal MySQL,
but not in the Sqlite 2_8_15,
The select statement does not show the ID index.
Which appears to be NULL.
Have I missed something?
Thanks for your help
Alain
|
2004-Oct-16 13:13:07 by anonymous:
Take a look at this
2004-Oct-16 13:18:40 by drh:
SQLite is not MySQL. It works differently. Please read the
documentation. |
|
961 |
new
|
closed
|
2004 Oct
|
anonymous
|
|
2004 Oct
|
anonymous
|
5
|
5
|
a varchar value can be longer than its definition
|
edit |
Hello,
Firstable, a big thank you for this library.
I love it, and I noticed a great reliability.
2 remarks :
1) Speed of insert (without transaction) is slower on Windows 2000/XP than on Windows 9x. I know that does not come from SQLite, but the difference is large.
2) These SQL commands don't produce an exception and the value is really inserted (maybe because SQLite3 change datatype to TEXT ?):
CREATE TABLE TESTTABLE (NAME VARCHAR(10))
INSERT INTO TESTTABLE VALUES('123456789 123456789 ')
|
2004-Oct-14 14:37:12 by anonymous:
Please see faq 11 with regards to varchar. SQLITE is typeless and so does not enforce constraints when inserting data into a column. This works as expected. With regards to the performance envolved there are alot of differences between them so I would expect that to be normal performance for an unwrapped insert. If you are performing multiple inserts wrapping them within a transaction provides greater performance.
I would recommend closing this ticket out as works as expected.
2004-Oct-14 14:38:56 by anonymous:
Also with regards to the speed of inserts between different operating systems if this is disk based inserts the factors such as hardsisk speed need to be factored in as well, so consider are you comparing apples to apples here ?
2004-Oct-14 16:34:44 by anonymous:
You are right.
Afflicted for this poor ticket... |
|
958 |
code
|
closed
|
2004 Oct
|
anonymous
|
Unknown
|
2004 Nov
|
drh
|
3
|
2
|
sqlite3_create_function() dose not really delete an user function
|
edit |
I use the following statement to create a user function, and it works OK:
sqlite3_create_function(db,"TestAdd",2,SQLITE_UTF8,p1,&TestAddFunc,NULL,NULL);
then I dispose the user function with the next statment:
sqlite3_create_function(db,
(db,"TestAdd",0,SQLITE_UTF8,NULL,NULL,NULL,NULL);
but a SQL statement used "TestAdd" still invoke my TestAdd function, but the p1 pointer was missed.
|
2004-Nov-20 20:53:45 by drh:
The 3rd parameter (the number of arguments to the function)
must match. |
|
957 |
new
|
closed
|
2004 Oct
|
ghaering
|
|
2004 Oct
|
|
1
|
1
|
Old callback-based API should still return column types
|
edit |
I'm trying to create a version of PySQLite that builds against SQLite3. I still need to use the callback-based API for this.
PRAGMA SHOW_DATATYPES=ON was removed. So far, ok. But please still return the types in the callback function. As it is now, it's not backwards-compatible and could easily be made so.
FWIW, I'm also developing a new PySQLite with the new API, but for my existing userbase I'd like to provide an easy way to switch to SQLite3 with an adaptation of the old PySQLite. |
2004-Oct-12 13:13:10 by drh:
The sqlite3_exec() function is implemented in terms of lower level
API functions. The implementation is in the source file
legacy.c.
I suggest you make a copy of this file, change a few names to avoid
linker conflicts, add the functionality you need, and include the
modified file as part of your project.
You will probably also want to
change sqliteMalloc() to just malloc(), and sqliteFree() to
free().
2004-Oct-12 15:36:10 by anonymous:
Unfortunately, it's not at all so easy. legacy.c is not only implemented in terms of the new API, but instead needs to know about the sqlite3 data structure, thus requires the inclusion of sqliteInt.h, os.h, which in turn requires tons of build-specific includes and defines.
It would really safe me a lot of work if you included the (hopefully) small change in the SQLite mainline.
2004-Oct-14 07:23:32 by anonymous:
Ok, nevermind. I can write something like sqlite3_exec without murking with the internals like the existing sqlite3_exec does. Please close. |
|
952 |
code
|
closed
|
2004 Oct
|
anonymous
|
Unknown
|
2004 Oct
|
|
1
|
2
|
Serious memory leak for insert into table with primary key
|
edit |
Almost same as Ticket #249 so apprently this bug has sneaked back in. When I took out the PK then it went from a very large mem leak to quite small but it still leaks. FYI, Windows 2000 SP 4
My code is quite large so I'll summarize it here with pseudo code. IF you'd like for me to create a test progam for you, that's fine.
CREATE TABLE X(a, b, c, PRIMARY KEY(a, b));
for (1 to [very large num of recs])
{
// in real code, a & b are unique
sSql += "INSERT INTO X(a, b, c) VALUES(1, 2, 3); ";
every 1000 recs
{
sqlite3_get_table(sSql);
// ...call sqlite3_free_table and sqlite3_free for results and error
}
}
// close SQLite
|
2004-Oct-08 17:42:46 by drh:
Unable to reproduce using the following text program (in TCL to
be executed by "testfixture"):
file delete -force test.db
file delete -force test.db-journal
set DB [sqlite3 db test.db]
db eval {CREATE TABLE x(a,b,c,primary key(a,b));}
set sql {}
for {set i 1} {$i<=1000000} {incr i} {
append sql "INSERT INTO x(a,b,c) VALUES($i,[expr {$i+1}],[expr {$i+2}]);"
if {$i%1000==0} {
sqlite3_get_table_printf $DB %s $sql
set sql {}
puts $i
}
}
db close
|
|
951 |
code
|
closed
|
2004 Oct
|
anonymous
|
Unknown
|
2004 Oct
|
|
1
|
1
|
DBD telling me table doesnt exist
|
edit |
POE::Component::EasyDBI Got STDERR from child, which should never happen ( <- errstr= ( 'no such table: trapdlog(1) at dbdimp.c line 412' ) [1 items] at SubProcess.pm line 866 ) at /usr/local/lib/perl5/site_perl/5.8.5/POE/Component/EasyDBI.pm line 678.
I keep getting these messages when I run my perl script with DBI->trace(1);
I created my database and table and its very simple
here are the steps I use as root (my script also runs as root)
dbish dbi:SQLite2:trapdlog.db
create table trapdlog (epochtime, trap_category, trap_create_time, ip_hostname, trap_source, description, status);
This code works:
use DBI;
my $dbh = DBI->connect("dbi:SQLite2:dbname=trapdlog.db","","");
my $sql = "INSERT INTO trapdlog (epochtime, trap_category, trap_create_time, ip_hostname, trap_source, descriptio
n, status) values ('epoc','trapc','trapcxi','ip','tsrc','moocow','CLEAR')";
my $sth = $dbh->prepare($sql) or die("$DBI::errstr\n");
$sth->execute;
I am able to go into the dbi shell and see the record, but my program
doesn't seem to want to think the table exists. The database and script calling the database are in the same cwd as well.
Any idears? |
2004-Oct-08 17:51:03 by drh:
DBD::SQLite problems should be reported at http://rt.cpan.org/.
This site is for SQLite core bugs only. |
|
950 |
new
|
closed
|
2004 Oct
|
anonymous
|
Unknown
|
2004 Oct
|
|
2
|
4
|
No access to sqlite3ErrStr and sqlite3_temp_directory
|
edit |
Clients using the dll do not have access to the sqlite3_temp_directory global variable. This should be get/set through some exported functions and not as a variable.
Yes, I know one can set the TEMP environment variable, but that's what sqlite3_temp_directory is for.
Same happens with the sqlite3ErrStr function, which is quite useful at least for me, it could also be included in the "def" file. |
2004-Oct-07 22:33:11 by drh:
sqlite3_temp_directory is there for compatibility with the unix
drivers. Unix doesn't have any problems changing the values of
variables in shared libraries. Windows users can change the TMP
or TEMP environment variables, or compile their own library. So
this enhancement request adds no new functionality. We
work very hard to minimize feature creep in SQLite. Since this
suggestion adds nothing to the core functionality it is easily
rejected.
The sqlite3ErrMsg() routine is intentionally not exported.
Unexported API routines are subject to change without notice.
We do not wish to be locked into supporting sqlite3ErrMsg() in
the future as our UTF-16 functionality evolves. Hence we will
not be exporting the sqlite3ErrMsg() routine at this time. |
|
949 |
new
|
closed
|
2004 Oct
|
anonymous
|
Unknown
|
2004 Oct
|
|
3
|
3
|
add user-level test for file validity
|
edit |
Please add a one-step user-level test that one can invoke to determine whether a file is a valid SQLite database. I can understand open() not doing this automatically for performance reasons, but there should be an alternative for users who want behaviour as if it did. Performing a dummy select, the current recommended solution to performing the test, is a very in-elegant solution.
1. One alternative option I suggest adding a new stateless function whose prototype looks like open() but has a name like "is_a_database" or "validate_file" or what-have-you. Conceptually, what this function could do is: open(), perform smarter replacement for dummy select, close(); it would return the code for OK if the given file is a valid database, and the appropriate SQLite error code if it is not.
2. An alternative solution, which could be done instead of or in addition to the above, is a stateful function that you invoke on the structure that open() returns. A user would invoke it right after open(); they then explicitly call close() if testing the file was all they wanted to do, or otherwise they keep it open and do whatever they were going to do, but now they can be confident that any actual work will not fail due to it being an invalid file.
3. A third solution would be to add an optional boolean argument to open() which, if set true, would cause open() to perform the test in question.
I suggest that option 2 may be the best one, for multiple reasons, including both flexability, future extensibility, performance, simplicity, and non-interference with other future design plans.
I believe that making this change will result in better self-documenting code for users than the current work-around is.
I also believe that this change should be very simple to do, especially if you pick option 2.
I also request that you implement this in the 2.8.x branch as well, so that applications which can possibly work with both versions of SQLite databases have the same simplicity of testing.
Finally, something which you don't have to do, but that my recommended change would make it easier for someone else to do, is that an application could quickly scan a file system (or a single directory at least) and quickly determine which files in it are SQLite databases and which aren't, a list of valid ones it would return for a user or program to select from.
Thank you. -- Darren Duncan |
2004-Oct-07 22:19:29 by drh:
The function below can be used to discover the database format
of an arbitrary file. I see no reason to add this to the core
SQLite release. So for simplicity I have elected to omit it.
/*
** This function looks at the first 16 bytes of a file and from that
** tries to determine if the file contains an SQLite 2.8 database,
** and SQLite 3.0 database, or no database at all.
**
** The integer returned is 2 for an version 2 database, 3 for a version 3
** database or 0 for an unrecognized file.
*/
#include <stdio.h>
#include <string.h>
int sqlite_database_format(const char *zFilename){
char zBuf[16];
FILE *in;
int cnt;
in = fopen(zFilename,"r");
if( in==0 ) return 0;
cnt = fread(zBuf, 1, 16, in);
fclose(in);
if( cnt!=16 ) return 0;
if( memcmp(zBuf, "** This file con", 16)==0 ) return 2;
if( memcmp(zBuf, "SQLite format 3", 16)==0 ) return 3;
return 0;
}
/*
** Use the following code tests the function above.
*/
#ifdef TEST
int main(int argc, char **argv){
if( argc!=2 ){
fprintf(stderr, "Usage: %s FILENAME\n", argv[0]);
exit(1);
}
printf("%d\n", sqlite_database_format(argv[1]));
return 0;
}
#endif /* TEST */
|
|
945 |
code
|
closed
|
2004 Oct
|
anonymous
|
Unknown
|
2004 Oct
|
|
2
|
2
|
sqlite3 opens sqlite2 databases without complaining
|
edit |
If you open a sqlite2 database using sqlite3_open(), the function will successfully report it opened the file. Unfortunately, this is not useful behaviour.
I expect that the sqlite3_open() will return SQLITE_FORMAT or SQLITE_WRONG_VERSION instead of SQLITE_OK.
This is necessary for my sqlite wrapper code to gracefully degrade from sqlite3 to sqlite2 as necessary. |
2004-Oct-06 15:50:35 by drh:
SQLite does not open or read the database file until the first SQL
statement is processed. This is by design. The error you seek will
appear if you try a dummy SQL statement such as
"SELECT name FROM sqlite_master LIMIT 1". |
|
942 |
code
|
closed
|
2004 Oct
|
anonymous
|
CodeGen
|
2004 Oct
|
|
1
|
2
|
Horrible time complexity for certain triple joins.
|
edit |
With the tables
CREATE TABLE aaa (id INTEGER PRIMARY KEY, val INTEGER);
CREATE TABLE bbb (id INTEGER PRIMARY KEY, val TEXT);
CREATE TABLE ccc (id INTEGER PRIMARY KEY, val TEXT, aid INTEGER, bid INTEGER);
Seeded with 8000 aaa rows, 25 bbb rows and 5*8000 ccc rows (i.e. aaa is objects, bbb is property names and ccc is a property value of an object) the following query
SELECT aaa.val FROM aaa,bbb,ccc WHERE aaa.id=ccc.aid AND ccc.bid=bbb.id AND bbb.val='P' AND ccc.val LIKE '%Q%';
runs in 234 seconds. On the same machine an identical database (with AUTO_INCREMENT on id columns) on MySQL takes 0.1 second. Altering the query to only return the ccc.aid and then manually query for aaa.val from the returned indices takes 37 ms, so clearly the query is not generated correctly. |
2004-Oct-06 13:57:10 by drh:
Reorder the tables in the FROM clause to ccc,aaa,bbb and it
should work fine.
Works as designed. No changes to code. |
|
941 |
code
|
closed
|
2004 Oct
|
anonymous
|
Unknown
|
2004 Oct
|
|
2
|
3
|
Updates are not atomic with respect to unique constraints
|
edit |
Here is some simplified code to generate an erronious unique constraint violation triggered by a transient condition occuring during a multiple-row update. I guess the workaround is not using constraints or primary keys in this particular database app, which is Joe Celko's nested set trees.
CREATE TABLE blah2 (a int, b int, CONSTRAINT nodups PRIMARY KEY(a, b))
;
INSERT INTO blah2 (a, b) VALUES(1,2)
;
INSERT INTO blah2 (a, b) VALUES(3,4)
;
UPDATE blah2 SET a = a + 2, b = b + 2
;
SELECT * FROM blah2
GO
|
2004-Oct-05 11:35:59 by drh:
Correct. SQLite applies uniqueness constraints after each row
is changed. There is no way to defer constraint checking until
after the entire UPDATE completes, or the entire transaction
completes.
This is unlikely to change. |
|
937 |
code
|
closed
|
2004 Oct
|
anonymous
|
VDBE
|
2004 Oct
|
drh
|
2
|
4
|
mixed wildcard "?" and ":abc" cause msvcrt.dll raise a exception.
|
edit |
// works good!
sql="insert into test_bind(bb,db,nl,tx) values(?,?,?,?)";
sqlite3_prepare(FDatabase,sql,strlen(sql),stmt,tail);
i=sqlite3_bind_parameter_index(stmt,":db");
Assert(i==0);
// works good!
sql="insert into test_bind(bb,db,nl,tx) values(:bb,:db,:nl,:tx)";
i=sqlite3_bind_parameter_index(stmt,":db");
Assert(i==2);
/*
sqlite3_bind_parameter_index() caused msvcrt.dll raise a Access violation Exception!
but other functions like sqlite3_bind_* and sqlite3_bind_parameter_name() still works good.
*/
sql="insert into test_bind(bb,db,nl,tx) values(?,:db,?,?)";
sqlite3_prepare(FDatabase,sql,strlen(sql),stmt,tail);
i=sqlite3_bind_parameter_index(stmt,":db");
Assert(i==2); |
2004-Oct-01 12:02:49 by anonymous:
sometimes the second condition may also raise a AV Exception too.
2004-Oct-01 12:04:38 by drh:
Duplicate of ticket #918. Fixed by check-in [1977]
.
2004-Oct-01 13:52:09 by anonymous:
It seems that the strcmp() function in msvcrt.dll dose not accept NULL pointer, but in sqlite3_bind_parameter_index(), a null was passed to strcmp().
I changed the following statement
if( strcmp(p->azVar[i],zName)==0 ){
to
if(p->azVar[i]!=NULL && strcmp(p->azVar[i],zName)==0 ){
then it works right!
|
|
935 |
code
|
closed
|
2004 Sep
|
anonymous
|
Unknown
|
2004 Nov
|
|
4
|
4
|
several crash.test tests fail (spuriously) when [sqlite3 -has-codec]
|
edit |
Several of the crash tests run by "make fulltest" fail when sqlite3 is built with -DSQLITE_HAS_CODEC. The generated tcl file "crash.tcl" attempts to open test.db but fails to provide the key.
One possible fix is to make a change like this to sqlite/test/crash.test:
Index: crash.test
===================================================================
RCS file: /sqlite/sqlite/test/crash.test,v
retrieving revision 1.9
diff -u -d -b -w -c -r1.9 crash.test
cvs diff: conflicting specifications of output style
*** crash.test 21 Aug 2004 19:20:42 -0000 1.9
--- crash.test 5 Oct 2004 05:11:51 -0000
***************
*** 43,52 ****
# occured.
proc crashsql {crashdelay crashfile sql} {
set cfile [file join [pwd] $crashfile]
set f [open crash.tcl w]
puts $f "sqlite3_crashparams $crashdelay $cfile"
! puts $f "sqlite3 db test.db"
puts $f "db eval {pragma cache_size = 10}"
puts $f "db eval {"
puts $f "$sql"
--- 43,53 ----
# occured.
proc crashsql {crashdelay crashfile sql} {
set cfile [file join [pwd] $crashfile]
+ set opt_key [expr {[sqlite3 -has-codec] ? " -key xyzzy" : ""}]
set f [open crash.tcl w]
puts $f "sqlite3_crashparams $crashdelay $cfile"
! puts $f "sqlite3 db test.db $opt_key"
puts $f "db eval {pragma cache_size = 10}"
puts $f "db eval {"
puts $f "$sql"
|
10/5/04 SCG: simplified proposed modification
2004-Nov-20 20:57:32 by drh:
SQLITE_HAS_CODEC is not supported in the public release. |
|
933 |
code
|
closed
|
2004 Sep
|
anonymous
|
Unknown
|
2004 Sep
|
anonymous
|
3
|
3
|
os_xxx.c does not always check for error and returns SQLITE_OK
|
edit |
In os_xxx.c several functions always return SQLITE_OK even when failed.
Reason: the return code of some OS api functions are not checked.
Functions:
sqlite3OsDelete, sqlite3OsSeek, sqlite3OsTruncate, sqlite3OsFileSize, sqlite3OsUnlock.
For example, if seek fails, one could overwrite the wrong file range leaving the database corrupted. |
2004-Sep-30 14:30:32 by drh:
Seeks cannot fail, at least not in linux, and probably not in any
other operating system, unless you give them an invalid parameter
such as an invalid file descriptor. In no case will that corrupt
the database file.
A similar argument can be made for the other routines mentioned
in the trouble ticket. |
|
929 |
code
|
closed
|
2004 Sep
|
anonymous
|
Parser
|
2004 Sep
|
|
2
|
1
|
Inserting duplicate primary key value returns success
|
edit |
We have created a table in database where primary key for the table is a string. Value for primary key gets inserted properly and while inserting a duplicate value for the primary key it works fine ie. it doesn't update the table but the return value is success(SQLITE_DONE). What I think is while executing the INSERT query it executes one more query which is internal and updates some internal master tables. And result of this query is success and gets returned so result of INSERT query for duplicate primary key value is returned as success although the values are not getting updated into the table. |
2004-Sep-28 12:05:34 by drh:
Unable to reproduce. When I try it, sqlite3_step always returns
SQLITE_ERROR and the following sqlite3_finalize returns
SQLITE_CONTRAINT. Please provide a specific example of how
you obtained behavior that you feel is incorrect. |
|
928 |
code
|
closed
|
2004 Sep
|
anonymous
|
VDBE
|
2004 Sep
|
drh
|
3
|
3
|
delete record by rowid would core dump
|
edit |
sqlite3 would core dump where delete records by specified rowid range.
- delete from TABLE_NAME where rowid < 10; //core dump
- delete from TABLE_NAME where rowid = 1; //ok
|
2004-Sep-28 11:55:23 by drh:
I am unable to reproduce this behavior. Please provide specifics.
If possible, attach an SQL script that causes the core dump. |
|
921 |
code
|
closed
|
2004 Sep
|
anonymous
|
|
2004 Sep
|
|
5
|
5
|
2nd time: SQL does not support non-ASCII IO?
|
edit |
I noticed that if I use the "attach" SQL command to attach a db file, it does not support non-ASCII file path.
"ATTACH 'c:\some non-ASCII characters here\myDB.db' AS myDB" |
2004-Sep-24 12:34:17 by drh:
Duplicate of #872 |
|
920 |
code
|
closed
|
2004 Sep
|
anonymous
|
Unknown
|
2004 Sep
|
anonymous
|
3
|
3
|
group by without having not supported
|
edit |
The following results in an error:
SELECT COUNT(*)
FROM T1
HAVING COUNT(*) > 5 |
|
917 |
code
|
closed
|
2004 Sep
|
anonymous
|
VDBE
|
2004 Sep
|
drh
|
1
|
1
|
bug with named parameters
|
edit |
I am using a parametric sql statement, with parameters of the form :Name
The following routines give an access violation, when called via the windows dll:
sqlite3_bind_parameter_name
sqlite3_bind_parameter_index
The access violation indicates that a NULL pointer is being accessed.
A brief look at the code suggests that some problem with the azVar initialization must be the reason, but I do not know enough C to fix it.
environment: Windows 2000, Delphi 7 calling sqlite3.dll.
can you pls do something about it, quickly, as I cannot continue my project.
thanks. |
This report is not accurate. see ticket #918, for explanation and a proposed fix |
|
915 |
code
|
closed
|
2004 Sep
|
anonymous
|
|
2004 Sep
|
|
3
|
2
|
problem #901, but on read-only databases
|
edit |
Seems to be the same issue as #901, but the fix did not work for
read-only databases. |
2004-Sep-27 17:42:47 by drh:
Works as designed.
sqlite3_step() returns SQLITE_ERROR if anything goes wrong. You then
get the detailed result code from the subsequent sqlite3_finalize().
In the test case attached, sqlite3_finalize() returns SQLITE_READONLY.
The first step of an INSERT statement is to create a journal file and
get a RESERVED lock on the original database. This occurs even if the
INSERT is being fed by a SELECT that returns zero rows. The lock
cannot be obtained on a read-only file, hence an INSERT will always
result in an SQLITE_READONLY error even if the INSERT is not really
inserting anything. |
|
909 |
code
|
closed
|
2004 Sep
|
anonymous
|
Unknown
|
2004 Oct
|
|
1
|
1
|
Inconsistent unordered and ordered selects (index corruption?)
|
edit |
Dear Sir,
I have a simple scheduler database (one table):
"CREATE TABLE Schedules ("
"Status INTEGER,\n"
"LastRun DOUBLE ,\n"
"NextRun DOUBLE ,\n"
"RecurEvery INTEGER,\n"
"RecurUnit INTEGER,\n"
"OptionDays INTEGER,\n"
"OptionHours INTEGER,\n"
"OptionClients INTEGER,\n"
"DaysHours INTEGER,\n"
"Description CHAR(128),\n"
"ActionList CHAR(255),\n"
"ClientList CHAR(255),\n"
"Log CHAR(255),\n"
"AInteger INTEGER,\n"
"AFloat FLOAT,\n"
"AString CHAR(255));\n"
"CREATE INDEX ByNextRun ON Schedules (NextRun);";
Users reported me quite often row duplication with inability of my interface to do anything with those rows. I've requested a sample database with two rows to test, and to my surprise I found the following:
SELECT COUNT(*) FROM SCHEDULES;
returns 0 (zero), but
SELECT COUNT(*) FROM SCHEDULES ORDER BY NextRun;
returns 2 (two)
Rows in the second case are of emtpy columns except of ROWIDs which hold some out of context values.
With my application this problem can be duplicated each time, but since this is a client server multithreaded one I cannot easily resolve the procedure in terms of simple sql commands.
I've tested with 2.7.5, 2.7.6 and 2.8.15
I was hoping if you had any ideas about this. Personally I could live without the index (I do not anticipate large tables) but I thought that perhaps this problem is of general interest.
Thank you in advance
Nick B. Cassos
http://www.flenik.com |
2004-Sep-24 10:58:25 by drh:
Please include instructions on how to reproduce this problem.
The fact that a database is corrupt is not helpful in fixing it.
I need to know what actions out take to cause the database to
get into its corrupt state in the first place.
2004-Sep-25 11:12:30 by anonymous:
I had to burn CDs with my app, so I did the fastest thing I could think of and just removed the "CREATE INDEX ...". Everything seems ok now.
But, then, you are right, I wasn't much helpful. So, I promise to make a new build of my app, to add a logging feature to my scheduler class, so that I can send you the exact sql sequence that causes the problem. Until I do this, please, close this ticket.
Thanks for your attention |
|
906 |
code
|
closed
|
2004 Sep
|
anonymous
|
Unknown
|
2004 Oct
|
anonymous
|
3
|
3
|
Wrong error code returned when there's not enough disk space available
|
edit |
SQLite returns SQLITE_ERROR when trying to insert large binary data into the database and there's no more space available on the disk.
Perhaps an error which says "no more space available on disk to perform operation" or "your disk is full" is more correct than "sql error or missing database". Since there's really no
sql error and the database is still there. |
2004-Oct-01 14:39:13 by drh:
Unable to reproduce. Probably the person reporting this saw the
SQLITE_ERROR returned from sqlite3_step() and did not realize that
the real error code is returned by sqlite3_finalize(). |
|
894 |
code
|
closed
|
2004 Sep
|
anonymous
|
Shell
|
2004 Sep
|
|
3
|
3
|
COUNT does not work with DISTINCT SUBSTR
|
edit |
I have a table 't1' with columns for file name and directory. I want to show how many files within a certain directory begin with the same 17 characters.
I can do this:
select distinct substr(t1.name, 0,16) from t1 where dir like "REL%";
and it will show me the list of distinct 17-byte beginning strings. But if I try to wrap that expression in COUNT like this:
select count(distinct substr(t1.name, 0,16)) from t1 where dir like "REL%";
then it fails with this message:
SQL error: near "distinct": syntax error
I'm pretty sure my syntax is OK here... |
2004-Sep-08 18:47:02 by drh:
This feature is deliberately omitted from SQLite.
See http://www.sqlite.org/omitted.html |
|
893 |
new
|
closed
|
2004 Sep
|
anonymous
|
|
2004 Sep
|
|
1
|
3
|
No string searches INSTR, LOCATE
|
edit |
I'm trying a product called Microweb, a standalone php engine. It comes with SPSQLite, a php class and a folder called sql, which is apparently mysql. I don't know quite where you fit into this, but I can't get the LOCATE OR INSTR functions working and escaping is giving problems too. I can't find anything helpful here, so I'm raising the matter with you.
Thanks |
2004-Sep-08 18:45:54 by drh:
SQLite does not support those functions.
2004-Nov-17 13:34:02 by anonymous:
I need the instr search function something like
select * from table where (instr(QueryVar, table) = true)
if the situation changes let me know - admintony@tpg.com.au
Love Sqlite :) |
|
889 |
event
|
closed
|
2004 Sep
|
anonymous
|
BTree
|
2004 Sep
|
anonymous
|
1
|
2
|
btree.c with new malloc
|
edit |
I got a "malformed database" in a 3kb db.
Unfortunately I don't have a stack trace but I keep the three involved files (master, journal and temporal).
It threw an assert in btree.c in function releasePage:
assert( &pPage->aData[pPage->pBt->pageSize]==(unsigned char*)pPage );
I will post an attachment with the files, if I fond out how :) |
2004-Sep-04 23:17:51 by drh:
Originator writes that this ticket is superceded by #890. |
|
887 |
code
|
closed
|
2004 Sep
|
anonymous
|
Pager
|
2004 Sep
|
|
3
|
2
|
Unable to recover from SQLITE_FULL error until DB file is reopened
|
edit |
SQLite database used up all disk space, and SQLite engine returned SQLITE_FULL error.
After that, we have freed up some disk space.
However, SQLite was still returning SQLITE_FULL on all queries.
The problem has gone only after we re-opened the DB file.
We suspect that the problem is that after pPager->errMask is set to PAGER_ERR_FULL, it never gets cleared out.
When executing subsequent queries (sqlite_compile) function pager_errcode returns SQLITE_FULL, as long as pPager->errMask remains PAGER_ERR_FULL. |
2004-Sep-30 14:02:05 by drh:
This is by design. |
|
884 |
new
|
closed
|
2004 Sep
|
anonymous
|
Parser
|
2004 Sep
|
|
5
|
1
|
Allow read only transactions.
|
edit |
The locking protocols of 3.x allow two connections to open a write transaction on the same database at once, resulting in deadlock when one connection tries to commit and subsequent requirement to rollback a transaction.
If given read-only transactions, developer can ensure their code never reaches this situation. What is suggested is a new variant of BEGIN:
BEGIN [TRANSACTION] FOR READ ONLY;
The subsequent transaction fails with error if any updates are attempted, hence removing the requirement for a write lock and potential deadlock against another transaction. |
2004-Sep-01 21:10:28 by anonymous:
Attached patch to implement read only transactions.
Notes:
- Updates sqlite structure with roTrans element, which is 1 (true) if the current transaction is read only.
- Overloads OP_AutoCommit opcode, which may not be ideal. If P1 is -1, sets the roTrans field for the sqlite structure to true.
- Trying to write to the database when a read only transaction is in effect results in a permission denied error.
2004-Sep-01 21:41:17 by anonymous:
Updated attached patch to apply read only transaction to:
"DELETE FROM <table>"
which is special cased for performance.
2004-Sep-01 22:14:52 by drh:
This patch has been overcome by events.
See ticket #885.
2004-Sep-01 22:55:17 by anonymous:
For completeness, updated patch to implement better behaviour when multiple sessions are open on the same database. |
|
882 |
code
|
closed
|
2004 Sep
|
anonymous
|
Parser
|
2004 Sep
|
|
1
|
1
|
crash on insert
|
edit |
crash on SQL:
create table test(a INTEGER);
insert into test(a) values(18446744073709551615);
|
This SQL above works fine for me on both Linux and Windows. |
|
880 |
code
|
closed
|
2004 Sep
|
anonymous
|
|
2004 Sep
|
|
1
|
1
|
dropping a temporary table locks the database
|
edit |
When dropping a temporary the database is locked. There seems no reason for the database to-be locked when freeing memory? |
2004-Sep-01 03:13:14 by drh:
I am unable to reproduce this. When I drop a TEMP table,
the TEMP database gets a transaction (in case there is a
ROLLBACK) but nothing gets locks that I can see.
2004-Sep-01 07:08:42 by anonymous:
There are times when I drop a temp table I recieve a SQLITE_BUSY return code.
2004-Sep-02 15:19:36 by drh:
Unable to reproduce. |
|
879 |
new
|
closed
|
2004 Aug
|
anonymous
|
|
2004 Aug
|
|
5
|
3
|
Makefile should produce GCC compatible import library for DLL as well
|
edit |
The Makefile for sqlite should produce an import library for use with the gcc compiler when the 'implib' target is built. I have attached patch files for Makefile.in for both SQLite 2 and SQLite 3 that will add this capability. This will produce an import library, either libsqlitedll.a or libsqlite3dll.a, in the build directory for the project. |
2004-Aug-31 22:27:32 by anonymous:
It turns out that GCC doesn't need an import library to link to a DLL. It can link directly to the DLL. Who knew? (Well actually Doug Currie did...Thanks for the info.)
I have marked this ticket closed since this change is obviously not needed. |
|
876 |
code
|
closed
|
2004 Aug
|
anonymous
|
Unknown
|
2004 Aug
|
|
1
|
3
|
select from ... where ... or ... is dead slow on indexed column
|
edit |
Create a table test with let's say 500000 rows. The table contains an
integer column named catid with unique integers and some text column.
Create an index on column catid. Now do (assuming that the catid
values stated below exist in the table):
SELECT catid FROM test where catid=12345 OR catid=23456;
This is dead slow. It takes in my case 0.5 seconds where the
two required values are spit out fast and then it seems the whole
table is continued to be parsed.
The only workaround is to do multiple select statements for
each catid but this is no solution when you need order by. |
2004-Aug-29 11:40:36 by drh:
OR defeats the optimizer and forces a full table scan.
Use the IN operator instead:
SELECT catid FROM test WHERE catid IN (12345,23456);
2004-Aug-29 15:13:29 by anonymous:
More testing results in a more detailed example. There isn't
even an index required to show the problem.
CREATE TABLE test (foo INTEGER PRIMARY KEY,bar TEXT);
INSERT INTO test VALUES(1,"1");
INSERT INTO test VALUES(2,"2");
INSERT INTO test VALUES(3,"3");
INSERT INTO test VALUES(4,"4");
INSERT INTO test VALUES(5,"5");
INSERT INTO test VALUES(6,"6");
PRAGMA vdbe_trace=ON;
Now execute:
SELECT foo FROM TEST WHERE foo=2;
This works fine as expected.
Then execute;
SELECT foo FROM TEST WHERE foo=2 or foo=3;
The whole table is parsed, bad.
Now we try to limit the amount of results as we know there are
only two results:
SELECT foo FROM TEST WHERE foo=2 or foo=3 LIMIT 2;
Again, the whole table is parsed, bad. The only way to work around
the problem I did find is using a value that is definitely in
the table, add this value as an 'or' case and keep the old limit:
SELECT foo FROM TEST WHERE foo=2 or foo=3 or foo=4 LIMIT 2;
This works, ouch. Still the table is sequentially processed, bad.
If you look at the traces follow closely the
MemIncr usage as this seems to be the culprit for the limit
not causing query termination.
Further fun:
In the 'or' case the table is always sequentially parsed even if
the value looked up is the primary key or indexed. This is dead
slow and a major performance problem. |
|
874 |
code
|
closed
|
2004 Aug
|
anonymous
|
Parser
|
2004 Aug
|
|
2
|
3
|
Inconsistent treatment of quoted strings: "x" vs 'x'
|
edit |
I have seen this problem before, but just now decided to try to get rid of it by upgrading to the latest driver (2.8.15). The problem is a difference in treatment of strings quoted with single quotes vs double quotes. E.g. the phrase WHERE FIELD="XXX" will find nothing but WHERE FIELD='XXX' will find several hits.
I will attach a screen shot showing the problem.
WIN-XP home SP1
Compaq Presario R3150US, P-IV, 512 MB RAM, 40 GB HDD
|
2004-Aug-28 16:17:35 by drh:
"MAIN" resolves to a column named MAIN if such a column exists.
Otherwise it is treated as a string. 'MAIN' is always a string.
This is as intended and as documented.
2004-Aug-28 17:07:29 by anonymous:
Wow!
Yes, it is documented, but in a very obscure place: in the section about keywords. This is not where one would start looking for the meaning of literal-value seen in the syntax productions.
I certainly missed it in 3 years of using SQLite!
It would be most helpful if the non-terminal "literal-value" were defined in the Expression syntax, at least to make clear the distinction between single and double quotes.
If I had come from a SQL background, this distinction may have been pounded into my head early on. Please have pity on us poor unwashed SQL-tyros and document more prominently this important (and not obvious!) difference.
-R. |
|
868 |
doc
|
closed
|
2004 Aug
|
anonymous
|
|
2004 Aug
|
|
1
|
1
|
Conflict resolution fails when attempting to create duplicate key
|
edit |
In my code, I always try to create an index. I expect the ON CONFLICT clause to make sqlite ignore any errors but it does not.
Example sql:
BEGIN;
CREATE INDEX foo ON foo_table (foo_col) ON CONFLICT IGNORE;
COMMIT;
The code above will leave SQLite thinking it's in the middle of a transaction. |
2004-Aug-25 11:53:19 by anonymous:
Of course, it's not "duplicate key". I meant duplicate index.
2004-Aug-25 12:41:52 by drh:
ON CONFLICT IGNORE causes INSERTs or UPDATEs that cause
constraint conflicts to be silently ignored. This is well
documented. |
|
866 |
code
|
closed
|
2004 Aug
|
anonymous
|
|
2004 Aug
|
|
2
|
3
|
Breakage when repeatedly creating tables in an attached database
|
edit |
21:40:44 mag@gaia:~/.imms $ rm -f test.db cluster.db
21:41:11 mag@gaia:~/.imms $ cat sql
ATTACH "cluster.db" AS Cluster;
CREATE TABLE 'Cluster.Distances' ('x' INTEGER NOT NULL, 'y' INTEGER NOT NULL, 'distance' INTEGER NOT NULL);
DETACH Cluster;
21:41:14 mag@gaia:~/.imms $ sqlite3 test.db '.read sql'
21:41:17 mag@gaia:~/.imms $ sqlite3 test.db '.read sql'
CREATE TABLE 'Cluster.Distances' ('x' INTEGER NOT NULL, 'y' INTEGER NOT NULL, 'distance' INTEGER NOT NULL);
SQL error: table 'Cluster.Distances' already exists
21:41:18 mag@gaia:~/.imms $ sqlite3 test.db 'select * from sqlite_master;' | grep Distances
table|Cluster.Distances|Cluster.Distances|2|CREATE TABLE 'Cluster.Distances' ('x' INTEGER NOT NULL, 'y' INTEGER NOT NULL, 'distance' INTEGER NOT NULL)
21:41:21 mag@gaia:~/.imms $ sqlite3 test.db 'DROP TABLE Cluster.Distances;'
SQL error: no such table: Cluster.Distances
Thanks,
Michael Grigoriev |
2004-Aug-25 11:05:50 by drh:
You have a quoting error. 'Cluster.Distances' is the name of
a table in the main database. It is the same as
main.'Cluster.Distances'. Cluster.Distances is a table named
Distances in the Cluster database.
Works as designed. |
|
863 |
code
|
closed
|
2004 Aug
|
anonymous
|
BTree
|
2004 Sep
|
|
2
|
2
|
Stack overflow in the btree.c module
|
edit |
Declarations of huge arrays and structures on the stack in the btree.c balance_nonroot function causes 'Stack overflow' in the OpenWatcom C 1.4:
static int balance_nonroot(MemPage *pPage){
[snip-snip] // only the suspected vars are left
int szCell[(MX_CELL+2)*NB]; // (8192-8)*3
u8 aCopy[NB][SQLITE_MAX_PAGE_SIZE+sizeof(MemPage)]; 3*(8192+ sth )
u8 aSpace[SQLITE_MAX_PAGE_SIZE*5]; // 5*8192
Short calculations shows that this function allocates >= 80 KB on the stack (for SQLITE_MAX_PAGE_SIZE==8192).
Could these variables be declared as pointers ?
Regards,
Bartosz
|
2004-Aug-20 02:08:05 by drh:
What architecture are you using that can't handle an 80K stack?
The choices are to allocate space off of the stack using
a maximum page size, as is now implemented, or use alloca()
to allocate only the amount needed (which could be as much as
is allocated now if the page size is big) or use malloc().
Alloca() has lots of problems, I'm told. Malloc() is slow.
That leaves the current method. If the page size is 8192 bytes
then I really do need about 80K of temporary memory space in
order to balance btree nodes. That space has got to come from
somewhere and the stack seems like as good a place as any
to get it.
You can change the maximum page size to 1024 if you never plan
to access a database with a larger page size (1024 is the
default) and reduce the stack space to about 10K or so.
2004-Aug-20 07:20:41 by anonymous:
Win2000 Wks + OpenWatcom 1.4 with default stack size.
There is no problem with increasing stack size to solve the problem.
I did it and all seems to work OK.
The potential problem could arise with porting v3 to system with small stack.
Could it be changed to compile time time option:
" to malloc or not to malloc" :-)
Bartosz
|
|
861 |
code
|
closed
|
2004 Aug
|
anonymous
|
Unknown
|
2004 Sep
|
anonymous
|
1
|
1
|
SqLite is accent-sensitive?
|
edit |
In table Clients .. name: End
Jo�o sep�
jos� gra�a
if i use Select * From Clients where nome like 'joao%'
the result set is Null, else
if i use Select * From Clients where nome like 'jo�o%'
the resultset is not Null ok/
Please Help-me |
2004-Aug-17 23:54:28 by anonymous:
This sounds to me like correct behavior: I'm really not aware of any human language in which accented and unaccented letters are considered interchangeable. The behavior you want would be rather surprising, IMHO. Now if SQLite were to implement something like MYSQL's REGEXP operator, you could emulate that sort of behavior. Probably wouldn't be that hard to do using the PCRE library, but that would break SQLite's public-domain status (even though PCRE's license is hardly restrictive). OTOH, someone could simply write an extension function to do regexp matching.
2004-Aug-19 07:02:20 by anonymous:
accent-insensitive comparison, like case-insensitive comparison, is usually been implemented using translation tables. this feature is included in sqlite 3.*, but not 2.*.
for version 2.*, you can implement such functionality for your specific language, in the btree comparison function (for indexes), and anywhere strings are being compared, as the like directive. just beware that every field comparison will use the same functionality.
2004-Sep-02 15:33:47 by drh:
SQLite handles case conversions of US-ASCII characters only.
This is a deliberate design decision - it is outside the scope
of SQLite to try to track the nuiances of case conversions in
1000s of languages. You can implement your own case conversions
using the sqlite3_create_collation() interface and by registering
new functions (lower(), like(), etc) to override the built-in
versions. |
|
858 |
code
|
closed
|
2004 Aug
|
anonymous
|
Unknown
|
2004 Aug
|
|
2
|
3
|
core dump when peforming bind
|
edit |
The following code creates a simple database and tries to insert a row into the table. When the code is compiled and run, it core dumps inside the sqlite3_bind_double() statement.
If the source is changed to not use the bind, there is no coredump and the row is successfully added to the table.
#include <stdio.h>
#include <stdlib.h>
#include "sqlite3.h"
sqlite3 *db;
sqlite3_stmt *pStmt;
const char *tail;
int main(int argc, char **argv)
{
sqlite3_open("test.db", &db);
sqlite3_prepare(db, "CREATE TABLE t1(a1 FLOAT, a2 FLOAT);", -1, &pStmt, &tail);
sqlite3_step(pStmt);
sqlite3_finalize(pStmt);
sqlite3_prepare(db, "INSERT INTO t1 VALUES(?, 2.5);", -1, &pStmt, &tail);
sqlite3_bind_double(pStmt, 1, 5.5);
sqlite3_step(pStmt);
sqlite3_finalize(pStmt);
sqlite3_close(db);
exit(0);
} |
2004-Aug-16 19:10:12 by drh:
When I compile and run the sample code on Linux (RH 7.2, gcc 2.96)
it works fine. Can you provide additional information about your
compilation and execution environment so that we can try to reproduce
the problem?
2004-Aug-16 19:22:28 by anonymous:
OS: Solaris 8
Compiler: g++ 3.2.3
2004-Aug-16 19:27:42 by anonymous:
Here is how it is being compiled:
g++ -o bind.o -c -I/home/wvk/sqlite/3.0.4/sun4v/bld bind.c
g++ -o ./bindbug ./bind.o /home/wvk/sqlite/3.0.4/sun4v/bld/.libs/libsqlite3.a
2004-Aug-16 21:20:55 by anonymous:
I suspect this may be a compile issue with gcc on Solaris.
I just rebuilt everything (sqlite3 and bind.c) with the Sun native compiler and the problem went away. Previously, sqlite3 was built with gcc (this is what the configure script selected by default).
This is good enough for me (actually, I would prefer to use the native compiler), so we can mark this as fixed unless you are interested in pursuing this further. |
|
856 |
code
|
closed
|
2004 Aug
|
anonymous
|
|
2004 Aug
|
|
1
|
1
|
memory leak within sqlite3_open()/sqlite3_close() pair
|
edit |
I use SQLite 3.0.4 and I have found that there is memory leak
in pair sqlite3_open()/sqlite3_close() functions.
The sample program is following:
#include <stdlib.h>
#include <sqlite3.h>
int main(int argc, char **argv)
{
sqlite3 *p_db;
int rc;
rc = sqlite3_open("./db", &p_db); /* Open the database. */
if (rc != SQLITE_OK) {
printf("Could not open database.");
exit(1);
}
/* Close the database. */
sqlite3_close(p_db);
return 0;
}
-------------------------------
If build this sample on Linux/x86 and run under Valgrind using
the following command line (I have used 2.1.0 version of the Valgrind):
valgrind -q --leak-check=yes --num-callers=12 --show-reachable=yes ./a.out
then the Valgrind reports 2 memory leaks (memory allocated in sqlite3_open()
has not been freed in sqlite3_close()), Valgrind's error log is following:
128 bytes in 2 blocks are still reachable in loss record 1 of 1
at 0x4002582D: malloc (vg_replace_malloc.c:160)
by 0x4024A4C1: sqlite3Malloc (src/util.c:280)
by 0x4023639C: rehash (src/hash.c:174)
by 0x4023677B: sqlite3HashInsert (src/hash.c:337)
by 0x40239E43: findLockInfo (src/os_unix.c:361)
by 0x40239F07: sqlite3OsOpenReadWrite (src/os_unix.c:450)
by 0x4023C570: sqlite3pager_open (src/pager.c:1434)
by 0x40228598: sqlite3BtreeOpen (src/btree.c:1015)
by 0x402390E4: sqlite3BtreeFactory (src/main.c:848)
by 0x4023990F: openDatabase (src/main.c:1160)
by 0x804859C: main (in /home/vnv/sqlite_bugs/a.out){linebreak} |
2004-Aug-16 09:16:26 by anonymous:
Is it correct:
sqlite3 *p_db; int rc;
rc = sqlite3_open("./db", &p_db); /* Open the database. */
^^^^^^ address of pointer
2004-Aug-16 12:48:18 by drh:
This is not a memory leak. SQLite has allocated memory that it
will reuse the next time sqlite3_open() is called. |
|
854 |
code
|
closed
|
2004 Aug
|
anonymous
|
Unknown
|
2004 Aug
|
anonymous
|
3
|
1
|
Index don't work with NULL field
|
edit |
I have a 100 MB database and a table which contains 160000 entries. Two fields can contain NULL values.
I have create an index on these fields.
select count(*) from EXPORTED_FILES where version_name = '6.4'; give the answer immediately but select count(*) from EXPORTED_FILES where version_name is NULL; is as long as select count(*) from EXPORTED_FILES;
(1 minute because the database is mount on NFS). |
2004-Aug-12 12:08:37 by drh:
The first query is able to use an index whereas the second
query has to do a full table scan. So it is expected that the
second query would take longer. |
|
850 |
code
|
closed
|
2004 Aug
|
anonymous
|
|
2004 Aug
|
|
1
|
1
|
quoted table names not allowed in combination with *
|
edit |
select "my table".* from "my table"
does not work, while
select "my table"."my field" from "my table"
does. Reason: when the asterics is handled, the quotes are handled as part of the table name (thus the table will not be found), for single fields the quotes of the table name will be correctly ignored |
2004-Aug-09 21:48:53 by drh:
This is a duplication of ticket #756, which has already been
fixed. |
|
849 |
code
|
closed
|
2004 Aug
|
anonymous
|
Parser
|
2004 Sep
|
|
1
|
1
|
error(1) for Statement "PRAGMA table_info(?)"
|
edit |
sqlite3_prepare is generating the error message.
is this still by design? How come? |
2004-Aug-09 20:53:52 by anonymous:
See #836 for a description of where ?'s can and can't be used.
Is this causing a problem anywhere other than Class::DBI::SQLite? If not, it can be fixed by changing the offending code to:
# find all columns.
my $sth = $class->db_Main->prepare(<<SQL);
PRAGMA table_info($table)
SQL
$sth->execute;
2004-Aug-09 21:29:20 by anonymous:
> Is this causing a problem anywhere other than Class::DBI::SQLite? If not, it can
yes, anywhere you want to use placeholders with a pragma.
Class::DBI::SQLite just happens to be one place.
It's best to restore this functionality.
2004-Aug-12 15:28:28 by anonymous:
> See #836 for a description of where ?'s can and can't be used.
It works in 2.x, why not 3.x
2004-Sep-02 15:37:28 by drh:
This seems to be a Perl issue, not a problem with the SQLite core.
Since this bug tracking system is for SQLite core issues only,
the bug is closed here.
2004-Sep-05 09:39:08 by anonymous:
A slight modification to the fix for Class::DBI::SQLite.pm
I had to add double quotes around $table to make it work thus:
# find all columns.
my $sth = $class->db_Main->prepare(<<SQL);
PRAGMA table_info("$table")
SQL
$sth->execute;
2004-Sep-10 22:14:14 by anonymous:
>This seems to be a Perl issue, not a problem with the SQLite core. >Since this bug tracking system is for SQLite core issues only, the >bug is closed here.
This is not a perl issue.
Let me say that again, this is not a perl issue.
This is a bug in SQLite core.
In sqlite2.x you could use placeholders with pragmas as given in the original report. In sqlite3.x you cannot do this.
Thus, it constitutes a bug.
If you don't want to fix it, say so, but please don't mark it as Not_A_Bug because it is a bug (yes, a feature that mysteriously goes away is a bug). |
|
847 |
code
|
closed
|
2004 Aug
|
anonymous
|
Unknown
|
2005 Jan
|
|
4
|
1
|
sqlite3_changes doesn't reset to zero after inserts
|
edit |
sqlite3_changes doesn't reset to zero after inserts, so it doesn't allow to use itself comfortably.
please, fix it.
sidenote: how can i register here? |
2005-Jan-13 22:28:41 by anonymous:
Attachment fixes it for me but not sure if it is done properly.
This is a very serious bug actually!
2005-Jan-13 23:22:25 by drh:
Unable to reproduce the original problem. Please provide a test
script or sample code that demonstrates how you think the program
is misbehaving. It works exactly as designed, as far as I can tell.
The supplied patch is not an appropriate fix.
2005-Jan-17 23:33:44 by anonymous:
This happens only both sqlite2 and sqlite3 are linked in an app at the same time, if that helps. Cannot gen a test easily as this happens in a C++ application that calls many sqlite(3) APIs directly. |
|
846 |
code
|
closed
|
2004 Aug
|
anonymous
|
Parser
|
2004 Aug
|
|
1
|
1
|
error(1) at dbdimp.c line 250 [for Statement "PRAGMA table_info(?)"]
|
edit |
In the 2.x series,
using placeholders with table_info pragma
is perfectly legal,
while in this version it is not.
Whats up with that? |
dbdimp.c is not a source file in SQLite.
I do not believe that wildcards have ever worked inside
the table_info() pragma. If they did, it was an accident.
2004-Aug-08 21:11:14 by anonymous:
>dbdimp.c is not a source file in SQLite.
Sorry, dbdimp.c is irrelevant (my bad for revealing that).
sqlite3_prepare is generating the error message.
is this still by design? how come? |
|
840 |
code
|
closed
|
2004 Aug
|
anonymous
|
|
2005 Jan
|
|
1
|
1
|
Query returns invalid results (Index problem?).
|
edit |
When I run the following query against the database I get the following behavior. I have attached the database to this ticket.
select Name, Value from T_ValueTable where Name = 'Types' and Value = 'Collection'
The following is returned.
Types|Collection
Types|Collection
Types|Collection
NodeCreate|632272518754289940
NodeCreate|632272518754289940
Types|Collection
Notice the two returned rusults that don't match the query. |
2004-Aug-05 18:18:22 by anonymous:
The database file was to large to add. It is about 2 Meg in size. I could get it to you another way if you let me know.
2004-Aug-05 18:21:07 by anonymous:
You can contact me at ryoung@novell.com
2004-Aug-08 18:40:39 by drh:
Please simplify the database so that it still exhibits the
problem but is also small enough to be added as an attachment.
The attach it. The bug report above does not contain nearly
enough information to even begin debugging this problem. |
|
836 |
code
|
closed
|
2004 Aug
|
anonymous
|
|
2004 Aug
|
|
1
|
1
|
sqlite3_prepare() fails when a temp table does not yet exists.
|
edit |
can not compile sql statement "SELECT uid FROM ? WHERE ROWID = 1;" fails with error message, near \"?\": syntax error. Error code SQLITE_ERROR.
This is because the table does not yet exists because it is temporary table yet created. It would be nice if this check was delayed until sqlite3_bind_text() or sqlite3_step() is called.
I am working around this problem by creating a placeholder. |
The "?" wildcard only works in places where it is valid to put
a string literal or numeric constant. The FROM clause is not
such a place. |
|
835 |
doc
|
closed
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Aug
|
|
4
|
4
|
Locks reference on the FAQ - Read while writing?
|
edit |
I am a begginer user. Forgive me if this is a stupid bug report.
http://www.sqlite.org/faq.html#q7
reads: "Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at once."
In a recent experiment with the Perl module for SQLite, I found that when one process is writing a table (database?), another process cannot even read it. A user in #perl at freenode confirmed that. Is it what's SQLite supposed to handle it? If so, the aforementioned text should maybe read:
"Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But no other process can read or write if there is another one changing the database."
Please forgive me if this is bogus. |
You are forgiven. |
|
830 |
code
|
closed
|
2004 Jul
|
anonymous
|
|
2004 Jul
|
|
1
|
1
|
sqlite3_get_table() error
|
edit |
excuse me, but i'm french, and it is difficult for speak english !
when i execute sqlite3_get_table() fonction on windows xp, then an error "instruction privilégiée" (in english, "privileged instruction" or perhaps "supervisor instruction" (?))
thanks
Thierry |
You didn't give us much information to go on.
What was the context of the error.
What SQL were you trying to execute.
How did you open the database.
Was the database initially empty?
What was the database schema.
Are you using C, C++, or some other language.
Etc...
2004-Jul-27 14:34:55 by anonymous:
some answers : i use C++, with wraper find at http://dev.int64.org/ My db was not empty when i try the function. My query was very simply : select * from table. Structure of my table : index_sp INTEGER PRIMARY_KEY ASC, famille TEXTE NOT NULL, [+ 14 column with TEXTE NOT NULL.]
I open database with sqlite3_open, and after try sqlite3_get_table.
Don't forget i am a newbie for c++, and it is possible my code is not good. Finally, i try an other issue, and that is run. Thank you for sqlite, it is a good tool. I use it for ornithologiques observation for naturel park ( http://grandvoyeux.free.fr ) Thierry. |
|
825 |
code
|
closed
|
2004 Jul
|
anonymous
|
|
2004 Jul
|
|
3
|
3
|
lower(X) / upper(X) - not work correctly on non Latin characters
|
edit |
good solution for Win32 is using CharUpper/CharLower API calls instead toupper()/tolower()
Windows NT/2000 or later: To make the conversion, the function uses the language driver for the current language selected by the user at setup or by using Control Panel. If no language has been selected, the system completes the conversion by using internal default mapping. The conversion is made based on the code page associated with the process locale.
Windows 95/98/Me: The function makes the conversion based on the information associated with the user's default locale, which is the locale selected by the user at setup or by using Control Panel. The system does not have language drivers. |
SQLite does not attempt to handle locale. If you want an Upper/Lower
function that works for your locale, you are welcomed to write your
own and register it using the sqlite3_create_function() API.
2004-Jul-27 10:14:51 by anonymous:
I sugges 90% of non-english users make those (add they own lower/upper implementations). Why not to include such common (and universal, based on win32API) functionality ? |
|
821 |
code
|
closed
|
2004 Jul
|
anonymous
|
BTree
|
2004 Jul
|
|
3
|
3
|
Allows string data on indexes INTEGER fields
|
edit |
Hi,
According to http://www.sqlite.org/lang.html#createtable, " However, if primary key is on a single column that has datatype INTEGER, then that column is used internally as the actual key of the B-Tree for the table. This means that the column may only hold unique integer values. (Except for this one case, SQLite ignores the datatype specification of columns and allows any kind of data to be put in a column regardless of its declared datatype.)"
However, I can insert string data into that table.
sqlite> BEGIN TRANSACTION;
sqlite> create table blech (f1 integer);
sqlite> commit;
sqlite> BEGIN TRANSACTION;
sqlite> insert into blech values (4);
sqlite> insert into blech values (8);
sqlite> insert into blech values ('5');
sqlite> insert into blech values ('ghmjym');
sqlite> commit;
sqlite> BEGIN TRANSACTION;
sqlite> create unique index x on blech (f1);
sqlite> commit;
sqlite> select * from blech;
4
8
5
ghmjym
sqlite> BEGIN TRANSACTION;
sqlite> insert into blech values ('ghmj');
sqlite> commit;
sqlite> select * from blech;
4
8
5
ghmjym
ghmj
|
2004-Jul-25 15:24:44 by drh:
F1 is an INTEGER, but it is not a primary key. |
|
820 |
code
|
closed
|
2004 Jul
|
anonymous
|
Parser
|
2004 Oct
|
|
4
|
4
|
problem with sqlite3_prepare and variables
|
edit |
According to the documentation we can use :N: to explicitly number the variables for subsequent binding, however the tokenizer only recognizes ? for variables. I'm assuming this is a coding oversight and not a documentation error.
Simple test case:
"SELECT * FROM test WHERE a=:1: ;"
sqlite3_prepare says unrecognized token ':' |
2004-Jul-25 15:24:00 by drh:
The documentation is a little ahead of the implementation.
The code for :N: variables has not been written yet. For
now, just use ?
2004-Oct-07 22:37:10 by drh:
The ":N" style variables (without the trailing ":") work now. |
|
817 |
new
|
closed
|
2004 Jul
|
anonymous
|
|
2004 Jul
|
|
4
|
2
|
Return size of blob
|
edit |
It would be usefull to know the size of a blob. So instead of:
const void sqlite3_column_blob(sqlite3_stmt, int iCol);
An interface like:
int sqlite3_column_blob(sqlite3_stmt*, int iCol, const void **);
or:
const void * sqlite3_column_blob(sqlite3_stmt*, int iCol, int *); |
2004-Jul-21 13:42:45 by drh:
sqlite3_column_bytes() returns the number of bytes in a BLOB.
I'll improve the documentation to make this clear. |
|
814 |
todo
|
closed
|
2004 Jul
|
anonymous
|
Unknown
|
2005 Jan
|
anonymous
|
1
|
1
|
How can I get the recent bug-fixed branch version 2?
|
edit |
How can I get the recent bug-fixed branch version 2 using browse of wiki? |
2005-Jan-18 17:46:28 by drh:
cvs update -r version_2 |
|
809 |
code
|
closed
|
2004 Jul
|
anonymous
|
|
2004 Jul
|
|
2
|
1
|
Sqlite also fetches the hooks
|
edit |
Example query:
SELECT DISTINCT(name) FROM tabel
sqlite_fetch_array (PHP5) gives:
(name) => "Someone"
But expected:
name => "Someone" |
2004-Jul-15 12:59:49 by drh:
When a column in a result set it an expression, SQLite returns the
full text of that expression as the column name. If the parentheses
are not desired, omit them from the query. Or use an AS clause to
rename the result set column. |
|
808 |
code
|
closed
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Jul
|
|
1
|
1
|
Lower() function with UNICODE
|
edit |
Lower() is with UNICODE not functional... |
2004-Jul-15 12:57:57 by drh:
A correct implementation for lower() for unicode is a large and
tricky routine. And there is no consistently available library
routine for lower() that SQLite can link against.
Users who need a correct lower() behavior in SQL are likely to
have a correct C-language implementation of lower() on hand,
and can easily use the sqlite3_create_function() API to make
that routine available as the lower() SQL function in SQLite.
We have no intention of providing a full unicode-correct lower()
routine in SQLite at this time. |
|
803 |
new
|
closed
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Jul
|
drh
|
1
|
1
|
sqlite3_create_function needs a userdata parameter
|
edit |
In 2.x, create_function had a userdata parameter. In 3.x it hasn't. I absolutely need one for writing a 3.x compatible Python library. |
2004-Jul-12 11:15:01 by drh:
5th parameter to sqlite3_create_function specifies user data.
Function implementations can access the user data using
the sqlite3_user_data() function. |
|
801 |
code
|
closed
|
2004 Jul
|
anonymous
|
|
2004 Sep
|
|
1
|
3
|
Multiple problems with v3.0.2
|
edit |
Hi,
I am playing around with sqlite v3.0.2, and I've run into a number of problems. It looks to me like I am seeing data corruptions but I am not sure.
Here's one problem:
01:30:47 mag@gaia:~/.imms $ sqlite3 imms2.db.brk 'select max(sid) from Library;'
3607
01:37:46 mag@gaia:~/.imms $ sqlite3 imms2.db.brk 'select sid from Library;' | sort -n | tail
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
The table is declared as:
01:37:52 mag@gaia:~/.imms $ sqlite3 imms2.db.brk 'select * from sqlite_master;' | grep Library
table|Library|Library|5164|CREATE TABLE 'Library' ('uid' INTEGER NOT NULL, 'sid' INTEGER DEFAULT '-1', 'path' VARCHAR(4096) UNIQUE NOT NULL, 'modtime' TIMESTAMP NOT NULL, 'checksum' VARCHAR(34) NOT NULL)
index|sqlite_autoindex_Library_1|Library|5163|
The other problem is that the "DEFAULT '-1'" for sid does not always seem to work. When I don't explicitly specify a sid on insert, I sometimes end up with garbage (quite clearly uninitialized memory) in the new row. This does not seem to happen when I try to do it by hand using sqlite3, but it happens all the time from within my program. (I am making heavy use of sqlite3_{prepare,step,reset} so that could maybe be making a difference). I am fairly sure that is not a bug in my code, because I made it go away by simply changing
"INSERT INTO 'Library' "
"('uid', 'path', 'modtime', 'checksum') "
"VALUES (?, ?, ?, ?);"
to
"INSERT INTO 'Library' "
"('uid', 'sid', 'path', 'modtime', 'checksum') "
"VALUES (?, -1, ?, ?, ?);"
Unfortunately, I have not found an easily way to reprouce either of these problems, (although they do happen regularly) but I do have a copy of a "corrupted" database from the first example, so that might help. It's ~9megs in size so let me know if you want it. (If I .dump the problematic table into a different database, it starts working again).
Thanks in advance,
Michael |
2004-Jul-18 21:51:19 by drh:
The first problem might be because '3607' was entered as a BLOB
rather than as an integer. To test for this, enter:
SELECT typeof(sid), sid FROM Library ORDER BY sid DESC LIMIT 1;
I am unable to reproduce the second problem. |
|
799 |
build
|
closed
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Jul
|
|
5
|
4
|
Missing exports in 3.0.2 Win32 DLL
|
edit |
It would be nice to have a typedef for utf-16 support. For compilers that support the wchar_t type it could be defind as wchar_t* rather than the current void*. |
2004-Jul-15 12:50:29 by drh:
Some systems define wchar_t to be 32-bits, not 16-bits.
We did an extensive search for what datatype to use for UTF-16
strings and found no solution that worked consistently across
all compilers. That's why we ended up going with void*. |
|
796 |
code
|
closed
|
2004 Jul
|
anonymous
|
|
2004 Sep
|
|
1
|
2
|
sqlite3_open16 Unworkable
|
edit |
Operating system: windows XP
Language: C#
IDEs: SharpDevelop, Borland C# Builder
A. sqlite3_open16() creates or opens a db file in the sqlite3.dll dir with a gibberish name.
for example call with string name = c:\\tests\\alpha16.db crates a db file with name "{c)gg
%g
4fg,f(c1f.b}" in the sqlite3.dll dir.
B. is there any way to find out by means of pragma or function call in what mode the db was created, i.e. UTF-8 or UTF-16.
Regards,
Nick Simeonov
P.S. by the way sqlitedll-3_0_2 does not export sqlite3_changes and sqlite3_total_changes. |
Please disregard the sqlite3_open16 question find a way to do it right.
nicksim
2004-Sep-02 15:55:45 by drh:
Closed by poster's request. |
|
795 |
new
|
closed
|
2004 Jul
|
anonymous
|
TclLib
|
2004 Oct
|
|
5
|
3
|
Separate TCL library from libsqlite3
|
edit |
For 3.x would it be desirable to split the TCL support out of the main library, and have a seperate libsqlite3_tcl library for the TCL wrappers?
For:
- libsqlite3 would be completely stand-alone, and a known quantity. At the moment, a libsqlite3 library may or may not contain TCL support,
depending on how it was compiled.
- TCL won't be a special case language binding. Other language
bindings may simply be added to the base package without changing
base library.
Against:
- Change to existing practice.
- Any others?
|
2004-Jul-07 00:37:38 by anonymous:
I would upgrade the severity to a 3 or 4 if I could, since it blocks my ability to compile/test SQLite as it is, and with a standard developer tool set.
A lot of people do not use the TCL binding, and compiling SQLite will be a lot easier for them since they don't have to first install or upgrade TCL, which they don't use.
I would much prefer for TCL to be a separate install, so only those people who actually use the language need to install it.
This would put TCL on an even stance with other non-C languages, like C++, Perl, Python, PHP, Objective-C, and the others.
But mainly important, people who don't have TCL support on their system can still compile and use SQLite without problems.
Please have the split in 3.0.3 if possible. Thank you.
2004-Oct-10 17:28:46 by drh:
sqlite.so is distinct from tclsqlite.so. I do not understand the
complaint. |
|
792 |
code
|
closed
|
2004 Jul
|
anonymous
|
|
2004 Sep
|
|
1
|
1
|
ODBC support is broken for 3.0.2
|
edit |
Since the names of the internal functions have changed, the ODBC driver is not non-functional. |
2004-Jul-06 21:56:00 by anonymous:
... should read uncompilable and therefore non-functional,
ie simply not working.
2004-Sep-02 15:57:36 by drh:
The ODBC driver is not part of the SQLite core. |
|
790 |
code
|
closed
|
2004 Jul
|
anonymous
|
|
2004 Jul
|
|
1
|
1
|
Missing include file for the SQLITE distribution 3.0.x
|
edit |
The include file sqliteint.h references sqlite3.h
The file sqlite3.h is not included anywhere in the distribution. |
2004-Jul-02 01:15:24 by drh:
The file sqlite3.h is automatically generated by the makefile.
The template is sqlite.h.in. |
|
788 |
build
|
closed
|
2004 Jun
|
anonymous
|
TclLib
|
2004 Jun
|
|
1
|
1
|
3.0.1 make test failure/death on Mac OS X 10.2.8
|
edit |
Okay, I'm sending a copy of my mailing list message here too.
I tried downloading and compiling "sqlite-3.0.1.tar.gz" today on my Mac OS X 10.2.8 machine, for the first time. (Sorry I didn't get to trying this earlier, but it is before the end of June.) If it helps, I'm using GCC version 3.1, from a December 2002 developer package.
I did the usual procedure:
- configure
- make
- make test
The first two were verbose but I didn't detect any errors. However, part way through its tests, "make test" died with the following errors:
ld: Undefined symbols:
_Tcl_GetWideIntFromObj
_Tcl_NewWideIntObj
make: *** [testfixture] Error 1
Prior to this, it printed out around 70 instances of warnings, all of which said the following or something similar:
warning: passing arg 2 of `Tcl_GetInt' discards qualifiers from pointer target type
Note that simply invoking ./sqlite3 after this point does run the program, though I didn't do anything there other than .help and .quit.
I'm afraid that I'm not at the moment experienced enough in C programming to search for the cause of this problem.
Note that just before this I tested my environment with "sqlite-2.8.14.tar.gz" using the same procedure, and "make test" ran through to completion, though it reported exactly 1 error. That binary likewise ran for the quick .help and .quit.
1 errors out of 28969 tests
Failures on these tests: format3-11.3
make: *** [test] Error 1
Let me know if you need more information, or whether I should use the bug reporting interface on the web site instead of telling you about this on the sqlite mailing list.
One more thing: your README file, for both 2.8.14 and 3.0.1, says this:
The linux binaries on the website are created using the generic makefile,
not the configure script. The configure script is unmaintained. (You
can volunteer to take over maintenance of the configure script, if you want!)
However, the file stamp for "configure" is 2004.06.22 in the latter version, and a corresponding earlier date in the earlier version. So it looks like it in fact is being maintained. So is that readme file out of date on this matter? |
2004-Jun-30 15:05:34 by drh:
The TCL interface requires TCL version 8.4. The core SQLite
library does not require TCL, but TCL 8.4 is required to run
the tests. |
|
787 |
code
|
closed
|
2004 Jun
|
anonymous
|
Unknown
|
2005 Jan
|
|
4
|
4
|
Bad free() ignored (PERL_CORE)
|
edit |
I'm using SQLite in a perl webapp. As the DB is getting more filled, the error message below is clogging up the httpd-errors.log. The app appears to work, but viewing the logfile is a drag.
example source:
#!/usr/bin/perl
use strict;
use DBI;
my $dbh = DBI->connect("dbi:SQLite:dbname=/home/www/links.sqlt", "", "",
{ RaiseError => 1, AutoCommit => 1 });
my $sth = $dbh->prepare( "SELECT id FROM link");
$sth->execute();
while (my $ref = $sth->fetch() ) {
print "id=$ref->[0];\n"; # Error msg occurs here
}
error: Bad free() ignored (PERL_CORE) at ./ex.pl line 12. The first 50 fetches appear to be fine, after that the error occurs on every fetch.
uname -mrs: FreeBSD 4.9-RELEASE i386;
perl -v : This is perl, v5.8.2 built for i386-freebsd;
sqlite -version: 2.8.13 |
2004-Jun-30 04:44:51 by anonymous:
Oops my email: wimrijnders@home.nl
2005-Jan-03 02:38:42 by drh:
This appears to be an error in the Perl wrapper for SQLite,
not in SQLite itself. |
|
781 |
code
|
closed
|
2004 Jun
|
anonymous
|
Unknown
|
2004 Jun
|
|
4
|
4
|
unable to run malloc test even with -DMEMORY_DEBUG
|
edit |
MacOS 10.3.4
gcc 3.3
Cannot run malloc test. -DMEMORY_DEBUG does not cause any new code to
be generated for malloc test to be run. |
2004-Jun-26 00:47:24 by anonymous:
For sqlite v3, define SQLITE_DEBUG=1 to run the malloc tests. |
|
779 |
code
|
closed
|
2004 Jun
|
anonymous
|
|
2004 Jun
|
|
4
|
1
|
duplicated declaration of sqlite3_changes() in sqlite.h.in
|
edit |
the file sqlite.h.in contains a duplicated declaration of the function
int sqlite3_changes(sqlite3*);
(includind documentation) before and after the declaration of the function
int sqlite3_total_changes(sqlite3*);
|
True. Oops. |
|
776 |
code
|
closed
|
2004 Jun
|
anonymous
|
|
2005 Jan
|
|
1
|
1
|
sqlite says Database is locked when database file is on Novel disk
|
edit |
My database file is on novell disk. This disk is mounted as L:. File can be opened under file managers(WinCmd etc.), can be deleted, is accesible to view. I run sqlite.exe l:\file.db and everything seems to be fine, but after trying to launch some query, e.g. simple SELECT, sqlite says "Database is locked". This problem is maybe related to novell share setting, because of sqlite with the same database file works flawless on some stations. I've got no more additional informations. |
2005-Jan-14 00:03:33 by drh:
The developers do not have access to Novel disks and are thus
unable to troubleshoot or fix this problem. No patches were
supplied. We have no choice but to close the ticket without action. |
|
775 |
code
|
closed
|
2004 Jun
|
anonymous
|
Unknown
|
2004 Aug
|
|
1
|
1
|
windows sqlite3.dll corrupt?
|
edit |
Thank you for changing the name to sqlite3.dll. However, I was not able to load the dll into my components. An attempt to use tdump (a utility to extract exported procedures etc) failed too, so I think that the dll might be corrupted. Can you check?
Albert Drent |
|
773 |
code
|
closed
|
2004 Jun
|
anonymous
|
Unknown
|
2004 Jun
|
|
3
|
4
|
user-defined sql function called unexpected number of times
|
edit |
Thank you for making sqlite such an excellent tool!
I am using the pysqlite (0.5.0) Python interface to the sqlite (2.8.14) API. My query is of the form:
select foo(x,y) as b, sum(z) from (
select * from main.table
) group by b
it can probably be simplified and still produce the error, but I'm not sure.
The table has 207869 rows.
I expected then that foo(x,y) would be called 207869 times. However, it was actually called 252194 times (44325 extra calls). I was surprised to see this and thought it might be a bug. |
2004-Jun-22 10:36:16 by anonymous:
Does the query return 44300 or so rows? SQLite makes no hard guarentees about when or how often user functions will be invoked, so it's not a bug on that basis.
2004-Jun-22 23:13:00 by anonymous:
Although I haven't verified it, yes, the result does return a number of rows of that order. I have not observed any incorrect results. This was interesting to me because in my case foo(x,y) is an expensive function, and the 20% extra calls impacts my applications performance. I thought it might give insight into possible sqlite speed improvements. |
|
769 |
code
|
closed
|
2004 Jun
|
anonymous
|
|
2004 Jun
|
|
2
|
2
|
macro SQLITE_OMIT_AUTHORIZATION is not honored
|
edit |
whether the macro SQLITE_OMIT_AUTHORIZATION is set or not
the functions sqlite3Auth* are always called |
2004-Jun-20 22:57:12 by drh:
I don't think so. The sqlite3Auth* functions are
disabled by the following code is in
sqliteInt.h:
#ifndef SQLITE_OMIT_AUTHORIZATION
void sqlite3AuthRead(Parse*,Expr*,SrcList*);
int sqlite3AuthCheck(Parse*,int, const char*, const char*, const char*);
void sqlite3AuthContextPush(Parse*, AuthContext*, const char*);
void sqlite3AuthContextPop(AuthContext*);
#else
# define sqlite3AuthRead(a,b,c)
# define sqlite3AuthCheck(a,b,c,d,e) SQLITE_OK
# define sqlite3AuthContextPush(a,b,c)
# define sqlite3AuthContextPop(a) ((void)(a))
#endif
|
|
767 |
new
|
closed
|
2004 Jun
|
anonymous
|
|
2004 Jun
|
|
1
|
1
|
Metadata of query
|
edit |
I'm developer of ADO.NET Data Provider for SQLite. Everything works fine except one thing - I can not correctly implement IDataReader.GetSchemaTable method.
Basically, this method must return the metadata of the query: tables and column names involved in the query, does the given column have UNIQUE constraint, is the column autoincremented and etc.
The correct implementation of this method is vital for the creation of the class similar to SqlCommandBuilder.
I was considering use EXPLAIN command and parsing the commands of the virtual machine, but VM commands do not contain the whole information. For ex., they do not contain constraints definitions.
What other options do I have?
Thank you,
Alexander Gavrilov |
2004-Jun-19 18:07:53 by drh:
Please ask your question on the SQLite mailing list. |
|
764 |
code
|
closed
|
2004 Jun
|
drh
|
|
2004 Jun
|
drh
|
1
|
1
|
ROLLBACK disables TEMP triggers.
|
edit |
When a ROLLBACK occurs, temporary triggers stop working. The
following code illustrates:
CREATE TABLE t1(x,y);
CREATE TABLE t2(z);
CREATE TEMP TRIGGER r1 AFTER INSERT ON t1 FOR EACH ROW BEGIN
INSERT INTO t2 VALUES(new.x+new.y);
END;
BEGIN;
INSERT INTO t1 VALUES(1,2);
SELECT 333, * FROM t2; -- Output "333|3"
ROLLBACK;
BEGIN;
INSERT INTO t1 VALUES(2,3);
SELECT 555, * FROM t2; -- Should be "555|5" but comes out blank
ROLLBACK;
|
2004-Jun-19 02:24:14 by anonymous:
Checkin [1628]
fixes this for version 3. It still needs to be applied to 2.8.14.
2004-Jun-19 06:07:36 by anonymous:
[1631]
is the same fix in version 2. |
|
761 |
todo
|
closed
|
2004 Jun
|
anonymous
|
Unknown
|
2004 Jun
|
|
5
|
5
|
the current sqlite_source.zip is 2.8.13, not 2.8.14
|
edit |
the "cleaned-up" source code file is not current, and does not include the binary encoding/decoding, despite the change log (which, since it isn't the right version, makes sense :) ). This is more of an FYI, I can get the complete 14 source and extract the encoding/decoding files myself.
--Keith |
Fixed.
Future releases will include a version number in the filename
to prevent this from happening again. |
|
759 |
event
|
closed
|
2004 Jun
|
anonymous
|
Unknown
|
2004 Jun
|
a.rottmann
|
2
|
1
|
record can't be inserted
|
edit |
Run the following code, the record can't be inserted
sqlite *lite;
char **results;
char *szError = 0;
int rows;
CString s,sCode,sDesc;
lite = sqlite_open("c:\\data.db", 0, &szError);
sqlite_exec(lite,"create table data(code0 int, desc char(500))",NULL,NULL,NULL);
sCode = "001";
sDesc = "UPDATE tableno SET tablestate='0' WHERE tablestate='3' and settletime<='%s';";
sqlite_exec_printf(lite,"insert into data(code0,desc) values(%s,'%s');",0,0,0,sCode,sDesc);
sqlite_close(lite);
|
2004-Jun-14 08:28:46 by danielk1977:
In the sqlite3_exec_printf() line, I think you need to replace the second instance of %s with %q. |
|
753 |
code
|
closed
|
2004 Jun
|
anonymous
|
Unknown
|
2004 Nov
|
drh
|
4
|
4
|
view always report numeric as data type
|
edit |
create view viewtest
as
select * from anothertable;
Using pragma table_info('viewtest') always reports column type as numeric. |
|
751 |
code
|
closed
|
2004 Jun
|
anonymous
|
VDBE
|
2005 Jan
|
|
1
|
2
|
sqliteVdbeExec: Assertion `db->magic==***' failed.
|
edit |
After a creating SQLite instance, opening the database, running the following function, and close the database for 50000 times. The following error is raised.
sqlite_get_table (db=0x83e8b68,
zSql=0x8134f00 "select questionIndex, numberOfChoice, erasable, sourceText from Questionnaire order by questionIndex", pazResult=0x82f183c, pnRow=0x82f1834, pnColumn=0x82f1838, pzErrMsg=0x4f121658)
The following error was raised in an abandonment. What's wrong?
exe: ./src/vdbe.c:1598: sqliteVdbeExec: Assertion `db->magic==0xf03b7906' failed.
The call stack of GDB is as follows
#0 0xffffe002 in ?? ()
#1 0x42028a73 in abort () from /lib/tls/libc.so.6
#2 0x42020e65 in __assert_fail () from /lib/tls/libc.so.6
#3 0x5a2c3ce1 in sqliteVdbeExec (p=0x83f5fa0) at ./src/vdbe.c:1598
#4 0x5a2d4481 in sqliteExec (pParse=0x4f12150c) at ./src/build.c:95
#5 0x5a2dffbd in yy_reduce (yypParser=0x83ca110, yyruleno=5) at parse.y:77
#6 0x5a2e182c in sqliteParser (yyp=0x83ca110, yymajor=107, yyminor=
{z = 0x8134f57 "questionIndex", dyn = 0, n = 13}, pParse=0x4f12150c) at parse.c:7017
#7 0x5a2c0a37 in sqliteRunParser (pParse=0x4f12150c,
zSql=0x8134f00 "select questionIndex, numberOfChoice, erasable, sourceText from Questionnaire order by questionIndex", pzErrMsg=0x4f121658) at ./src/tokenize.c:464
#8 0x5a2bdb9b in sqliteMain (db=0x83e8b68,
zSql=0x8134f00 "select questionIndex, numberOfChoice, erasable, sourceText from Questionnaire order by questionIndex", xCallback=0x5a2bffe0 <sqlite_get_table_cb>, pArg=0x4f1215ec, pzTail=0x0, ppVm=0x0,
pzErrMsg=0x4f121658) at ./src/main.c:629
#9 0x5a2bdce6 in sqlite_exec (db=0x83e8b68,
zSql=0x8134f00 "select questionIndex, numberOfChoice, erasable, sourceText from Questionnaire order by questionIndex", xCallback=0x5a2bffe0 <sqlite_get_table_cb>, pArg=0x4f1215ec, pzErrMsg=0x4f121658)
at ./src/main.c:679
#10 0x5a2c023a in sqlite_get_table (db=0x83e8b68,
zSql=0x8134f00 "select questionIndex, numberOfChoice, erasable, sourceText from Questionnaire order by questionIndex", pazResult=0x82f183c, pnRow=0x82f1834, pnColumn=0x82f1838, pzErrMsg=0x4f121658)
at ./src/table.c:150
#11 0x5a2b9960 in SqliteResult::reset ()
from /root/qt-embedded-free-3.2.2/plugins/sqldrivers/libqsqlsqlite.so
#12 0x404f2489 in QSqlQuery::exec () from /root/qt-embedded-free-3.2.2/lib/libqte-mt.so.3
#13 0x404f2002 in QSqlQuery::init () from /root/qt-embedded-free-3.2.2/lib/libqte-mt.so.3
#14 0x404f1ee8 in QSqlQuery::QSqlQuery () from /root/qt-embedded-free-3.2.2/lib/libqte-mt.so.3
|
2004-Jun-01 14:03:11 by drh:
You need to tell us the version number of the SQLite library you
are using. |
|
750 |
code
|
closed
|
2004 May
|
anonymous
|
Unknown
|
2004 Jul
|
|
2
|
3
|
copy command does not work with existing table
|
edit |
Create a table with a "create table" command. Use pg_dump -a command to create a dump of the data, and edit out all but the actual data (no other SQL commands). This will be a tab-delimited one-per-line set of records. SQLite docs say that the copy command works on an existing table, and is designed specifically to understand pg_dump output. When you issue the copy command as: "copy mytable from mydump" or "copy mytable from mydump using delimiters tab" via the C function sqlite_exec(), SQLite issues the error message that "table mytable already exists" and will not copy the data. The workaround is to use "insert" commands, which is probably a lot slower. |
2004-May-30 20:51:35 by anonymous:
THIS BUG REPORT IS BOGUS. MY APOLOGIES. It was a coding mistake on my part. Again, apologies. |
|
747 |
code
|
closed
|
2004 May
|
anonymous
|
|
2005 Jan
|
|
3
|
3
|
database not closed if un-finalized VMs exist
|
edit |
SQLite does not close the database file and release its open file handle if sqlite_close() is called when there are SQLite VMs that have not been finalized.
The application opens a file handle when it calls sqlite_open(). This file handle is normally released when the application calls sqlite_close(), but sqlite_close() checks if there are any outstanding VMs and skips the file close operation if there are. This open file handle prevents any other applications from deleting the file. This file handle is released automatically by the OS when the application terminates.
It looks like SQLite is trying to delay the close operation until the VMs are finalized, but there seems to be an error in the logic. The database is marked with an error state (db->magic = SQLITE_MAGIC_ERROR) when the database is closed with sqlite_close() when there is an un-finalized VM (in sqliteSafetyCheck()). Furthermore, sqlite_close() does not return any error indication that the user can check (you can't check db->magic since the database structure is opaque, and it wouldn't be safe anyway because the database structure may have been deallocated by sqlite_close()) to see if the database was actually closed or not.
In any case, the code in sqlite_finalize() calls sqlite_close() when the last VM is finalized. However, it doesn't work, because sqlite_close() checks the db->magic field in sqliteSafetyOn() and does nothing if it is set to the SQLITE_MAGIC_ERROR value (which it is because of the previous close). Again no errors are produced or checked so the call to sqlite_finalize() doesn't return any error code, but the file is never closed and the handle is not released.
At this point nothing else can delete or rename the file until the application quits since all the pointers to the database structure are invalid. The VM pointers were invalidated by sqlite_finalize() and the database pointer was invalidated by sqlite_close(). You have to rely on the OS to release the file handle now.
The workaround is to ensure that all VMs are finalized before the database is closed.
SQlite should return an error on sqlite_finalize() calls after the database has been closed if this action is not supported. If it is supported, then sqlite_close() should be fixed to actually close the file when called by sqlite_finalize() after the last VM is released. |
2004-May-25 19:31:05 by drh:
If you call sqlite_close() while there are unfinalized VMs, that is
an error. You are misusing the library. SQLite does not attempt to
keep the library open. But it does attempt to avoid a segmentation
fault. In its efforts to avoid segfaulting, it might be leaking
file descriptors or memory or both.
2004-May-25 22:42:42 by anonymous:
If that is the case, then sqlite_finalize() should return SQLITE_MISUSE if it is called after sqlite_close(). Right now it returns SQLITE_OK.
Another idea might be to have sqlite_close() automatically finalize all the VMs on the database's list of VMs. This would ensure that the VM memory would be released. Of course calling sqlite_finalize() after this would be bad because the application's VM pointers would be invalid.
It sure looks like the original idea was to delay closing the database until the application finalized its last VM.
In sqlite_close() want_to_close is set and a check is done which aborts the file close operations that appear later.
db->want_to_close = 1;
if( sqliteSafetyCheck(db) || sqliteSafetyOn(db) ){
/* printf("DID NOT CLOSE\n"); fflush(stdout); */
return;
}
Then in sqlite_finalize() the following check looks like it is supposed to close the database when the last VM has been released (i.e. when pVdbe is NULL).
if( db->want_to_close && db->pVdbe==0 ){
sqlite_close(db);
}
It might be possible to get this to work by adding another magic value SQLITE_MAGIC_CLOSING which gets set by the first call to sqlite_close() if there are outstanding VMs instead of SQLITE_MAGIC_ERROR. It would still return SQLITE_MISUSE on any other attempted use of the database (such as sqlite_compile()), but it would allow sqlite_finalize() calls to work as they do now and free the VMs. After the last VM is finalized then sqlite_close() would be called automatically (as it is now), but it would succeed and actually close the database file because it could accept this new magic value. |
|
745 |
code
|
closed
|
2004 May
|
anonymous
|
VDBE
|
2005 Jan
|
|
5
|
3
|
no error message when two statements cause a conflict
|
edit |
when accessing data without using callbacks, and you manage to mix two statements together that block because they lock each other, the error message is null. |
|
740 |
code
|
closed
|
2004 May
|
anonymous
|
BTree
|
2004 May
|
|
1
|
1
|
Unable to compile on Fedora core 1
|
edit |
On a fully patched Fedora core 1, I have been unable to build sqlite for weeks now.
I have my build directory as a subdirectory of sqlite. In this directory ../configure seems to work. Make fails to compile, the first few lines of the compile error listing are:
gcc -g -O2 -DOS_UNIX=1 -DOS_WIN=0 -DHAVE_USLEEP=1 -I. -I../src -c ../src/btree_rb.c -fPIC -DPIC -o .libs/btree_rb.o
In file included from ../src/btree_rb.c:19:
../src/btree.h:64: error: syntax error before "u32"
../src/btree.h:65: error: syntax error before "u32"
../src/btree.h:83: error: syntax error before "i64"
../src/btree.h:85: error: syntax error before "i64"
../src/btree.h:93: error: syntax error before "i64"
../src/btree.h:94: error: syntax error before "u32"
../src/btree.h:97: error: syntax error before "u32"
../src/btree.h:98: error: syntax error before "u32"
../src/btree_rb.c:38: error: syntax error before "sqliteRbtreeOps" |
2004-May-18 16:25:51 by drh:
CVS HEAD is undergoing an extensive change to move it to version 3.0.0.
It is currently unstable and will not compile using ./configure.
Either use the prepackaged source code for 2.8.13
on the website or use the "version_2" branch of CVS. |
|
733 |
code
|
closed
|
2004 May
|
anonymous
|
|
2004 Aug
|
anonymous
|
3
|
3
|
About Ticket #731
|
edit |
It seems that Dr. drh misunderstood Ticket #731
the result is
foo|bar |baz|frob
1 |fred| |bill
2 |fred| |
it shouldn't be because baz is unique.
but when we create table with each unique column it is ok.
(for example : create table test2 ( foo integer primary key, bar text unique, baz text unique, frob text); )
so Ticket #731 is about the problem that unique() command has. |
2004-May-17 11:44:11 by anonymous:
This is the difference between a compound unique and a individual unique. nothing to be fixed. should be closed. |
|
731 |
code
|
closed
|
2004 May
|
anonymous
|
|
2004 May
|
|
2
|
3
|
UNIQUE constraint not working when one of the fields is null
|
edit |
The UNIQUE constraint is supposed to prevent the specified columns from being duplicated. To me, that means that if I do a query selecting for those columns (WHERE colA=something1 AND colB=something2 AND ... AND colN=somethingN) then I should get back at most one row. However, here is a situation where I can add the same index twice:
create table test (foo integer primary key, bar text,
baz text, frob text, unique(bar, baz));
pragma index_info('(test autoindex 1)');
insert into test values (null, "fred", null, "bill");
insert into test values (null, "fred", null, "");
select * from test;
Notice that bar and baz have values "fred" and null, respectively in both rows. This does not seem correct - certainly not what I'm expecting.
Csaba Gabor |
2004-May-10 23:41:52 by anonymous:
Quite interesting...
I've tested a little different.
create table test2 (
foo integer primary key,
bar text unique,
baz text unique,
frob text);
sqlite> insert into test2 values(null,'fred',null,'bill');
sqlite> insert into test2 values(null,'fred',null,'');
SQL error: column bar is not unique
with this code it works fine. but the former code has bad result. if we do it again like below, sqlite accepts it.
sqlite> insert into test values(null,'fred',null,'bill');
sqlite> insert into test values(null,'fred',null,'');
so the result is :
sqlite> select * from test;
foo|bar|baz|frob
1|fred||bill
2|fred||
3|fred||bill
4|fred||
2004-May-10 23:42:38 by drh:
See http://www.sqlite.org/nulls.html.
The behavior you desire is what Informix and MS-SQL give.
Most other RDBMSes (PostgreSQL, Oracle, DB2, MySQL) work
like SQLite. I'm going to leave the behavior as it is.
The SQL spec is ambiguous about what should be done. |
|
730 |
new
|
closed
|
2004 May
|
anonymous
|
|
2004 May
|
|
4
|
3
|
Differentiate context-sensetive user actions and navigation in UI
|
edit |
It would be very helpful if the links at the top could be differentiated into two classes: fixed links which are always there for navigation, and page-specific actions / functions.
I slapped myself when I couldn't figure out how to attach a file to a ticket, and realized it was because I hadn't even thought to look in the navigation bar. It's a bit confusing, and even now that I know where to look I find it awkward.
This could be solved in an abstract way by putting the two classes of links into two different <div class="menuNavigation"> <div class="pageActions"> tags, and allowing users to specify a custom CSS url.
Also I would be more than happy to contribute my time to helping with CSS, etc. I am not a c hacker, but this project is helping me immensely, and I've only been using it for 2 days.
Thanks for all the fantastic work. |
2004-May-09 01:03:45 by anonymous:
GAH!
Somehow I got to sqlite CVSTrac?
Will pull this ticket and resubmit on cvstrac cvstrac! |
|
729 |
new
|
closed
|
2004 May
|
anonymous
|
Unknown
|
2004 Oct
|
|
5
|
3
|
Support wiki-style bulleted lists in tickets
|
edit |
Formatting hints mentiones everything I'm used to seeing with basic wiki formatting except bulleted lists, which are very nice to have in a ticket.
While we're at it - headings wouldn't be a bad thing either. But bulleted lists would be really excellent and useful. |
2004-Oct-10 17:31:34 by drh:
Read the formatting hints again. They are there. Always have been. |
|
728 |
code
|
closed
|
2004 May
|
anonymous
|
Unknown
|
2004 Nov
|
anonymous
|
4
|
3
|
.schema table fails if followed by a semicolon
|
edit |
sqlite> .schema smslog;
sqlite> .schema smslog
create table smslog (
smsid INTEGER PRIMARY KEY,
udh text,
data text,
receipt text,
sendid int);
sqlite>
|
2004-May-08 13:59:08 by anonymous:
You can reach me at beckman & purplecow *%^&#^ com |
|
722 |
code
|
closed
|
2004 May
|
anonymous
|
VDBE
|
2004 Jul
|
drh
|
2
|
1
|
long long format specifier in sqlite_exec_printf missing
|
edit |
sqlite_exec_printf and friends not not handle 64 bit longs - i.e. lack the "llu" or "I64u" format specifier.
This makes it quite harder and uglier to put 'long long's into the database on 32 bit platforms. At the moment the hack is:
---
static char ts1[64];
memset(ts1, 0, 64);
snprintf(ts1, 64, "%llu", l);
// llu does not work below
char* foo = sqlite_mprintf("select * from foo where bar=%q;", ts1);
printf("%s\n", foo);
---
which does the trick. Note the above is testing code, not production, which uses %Q,%q,%d and sqlite_exec_printf().
This could probably be fixed by adding the printf implementation up to date. |
2004-May-05 19:23:05 by anonymous:
Me again, quick note: while in 64bit mode (linux fedora core 1 x86_64 gcc 3.3.2), using "%ld" or "%lu" works fine of course, since sizeof(long)=sizeof(long long)=8.
In 32 bit mode however, "%ld" truncates to 32 bit.
Should it matter in any way, I'm using long long to store timestamps (milliseconds since 1/1/1970 - like System.currentTimeMillis(), but in C++).
Thanks & regards, great job.
2004-Jul-19 02:27:24 by drh:
I consider this a new feature request. It has been implemented in
version 3.0. |
|
719 |
code
|
closed
|
2004 May
|
anonymous
|
|
2004 May
|
|
2
|
3
|
index_list not reporting my indeces
|
edit |
I discovered this in using sqlite with PHP (version 2.8.11) and just downloaded sqlite (version 3.8.13 and tested with command line interface) on my Win2K Pro system.
sqlite does not seem to be finding all the indeces. If I do something like:
CREATE TABLE Macs (Id INTEGER PRIMARY KEY, hIP VARCHAR(11), Host TEXT, FirstTime VARCHAR(19), browVer TEXT, UNIQUE (hIP, browVer));
PRAGMA index_list('Macs');
what I get is:
0|(Mac2 autoindex 1)|1
As I understand it, Id is a PRIMARY KEY is an index (at least that's what the CREATE TABLE documentation would lead a reader to believe:
Specifying a PRIMARY KEY normally just creates a UNIQUE index on the primary key. However, if primary key is on a single column that has datatype INTEGER, then that column is used internally... that word "just" would be interpreted "only"). Therefore, it should ether be listed under index_list or this non listing should be prominently trumpeted under the appropriate PRAGMA heading. In addition, it might be pointed out that CONSTRAINTS can get these funny type of "autoindex" names.
Thanks,
Csaba Gabor |
An INTEGER PRIMARY KEY does not generate a separate index.
Works as designed. No changes to code. |
|
715 |
code
|
closed
|
2004 Apr
|
anonymous
|
Unknown
|
2004 Apr
|
|
2
|
3
|
reference counted file locking attempts to unlock on different thread
|
edit |
UNIX multi-threaded only bug.
os.c:1523:
if( id->pLock->cnt>1 ){
id->pLock->cnt--;
rc = SQLITE_OK;
}else{
In Linux 2.4.20 fcntl() file locks are owned by specific threads.
In multi-threaded use cases, due to lock counting, it is possible that a different thread will attempt to unlock from the thread that locked. This results in a leaked file lock. Because this can only happen for read locks, the visible symptom is the database will be readable but forever unwritable until the program is restarted.
The leaked lock can be observed in /proc/locks after the condition has occured.
Solution: fcntl() Lock/Unlock for each call to:
sqliteOsReadLock()
sqliteOsWriteLock()
sqliteOsUnlock() |
Fixed 3 months ago with version 2.8.10. Version 2.8.13 is
current. See associated check-ins for more information. |
|
706 |
build
|
closed
|
2004 Apr
|
anonymous
|
Unknown
|
2004 Apr
|
|
1
|
1
|
undefined reference
|
edit |
It builds and ar's and ranlib's fine, but no matter what I do I wind up with this:
gcc -g -O2 -Wall -I../sqlite -L../sqlite -lsqlite ../sqlite/libsqlite.a -o main main.o
main.o: In function `main':
/staff/rakaur/test/src/main.c:23: undefined reference to `sqlite_open'
/staff/rakaur/test/src/main.c:28: undefined reference to `sqlite_exec'
/staff/rakaur/test/src/main.c:32: undefined reference to `sqlite_close'
*** Error code 1
Stop in /staff/rakaur/test/src.
*** Error code 1
Stop in /staff/rakaur/test. |
Do this:
gcc -g -O2 -Wall -o main.o main.c ../sqlite/sqlite.a
User error. No changes to code.
2004-Apr-26 12:39:11 by anonymous:
I used -L../sqlite -lsqlite -o bin main.o ../sqlite/libsqlite.a
That worked fine. |
|
704 |
event
|
closed
|
2004 Apr
|
anonymous
|
|
2004 Apr
|
|
5
|
5
|
.database && .databases
|
edit |
In dot commands, there is ".databases". you can use ".database" and expect the same result. I tested it on Windows 2000 computer.
Thanks for your work, D. Richard Hipp! |
2004-Apr-24 10:20:34 by drh:
You can use any unique prefix for the "dot" commands of the shell.
The full command is ".databases". But you can also use:
.da
.dat
.data
.datab
.databa
.databas
.database
Be careful with this, though, since new commands might be added
to the shell in the future that might make some of these
abbreviations ambiguous. |
|
702 |
code
|
closed
|
2004 Apr
|
anonymous
|
|
2004 Jul
|
|
3
|
3
|
Bug in sorting: some strings sort in the middle of numerical values
|
edit |
This shows a bug in SQLite The doc says strings sort before numbers.
I entered some values into a simple table with just one column, named
int. Generally the values with leading spaces, or leading dashes, as
treated as a string. But they sort in the middle of the numbers. The
fact that they land in the middle of the two values of 13 is also a
problem. (I think that oen of them was inserted with trailing space.)
sqlite> select * from t order by int;
1
1
9
11
13
13
13.0001
--11
13
13.0
13.00001
a11
a9
sqlite>
|
2004-Apr-23 23:10:01 by drh:
Unable to reproduce.
When I enter the values shown above into a simple table and do a
SELECT with an ORDER BY, they come out in the correct order.
Note, however, that if there are trailing spaces on the second '13'
and on the '13.0' and "13.000001' then the order is as shown. Are
you sure that there are not trailing spaces on your numbers?
2004-Jun-02 23:22:16 by anonymous:
"order by int" might be your problem cause "int" is a data type?? maybe: order by `int` ? |
|
701 |
todo
|
closed
|
2004 Apr
|
anonymous
|
|
2004 Apr
|
drh
|
3
|
3
|
INSERT FAILED?
|
edit |
CREATE TABLE TEST (ID INT PRIMARY KEY, [NAME] NVARCHAR(100))
INSERT INTO TEST [NAME] VALUES('ABC')
SQL logic error or missing database: near "[NAME]": syntax error
Am I wrong? |
2004-Apr-23 05:56:52 by anonymous:
oh, there a character return before "INSERT INTO..."
2004-Apr-23 10:46:34 by drh:
Operator error. Works as designed. |
|
696 |
code
|
closed
|
2004 Apr
|
anonymous
|
TclLib
|
2005 Jan
|
|
1
|
1
|
tclsqlite does not build on RH 7.3
|
edit |
[davidw@mod3 bld]$ ../configure --with-tcl=/usr/lib/ --prefix=/usr/
results in a build that doesn't handle Tcl correctly:
./libtool --mode=link gcc -g -O2 -DOS_UNIX=1 -DOS_WIN=0 -DHAVE_USLEEP=1 -I. -I../src -I/usr/lib//generic -I/usr/lib//unix -o tclsqlite tclsqlite-sh.lo libsqlite.la /usr/lib//unix/libtcl8*.a -ldl -lm
gcc: /usr/lib//unix/libtcl8*.a: No such file or directory
I have no idea where it got that directory from.
Thanks, Dave |
2004-Apr-17 07:07:15 by anonymous:
In my opinion problem this is the problem:
..... /usr/lib//unix/libtcl8*.a ......
^^^^ double slash int the library path
Bartosz
2004-Apr-17 07:14:54 by anonymous:
Sorry but my remark was suddenly truncated.
Please search env. settings like PATH, LIB for directory
with / at the end. But if other programs compile it should be
correct setting.
Next step is to search makefile for absolute name of tcl library -
it means / at the beginning of the library name - so concatenation
ot these name gives doble slash.
Finnaly, there could be an error in the configure script.
|
|
695 |
code
|
closed
|
2004 Apr
|
anonymous
|
|
2005 Jan
|
|
3
|
3
|
CREATE INDEX and dbl-quoted index names
|
edit |
Newly created indices which are double-quoted retain the
double-quotes in the index name.
sqlite> create table x (id integer, name varchar);
sqlite> create index "x_index" on x(name ASC);
sqlite> drop index "x_index";
SQL error: no such index: x_index
sqlite> drop index '"x_index"';
sqlite>
Following patch against sqlite 2.8.13 src/build.c remedies the
problem:
--- sqlite.orig/src/build.c 2004-02-24 02:04:12.000000000 +0100
+++ sqlite/src/build.c 2004-04-16 15:49:49.000000000 +0200
@@ -1538,7 +1538,7 @@
if( pName && !db->init.busy ){
Index *pISameName; /* Another index with the same name */
Table *pTSameName; /* A table with same name as the index */
- zName = sqliteStrNDup(pName->z, pName->n);
+ zName = sqliteTableNameFromToken(pName);
if( zName==0 ) goto exit_create_index;
if( (pISameName = sqliteFindIndex(db, zName, 0))!=0 ){
sqliteErrorMsg(pParse, "index %s already exists", zName);
|
2004-Apr-17 11:25:42 by anonymous:
Corrected patch:
diff -ur sqlite.orig/src/build.c sqlite/src/build.c
--- sqlite.orig/src/build.c 2004-02-24 02:04:12.000000000 +0100
+++ sqlite/src/build.c 2004-04-17 11:05:42.000000000 +0200
@@ -1538,7 +1538,7 @@
if( pName && !db->init.busy ){
Index *pISameName; /* Another index with the same name */
Table *pTSameName; /* A table with same name as the index */
- zName = sqliteStrNDup(pName->z, pName->n);
+ zName = sqliteTableNameFromToken(pName);
if( zName==0 ) goto exit_create_index;
if( (pISameName = sqliteFindIndex(db, zName, 0))!=0 ){
sqliteErrorMsg(pParse, "index %s already exists", zName);
@@ -1558,7 +1558,7 @@
sqliteSetString(&zName, "(", pTab->zName, " autoindex ", zBuf, (char*)0);
if( zName==0 ) goto exit_create_index;
}else{
- zName = sqliteStrNDup(pName->z, pName->n);
+ zName = sqliteTableNameFromToken(pName);
}
/* Check for authorization to create an index.
2005-Jan-13 14:49:32 by anonymous:
This "corrected" patch is not in version 2.8.15 and should be.
2005-Jan-13 23:32:16 by drh:
The corrected patch is in the head of the Version 2 branch of the
source tree. See ticket #869 and check-in [1907]
. |
|
694 |
code
|
closed
|
2004 Apr
|
anonymous
|
Unknown
|
2004 Apr
|
|
3
|
4
|
uninitialised or unaddressable byte(s) in os.c
|
edit |
I'm using SQLite from cvs 2004-04-12 with
gcc 3.3.1
Linux 2.4.21-199
When i test my code with valgrind i get following error:
======================================================================
==23150== ERROR SUMMARY: 12 errors from 1 contexts (suppressed: 1 from 1)
==23150==
==23150== 12 errors in context 1 of 1:
==23150== Syscall param write(buf) contains uninitialised or unaddressable byte(s)
==23150== at 0x4039A108: __GI___libc_write (in /lib/i686/libc.so.6)
==23150== by 0x4024533E: sqliteOsWrite (os.c:1000)
==23150== by 0x402470AE: pager_write_pagelist (pager.c:1262)
==23150== by 0x402483E2: sqlitepager_commit (pager.c:2020)
==23150== Address 0x415E5252 is 142 bytes inside a block of size 1364 alloc'd
==23150== at 0x4002CEAF: malloc (vg_replace_malloc.c:160)
==23150== by 0x40254A1C: sqliteMallocRaw (util.c:268)
==23150== by 0x402471EC: sqlitepager_get (pager.c:1387)
==23150== by 0x40230BCA: newDatabase (btree.c:840)
--23150--
--23150-- supp: 1 __pthread_mutex_unlock/_IO_funlockfile
==23150==
==23150== IN SUMMARY: 12 errors from 1 contexts (suppressed: 1 from 1)
==23150==
==23150== malloc/free: in use at exit: 128 bytes in 2 blocks.
==23150== malloc/free: 1946 allocs, 1944 frees, 447323 bytes allocated.
==23150==
==23150== searching for pointers to 2 not-freed blocks.
==23150== checked 4115340 bytes.
==23150==
==23150== 128 bytes in 2 blocks are still reachable in loss record 1 of 1
==23150== at 0x4002CEAF: malloc (vg_replace_malloc.c:160)
==23150== by 0x402549BD: sqliteMalloc (util.c:254)
==23150== by 0x40240E15: rehash (hash.c:172)
==23150== by 0x40241311: sqliteHashInsert (hash.c:344)
==23150==
==23150== LEAK SUMMARY:
==23150== definitely lost: 0 bytes in 0 blocks.
==23150== possibly lost: 0 bytes in 0 blocks.
==23150== still reachable: 128 bytes in 2 blocks.
==23150== suppressed: 0 bytes in 0 blocks.
--23150-- TT/TC: 0 tc sectors discarded.
--23150-- 5986 chainings, 0 unchainings.
--23150-- translate: new 6886 (116999 -> 1604243; ratio 137:10)
======================================================================
Note the the only change i have made to the cvs is:
--------------------------------------------
RCS file: /sqlite/sqlite/src/os.c,v
retrieving revision 1.66
diff -r1.66 os.c
19a20,21
> #define THREADSAFE 1
>
--------------------------------------------
so you need to correct the line number in the above os.c error.
Is this an error in my code using SQLite or is this a problem in SQLite? |
The "problem" reported by valgrind above is benign. It is not
a real error. |
|
693 |
build
|
closed
|
2004 Apr
|
anonymous
|
|
2004 Apr
|
|
1
|
1
|
Compiling for freeBSD
|
edit |
I've tried everything suggested in this forum and can't get SQlite to compile properly.
Any chance I can get someone to post the exact steps they used to get it to work.
Or provide a binary.
Used this from the package, with 'make' and "gmake":
tar xzf sqlite.tar.gz ;# Unpack the source tree into "sqlite"
mkdir bld ;# Build will occur in a sibling directory
cd bld ;# Change to the build directory
../sqlite/configure ;# Run the configure script
make ;# Run the makefile. |
FreeBSD is not a supported platform, so this is not an appropriate
forum for asking these kinds of questions. Please try posting to
the sqlite-users mailing list. Instructions are on the SQLite
homepage.
I would also add that there is a port available from the FreeBSD ports collection. Google it.
-LPS- 20040414
2004-Apr-26 03:14:18 by anonymous:
Why is FreeBSD not a "supported platform"? It's far more common/stable/useful/etc than Linux. You say "no dependancies" but fail to mention gmake and libtool.... |
|
688 |
code
|
closed
|
2004 Apr
|
anonymous
|
|
2004 Apr
|
|
1
|
1
|
Scope problem in subselect
|
edit |
Hi,
when using the following SQL-SELECT, I receive an SQL error.
SELECT A1.IDENTIFIER, A1.FIRSTNAME, (SELECT COUNT(A2.PHONE) FROM CONTACT A2 WHERE A1.IDENTIFIER = A2.FK_PERSON) AS RELCOUNT FROM PERSON A1;
==> SQL error: no such column: A1.IDENTIFIER
Both tables (PERSON and CONTACT) have a column named "IDENTIFIER". The SQL succeeds if I use the following SQL-Select:
SELECT IDENTIFIER, FIRSTNAME, (SELECT COUNT(A2.PHONE) FROM CONTACT A2 WHERE IDENTIFIER = A2.FK_PERSON) AS RELCOUNT FROM PERSON;
==> but the IDENTIFIER column reference seems not to be unique anymore...
Thanks and best regards,
Timo |
SQLite supports static subqueries only. The subquery cannot refer
to a value in the outer query. This is a known and documented
limitation of SQLite.
You can usually accomplish the same thing with a join. For
example:
SELECT a1.identifier, a1.firstname, sub.cnt
FROM person AS a1,
(SELECT count(phone) AS cnt, fk_person FROM contact
GROUP BY fk_person) AS sub
WHERE a1.identifer = sub.fk_person;
|
|
681 |
build
|
closed
|
2004 Apr
|
anonymous
|
CodeGen
|
2004 Apr
|
|
1
|
1
|
undefined reference to 'sqlite_open'
|
edit |
unable to compile any sqlite APIs.
( included sqlite.h )
getting compiler error: undefined reference to 'sqlite_open' |
Complaintant provides no information about how he is attempting
to compile, so nothing can be done to help him correct his problem.
No action taken. |
|
679 |
code
|
closed
|
2004 Mar
|
anonymous
|
Unknown
|
2006 Jan
|
a.rottmann
|
2
|
1
|
database closed
|
edit |
i am using sqlite with delphi7 and it was great untill i got a errore database locked when i try to do insert. i cant unlock it and if i change the database to a new one i get the same error . the progrem i am making is for a stand alone one computer one database no multi user. |
2004-Mar-31 15:01:43 by drh:
The error report does not describe how to reproduce the
problem. It does not specify the SQLite version number.
No contact information is provided.
From the quality of the error report, one may infer that the
problem is a result of a user error. Insufficient data is available
for further analysis. |
|
678 |
code
|
closed
|
2004 Mar
|
anonymous
|
Unknown
|
2004 Jul
|
anonymous
|
1
|
1
|
Group by only returning one row when source table is sub-query or view
|
edit |
Try this query
select tbl_name from sqlite_master group by tbl_name
Now try this query
select tbl_name from (select * from sqlite_master) group by tbl_name
The same results should be displayed but only one row is displayed.
This also affects group by when using a view |
2004-Jul-20 00:31:22 by drh:
GROUP BY only works when you have aggregate functions. |
|
677 |
code
|
closed
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
|
2
|
3
|
Failure to convert to FP on division involving a constant
|
edit |
sqlite> select * from idiv;
I J
---------- ----------
1 3
2 3
3 3
4 3
sqlite> select I/J from idiv;
I/J
-----------------
0.333333333333333
0.666666666666667
1
1.33333333333333
sqlite> select I/3 from idiv;
I/3
----------
0
0
1
1
sqlite> select J/I from idiv;
J/I
----------
3
1.5
1
0.75
sqlite> select 3/I from idiv;
3/I
----------
3
1
1
0
|
2004-Mar-31 01:12:00 by drh:
Works fine when I try it. How did you define the IDIV table?
What are the column types? Did you compile SQLite yourself or
use the precompiled copies on the website? What OS?
2004-Mar-31 02:21:45 by drh:
The phenomenon appears when column I is an INTEGER PRIMARY KEY.
An INTEGER PRIMARY KEY column has an integer datatype. All other
columns in SQLite (whether numeric or text) have a floating point
datatype. If you take this rule into account, the behavior above
is correct.
Works as designed, no changes to code. |
|
675 |
code
|
closed
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
|
2
|
1
|
Malformed error at GET BLOB DATA from database file
|
edit |
Generally, It is no problem that we input a BLOB DATA into database file, but it is failed that we search a BLOB DATA from database file.
The fail message is followed by "The database disk image is malformed.".
Why this problem ocurrs? |
SQLite will not work if you put binary data into an indexed column.
An incompatible file format change will be necessary to fix this.
The fix will not occur prior to version 3.0.
Use sqlite_encode_binary() as an alternative. |
|
674 |
code
|
closed
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
|
3
|
4
|
insert record fails mpatrol tests
|
edit |
mpatrol reports this:
ERROR: [NULOPN]: memcpy: attempt to perform operation on a NULL pointer
ALLOC: malloc (100206, 0 bytes, 4 bytes) [-|-|-]
0x4007D022 sqliteMallocRaw+34
0x40090F17 memRbtreeInsert+71
0x400846C8 sqliteVdbeExec+19080
0x4005A59F sqliteExec+319
0x4006F655 yy_reduce+277
0x4007280D sqliteParser+605
0x4007B911 sqliteRunParser+353
0x4006A517 sqliteMain+327
0x4006A739 sqlite_exec+57
0x0804B391 parse_for_key_words+213
0x0804C781 parse_is_wanted_page+3846
0x0804B11B display_dump_and_free_links+1949
0x0804B20C display_google_page+101
0x0804A7EF main+141
0x401CFC5F __libc_start_main+207
0x0804A651 _start+33
WARNING: [ALLZER]: malloc: attempt to create an allocation of size 0
MEMCOPY: memcpy (0x00000000, 0x0810E078, 0 bytes, 0x00) [-|-|-]
0x40090F43 memRbtreeInsert+115
0x400846C8 sqliteVdbeExec+19080
0x4005A59F sqliteExec+319
0x4006F655 yy_reduce+277
0x4007280D sqliteParser+605
0x4007B911 sqliteRunParser+353
0x4006A517 sqliteMain+327
0x4006A739 sqlite_exec+57
0x0804B391 parse_for_key_words+213
0x0804C781 parse_is_wanted_page+3846
0x0804B11B display_dump_and_free_links+1949
0x0804B20C display_google_page+101
0x0804A7EF main+141
0x401CFC5F __libc_start_main+207
0x0804A651 _start+33
i believe the fix is .. at least it stops the mpatrol error ..
in btree_rb.c in memRbtreeInsert()
replace:
pData = sqliteMallocRaw(nData);
if( sqlite_malloc_failed ) return SQLITE_NOMEM;
memcpy(pData, pDataInput, nData);
with:
if(nData==0)
{
pData=NULL;
}
else
{
pData = sqliteMallocRaw(nData);
if( sqlite_malloc_failed ) return SQLITE_NOMEM;
memcpy(pData, pDataInput, nData);
}
</PRE> |
In this block of code:
pData = sqliteMallocRaw(nData);
if( sqlite_malloc_failed ) return SQLITE_NOMEM;
memcpy(pData, pDataInput, nData);
sqliteMallocRaw() will return 0 (or NULL - same thing) if the
system is out of memory or if nData==0. In the first case (out
of memory) the global variable sqlite_malloc_failed will have
been set, the jump will be taken and the memcpy will never be
reached. The only other way for pData to be 0 if for nData
to be zero. But the statement:
memcpy(0, pDataInput, 0);
Should be benign. The NULL passed in as the first argument
should not matter since the 0 in the third argument makes the
memcpy() a no-op.
Until somebody reports a machine where an memcpy() of zero
bytes actually dereferences the destination pointer, I will
consider this a non-issue. |
|
672 |
warn
|
closed
|
2004 Mar
|
anonymous
|
Unknown
|
2004 Mar
|
|
1
|
1
|
THE DLL FILE FOR WINDOWS IS CURRUPTED
|
edit |
THE DLL FILE IS GET CURRUPTED PLEASE UPLOAD THE NEW VERSION |
MD5 checksums are correct. Must be a user problem. |
|
671 |
build
|
closed
|
2004 Mar
|
anonymous
|
TclLib
|
2004 Mar
|
|
4
|
4
|
Missing tcl.h from /src
|
edit |
I downloaded and gunzipped the 2.8.13.tar.gz file. Then ./configure
and make. No problems. The output of make test showed the
following lines at the very end:
./src/test1.c:19: tcl.h: No such file or directory
./src/test2.c:21: tcl.h: No such file or directory
./src/test3.c:21: tcl.h: No such file or directory
./src/test4.c:17: tcl.h: No such file or directory
./src/md5.c:31: tcl.h: No such file or directory
make: *** [testfixture] Error 1
bash-2.04$
I don't know if the absence of tcl.h from the /src directory
is important, or whether some tests couldn't be performed.
Thank you,
Peter F. Clark cpf101@stu.wccnet.org |
You have to have TCL installed in order to run the tests.
Get a copy from http://www.tcl.tk/ |
|
669 |
new
|
closed
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
|
5
|
5
|
named-field?
|
edit |
right now we still need to use number-based index to acces fields, but how about named-fields such as "name","desciption" etc. rather than 0,1... ? |
2004-Mar-18 13:53:03 by drh:
I have no idea what this ticket is talking about. |
|
664 |
new
|
closed
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
|
5
|
5
|
In-Memory convert to disk database file?
|
edit |
If I connect an in-memory database, do som operations, then I wish to persist the data to the disk, how ? |
Usage questions are handled on the SQLite mailing list, not using
trouble tickets. |
|
663 |
new
|
closed
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
drh
|
5
|
5
|
SELECT TOP n?
|
edit |
how about supporting the "SELECT TOP n" clause? refer to:http://archives.postgresql.org/pgsql-sql/1999-04/msg00102.php |
Use the LIMIT clause. |
|
661 |
new
|
closed
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
|
5
|
5
|
In-Memory feature?
|
edit |
Will sqlite add the in-memory feature? that is, like the hsqldb in sourceforge.net, it has physical disk/in-memory modes, some times, we do not want to generate disk files. In-memory mode, allow user to opereate sql without disk files, that is any way out. |
Already exists. Read the documentation. |
|
657 |
code
|
closed
|
2004 Mar
|
anonymous
|
Unknown
|
2004 Mar
|
|
1
|
1
|
Wrong reported columncount in CallBack routine
|
edit |
The Callback routine (called after select) reports 0 as the columncount when the first record (containing the field definitions metadata) is retrieved. The second record (first real data record) reports the correct number of columns. This is a real showstopper for the Delphi components we develop, since the datastructure of the select must be known before datarecords can be processed. The components do work with version 12 and older where the problem does not exists.
Albert Drent |
This doesn't make any sense. The query callback in SQLite has never
returned meta data in a separate row prior to returning the result set.
In the callback API, meta data is always
passed in with every row as the 4th parameter to the callback function.
The sqlite_get_table() API returns meta data in a prior row, but it
does not use callbacks. The columncount field there appears to
be correct, at least in the test cases that are run as part of the
regression test suite.
This ticket is closed pending more data and/or a better description
of the problem.
2004-Mar-13 12:42:07 by anonymous:
It' appearantly difficult to explain the problem, but you're right, the column info is added to every record. Problem still exists: on the first time the callback is called the columncount is 0, all other times the columncount contains the correct value. The metadata added to every record in the callback is only parsed at the first time the callback is called, explaining the confusion.
albert
2004-Mar-13 20:39:02 by anonymous:
Well the problem was a little more complex since v12 workded and v13 did not. But I have found a way-out. Thanks for your time, and sorry for the trouble.
Albert |
|
653 |
code
|
closed
|
2004 Mar
|
anonymous
|
Unknown
|
2004 Mar
|
|
1
|
1
|
sqlite db 'create table t(f)' dumps core
|
edit |
sqlite db 'create table t(f)' coredumps : sqliteSafetyOn (db=0x0) at ./src/util.c:1200
on
/dmsp/reference/build/sqlite-2.8.12 > uname -srm
Linux 2.4.21-9.0.1.ELsmp i686
and
/dmsp/reference/build/sqlite-2.8.12 > uname -srm
Linux 2.4.20-28.7smp i686
built with NO configure options. |
2004-Mar-10 02:53:26 by anonymous:
i did this to src/shell.c and it seems to work. the problem seems to be that some of code is using data->db while some uses the global db ptr. to fix this i simply made open_db also initialize the db ptr. here is a patch:
--- shell.c 2004-03-09 19:50:44.000000000 -0700
+++ shell.c.patched 2004-03-09 19:50:54.000000000 -0700
@@ -528,6 +528,7 @@
exit(1);
}
}
+ db = p->db;
}
/*
Previously reported by tickets #649, #642, and #620. Fixed
by check-in [1238]
and in version 2.8.13. |
|
650 |
new
|
closed
|
2004 Mar
|
anonymous
|
Parser
|
2004 Mar
|
|
4
|
4
|
DISTINCT aggregates
|
edit |
Attempting DISTINCT within aggregates generates syntax errors.
SELECT count(*), count(DISTINCT state) FROM ... |
See http://www.sqlite.org/omitted.html |
|
649 |
code
|
closed
|
2004 Mar
|
anonymous
|
Shell
|
2004 Mar
|
|
1
|
1
|
sqlite-2.8.12 segmentation fault in shell command-line usage
|
edit |
sqlite segfault if i use it in command-line, for example
sqlite db "select * from table"
my system is:
Acer Travelmate 313T
Slackware Linux 9.1
kernel 2.4.24
sqlite compiled from source with gcc and libs default included in slackware 9.1. I also tried sqlite.bin.gz and segfault too. 2.2.5 version compiled in same pc works fine. I will happy to provide you more info if needed.
Thanks for your work. |
Previously reported as ticket #642 and #620. Fixed by
check-in [1238]
. |
|
643 |
code
|
closed
|
2004 Mar
|
anonymous
|
Unknown
|
2004 Mar
|
|
3
|
2
|
local variable 'db' used without having been initialized
|
edit |
While compiling the .c files from sqlite_source.zip under Visual Studio .NET 2003, I noticed this error:
expr.c(456) : warning C4700: local variable 'db' used without having been initialized
And upon further investigation, I noticed that this was more than just an annoying warning message. The pointer variable 'db' is actually being derefenced without initialization:
if( zDb!=0 && sqliteStrICmp(db->aDb[pTab->iDb].zName, zDb)!=0 ){
continue;
This is from line 457 in expr.c.
Regards,
-Karthi. |
Already reported in #604, #612, #616, #629, and #630.
Fixed by check-in [1225]
. |
|
642 |
code
|
closed
|
2004 Mar
|
anonymous
|
Shell
|
2004 Mar
|
|
1
|
1
|
Problem when adding a SQL string on the command line - THIS IS REAL!!
|
edit |
When using the command-line version of "sqlite", if I add the SQL
string to the command line like this:
sqlite ex1 "select * from tblCandy"
I get a "Send Error Report" on Windows XP and a
"Segmentation Fault" under UNIX.
I looked into the problem and solved it myself by changing the
code in the "shell.c" file on UNIX. The 1st parameter to the
"sqlite_exec" call is "db". But when I changed it to "(&data)->db",
it worked on UNIX. Trouble is, I can't compile under Windows XP and
that's where I need it the most!
It looks like this error was already reported (#631), but got closed out when it was assumed that the user needed double quotes around the
SQL string parameter. I assure you ... there is a problem here!!!
It's not just the quotes and it happens only when a SQL string is
passed on the command line!!! |
Already fixed. See ticket #620 and check-in [1238]
.
2004-Mar-08 08:20:04 by anonymous:
you can compile shell.c in VC, but first delete the file"tclsqlite.c" |
|
639 |
event
|
closed
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
|
1
|
1
|
Why fixed tickets are not closed ?
|
edit |
Why fixed tickets are not closed ?
Bartosz |
Frivolous tickets like this one get closed....
2004-Mar-01 14:57:30 by anonymous:
To ask or not to ask ??
Bartosz. |
|
636 |
new
|
closed
|
2004 Mar
|
anonymous
|
Unknown
|
2004 Mar
|
|
1
|
1
|
Retaining autoincrement (Primary key) generated values
|
edit |
I need to
- re-create a table to add a column or remove a column (as there is no alter table)
- retain the data
- table has a primary key auto-increment column
Then I cannot keep the values.
A function to allow:
- turning off of auto-incremement
- then I do my insert of old table rows into new table
- and then turning back on auto-increment with a seed value (starting point)
would be the way to go.
As it stands I will lose these values otherwise. Any assistance you can give with this problem would be appreciated. |
SQLite already provides everything the complainant needs.
He just needs to read the documentation a little closer or
perhaps consult the mailing list for help. |
|
635 |
new
|
closed
|
2004 Feb
|
anonymous
|
|
2004 Mar
|
|
5
|
5
|
ROWID as ref. number
|
edit |
The ROWID is unusable as reference number.
- I create a list.
- I want to change the last item referenced with ROWID, and I start editing the record.
- Meanwhile somebody deletes the last record and makes a new one, BUT it's ROWID will be same as my record's.
- I finish editing, and post the changes, so I will overwrite somebody's fresh new record.
|
2004-Mar-01 01:34:35 by anonymous:
sqlite> create table tbl2 (
...> p text not null primary key,
...> i integer);
sqlite> insert into tbl2 values('a',1);
sqlite> insert into tbl2 values('b',2);
sqlite> insert into tbl2 values('c',3);
sqlite> insert into tbl2 values('d',4);
sqlite> select * from tbl2;
p i
---------- ----------
a 1
b 2
c 3
d 4
sqlite> select rowid from tbl2;
rowid
----------
1
2
3
4
sqlite> delete from tbl2 where p='d';
sqlite> insert into tbl2 values ('e',5);
sqlite> update tbl2 set i=10 where rowid=4;
sqlite> select * from tbl2;
p i
---------- ----------
a 1
b 2
c 3
e 10
sqlite>
2004-Mar-01 14:44:25 by drh:
The ROWID is not a Universally Unique ID (UUID). If you need
a UUID, generate one on your own and use that for your record
key. Use either uuid_generate() or UuidCreate() depending on
your operating system. |
|
632 |
doc
|
closed
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
2
|
2
|
fix links on wrappers page
|
edit |
On http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers please update the following text/links.
OLD TEXT: PHP driver for SQLite. (Official)
NEW TEXT: PHP 4 extension for SQLite. (Official)
NEW URI: http://pecl.php.net/package/SQLite
OLD TEXT: PHP PEAR abstraction for SQLite.
NEW TEXT: PEAR DB contains an interface for SQLite.
NEW URI: http://pear.php.net/package/DB
Thanks,
--Dan |
Anonymous users (such as you, Dan) are welcomed and encouraged
to edit the wiki pages. |
|
631 |
code
|
closed
|
2004 Feb
|
anonymous
|
Shell
|
2004 Feb
|
|
2
|
3
|
command line SQL paramater doesn't work on windows pre-compiled binary
|
edit |
Can't perform a sql command as a parameter to the command line. First example shows working internal select statement, second shows sqlite returns nothing.
G:\sqlite\sqlite>sqlite exl.db
SQLite version 2.8.12
Enter ".help" for instructions
sqlite> .tables
tbl1 tbl2
sqlite> select * from tbl1;
hello!|10
goodbye|20
Hew baby|30
test2|1234
sqlite> .quit
G:\sqlite\sqlite>sqlite exl.db 'select * from tbl1'
G:\sqlite\sqlite>
|
You have to use double-quotes, not single-quotes, on windows.
This is a windows thing. It has nothing to do with SQLite and
there is nothing that SQLite can do about it. |
|
630 |
code
|
closed
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
1
|
1
|
using uninitialized variable
|
edit |
compiler complains about using uninitialized variable in function
static int lookupName(
Parse pParse, / The parsing context /
Token *pDbToken, / Name of the database containing table, or NULL /
Token *pTableToken, / Name of table containing column, or NULL /
Token *pColumnToken, / Name of the column. /
SrcList *pSrcList, / List of tables used to resolve column names /
ExprList *pEList, / List of expressions used to resolve "AS" /
Expr *pExpr / Make this EXPR node point to the selected column */
) in file expr.c at line # 456, variable db isn't initialized.
if( zDb!=0 && sqliteStrICmp(db->aDb[pTab->iDb].zName, zDb)!=0 ){
continue;
|
2004-Feb-24 20:03:16 by drh:
Already reported in #604, #612, #616, and #629.
Fixed by [1225]
. |
|
629 |
code
|
closed
|
2004 Feb
|
anonymous
|
Parser
|
2004 Feb
|
|
3
|
3
|
Variable used without having been initialized
|
edit |
While compiling expr.c I get the following warning from Visual C++:
:\wolfpack\wolfpack\sqlite\expr.c(456) : warning C4700: local variable 'db' used without having been initialized
I've checked that db variable and it's created at the beginning of that function and never referenced again until that line where it's used in this way: db->aDb[pTab->iDb].zName
This is either dead code or a crash waiting to happen. |
Duplicate of ticket #604. Already fixed. |
|
628 |
code
|
closed
|
2004 Feb
|
anonymous
|
Pager
|
2004 Feb
|
|
1
|
3
|
Assertion failure in syncJournal
|
edit |
An assertion failure happens when using cscvs. cscvs is a CVS analysis tool, written in Python, which uses sqlite to store information about CVS "changesets".
[Yes, yes, I know: this bug report system is not for cscvs nor the Python binding for sqlite. I'm making the report based on the principle that assertions should not fail in shipping library code. There shouldn't be anything a poorly-written client code (interpreter binding, or a script that uses that binding) can do to make an assertion fail. If the client code does something wrong, it should be an error, not an assertion failure. If sqlite uses assertions for error messages, well, I don't agree with that, but I've filed this bug report in error. Sorry!]
The basics: the assertion failure happens when using "cscvs cache -b" to create a new database of CVS changesets. The text output is:
python: src/pager.c:1168: syncJournal: Assertion `!pPager->noSync' failed.
Some software versions: I'm using Debian GNU/Linux unstable, recently updated. "sqlite -version" gives 2.8.12. The python binding is version 0.4.3. Python itself is at 2.3.3. The cscvs tool can be found here:
http://wiki.gnuarch.org/moin.cgi/cscvs
I'm using the latest version (cscvs--experimental--1.1--patch-79). The CVS repository I'm using is for the MediaWiki software (http://wikipedia.sourceforge.net/), but I seem to get the same error on any CVS repository I try.
I realize this is a terribly annoying bug report, but I figured assertion failures are a big deal, so you'd want to know. I don't like Python, and I don't really care all that much about sqlite. I just figured it's only decent to send in a bug report if you find a problem. |
2004-Feb-24 15:50:31 by anonymous:
OK, so, this seems to be entirely dependent on ticket #615. cscvs uses the synchronous pragma in the middle of a transaction with create table statements in it. Removing the pragma stops the assertion failure.
2004-Feb-24 18:44:58 by drh:
This is the same problem as ticket #615. |
|
625 |
code
|
closed
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
1
|
1
|
CORE DUMPED when running sum() in DBD::SQLite
|
edit |
The following has the perl script I used to test some function with DBD::SQLite. It turns out to be CORE DUMPED. I really have no idea why!? I can use count(*) min() max() but sum() avg() will result in CORE DUMPED BUS ERROR.
Thanks for your help
$ pico dbi_err.pl
UW PICO(tm) 4.2 File: dbi_err.pl Modified
#!/usr/bin/perl -w
#
# ch04/error/ex2: Small example using automatic error handling with
# RaiseError, i.e., the program will abort upon detection
# of any errors.
use DBI; # Load the DBI module
my ($dbh, $sth, @row, $h);
### Perform the connection using the Oracle driver
$dbh = DBI->connect( "dbi:SQLite:sqlite_db/foo.db", "", "", {
PrintError => 0, ### Don't report errors via warn( )
RaiseError => 1 ### Do report errors via die( )
} );
my $version= $dbh->{sqlite_version};
print "The SQLite lib version is $version\n";
### Prepare a SQL statement for execution
$sth = $dbh->prepare( "SELECT name, sum(day) from modules group by name " );
### Execute the statement in the database
$sth->execute( );
### Retrieve the returned rows of data
while ( @row = $sth->fetchrow_array( ) ) {
print "Row: @row\n";
}
### Disconnect from the database
$dbh->disconnect( );
exit;
[ Wrote 35 lines ]
$ perl dbi_err.pl
The SQLite lib version is 2.8.12
Bus Error - core dumped |
Since this appears to work with the core SQLite library, it
appears to be some kind of DBD::SQLite problem. You should
perhaps report the bug there. This site only deals with the
core SQLite library. |
|
624 |
new
|
closed
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
1
|
1
|
SQLite transaction...
|
edit |
Hello,
I am using SQLite database as my local database i.e. I am importing
data from SQL server or any other database. While writing the data in SQLite database all the inserts are put into a transaction.
e.g.
BEGIN;
Insert into table.. 1st row
Insert into table.. 2nd row
.
.
.
Insert into table.. 30 thousand row.
COMMIT;
For about first 5 to 6 thousand records it works pretty fast but after that the speed slows down and after importing 10 thousand records it becomes very slow.
Is there any solution to overcome this problem?
Thanks,
|
2004-Feb-23 12:16:53 by anonymous:
This is definitely the wrong place to ask this question. Please post requests like such to the SQLite - Mailing - List (refer to section Mailing List at http://www.sqlite.com for futher instructions!!)
2004-Feb-23 13:14:57 by drh:
The anonymous poster above is correct. This is where you report
bugs, not ask questions about usage and performance. |
|
619 |
code
|
closed
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
1
|
1
|
Multiple BEGIN and COMMIT transaction problem...
|
edit |
While doing multiple trnsactions the first transaction is pretty fast but all the following are becoming slow.
e.g.
BEGIN;
Insert Into...1st record
Insert Into...2nd record
.
.
Insert Into...1000 record
COMMIT;
this transaction takes only 4 to 5 seconds
but again doing the same
BEGIN;
Insert Into...1001th record
Insert Into...1002nd record
.
.
Insert Into...2000 record
COMMIT;
takes more time than the first one.
multiple BEGIN & COMMIT transactions on the same database are required because at any time I want append the data to SQLite table. |
Inserting data into an existing database takes more work
(and more time) than adding data to a previously empty
database. This is not a code defect. |
|
618 |
code
|
closed
|
2004 Feb
|
anonymous
|
Unknown
|
2004 Feb
|
|
3
|
3
|
fails test btree-1.1.1
|
edit |
Macintosh G4 Desktop 867MHZ DP
OSX 10.3.2, gcc 3.3
Built from package sqlite-2.8.12.tar.gz
When running test via "make test", run ends with error
btree-1.1.1...../sqlite/src/btree.c:2689: failed assertion `pPage->isInit'
make: *** [test] Abort trap |
Duplicate of tickets #376 and #369 |
|
616 |
code
|
closed
|
2004 Feb
|
anonymous
|
VDBE
|
2004 Feb
|
|
1
|
1
|
variable 'db' is not initialized before being used (expr.c line 418)
|
edit |
Compiling your most excellent sqlite 2.8.12 with CodeWarrior 8.3. It appears that in the function 'lookupName' the local variable 'db' is never set, but it is used.
I'm guessing that expr.c line 418 should be:
sqlite *db = pParse->db;
|
This is a duplicate of ticket #604 which has already been fixed. |
|
607 |
code
|
closed
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
1
|
1
|
odbc doesn't like field name date
|
edit |
change field name to something like eventdate and it works |
This site covers the SQLite core only - not the ODBC driver. |
|
606 |
code
|
closed
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
1
|
1
|
odbc doesn't like datetime type - returns a null
|
edit |
change types to time or date and it will work |
This site covers the SQLite core only - not the ODBC driver. |
|
600 |
code
|
closed
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
1
|
1
|
unable to open database file, win32, Java jdbc
|
edit |
Using sqlite 2.8.3, windows 2000, Java JDBC, I get an exception: "unable to open database file". It happens during the use of the database, when tring to insert a large amount of data. It is done under a transaction. The same problem does not occur under linux. |
Please report this problem to the developer of the JDBC driver. |
|
598 |
code
|
closed
|
2004 Feb
|
anonymous
|
|
2005 Jan
|
|
1
|
4
|
Joins not supported in DELETE
|
edit |
Given 2 tables 'foo' and 'bar', both having an 'id' column to join on, the following simple query fails:
DELETE FROM foo WHERE foo.id = bar.id
with the error "no such column: bar.id". Hence, no joins seem possible in a DELETE (barring use of a subselect)! :-/ |
2004-Feb-06 15:32:44 by anonymous:
This bug is also in the latest version, 2.8.11.
2004-Feb-08 06:18:55 by drh:
Is this a bug or a feature request? Does ANSI SQL allow joins
in a delete?
2004-Feb-17 04:28:40 by anonymous:
It appears to be SQL-89 "implicit join", not ANSI SQL. |
|
597 |
code
|
closed
|
2004 Feb
|
anonymous
|
Unknown
|
2004 Feb
|
|
3
|
2
|
SELECT * FROM TB_LINFPSP_CONFIG WHERE LINFPSP_CUST_CODE='HBC'
|
edit |
Hi,
I have created a database called LINFPSP_CONFIG.db and then created a table in it called TB_LINFPSP_CONFIG with the structure
CREATE TABLE TB_LINFPSP_CONFIG (LINFPSP_id integer primary key not null, LINFPSP_KEY varchar(200), LINFPSP_VALUE varchar(200), LINFPSP_CUST_CODE varchar(100))
It has following data
1, cust_in_dir_path, c:\projects\test, HBC
1, cust_out_dir_path, c:\projects\test, HBC
When I run the query
SELECT * FROM TB_LINFPSP_CONFIG WHERE LINFPSP_CUST_CODE='HBC'
It returns 0 rows.
But when I run query
SELECT * FROM TB_LINFPSP_CONFIG WHERE LINFPSP_CUST_CODE like 'HBC'
It returns both rows. There is no extra whit space after HBC.
When I run the query
SELECT * FROM TB_LINFPSP_CONFIG WHERE LINFPSP_KEY="cust_in_dir_name"
It returns a proper one row.
I tried recreating the database many times but still the same error. I think its a bug.
Thanks
with best regards,
Vikrant |
It is not possible that the data described above could be in the
table described above because the primary key is not unique.
If you still think you are seeing a problem, attach a script that
can be run using the sqlite shell and which reproduces the problem
exactly.
User error. No changes to code. |
|
596 |
code
|
closed
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
1
|
1
|
sqlite_exec OR sqlite_get_table can not handle empty results sets
|
edit |
c++ api
the char** results can not be influenced by the application programmer (f.ex. initialized) and
given a certain content for testing later.
If the result set is empty (and the PRAGMA for empty callbacks is ON) as
it is in an empty table.
f.ex. SELECT max(id) FROM customer;
trying to get the value out of results[0] ==> segmentation fault.
Can't work around that bug (it is present in sqlite_get_table and in sqlite_exec).
Except not using the api.. but what is it goor for then?! |
See documentation on the empty_result_callbacks pragma.
Works as designed. No changes to code. |
|
595 |
code
|
closed
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
1
|
4
|
Big joins dont work as I expect
|
edit |
I have a db about 490Mb in size with 3 big tables with 97,000 rows.
These are patient, accn (episode) and rpt. All have a key called pnumber (content looks like '03B1234'). Report has a big field report containing 2-4K of HTML.
This works:
SELECT patient.surname, rpt.labno,accn.requested, rpt.summary from rpt,accn,patient where patient.pnumber = accn.pnumber and rpt.pnumber = accn.pnumber LIMIT 100;
SELECT patient.surname, rpt.labno,accn.requested, rpt.summary from rpt,accn,patient where patient.pnumber = accn.pnumber and rpt.pnumber = accn.pnumber and rpt.report like '%carcinoma%' LIMIT 100;
I start getting all sorts of duplicate rows and some of the data seems incorrect. ?buffer overflow or something.
Version 2.8.11. (It was worse with older version when the simple join without a where statement would generate duplicaes, partially improved by a DISTINCT clause). Could I have an old DLL around?
Is my database too big? (I want to quadruple it, too).
Especially since I use python pysqlite. I dont really understand where Win XP on my work computer might put dlls. |
In sufficient data to reproduce. The report above does not
provide a schema nor does it provide examples of incorrect output. |
|
589 |
new
|
closed
|
2004 Jan
|
anonymous
|
Shell
|
2005 Sep
|
|
5
|
4
|
HTML tags in shell.c should be lower case
|
edit |
If you are going to call it XHTML,
case MODE_Html: {
if( p->cnt++==0 && p->showHeader ){
fprintf(p->out,"");
for(i=0; i<nArg; i++){
fprintf(p->out,"%s | ",azCol[i]);
}
fprintf(p->out," \n");
}
if( azArg==0 ) break;
fprintf(p->out,"");
for(i=0; i<nArg; i++){
fprintf(p->out,"");
output_html_string(p->out, azArg[i] ? azArg[i] : p->nullvalue);
fprintf(p->out," | \n");
}
fprintf(p->out," \n");
break;
}
should (according to W3C ) really be like this:
case MODE_Html: {
if( p->cnt++==0 && p->showHeader ){
fprintf(p->out,"");
for(i=0; i<nArg; i++){
fprintf(p->out,"%s | ",azCol[i]);
}
fprintf(p->out," \n");
}
if( azArg==0 ) break;
fprintf(p->out,"");
for(i=0; i<nArg; i++){
fprintf(p->out,"");
output_html_string(p->out, azArg[i] ? azArg[i] : p->nullvalue);
fprintf(p->out," | \n");
}
fprintf(p->out," \n");
break;
}
|
2004-Jan-31 00:28:35 by anonymous:
Sorry, the tags disappeared from the description. Let me try again:
case MODE_Html: {
if( p->cnt++==0 && p->showHeader ){
fprintf(p->out,"<tr>");
for(i=0; i<nArg; i++){
fprintf(p->out,"<th>%s</th>",azCol[i]);
}
fprintf(p->out,"</tr>\n");
}
if( azArg==0 ) break;
fprintf(p->out,"<tr>");
for(i=0; i<nArg; i++){
fprintf(p->out,"<td>");
output_html_string(p->out, azArg[i] ? azArg[i] : p->nullvalue);
fprintf(p->out,"</td>\n");
}
fprintf(p->out,"</tr>\n");
break;
}
2005-Sep-08 01:00:53 by anonymous:
Duplicate of ticket #450 |
|
586 |
code
|
closed
|
2004 Jan
|
anonymous
|
|
2004 Jan
|
|
2
|
1
|
Memory allocation problem ?
|
edit |
Hi,
if sqlite can't allocate memory then sets sqlite_malloc_failed variable. The comment says that, if malloc only once fails that sqlite is unusable. Is that true ? What should I do in that case ?
thx for help
/*
** If malloc() ever fails, this global variable gets set to 1.
** This causes the library to abort and never again function.
*/ |
This is a question for the mailing list, not a bug.
Works as designed. No changes to code. |
|
585 |
code
|
closed
|
2004 Jan
|
anonymous
|
|
2004 Jan
|
|
1
|
1
|
sqlite is not thread safe
|
edit |
Hi,
I just downloaded the latest version of sqlite. In documentation I've read that sqlite is thread safe. But in file util.c, linie 27 is declared the global variable:
int sqlite_malloc_failed = 0;
This is not thread safe for me.
sqlite_malloc_failed variable is used in many parts of code.
Could You comment this ?
ps. sorry for my terrible english |
The only thing that can happen to the sqlite_malloc_failed
variable is that it can get set to 1. After being set to
1, it is never set back to 0 again. This is threadsafe even
outside of a mutex. |
|
584 |
new
|
closed
|
2004 Jan
|
anonymous
|
|
2004 Jan
|
anonymous
|
5
|
1
|
Cursor support in SQLite
|
edit |
hi
I am using the sqlite vb wrapper in my application i need to know urgently if cursors are supported by sqlite and if yes how should i use it. |
This is a question for the mailing list. |
|
581 |
code
|
closed
|
2004 Jan
|
anonymous
|
Parser
|
2004 Jan
|
|
3
|
1
|
Failure for lemon.c to compile on MacOSX (fixed as well ;-))
|
edit |
Hi,
When compiling on MacOSX 10.3.2 (Panther) I get the following error,
In file included from ../tool/lemon.c:10:
/usr/include/gcc/darwin/3.3/varargs.h:10:2: #error "GCC no longer implements <varargs.h>."
/usr/include/gcc/darwin/3.3/varargs.h:11:2: #error "Revise your code to use <stdarg.h>."
I updated lemon.c to use stdargs as requested. First use of stdargs so I hope I got it right. The diff is small,
[aid:~/tmp] aid% diff lemon-orig.c lemon.c
10c10
< #include <varargs.h>
---
> #include <stdarg.h>
73c73
< void ErrorMsg( /* char , int, char *, ... */ );
---
> void ErrorMsg(char * filename, int lineno, char * format, ... );
1105,1106c1105
< void ErrorMsg(va_alist)
< va_dcl
---
> void ErrorMsg(char * filename, int lineno, char * format, ... )
1108,1110d1106
< char *filename;
< int lineno;
< char *format;
1119,1122c1115
< va_start(ap);
< filename = va_arg(ap,char);
< lineno = va_arg(ap,int);
< format = va_arg(ap,char*);
---
> va_start(ap,format);
All seems to compile now. Unfortantely I don't have another OS (eg. Linux) here to check if it is compatible.
Regards,
aid |
This is a duplicate of tickets #280 and #288.
The problem was fixed by check-in [905]
on 2003-Apr-15
for SQLite version 2.8.1. |
|
580 |
code
|
closed
|
2004 Jan
|
anonymous
|
VDBE
|
2004 Jan
|
|
2
|
3
|
Incorrect Select when specifying same field value as column name
|
edit |
Select statement gives incorrect results when specifying same field value as column name with the "=", "<", ">", "<>" operators.
Test:
sqlite> create table test (name varchar);
sqlite> insert into test (name) values ("a");
sqlite> insert into test (name) values ("name");
sqlite> insert into test (name) values ("test1");
sqlite> insert into test (name) values ("test2");
sqlite> select * from test;
a
name
test1
test2
sqlite> select * from test where name = "name";
a
name
test1
test2
sqlite> select * from test where name < "name";
(no results)
sqlite> select * from test where name > "name";
(no results)
sqlite> select * from test where name <> "name";
(no results)
sqlite> select * from test where name like "name";
a
name
test1
test2
sqlite> select * from test where name like "name%";
name
vdbe explain:
sqlite> explain select * from test where name = "name";
0|ColumnName|0|0|name
1|Integer|0|0|
2|OpenRead|0|3|test
3|VerifyCookie|0|276|
4|Rewind|0|11|
5|Column|0|0| <===== ????!!!!
6|Column|0|0|
7|StrNe|1|10|
8|Column|0|0|
9|Callback|1|0|
10|Next|0|5|
11|Close|0|0|
12|Halt|0|0|
sqlite> explain select * from test where name like "name%";
0|ColumnName|0|0|name
1|Integer|0|0|
2|OpenRead|0|3|test
3|VerifyCookie|0|276|
4|Rewind|0|12|
5|String|0|0|name%
6|Column|0|0|
7|Function|2|0|ptr(0x451f40)
8|IfNot|1|11|
9|Column|0|0|
10|Callback|1|0|
11|Next|0|5|
12|Close|0|0|
13|Halt|0|0|
How to specify "name" is a value and not a column name?
Also, any plans to implement sorting in a temp table on disk? (grouping consumes a lot of RAM with large recordsets. |
Strings in double-quotes (") resolve to column names if they
can, then to string literals. Use single-quotes (') if you want
the constant to always be a string literal.
Works as designed. No changes to code. |
|
579 |
code
|
closed
|
2004 Jan
|
anonymous
|
|
2004 Jan
|
|
3
|
1
|
condition where sqlite_decode_binary will return -1
|
edit |
Hi. Others have reported that sometimes sqlite_decode_binary can fail. I understand it is not part of the official distribution, but I believe lots of people are using it.
I had some data where I could reproduce this behavior, as sqlite_decode_binary was sometimes returning -1 after decoding the whole file.
The strange part is that with EXACTLY the same data input it will fail sometimes, and not others. I can not explain the situation. Maybe it is caused by compiler optimizations and/or rounding in buffer allocation of the input stream? I saw this on Linux (Slackware 9) and also on Windows XP, always decoding the same data.
Below is the revised version that catches this condition in my tests:
/*original version until the next comment*/
int sqlite_decode_binary(const unsigned char *in, unsigned char *out){
int i, c, e;
int s = strlen(in);
e = *(in++);
i = 0;
while( (c = *(in++))!=0 ){
if( c==1 ){
c = *(in++);
if( c==1 ){
c = 0;
}else if( c==2 ){
c = 1;
}else if( c==3 ){
c = '\'';
}else{
/*here is the problem: it is possible to get here if the
length of your data is uneven and have c with a pixel
value of 0. See that it is not tested above. In my tests
when this happens is always at the end of the decoded
data , so I added the simple assignment below:*/
if (c==0){
return i;
}
/*below here is original code*/
return -1;
}
}
out[i++] = (c + e)&0xff;
}
return i;
}
Now, I am not sure if the problem is really here OR in the encoder, since it is strange that the last character in the data stream is 1, followed by a 0. Does the above makes sense to you? Contact me if you need more information. The fact is that with this fix I no longer get this condition, strange as it sounds. |
sqlite_decode_binary() returns -1 if it receives an ill-formed
input string. This is by design. The change suggested above is
rejected.
If there is a problem here, the problem is with sqlite_encode_binary().
But without additional information (such as a string that
sqlite_encode_binary() encodes incorrectly) there is nothing I
can do to troubleshoot the problem.
No changes to code. |
|
578 |
code
|
closed
|
2004 Jan
|
anonymous
|
|
2004 Feb
|
|
4
|
2
|
calling isdigit in sqliteIsNumber cause asserts (VC.NET)
|
edit |
If database contains characters with code >= 0x80, then any SELECT cause hundreds of asserts in isctype.c (68) (VC.NET).
As solution, I suggests casting char to unsigned char before calling isdigit in sqliteIsNumber function as shown here:
isdigit((unsigned char)*z);
|
2004-Feb-25 02:36:00 by drh:
I believe this is a bug in VC.NET. The problem should be fixed
there.
2004-Feb-26 20:49:40 by anonymous:
I shall not argue :)
However, correction of this error in CRT VC.NET is very problematic and is non portable - it is necessary to recompile the standard library for this purpose...
And, if you'll look at a code in util.c it is possible to see already available castings:
h = (h<<3) ^ h ^ UpperToLower[(unsigned char)*z++];
a = (unsigned char *)zLeft;
b = (unsigned char *)zRight;
etc...
Why not to insert a little more? ;) |
|
571 |
code
|
closed
|
2004 Jan
|
anonymous
|
Unknown
|
2004 Jan
|
|
1
|
1
|
Execution of comment via sqlite_step raise Access violation
|
edit |
Execution of following script via sqlite_step raise Access violation:
DROP TABLE products;
--This comment raise exception |
Works fine when I try it.
Probably what happened is that there is no table named "products"
in your database. Your call to sqlite_compile() failed and set
the VM pointer to NULL. If you did not to check for the error that
sqlite_compile() returns and passed the NULL pointer into
sqlite_step(), then the sqlite_step() function my segfault
when it tries to dereference the NULL pointer.
Unable to reproduce. No changes to code. |
|
570 |
event
|
closed
|
2004 Jan
|
anonymous
|
|
2004 Jan
|
|
5
|
5
|
database created on x86 can't work on arm
|
edit |
The version of sqlite i am using is 2.8.6. I created the database on x86, then add some data into the database. It worked well on x86. But when i moved it onto the Intel Xscale 255 (also Linux), it returned error (no such table 'XXX') when read from the database. |
(comment by Justin Fletcher <justin.fletcher@ntlworld.com>, not the original poster)
I have transferred databases created on x86 linux by sqlite 2.8.6 and used them happily on RISC OS (ARM) using sqlite 2.8.9, so I don't personally believe that this is a specifically an ARM problem.
Perhaps some kind of NL->NLCR translate occurred when moving the
database from one machien to the other. Did you verify the md5
checksum after the move to make sure the file had not changed?
For whatever reason, I am unable to duplicate this problem. I've
moved massive databases from big-endian to little-endian machines
and back again without problems. |
|
562 |
code
|
closed
|
2004 Jan
|
anonymous
|
Unknown
|
2004 Jan
|
|
2
|
3
|
System needs to rename duplicate named columns.
|
edit |
If you execute a query with multiple columns and two or more of the columns resolve to the same column name it crashes the system.
Ex:
Select 1,1 |
Works fine on 2.8.9. |
|
559 |
code
|
closed
|
2004 Jan
|
anonymous
|
Unknown
|
2004 Jan
|
|
1
|
1
|
Very slow insert into ... under Win2K
|
edit |
The following code needs 40 secs for 1000 inserts. CPU usage in Task manager is alway in the range 0..5% !!!
System: P4 2.66, 512 MB, Win2K, MS VC/C++ 6.0 SP5
void CTestDlg::OnTest()
{
sqlite *db; /* SQLITE.DLL VERSION 2.8.9 */
db = sqlite_open("d:\\test.dbl", 0, NULL);
if (db) {
int nErr = sqlite_exec(db,
"create table data(one varchar(10), two smallint)",
NULL, NULL, NULL);
if (nErr == 0) {
for (int n = 0; n < 1000; n++) {
nErr = sqlite_exec(db,
"insert into data values('hello!', 10)",
NULL, NULL, NULL);
if (nErr != 0)
break;
}
}
sqlite_close(db);
}
}
|
This is an operating system problem, not an SQLite problem.
Suggested workarounds:
- Enclose all INSERTs within BEGIN and COMMIT.
- Use "PRAGMA synchronous=off"
|
|
557 |
code
|
closed
|
2004 Jan
|
anonymous
|
Unknown
|
2004 Jan
|
|
3
|
1
|
sqlite_close SQLITE_MAGIC_ERROR reply.
|
edit |
I dont understand why you want me to provide some code, I'm using the version 2.8.8 and i make a normal call to sqlite_close using the Dll.
the if in bold always return true. So it never close the database. So keep eating memory each time i connect to a new database.
I dont have make any change into the original code. i just notice this problem.
void sqlite_close(sqlite *db){
HashElem *i;
int j;
db->want_to_close = 1;
if( sqliteSafetyCheck(db) || sqliteSafetyOn(db) ){
/* printf("DID NOT CLOSE\n"); fflush(stdout); */
return;
}
........
Ticket 554: sqlite_close SQLITE_MAGIC_ERROR
I open a database using sqlite_close. and even if i call sqlite_close right after, the variable db->magic is already set to SQLITE_MAGIC_ERROR when entering the function. So the call to sqliteSafetyOn(db) always fails.
do you have any clues ?
thanks JP.
Remarks:
No clues.
Because no code was provided, nothing can be done to troubleshoot. This ticket is therefore closed without action.
|
It appears that sqlite_close() is being called while there are
still outstanding VMs (VMs that have not been sent to sqlite_finalize())
or perhaps from callback of sqlite_exec(). sqlite_close() is doing
the right thing, which is to make a notation to delete itself after
all operations currently in progress complete.
Works as designed. No changes to code. |
|
556 |
warn
|
closed
|
2004 Jan
|
anonymous
|
CodeGen
|
2004 Jan
|
|
3
|
4
|
double to int warnings in date.c
|
edit |
lot of double to int warnings in date.c
why not use this
long DateToJulian(int year, int month, int day)
{
if (month > 2) month -= 3; else { month += 9; year--; }
long ta = (146097L * (year / 100)) / 4;
long tb = ( 1461L * (year % 100)) / 4;
long tc = (153L * month + 2) / 5 + day + 1721119L;
return (ta + tb + tc);
}
void JulianToDate(long j, int& year, int& month, int& day)
{
long x, y, d, m;
x = 4 * j - 6884477L;
y = (x / 146097L) * 100;
d = (x % 146097L) / 4;
x = 4 * d + 3;
y += (x / 1461);
d = (x % 1461) / 4 + 1;
x = 5 * d - 3;
m = (x / 153) + 1;
d = (x % 153) / 5 + 1;
month = (m < 11) ? (int) (m + 2) : (int) (m - 10);
day = (int) d;
year = (int) (y + m / 11);
}
|
There are two reasons for not using the code samples shown
above:
- The examples assume an integer julian day. Dropping
the fractionaly part of the julian day number would
loose the hours, minutes, and seconds.
- The code above is C++. SQLite is written in C.
|
|
555 |
code
|
closed
|
2004 Jan
|
anonymous
|
VDBE
|
2004 Jan
|
|
1
|
1
|
sqlite_step and sqlite_compile cause locking problem
|
edit |
I may just be mis-understanding how I am supposed to use the sqlite_step interfaces, but it makes little sense to me. (I am using visual C++ 6.0 to compile sqlite). Psudocode follows:
#1
I open a connection to the database-
pConnection = sqlite_open(sDBPath,0,NULL);
#2
I compile a query into a vm:
pConnection,"SELECT ROWID,* FROM test_table",&query_tail,&m_pVM,NULL);
#3
Step through some records....
#4
Open another connection to the same database
pConnection2 = sqlite_open(sDBPath,0,NULL);
#5 try to update test_table using sqlite_exec
-database_locked
#6 try to update test_table using the first connection
-database_locked
if I finalize the vm-
-sqliteok
I am very curious over this - how is one supposed to use the step
interface if at all times a vm is not finalized it locks the table?
Any help would be greatly appreciated. |
Code works as documented and designed.
Refer questions on operation to the mailing list. |
|
554 |
code
|
closed
|
2004 Jan
|
anonymous
|
Unknown
|
2004 Jan
|
|
3
|
1
|
sqlite_close SQLITE_MAGIC_ERROR
|
edit |
I open a database using sqlite_close. and even if i call sqlite_close right after, the variable db->magic is already set to SQLITE_MAGIC_ERROR when entering the function. So the call to sqliteSafetyOn(db) always fails.
do you have any clues ?
thanks JP. |
No clues.
Because no code was provided, nothing can be done to troubleshoot.
This ticket is therefore closed without action. |
|
553 |
code
|
closed
|
2004 Jan
|
anonymous
|
Pager
|
2004 Jan
|
|
2
|
2
|
conversion error in compiling pager.c
|
edit |
Excuse me if this is not a bug and I am doing something wrong. This is my first attempt at using SQLITE.
I downloaded the source and when I tried to build in Metrowerks Code Warrior, version 4.2.5.766, I got the following error in pager.c:
Error : illegal implicit conversion from 'int *' to
'unsigned int *'
pager.c line 598 rc = read32bits(format, &pPager->jfd, &nRec);
Since I am not a C programmer (yet), I did not try to fix it. I just commented out the line, and then everything went OK.
But I suspect things will break with this line commented out. |
I don't know if it is allowed for me to comment on this, but if you cast to (u32*) it will compile. So the line would look like this:
rc = read32bits(format, &pPager->jfd, (u32*)&nRec);
Of course, nRec is an int, so I'm not sure how safe that cast really is. |
|
549 |
code
|
closed
|
2004 Jan
|
anonymous
|
Shell
|
2004 Jan
|
|
1
|
1
|
number of week change in wendesday/thursday
|
edit |
i want search days in one week, but the weeks start on thursday...? |
This appears to be a question, not a bug report. |
|
547 |
code
|
closed
|
2004 Jan
|
anonymous
|
TclLib
|
2005 Jan
|
|
3
|
4
|
tcl array not cleared between queries
|
edit |
If the same tcl array (hash table) is used for successive queries, column data are overwritten but never deleted; so the array may contain data for columns that do not apear in the current query. This is perhaps not too serious, since the entry for the key "*" correctly specifies the current columns.
On the other hand, if pragma show_datatypes is ON, the type entries in the array can grow with each query, since the type info is appended without clearing the previous value. This can have a noticeable effect on execution time.
A brief example using the std supplier/parts database:
% sqlite db sp
% db eval {pragma show_datatypes = on}
% db eval {select pno from sp where sno='S3'} h {parray h}
h(*) = pno
h(pno) = P2
h(typeof:pno) = char(2)
% db eval {select pno from sp where sno='S3'} h {parray h};#repeat
h(*) = pno
h(pno) = P2
h(typeof:pno) = char(2) char(2) ;# oops
% db eval {select sno from sp where pno='P6'} h {parray h} ;#new
h(*) = sno ;# correct
h(pno) = P2 ;# left over from previous query
h(sno) = S1
h(typeof:pno) = char(2) char(2) ;# left over from previous query
h(typeof:sno) = char(2)
|
2005-Jan-03 01:47:09 by drh:
This is by design. Use the TCL unset command if you want to
clear the array. |
|
546 |
code
|
closed
|
2004 Jan
|
anonymous
|
Pager
|
2004 Jan
|
|
3
|
3
|
(Program received signal SIGSEGV) when sqlite_open()
|
edit |
sqlites[0].db = sqlite_open( sqlites[0].dbname, 0, &(sqlites[0].errmsg) );
no malloc() to errmsg.
this full source no errors in Mac OS X.3
but 2 RedHat 7.3 machines make crash
strace
[pid 1941] getcwd("/work/root/board", 5000) = 17
[pid 1941] open("/work/root/board/board_1", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 7
[pid 1941] fstat64(7, {st_mode=S_IFREG|0644, st_size=11628544, ...}) = 0
[pid 1941] --- SIGSEGV (Segmentation fault) ---
[pid 1940] <... poll resumed> [{fd=5, events=POLLIN}], 1, 2000) = -1 EINTR (Interrupted system call)
[pid 1940] --- SIGRT_1 (Real-time signal 1) ---
[pid 1940] sigreturn() = ? (mask now ~[TRAP KILL STOP])
[pid 1940] getppid() = 1939
[pid 1940] wait4(-1, [WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV], WNOHANG|__WCLONE, NULL) = 1941
[pid 1940] munmap(0xbf600000, 2097152) = 0
[pid 1940] kill(1939, SIGSEGV) = 0
[pid 1940] _exit(0) = ?
<... poll resumed> [{fd=3, events=POLLIN}], 1, 1000) = -1 EINTR (Interrupted system call)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
GDB result
[root@linux board]# gdb ./board
GNU gdb Red Hat Linux (5.2-2)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run
Starting program: /work/root/board/board
[New Thread 1024 (LWP 1914)]
[New Thread 2049 (LWP 1921)]
[New Thread 1026 (LWP 1922)]
THREAD START
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1026 (LWP 1922)]
0x4012802f in chunk_alloc () from /lib/libc.so.6
(gdb) bt
#0 0x4012802f in chunk_alloc () from /lib/libc.so.6
#1 0x401279d0 in malloc () from /lib/libc.so.6
#2 0x40092461 in sqliteMalloc (n=8462) at ./src/util.c:254
#3 0x4008540d in sqlitepager_open (ppPager=0x8a7833c, zFilename=0x804cfe8 "board_1", mxPage=2000, nExtra=280, useJournal=1) at ./src/pager.c:857
#4 0x4007001e in sqliteBtreeOpen (zFilename=0x804cfe8 "board_1", omitJournal=0, nCache=2000, ppBtree=0x8a7820c) at ./src/btree.c:711
#5 0x40083a61 in sqliteBtreeFactory (db=0x8a78200, zFilename=0x804cfe8 "board_1", omitJournal=0, nCache=2000, ppBtree=0x8a7820c) at ./src/main.c:1036
#6 0x40082d95 in sqlite_open (zFilename=0x804cfe8 "board_1", mode=0, pzErrMsg=0x804cc74) at ./src/main.c:447
#7 0x08049f79 in find_sqlite_pool ()
#8 0x080495b6 in query_cache_check ()
#9 0x08049528 in request_parse ()
#10 0x0804929f in proc ()
#11 0x40035f77 in pthread_start_thread () from /lib/libpthread.so.0
(gdb)
package info
[root@linux board]# rpm -qa | grep glibc
glibc-utils-2.2.5-44
glibc-2.2.5-44
glibc-common-2.2.5-44
glibc-debug-static-2.2.5-44
glibc-debug-2.2.5-44
glibc-kernheaders-2.4-7.16
glibc-devel-2.2.5-44
compat-glibc-6.2-2.1.3.2
glibc-profile-2.2.5-44
[root@linux board]# rpm -qa | grep gcc
gcc-chill-2.96-113
gcc-2.96-113
gcc-objc-2.96-113
gcc-java-2.96-113
gcc-c++-2.96-113
gcc-g77-2.96-113
[root@linux board]# cat /etc/redhat-release
Red Hat Linux release 7.3 (Valhalla)
threadsafe compiled, sqlites(sqlite db pool) global variable
|
Diagnosis:
Some other part of the user's
program that is linking against
SQLite has corrupted the malloc() memory pool.
This is not a problem in SQLite - it is a problem
in the program that is calling SQLite.
Rational:
- It is common for glibc to segfault inside chunk_alloc() after
memory corruption.
- Hundreds or thousands of people are using sqlite_open() without
any problems.
- The memory allocation system for SQLite is extensively
instrumented and tested with over 90% code coverage without
any hint of this problem.
No changes to code. |
|
543 |
new
|
closed
|
2003 Dec
|
anonymous
|
|
2003 Dec
|
|
5
|
4
|
Feature Request: Indicate NOT NULL columns in table_info.
|
edit |
It would be neat if there were a new column added to table_info that indicated which columns of a table were NOT NULL. |
The fourth column of the results set from the table_info pragma is
non-zero for NOT NULL columns. |
|
537 |
code
|
closed
|
2003 Dec
|
anonymous
|
VDBE
|
2003 Dec
|
|
1
|
2
|
Problems using sqlite_bind() with INSERT INTO ... SELECT statements
|
edit |
Precompiled INSERT INTO ... SELECT statements which use sqlite_bind() to insert values seem to fail. Attached is a simple test program to demonstrate.
I'm more than a little rusty with SQL, and new to sqlite, so it's entirely possible I'm doing this the wrong way. :)
#include <assert.h>
#include <stddef.h>
#include <sqlite.h>
int main (void)
{
static const char * FILENAME = "/tmp/test.sqlite";
int tmp;
int sqlstate;
sqlite * db = NULL;
sqlite_vm * pVm = NULL;
/* create a new database */
unlink (FILENAME);
db = sqlite_open (FILENAME, 1, NULL);
sqlstate = sqlite_exec (db, "CREATE TABLE department ( name TEXT NOT NULL );", NULL, NULL, NULL);
assert (SQLITE_OK == sqlstate);
sqlstate = sqlite_exec (db, "CREATE TABLE professor ( name TEXT NOT NULL, department_id INTEGER NOT NULL );", NULL, NULL, NULL);
assert (SQLITE_OK == sqlstate);
/* add some departments */
sqlstate = sqlite_exec (db, "INSERT INTO department VALUES ('history');", NULL, NULL, NULL);
assert (SQLITE_OK == sqlstate);
sqlstate = sqlite_exec (db, "INSERT INTO department VALUES ('english');", NULL, NULL, NULL);
assert (SQLITE_OK == sqlstate);
assert (sqlite_last_insert_rowid(db) == 2); /* two rows added */
tmp = sqlite_last_insert_rowid (db);
/* precompile an insert statement */
sqlstate = sqlite_compile (db, "INSERT INTO professor SELECT '?', department.ROWID FROM department WHERE department.name='?'", NULL, &pVm, NULL);
assert (SQLITE_OK == sqlstate);
/* insert via the precompiled statement */
sqlite_bind (pVm, 1, "Bob Jones", -1, 0);
sqlite_bind (pVm, 2, "history", -1, 0);
sqlstate = sqlite_step (pVm, NULL, NULL, NULL);
assert (SQLITE_DONE == sqlstate);
assert (tmp != sqlite_last_insert_rowid (db)); /* this assert fails -- sqlite_step() didn't insert anything */
sqlite_finalize (pVm, NULL);
sqlite_close (db);
return 0;
}
|
You are doing it wrong.
'?'
Is a string literal. A bindable parameter is a question mark that
is not contained inside single quotes.
Works as designed. no changes to code. |
|
536 |
code
|
closed
|
2003 Dec
|
anonymous
|
Pager
|
2003 Dec
|
|
1
|
1
|
Syscall param write(buf) contains unaddressable byte(s)
|
edit |
Wrong memory access. This is a general library problem.
To reproduce:
- Run valgrind like so: valgrind --num-callers=16 sqlite some.db
- Run any database change SQL statement on the sqlite command line
- For instance: create table X(Y varchar(20) primary key); or
insert into X values('blabla'); or update(...)
The stack trace generated by valgrind:
==10597== Syscall param write(buf) contains uninitialised or unaddressable byte(s)
==10597== at 0x420DAE54: __libc_write (in /lib/i686/libc-2.2.5.so)
==10597== by 0x804D48A: sqliteOsWrite (./src/os.c:866)
==10597== by 0x8065F48: pager_write_pagelist (./src/pager.c:1155)
==10597== by 0x8066FC0: sqlitepager_commit (./src/pager.c:1904)
==10597== by 0x8056D20: fileBtreeCommit (./src/btree.c:906)
==10597== by 0x8072ECC: sqliteVdbeExec (./src/vdbe.c:2269)
==10597== by 0x805B660: sqliteExec (./src/build.c:97)
==10597== by 0x80678A0: yy_reduce (in /home/hauk/bin/sqlite)
==10597== by 0x8069139: sqliteParser (parse.c:3946)
==10597== by 0x804F90E: sqliteRunParser (./src/tokenize.c:450)
==10597== by 0x804C8EA: sqliteMain (./src/main.c:631)
==10597== by 0x804CA35: sqlite_exec (./src/main.c:681)
==10597== by 0x804B1CF: process_input (./src/shell.c:1038)
==10597== by 0x804BA83: main (./src/shell.c:1329)
==10597== Address 0x41718319 is 861 bytes inside a block of size 1364 alloc'd
==10597== at 0x40027CA6: malloc (vg_replace_malloc.c:160)
==10597== by 0x804FCD1: sqliteMallocRaw (./src/util.c:268)
==10597== by 0x8066155: sqlitepager_get (./src/pager.c:1279)
==10597== by 0x805783D: moveToChild (./src/btree.c:1392)
==10597== by 0x8057B2A: moveToRightmost (./src/btree.c:1510)
==10597== by 0x8057C22: fileBtreeLast (./src/btree.c:1551)
==10597== by 0x8073E18: sqliteVdbeExec (./src/vdbe.c:2872)
==10597== by 0x805B660: sqliteExec (./src/build.c:97)
==10597== by 0x80678A0: yy_reduce (in /home/hauk/bin/sqlite)
==10597== by 0x8069139: sqliteParser (parse.c:3946)
==10597== by 0x804F90E: sqliteRunParser (./src/tokenize.c:450)
==10597== by 0x804C8EA: sqliteMain (./src/main.c:631)
==10597== by 0x804CA35: sqlite_exec (./src/main.c:681)
==10597== by 0x804B1CF: process_input (./src/shell.c:1038)
==10597== by 0x804BA83: main (./src/shell.c:1329)
|
> This is a bug in valgrind. The section of the SQLite library
> identified works exactly as it should. All parameters to the
> write() function are fully and correctly initialized.
FYI: I Reported this back to the valgrind maintainers and got this reply: http://bugs.kde.org/show_bug.cgi?id=71523 |
|
535 |
code
|
closed
|
2003 Dec
|
anonymous
|
Unknown
|
2003 Dec
|
|
1
|
1
|
Use of uninitialised value of size 4
|
edit |
The problem is reported by valgrind and may indicate a real problem. To reproduce the error, run the sqlite utility from valgrind like so:
valgrind -v --leak-check=yes --leak-resolution=high --num-callers=16 \
--freelist-vol=10000000 sqlite some.db
Then excute any SQL-statement at the sqlite command line, e.g.: begin transaction;
The problem is in the library and is not particularly to sqlite. Here's a stack trace (there is also a memory leak but it's not important for this error report)
Stack trace from the example run above:
==3746== Use of uninitialised value of size 4
==3746== at 0x804EE3D: randomByte (./src/random.c:70)
==3746== by 0x804EF02: sqliteRandomInteger (./src/random.c:107)
==3746== by 0x80668AD: pager_open_journal (./src/pager.c:1560)
==3746== by 0x80669C2: sqlitepager_begin (./src/pager.c:1620)
==3746== by 0x8056CC9: fileBtreeBeginTrans (./src/btree.c:885)
==3746== by 0x8072DB6: sqliteVdbeExec (./src/vdbe.c:2224)
==3746== by 0x805B660: sqliteExec (./src/build.c:97)
==3746== by 0x80678A0: yy_reduce (parse.y:77)
==3746== by 0x8069139: sqliteParser (parse.c:3946)
==3746== by 0x804F90E: sqliteRunParser (./src/tokenize.c:450)
==3746== by 0x804C8EA: sqliteMain (./src/main.c:631)
==3746== by 0x804CA35: sqlite_exec (./src/main.c:681)
==3746== by 0x804B1CF: process_input (./src/shell.c:1038)
==3746== by 0x804BA83: main (./src/shell.c:1329)
==3746== by 0x42017588: __libc_start_main (in /lib/i686/libc-2.2.5.so)
==3746== by 0x8049190: (within /home/hauk/bin/sqlite)
[Supressed similar error stack traces]
|
> The uninitialized variable warning must be a bug in valgrind. If
> you look in the random.c source file on line 70, you will clearly
> see that prng.s[] is initialized in the previous loop and that the
> index to prng.s[] (the value prng.j) must be in the range 0..255 due
> to the "& 0xff" in the previous statement.
Actually valgrind is correct. The problem lies in os.c:sqliteOsRandomSeed. The code looks like this:
int sqliteOsRandomSeed(char *zBuf){
#ifdef SQLITE_TEST
/* When testing, always use the same random number sequence.
** This makes the tests repeatable.
*/
memset(zBuf, 0, 256);
#endif
#if OS_UNIX && !defined(SQLITE_TEST)
int pid;
time((time_t*)zBuf);
pid = getpid();
memcpy(&zBuf[sizeof(time_t)], &pid, sizeof(pid));
#endif
....
Clearly, the zBuf is only cleared when SQLITE_TEST is defined, which it is not during normal build (and the memset is misplaced). Changing the code to:
--- random.c Wed Dec 31 03:56:58 2003
+++ random.diff Wed Dec 31 03:57:15 2003
@@ -60,6 +60,7 @@
char k[256];
prng.j = 0;
prng.i = 0;
+ memset(k, 0, 256);
sqliteOsRandomSeed(k);
for(i=0; i<256; i++){
prng.s[i] = i;
Makes the problem go away and the k buffer properly initialized.
Ps. You might want to reconsider and look into the other bug I reported based on the valgrind error report on writing unaddressable bytes :-)
This is a bug in valgrind. It reported the problem on random.c
line 70 when in fact it meant to say line 69.
Yes, there are parts of the k[] array that are uninitialized. But
think about what k[] is suppose to hold - random data. Any portion
of k[] that is not set by sqliteRandomSeed() might as well be
uninitialized since that will increase the randomness. Initializing
k[] to 0 removes the valgrind warning, but reduces the randomness
of k[]. |
|
532 |
code
|
closed
|
2003 Dec
|
anonymous
|
Parser
|
2003 Dec
|
|
2
|
3
|
crashes on gigantic query
|
edit |
I'm generating a gigantic query with a for loop. With a query string of length 4,878, which asks for 109 columns, it works OK; extending the query by about 30 chars to 110 col.s causes SQLite to segfault. My debugger says the error is somewhere in SqliteParserAlloc, but I can't get further than that.
I've looked for limitations listed in the documentation and could find none.
Code sample available on request. |
Submitter reports the problem was in the application code,
not in SQLite. |
|
531 |
code
|
closed
|
2003 Dec
|
anonymous
|
|
2003 Dec
|
|
4
|
4
|
INT is not treated the same as INTEGER
|
edit |
The INT and INTEGER keywords should be functionally equivalent, but they aren't specifically when creating an auto-incrementing primary key. |
Works as designed. |
|
528 |
code
|
closed
|
2003 Dec
|
anonymous
|
Unknown
|
2003 Dec
|
|
4
|
2
|
compiled c code shows queries in executable
|
edit |
if you run `strings` against your outputted c program or shared library you can see all the sql queries. this may be a security risk for some people.
ex:
bash # strings my_prog |
- This is a programming language (C/C++) issue, not an SQLite issue.
- It is impossible to construct a program which an advisary can read
which cannot also be reverse engineered by that advisary.
No changes to code. |
|
527 |
code
|
closed
|
2003 Dec
|
anonymous
|
Shell
|
2004 Feb
|
|
3
|
3
|
Sqlite shell: lack of checks
|
edit |
The shell command ('d' not exists):
sqlite ./d/myfile
Gives an error as follows:
SQLite version 2.8.7
Enter ".help" for instructions
sqlite> select * from mytable;
Unable to open database "./d1/test": unable to open database ./d1/test
The error of using a non existant directory should be caught sooner by checking the path and a better error message should be returned.
Same problem with a non writable directory. |
The shell intentionally does not open the database file until the
database file is actually used. This avoid creating empty files
when misspell the name of the database file. |
|
522 |
code
|
closed
|
2003 Dec
|
anonymous
|
Unknown
|
2003 Dec
|
|
1
|
1
|
Error in comparision equal and less-equal
|
edit |
To whom it may concern,
there is a inconsistent tuple given terface adding patch-sets, bug tracking, and Wiki
to CVS. http://www.hwaci.com/sw/cvstrac/.
|
|
516 |
code
|
closed
|
2003 Dec
|
anonymous
|
Parser
|
2003 Dec
|
|
1
|
1
|
unrecognized token error when a string contains a \' escape sequence
|
edit |
When .read[ing] a file with sqlite.exe on a Win2k Pro box that was produced with phpmyadmin containing a single quote escape (\') within a single-quoted string, an "unrecognized token" error occurs. It appears the case '\'': in tokenize.c is failing
-- seems it should be double-quoted as case "\'": |
Backslash quoting is a C-language convention. It does not
work in SQL. In SQL you double the quotes. Ex:
'That''s all folk!'
^^
No code changes. Works as designed. |
|
513 |
code
|
closed
|
2003 Dec
|
anonymous
|
|
2003 Dec
|
|
2
|
3
|
C++-style comments prevent compilation
|
edit |
I tried to install DBD::SQLite (perl module) on my AIX
box. The install fails because the AIX compiler rejects
dbdimp.c because it has // comments in it, which are
not allowed in C code.
cc -c -I/usr/local/perl-5.6.1/lib/site_perl/5.6.1/aix/auto/DBI -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=16384 -I/usr/local/include -q32 -D_LARGE_FILES -qlonglong -O6 -DNDEBUG=1 -DSQLITE_PTR_SZ=4 -DVERSION=\"0.28\" -DXS_VERSION=\"0.28\" -I/usr/local/perl-5.6.1/lib/5.6.1/aix/CORE dbdimp.c
cc: 1501-216 command option 6 is not recognized - passed to ld
"/usr/local/perl-5.6.1/lib/site_perl/5.6.1/aix/auto/DBI/dbipport.h", line 43.43: 1506-342 (W) "/*" detected in comment.
"dbdimp.c", line 389.5: 1506-046 (S) Syntax error.
"dbdimp.c", line 390.5: 1506-046 (S) Syntax error.
make: 1254-004 The error code from the last command is 1.
|
This appears to be a perl or DBD:SQLite error. The dbdimp.c file is
not a part of the SQLite core. |
|
512 |
code
|
closed
|
2003 Dec
|
anonymous
|
Parser
|
2003 Dec
|
|
2
|
2
|
order by clause is not ordering data properly in aggregate functions
|
edit |
order by clause is not ordering data properly in aggregate functions |
There are dozens and dozens of tests in the regression test suite
for SQLite that check that ORDER BY is working properly on queries
that contain aggregates. All of those tests pass.
Perhaps the person who submitted this ticket could provide a
specific example of a case that he thinks is not being sorted
correctly. Until then, there isn't much we can do to "fix" the
problem.
Works as designed. No changes to code.
The original poster writes:
After trying long and hard to come up with an example to pass on to you I've decided that it would be best to explain the problem in more detail instead. Here I go. I have an SQLite database that I frequently do insert replace on one particular table. I have also created a few aggregate functions that do specific math operations on values in that table. These math functions operated on ordered data (order by field clause). I noticed that my aggregate functions were not returning expected data so I decide to create an aggregate function that simply echoed the argv[0] value of the aggregate step function. To my surprise the value that is sometimes echoed did not match the order of the value that showed up when I did the same select without the aggregate function and the order by field clause. As I said I have verify the problem, the problem does not show up all the time and aggregate functions that do not care about the ordering of data (for example min, max, etc) do not exhibit the problem.
drh replies:
The ORDER BY applies to the output of the query, not the input.
So (for example) if you say:
SELECT count(*), type FROM table GROUP BY type ORDER BY 1;
The aggregate function runs first to compute a new virtual
table of two columns where the first column is a count and the
second column is "type". Then the sort occurs on the new
virtual table to order the output by count.
If you want to order the input, you have to do that with a
subquery:
SELECT count(*), type FROM (SELECT type FROM table ORDER BY 1)
GROUP BY 2;
|
|
511 |
code
|
closed
|
2003 Nov
|
anonymous
|
VDBE
|
2003 Nov
|
|
1
|
1
|
confused error of nested calling of "sqlite_compile"
|
edit |
the calling sequence is as follows
void func1()
{
sqlite *db;
sqlite_vm *vm;
char *zErrMsg, *zTail, char[1024];
db = sqlite_open("ex1", 0, &zErrMsg);
sqlite_compile(db, sql, &zTail, &vm, &zErrMsg);
sqlite_step( vm, &nRows, &zValue, &zColName);
func2();
func3();
...
sqlite_finalize( vm, &zErrMsg);
sqlite_close(db);
}
void func2()
{
sqlite_vm *vm;
char *zErrMsg, *zTail, char[1024];
sqlite_compile(db, sql, &zTail, &vm, &zErrMsg);
sqlite_step( vm, &nRows, &zValue, &zColName);
func2();
func3();
...
sqlite_finalize( vm, &zErrMsg);
}
void func3()
{
sqlite_vm *vm;
char *zErrMsg, *zTail, char[1024];
sqlite_compile(db, sql, &zTail, &vm, &zErrMsg);
sqlite_step( vm, &nRows, &zValue, &zColName);
...
sqlite_finalize( vm, &zErrMsg);
}
when executing, it reported an error of SQLITE_MISUSE in func3(), while it ran well in func2(). I am afraid maybe there is any error in the SQL statement. the SQL statement is "select user_id, user_name from t_user_info where depart_id=''"
who can give some idea about this question? |
This is not an SQLite bug. This is a question about how to use SQLite.
Questions about how to use SQLite should be directed to the mailing
list.
No changes to code. Works as designed. |
|
507 |
code
|
closed
|
2003 Nov
|
anonymous
|
Unknown
|
2003 Nov
|
|
2
|
4
|
string comparison in where-clause of select
|
edit |
when having a table with normal strings:
"select * from table where field>='A' and field<='B';"
you get only fields beginning with an 'A', not also fields beginning with an 'B'.
Bug or feature ? I think it is a bug.
Workaround is:
"select * from table where field>='A' and field<='B~';" |
'Bcde'>'B', hence if field is 'Bcde' then
select * from table where field<='B';
will return nothing.
No changes. Works as designed. |
|
506 |
code
|
closed
|
2003 Nov
|
anonymous
|
|
2003 Nov
|
|
2
|
1
|
Result tuple not formed correctly on select query
|
edit |
I use pySQLite, but I've looked in the code and it seems that the problem is in SQLite itself.
Querying: "SELECT * from student" gets me the following results using fetchall():
[(1, 'Kees', 'van den', 'Broek', 22)]
That's good. Now, I select 1 row:
"SELECT lastname from student"
with fetchall(), this gives me:
[('Broek',)]
I think this should be:
[('Broek')]
So it's a bug, right? |
This is not an SQLite problem since SQLite doesn't know
anything about python lists. If this is really a problem,
you should report it on the pySQLite website, not here. |
|
499 |
code
|
closed
|
2003 Nov
|
anonymous
|
Unknown
|
2004 Feb
|
|
1
|
3
|
dot in table name and in column name makes full_column_names unusable
|
edit |
if you select a column containing a dot from a table containing a dot and wish to use the full_column_names, there is no clean way to parse the column name.
the dot in the table name should be escaped.
in select.c:
line 783: if( showFullNames || zTab==0 ) zTab = pTab->zName;
insert code to escape an eventual '.', like:
if (strchr(zTab, '.') != 0)
sqliteSetString(&zName, "[", zTab, "]", ".", zCol, 0);
else
line 784: sqliteSetString(&zName, zTab, ".", zCol, 0); |
2004-Feb-25 02:44:45 by drh:
The full_column_names pragma is a kludge. And it gets used by
other kludges all over the place. If I change what it does in any
way, it is likely to break lots of code.
The current behavior must be preserved to protect backwards
compatibility, even if the current behavior is less than
optimal. |
|
497 |
new
|
closed
|
2003 Nov
|
anonymous
|
Unknown
|
2003 Nov
|
|
3
|
3
|
not able to escape quotes
|
edit |
I am not able to 'escape' quotes. I.e. insert into table values("a","b","<xml id="abc">". I know i could use ' but this is not always a solution. It could be expected that you should enter \" or \' to accept a quote in the string. It's not a bug, but a feature request. Perhaps there is another solution here? |
The SQL standard way of doing this is to double the quoting
characters - either two ' in a row or two " in a row. Backslashes
are not an SQL quote character and if implemented would break
many valid SQL scripts.
INSERT INTO table VALUES("a","b","<xml id=""abc"">");
See also the documentation on the "%q" conversion character for
sqlite_exec_printf() and its cousins.
This should be in the FAQ... |
|
494 |
new
|
closed
|
2003 Nov
|
anonymous
|
|
2003 Nov
|
|
4
|
4
|
No way to get a list of table columns without parsing the schema
|
edit |
It would be very nice to have a way to get a list of column names and types in a table, without having to parse the schema. |
PRAGMA table_info(<table-name>); |
|
492 |
code
|
closed
|
2003 Nov
|
anonymous
|
Unknown
|
2003 Nov
|
|
2
|
4
|
database image is malformed
|
edit |
I did this: drop table offer; create table offer; load data into table offer; ( there was index on that table )
On original machine (i386) all is peachy, but when I transfer file to mipsel machine I get: "database image is malformed" whenever I do 'select count(*) from offer', most other things work ok ( select * from offer works fine for example ).
As a workaround I dumped the database to file and re-created everything from scratch.
Oh, and web-based forms are not the best medium for filling reports,
we've got e-mail for that. |
Bug summitter reports that the problem has now been traced
to parts of the system that are unrelated to SQLite. |
|
476 |
doc
|
closed
|
2003 Oct
|
anonymous
|
|
2003 Nov
|
|
3
|
3
|
Define for omitting time and date functions
|
edit |
There is a define for omitting time and date functions defined in sqliteInt.h (SQLITE_OMIT_TIMEDATE_FUNCS). However, the code in func.c to omit this is: #ifndef SQLITE_OMIT_DATETIME_FUNCS (notice the swap of DATE and TIME in the name).
You can solve this PR by just making them consistent. |
|
475 |
code
|
closed
|
2003 Oct
|
anonymous
|
|
2003 Oct
|
|
1
|
1
|
question:how to use the sqlite in my VC6 project?
|
edit |
If somebody can give me some advice to use sqlite source in VC6 project instead of DLL?
thanks a lot
|
This is a question for the mailing list, not a bug report. |
|
474 |
code
|
closed
|
2003 Oct
|
anonymous
|
Unknown
|
2003 Oct
|
|
4
|
1
|
Problem with showing the datatypes of columns of a empty table
|
edit |
When turned on, the SHOW_DATATYPES pragma causes extra entries containing the names of datatypes of columns to be appended to the 4th ("columnNames") argument to sqlite_exec() callbacks.
But if the table is empty,sqlite_exec() callbacks will never be called.So we can never show the names of datatypes of columns of a empty table in this way. |
See the documentation on the EMPTY_RESULT_CALLBACKS pragma at
http://www.sqlite.org/lang.html#pragma. |
|
471 |
code
|
closed
|
2003 Oct
|
anonymous
|
Parser
|
2003 Oct
|
|
5
|
1
|
Parser accepts faulty SQL
|
edit |
SQL parser doesn't complain when I enter a SQL with syntax error
("INTEGER id PRIMARY KEY" instead of "id INTEGER PRIMARY KEY")
xxxx@lilly(~/pym)$ sqlite xx.db
SQLite version 2.8.6
Enter ".help" for instructions
sqlite> create table xx (INTEGER id PRIMARY KEY, dsc);
sqlite> insert into xx values(NULL, "xx");
sqlite> select * from xx;
|xx |
This is a feature, not a bug. The line "INTEGER id PRIMARY KEY"
declares a column names "INTEGER" of type "id" which is the
primary key for the table. SQLite is deliberately flexible in
its parsing (accepting words like "INTEGER" as a column name and
"id" as a type name) in order to be compatible with as many other
database engines as possible. |
|
470 |
code
|
closed
|
2003 Oct
|
anonymous
|
Unknown
|
2005 Jan
|
|
2
|
3
|
Unnecessary 31-character name limit on Mac
|
edit |
There is a SQLITE_CANTOPEN error being returned from sqliteOsOpenExclusive when the file name is more than 31 characters long, which is especially likely when "-journal" is appended to the name. Within the _LARGE_FILE code path, there is no need to use the old APIs with that file name limit. I have a patch for os.c to fix it. Replace:
FSRef fsRef;
__path2fss(zFilename, &fsSpec);
if( HCreate(fsSpec.vRefNum, fsSpec.parID, fsSpec.name, 'SQLI', cDocumentFile) != noErr )
return SQLITE_CANTOPEN;
if( FSpMakeFSRef(&fsSpec, &fsRef) != noErr )
return SQLITE_CANTOPEN;
with the new code
FSRef fsRef, parentRef;
FSCatalogInfo catInfo;
FileInfo* finderInfo;
if (__msl_path2splitfsr( zFilename, &parentRef, &dfName ) != noErr)
return SQLITE_CANTOPEN;
finderInfo = (FileInfo*) catInfo.finderInfo;
memset( finderInfo, 0, sizeof(FileInfo) );
finderInfo->fileType = cDocumentFile;
finderInfo->fileCreator = 'SQLI';
if (FSCreateFileUnicode( &parentRef, dfName.length, dfName.unicode, kFSCatInfoFinderInfo,
&catInfo, &fsRef, NULL ) != noErr)
return SQLITE_CANTOPEN;
|
2004-Feb-06 15:52:22 by anonymous:
There is a similar problem with sqliteOsOpenReadWrite.
2005-Jan-16 by drh:
Support for Mac OS9 is removed from version 3 due to lack of interest. |
|
467 |
code
|
closed
|
2003 Sep
|
anonymous
|
Unknown
|
2003 Oct
|
|
2
|
1
|
Problem with renaming fields
|
edit |
If I have a table named 'Properties' with two fields, 'propName' and 'propValue'
This SQL:
SELECT propValue as title FROM properties WHERE propName = "title";
will return 0 entries where there exists valid results. The SQL parser does not seem to like that 'title' is used twice (once in the SELECT clause and once in the WHERE clause)
This SQL Does work:
SELECT propValue as _title FROM properties WHERE propName = "title"
becuase _title != title.
Try it!
CREATE TABLE Properties (propName char(50), propValue char(50));
INSERT INTO Properties values ("title","test1");
INSERT INTO Properties values ("title","test2");
INSERT INTO Properties values ("title","test3");
INSERT INTO Properties values ("creator","test4");
INSERT INTO Properties values ("creator","test5");
SELECT propValue as title FROM Properties WHERE propName = "title";
--> returns 0 entries - should have returned 'test1','test2',test3'
SELECT propValue as title_x FROM Properties WHERE propName = "title";
-->test1
-->test2
-->test3
SELECT propValue as title FROM Properties WHERE propName = "creator";
-->test4
-->test5
It appears to break when
SELECT field1 as xxxx FROM table WHERE field2 = "xxxx";
when xxxx=xxxx
thanks- Shannon |
A name in double-quotes (ex: "title") resolves to a column name
if it can and to a string literal if not column is available with
that name. Use single-quotes (ex: 'title') for a pure string
literal.
No changes. Works as designed. |
|
466 |
todo
|
closed
|
2003 Sep
|
anonymous
|
|
2005 Jan
|
|
4
|
4
|
index internationalisation
|
edit |
nowadays, it's quite trivial that a piece of software would be used worldwide, partly by speakers of non-english languages.
most of the issues with native language support rely in different encodings (numeric value assigned to a single character of a particular human language), and in special sorting order of characters for a language, other than their usual order of the characters encoding in the codepage.
for example, the romanian alphabet contains the latin characters, plus 5 special characters. for the computer they are all numbers, and are expressed in a codepage. to write in romanian, a user may use any codepage which support the latin character set plus the romanian one.
there are various codepages that support the special character needed for the romanian language. some code page might assign them values 135,138,252, and nother might assign the same characters the values 201,207,190. the user of the database should know what codepage has been used for each field in the database, in order to formulate his/her query.
with the same example, the sort order of the characters in romanian is A, A_circumflex, A_with_hat, B, C, D ... as you can see, this is not the concatenation of the latin character set and the romanian one. thus, comparison of two strings in romanian would require a sort value for each character. this is usualy implemented as an array, that has at each character value a sorting value for that character.
since different fields of a same table might use different languages (imagine a two way english-romanian dictionary), each field should be possible to be assigned a codepage and a language, and the database should contain a table able to provide a translation table for comparing values for that field.
i have personaly created a library that makes such native language data and operations, and i'd be happy to make it co-operate with sqlite. |
Version 3 provide i18n support. |
|
464 |
code
|
closed
|
2003 Sep
|
anonymous
|
|
2003 Dec
|
|
2
|
2
|
VACUUM doesn't compile with sqlite_compile
|
edit |
Hello,
When trying to compile (with sqlite_compile) the following query "VACCUM;" the function returns SQLITE_ERROR.
Running VACCUM with sqlite_exec is working fine.
I was not able to find where the problem was exactly, but I can say that a lot of processing is done correctly.
I would say that somewhere an error code is set erroneously but without being able to confirm it.
Kind regards
Valere Monseur
aka dobedo. |
Fixed. |
|
455 |
doc
|
closed
|
2003 Sep
|
anonymous
|
|
2003 Sep
|
|
4
|
2
|
undocumented functions: sqlite_mprintf,and sqlite_vmprintf
|
edit |
I just would like to notice that those two functions (sqlite_mprintf,
and sqlite_vmprintf) remain undocumented since ages, and make port coders' work unnecessarily hard.
They're very useful and they've been around for a while, so I guess it's somewhat stable code, but the only way to know how they work is either looking at the code, or navigating through google looking for how to escape code in SQLite.
Any chances you could add one line explaining how it works?
Undocumented code is ~ unusable code |
Sorry, I found the documentation. It seems it's somewhat hidden, but it's there. |
|
449 |
new
|
closed
|
2003 Sep
|
anonymous
|
|
2005 Jan
|
|
3
|
4
|
Date and time functions for SELECTs
|
edit |
A basic set of D&T functions (now(), formatting from timestamp, arithemetic, etc.) for use in SELECT statements would be very useful. |
I looked at the source and found the new set of functions which aren't yet in the docs. Would there be any interest in a date formatting function along the lines of MySQL's date_format(date, format_string) or Oracle's TO_CHAR? I could contribute one if so. |
|
443 |
new
|
closed
|
2003 Sep
|
anonymous
|
Parser
|
2005 Jan
|
anonymous
|
3
|
3
|
LIKE ... should support ESCAPE as per SQL spec
|
edit |
Currently LIKE % and _ are supported but if you have a string with % and _ in it then you are in trouble.
\% or \_ would be ok or %% or __ are also valid but the spec describes a
ESCAPE clause for the LIKE option - could that be implimented? |
This is already covered by ticket #324. |
|
441 |
code
|
closed
|
2003 Sep
|
anonymous
|
Parser
|
2003 Dec
|
drh
|
1
|
1
|
Cannot find table under Managed C++
|
edit |
I am writing a .NET wrapper for Sqlite in Managed C++. I've divided the task in a couple of stages:
A native C++ project that builds Sqlite into a library Sqlite.lib
A native C++ project that wraps sqlite into a library SqliteNative.lib
A native test application of the native C++ wrappers.
A managed C++ project that wraps the native C++ wrappers for use in a C# application
A C# application.
All phase build correctly. However the native version works and the managed version fail to create the VM and reports that it cannot find the table in the test database.
I'm not certain how the hash functions work but I think there may be some pointer assumptions going on as it is puzzling why the same code works on the native side but fails under Managed C++.
Whoever contacts me (chriswa@comcast.net) I can send you zip files of the projects.
Thanks |
my email address is chriswa@comcast.net
This is not a bug. It is a request for help in porting SQLite to
a new compiler and execution environment. The appropriate forum is
the SQLite users mailing list. |
|
440 |
code
|
closed
|
2003 Sep
|
anonymous
|
|
2003 Dec
|
drh
|
3
|
3
|
dayofmonth("now") returns one more than actual day
|
edit |
The 'dayofmonth()' function returns one more than the correct value, on both Linux and Win32 compiled with gcc.
Today is the second of September, but:
select dayofmonth('now');
returns '3'. (both machines I tried this on are set to the correct date) |
Note the time on the ticket.
I suspect it was 2003-Sep-02 local time on the user's computer, but 2003-Sep-03 GMT
e
That is what I think; shouldn't it return local time?
OBE: Time & date functions have been rewritten. |
|
438 |
code
|
closed
|
2003 Aug
|
anonymous
|
Unknown
|
2005 Jan
|
|
1
|
4
|
Minute function off between 11:16 and 11:20
|
edit |
select minute('2003-08-29 11:16');
returns 15
select minute('2003-08-29 11:20');
returns 19
everything between these two time values is off by one minute. |
These problems don't occur in my version modified as per Tickets #425 #426 and Ticket #415.
There are two parts to the fix.
One is for hardStringify() to produce all the significant digits of a double. This is Ticket #415.
The other is to round the JD value appropriately before (or within) function decomposeDate(). This is done in my fixes attached to Tickets #425 and #426. |
|
437 |
code
|
closed
|
2003 Aug
|
anonymous
|
Unknown
|
2003 Aug
|
|
3
|
3
|
Wrong order for results of SELECT
|
edit |
I have the following SQL Statement:
CREATE TABLE uobject (
name varchar(255) default NULL,
serial int(11) NOT NULL default '0',
multis int(11) NOT NULL default '-1',
pos_x smallint(6) NOT NULL default '0',
pos_y smallint(6) NOT NULL default '0',
pos_z smallint(6) NOT NULL default '0',
pos_map tinyint(4) NOT NULL default '0',
direction char(1) NOT NULL default '0',
events varchar(255) default NULL,
bindmenu varchar(255) default NULL,
havetags tinyint(1) NOT NULL default '0',
PRIMARY KEY (serial)
);
I am querying this table and another one using this statement:
SELECT uobject.name,uobject.serial,uobject.direction,
uobject.multis,uobject.pos_x,uobject.pos_y,
uobject.pos_z,uobject.pos_map,uobject.events,
uobject.bindmenu,uobject.havetags
FROM uobject,uobjectmap;
And i am not using the column information returned by sqlite but assumed that actually the field order would matter but actually sqlite returned the fields in the order used when creating the table... |
I'm not sure what this bug report is saying.
The columns in the result set of an SQLite query are
determined by the SELECT statement, not by the original
table definition. This is per SQL specs. I have
verified this behavior.
Unable to reproduce any problems. |
|
436 |
code
|
closed
|
2003 Aug
|
drh
|
BTree
|
2003 Aug
|
drh
|
1
|
1
|
In-memory database backend segfaults on recursive access
|
edit |
The following code (using the TCL bindings) causes a segfault:
sqlite db :memory:
db eval {
CREATE TABLE t1(x);
INSERT INTO t1 VALUES(1);
}
db eval {SELECT rowid, x FROM t1} {} {
db eval "DELETE FROM t1 WHERE rowid=$rowid"
}
The segfault only occurs using the in-memory backend. The file-based
backend returns an error "database is locked" which is the correct
behavior. |
|
431 |
new
|
closed
|
2003 Aug
|
anonymous
|
Shell
|
2003 Aug
|
|
5
|
4
|
possibility to use sql scripts in a file on the command line
|
edit |
It would be nice if one could create a db from a script only with
the commandline.
syntax more or less like this:
sqlite newdb.db .read scripts.sql
(analog to: sqlite newdb.db .dump > backup.sqlbak)
regards,
Yves Glodt |
You can do this now, simply redirect the input to sqlite. For example;
sqlite newdb.db <scripts.sql >error.log
The anonymous remarks above are correct. Another way to do it
is like this:
sqlite newdb.db '.read scripts.sql'
ok, thank you.
this works in bash: sqlite newdb.db '.read scripts.sql'
and this in cmd.exe: sqlite test.db <backup.sql>error.log
thank you! |
|
426 |
code
|
closed
|
2003 Aug
|
anonymous
|
VDBE
|
2003 Dec
|
|
2
|
3
|
TIME produces JDs off by 12 hours
|
edit |
In both the CVS version, and in my enhancement #425, the TIME function is broken:
sqlite> select time('12:34:56');
00:34:56
My preferred solution is to use Truncated Julian Dates which use midnight as a time base.
e |
The TJD code as implemented here fixes this problem.
Three files added:
- func.c.diff includes changes for #425 plus a TJD fix for this bug
- funct.c.diff just the changes from #425 to TJD fix for this bug
- tjdate.test a test file for datetime
OBE: Time and date functions have been rewritten. |
|
423 |
code
|
closed
|
2003 Aug
|
anonymous
|
Unknown
|
2003 Dec
|
|
1
|
1
|
'data schema has been changed error' how will overcome this
|
edit |
when adding new table in to the existing database it throwing 'data schema has been changed error' how wil l overcome this |
Answer: issue the request again.
This is not a bug. It is documented behavior. |
|
422 |
code
|
closed
|
2003 Aug
|
anonymous
|
Unknown
|
2003 Dec
|
|
4
|
1
|
Memory leak in src/build.c
|
edit |
I use dmalloc memory debuger (dmalloc.com) to debug memory usage in my application, this application now use SQLite, but dmalloc now report an memory leak: some memory allocated at src/build.c line 1661 of SQLite is not fried at exit. |
SQLite allocates a little bit of memory once, in several places, and
then reuses that same memory over and over. The memory is never freed.
But this is not a leak. |
|
418 |
code
|
closed
|
2003 Jul
|
anonymous
|
Unknown
|
2005 Jan
|
|
4
|
4
|
sometimes web page returns error, hitting refresh makes it work
|
edit |
The very first time I visit the SQLite page on a different computer
I get an error back from the server. Internet Explorer displays a
"This page cannot be displayed" page. If I hit refresh the page
displays properly. The server never returns errors again.
This has happened on a few different computers all using different
internet connections so I don't think it has anything to do with my
setup. |
Unable to reproduce. |
|
417 |
code
|
closed
|
2003 Jul
|
anonymous
|
Unknown
|
2003 Aug
|
|
4
|
4
|
Resultset differs between ..LIMIT 20 OFFSET 100 and ..LIMIT 20, 100
|
edit |
I tried some simple queries with the commandline interface (RPM version 2.8.5). When using the LIMIT clause I realized different resultsets. As I understood the documentation using ...LIMIT 20 OFFSET 100 should return exactly the same resultset as using ...LIMIT 20, 100 |
"LIMIT 20 OFFSET 100" is the same as "LIMIT 100,20".
See ticket #245. |
|
415 |
code
|
closed
|
2003 Jul
|
anonymous
|
VDBE
|
2003 Dec
|
|
3
|
3
|
Stringify can loose digits in doubles
|
edit |
The Stringify macro's hardStringify function uses printf to convert doubles to strings. The format argument used is "%.15g" but to retain full precision for IEEE doubles "%.17g" should be used.
I verified this with
printf("%.17g\n", 2.225073858507201e-308);
printf("%.16g\n", 2.225073858507201e-308);
printf("%.15g\n", 2.225073858507201e-308);
printf("%.17g\n", 2.2250738585072014e-308);
printf("%.16g\n", 2.2250738585072014e-308);
printf("%.15g\n", 2.2250738585072014e-308);
printf("%.17g\n", 2.2250738585072018e-308);
printf("%.16g\n", 2.2250738585072018e-308);
printf("%.15g\n", 2.2250738585072018e-308);
printf("%.17g\n", 0x7FEFFFFFFFFFFFFFLL);
printf("%.16g\n", 0x7FEFFFFFFFFFFFFFLL);
printf("%.15g\n", 0x7FEFFFFFFFFFFFFFLL);
printf("%.17g\n", 0x7FEFFFFFFFFFFFFELL);
printf("%.16g\n", 0x7FEFFFFFFFFFFFFELL);
printf("%.15g\n", 0x7FEFFFFFFFFFFFFELL);
A related note:
The reliance upon the standard C library for conversion between strings and doubles is certainly a reasonable and obvious decision. If the inconsistency between sqlite platforms ever becomes an issue, I recommend using David Gay's dtoa available from netlib which prints doubles in the fewest characters needed to read them back accurately with the supplied strtod. http://www.netlib.org/fp/dtoa.c
e |
Formats %.17g and %.16g cause too much roundoff error. Values that
should be 0.1 come out as 0.09999999999999998. I'm deliberately
choosing to leave the conversion at %.15g. |
|
402 |
code
|
closed
|
2003 Jul
|
anonymous
|
Shell
|
2005 Jan
|
anonymous
|
2
|
3
|
linebreake
|
edit |
When I order by an expression and include a limit clause I get blank
output printed from the sqlite shell. There are no NULL rows in the
table. I've not yet tested this in a c or perl program to see if it
is a problem only with the shell. I logged my session so you can
see exactly what I mean.
non default options: Page size = 16384
***LOG BEGINS HERE***
sqlite> select count(*) --make sure we have no null rows
...> from cache
...> where extension is null
...> and filename is null;
0
sqlite> -- ok no NULL records
sqlite> select filename || extension -- limit OK without order by
...> from cache
...> limit 10;
Slide_Scans_053.jpg
Slide_Scans_099.jpg
P6066219-NS-Cresson-service-3343.jpg
P6066227-ns-cresson-primer-clad-horse-leading.jpg
ContactSheet-1_copy.jpg
CP_2816_pistons_and_drivers.mov
ABPRPine2.jpg
caltrain925sclara061303.jpg
henryhunningtonsclara031703.jpg
061403_3436b.jpg
sqlite> -- looks good extension and filename together
-- ***HERE IS THE PROBLEM***--
sqlite> select filename || extension
...> from cache
...> order by filename||extension
...> limit 10;
sqlite> -- NULL output???? there should have been 10 records!
sqlite> select filename || extension
...> from cache
...> order by filename, extension -- use , instead of ||
...> limit 10;
00-0094_img.jpg
000_0026.jpg
000_0026r.jpg
000_0076.jpg
000_0082.jpg
00178_RT8.jpg
00178_RT8.jpg
01072003-42765-bury-3.jpg
01072003-d1041-bury-2.jpg
01072003-d1041-bury-4.jpg
sqlite> -- that works fine.. apparently using the concat expression
breaks limit
sqlite> ^D
|
Probably you have 10 or more rows where extension is NULL.
Anything concatenated with NULL gives NULL so the
"filename||extension" will be NULL. NULLs sort before anything
else, so the output will be all NULLs.
To test this theory add "WHERE extension NOT NULL" to the query.
To the person who wrote this ticket (swany): Please verify that
the above diagnosis is correct, add a remark to that effect, then
close this ticket. Or if the theory above is wrong, add additional
explanation and I will look further into the problem.
That is the problem.. I tested it excluding rows with NULL
extensions and it worked as expected. In Oracle a string that is concatted with NULL doesn't return NULL.. Oracle treats NULL as an
empty string in the string concat operator. Is that the SQL standard or is that something specific to Oracle? Oracle example below..
bash$ sqlplus
SQL*Plus: Release 9.2.0.3.0 - Production on Sun Jul 20 12:43:33 2003
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Enter user-name: / as sysdba
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.3.0 - Production
SQL> select NULL || '-1' A, -- start_with_null
2 '1-' || NULL B, -- end_with_null,
3 '1-' || NULL || '-1' C -- null_in_middle
4 from dual;
A B C
-- -- ----
-1 1- 1--1
SQL> quit
The SQLite solution is to use coalesce but that can be a pain
when you need to concat a lot of stuff together....
select filename || coalesce(extension, '')
...> from cache
...> order by filename || coalesce(extension, '')
...> limit 10;
|
|
399 |
event
|
closed
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
drh
|
3
|
3
|
SELECT COUNT(*) FROM TABLE
|
edit |
when using with the DLL, it return count(*).
While modifying:
/* If this is the first row, then generate an extra row containing
** the names of all columns.
*/
if( p->nRow==0 ){
p->nColumn = nCol;
for(i=0; i<nCol; i++){
if( colv[i]==0 ){
z = 0;
}else{
z = malloc( strlen(colv[i])+1 );
if( z==0 ){
p->rc = SQLITE_NOMEM;
return 1;
}
strcpy(z, colv[i]);
}
//WHEN YOU REMOVE THIS LINE, IT FIX THIS PROBLEM.
p->azResult[p->nData++] = z;
}
}else if( p->nColumn!=nCol ){
sqliteSetString(&p->zErrMsg,
"sqlite_get_table() called with two or more incompatible queries", 0);
p->rc = SQLITE_ERROR;
return 1;
}
|
I do not understand the description of the problem. And the
line that is marked as being removed appears to be an essential
part of SQLite - removing it creates an error.
No changes.
The originator further describes the error as returning
the text string 'count(*)' instead of an integer which is
the actual count.
I Think I see the difficulty here. The user is expecting the 0th element of the 0th result row returned by the query "SELECT COUNT(*) FROM tablename" to be the actual count when it is instead the column name. The data rows start after the row of column names. I will email the poster. |
|
392 |
event
|
closed
|
2003 Jul
|
anonymous
|
Shell
|
2003 Jul
|
anonymous
|
1
|
1
|
Unable to link libsqlite.so file on SunOS 5.8
|
edit |
After I compiled the source files, I tried to link my own test file with libsqlite.so, and I got an error as below.
$ cc -o SQLiteTest SQLiteTest.c -L . -R . -lsqlite
Undefined _________________________ first referenced
symbol ____________________________ in file
sqlite_version------------------------------>./libsqlite.so
sqlite_interrupt---------------------------->./libsqlite.so
sqliteBtreeFactory------------------------>./libsqlite.so
sqlite_freemem---------------------------->./libsqlite.so
sqliteInit---------------------------------->./libsqlite.so
sqlite_create_function--------------------->./libsqlite.so
sqlite_open------------------------------->SQLiteTest.o
sqliteRollbackAll------------------------->./libsqlite.so
sqlite_error_string------------------------>./libsqlite.so
sqlite_busy_timeout---------------------->./libsqlite.so
sqlite_create_aggregate------------------>./libsqlite.so
sqlite_last_insert_rowid------------------>./libsqlite.so
sqlite_function_type---------------------->./libsqlite.so
sqlite_exec------------------------------->SQLiteTest.o
sqlite_close------------------------------>SQLiteTest.o
ld: fatal: Symbol referencing errors. No output written to
SQLiteTest
Please instruct me how I can solve this problem. Thank you very much!
|
I don't have SunOS and so I do not have any idea why
your software is not working. But it appears to be a
compilation problem, not an SQLite problem. So the bug
report does not really belong here. Try asking for
help on the SQLite newsgroup.
This is a duplicate of ticket #389. |
|
390 |
code
|
closed
|
2003 Jul
|
anonymous
|
Shell
|
2003 Jul
|
|
3
|
4
|
database creation
|
edit |
Using sqlite to create a database when one does not yet exist, does not work until you do some dummy select.
sqlite db314
.exit at the prompt (in a dosbox and no file shows up in the explorer)
sqlite db314
select * from users;
.exit at the prompt (in a dsobox and the file shows up as en empty file) |
This is a feature, not a bug. By delaying the creation of the
database, you don't get an empty database if you mistype the
name of database on the "sqlite" command line.
Example: Suppose you want to look at database "fuzzy.db" but
you mistype the name as "duzzy.db". As currently implemented, you
can immediately type ".exit" to leave sqlite and no new files are
created. |
|
389 |
event
|
closed
|
2003 Jul
|
anonymous
|
Shell
|
2003 Jul
|
|
1
|
1
|
Undefined symbol
|
edit |
$ cc -o SQLiteTest SQLiteTest.c -L . -R . -lsqlite
Undefined _________________________ first referenced
symbol ____________________________ in file
sqlite_version------------------------------>./libsqlite.so
sqlite_interrupt---------------------------->./libsqlite.so
sqliteBtreeFactory------------------------>./libsqlite.so
sqlite_freemem---------------------------->./libsqlite.so
sqliteInit---------------------------------->./libsqlite.so
sqlite_create_function--------------------->./libsqlite.so
sqlite_open------------------------------->SQLiteTest.o
sqliteRollbackAll------------------------->./libsqlite.so
sqlite_error_string------------------------>./libsqlite.so
sqlite_busy_timeout---------------------->./libsqlite.so
sqlite_create_aggregate------------------>./libsqlite.so
sqlite_last_insert_rowid------------------>./libsqlite.so
sqlite_function_type---------------------->./libsqlite.so
sqlite_exec------------------------------->SQLiteTest.o
sqlite_close------------------------------>SQLiteTest.o
ld: fatal: Symbol referencing errors. No output written to
SQLiteTest |
|
388 |
code
|
closed
|
2003 Jul
|
anonymous
|
Unknown
|
2003 Jul
|
|
2
|
1
|
sqlite-2.8.4.tar.gz doesn't have the Constants.java file
|
edit |
Can't compile unless the Constants.java file is included |
You are mistaken. No file named "Constants.java" has ever been
a part of SQLite. SQLite does not have anything to do with java.
Perhaps you are trying to compile another package that uses SQLite and
the file you need is missing from that other package. |
|
382 |
code
|
closed
|
2003 Jul
|
|
Unknown
|
2003 Jul
|
|
2
|
2
|
Triggers stop firing under certain situations
|
edit |
I have encountered a very strange problem with sqlite (tested with 2.8.4 and latest post 2.8.4 code base using MSVC7.1).
I have a table with a temp AFTER UPDATE trigger (also occurs with AFTER INSERT) defined. I start a transaction, create a temp table, then do an update on the table with the temp AFTER UPDATE trigger. I then call splite_exec with a callback function that returns false on it's first invocation (preventing further records from being retrieved). After this, no triggers fire for that instance of sqlite.
Requirements to see the error:
1) have a trigger defined (AFTER INSERT or AFTER UPDATE, maybe others)
2) create a table (temp or non-temp)
3) call sqlite_exec with a callback that returns a non-zero result
4) do these things inside an explicit transaction
future updates/inserts will not fire triggers defined in the db... The only workaround I can find is to not return a non-zero result from callbacks...
Kevin Alons
Additional Info: Here is a quick c routine to duplicate the problem.
#include "sqlite/sqlite.h"
static int static_Callback(void *instance, int argc, char **argv, char **azColName)
{
return 1;
}
int main()
{
sqlite* db;
db = sqlite_open("c:\\test.db", 0, 0);
sqlite_exec(db, "CREATE TABLE Test (a);\n", 0, 0, 0);
sqlite_exec(db, "INSERT INTO Test (a) VALUES ('Test1');", 0, 0, 0);
sqlite_exec(db, "CREATE TABLE TrigResult (a);", 0, 0, 0);
sqlite_exec(db, "CREATE TEMP TRIGGER trigTest_AU AFTER UPDATE ON Test FOR EACH ROW BEGIN INSERT INTO TrigResult (a) VALUES (new.a); END;", 0, 0, 0);
//trigger fires just fine
sqlite_exec(db, "BEGIN; UPDATE Test SET a = 'Test2'; COMMIT;", static_Callback, &static_Callback, 0);
// select a single row (but use a callback that returns non-zero to terminate)
sqlite_exec(db, "BEGIN; SELECT Count(*) FROM Test; COMMIT;", static_Callback, &static_Callback, 0);
// trigger no longer fires
sqlite_exec(db, "BEGIN; UPDATE Test SET a = 'Test3'; COMMIT;", 0, 0, 0);
sqlite_exec(db, "BEGIN; UPDATE Test SET a = 'Test4'; COMMIT;", 0, 0, 0);
// 'Test2' will be in the TrigResult table, but not 'Test3' or 'Test4'
sqlite_close(db);
} |
Hmmm... Is the CREATE TRIGGER inside the same transaction that for
which the callback returns non-zero? A non-zero callback return causes
the transaction to rollback which effectively deletes the trigger.
Could that be the source of your problem?
No, the create trigger wasn't inside the transaction... I posted the test code previously, but later realized that it had errors that precluded it from properly identifying the problem. Instead I have created a new ticket (#420 for an enhancement that proposes a solution that works for me related to cancelling a callback). I am closing this ticket and hoping you can review my ticket #420 and include it (or something similar) in future sqlite releases. |
|
380 |
code
|
closed
|
2003 Jul
|
anonymous
|
Unknown
|
2003 Jul
|
|
2
|
2
|
"uniqueness constraint failed" on insertion of distinct rows
|
edit |
The below happens when running the 2.8.2-2 debian package, accessing sqlite through version 0.4.3 of the Python bindings.
The attached script permits reproduction of the issue. Note that the failing constraint is that on the primary key, "(filename, revision)", though both filename and revision are different between the two rows (the former changing from 11 to 111 and the latter from '1.1' to '1.10'). |
Works as designed. See http://www.sqlite.org/datatypes.html.
The SQL to reproduce the observed behavior is as follows:
create table revision (
changeset integer,
filename string,
revision string,
primary key (filename, revision),
unique (filename, changeset)
);
insert into revision values(11, 'controller/Controller.java', '1.1');
insert into revision values(111, 'controller/Controller.java', '1.10');
The uniqueness constraint that fails is the one associated
with the primary key. The datatype "string" on both the
FILENAME and REVISION columns does not contain characters
BLOB, CHAR, CLOB, or TEXT so it is interpreted as a numeric
datatype. Hence '1.1' is equal to '1.10'. The filenames are
also the same so the uniqueness check fails.
The solution here is to change the datatype of FILENAME and
REVISION to "TEXT". The following SQL works as desired:
create table revision (
changeset integer,
filename text,
revision text,
primary key (filename, revision),
unique (filename, changeset)
);
insert into revision values(11, 'controller/Controller.java', '1.1');
insert into revision values(111, 'controller/Controller.java', '1.10');
|
|
379 |
new
|
closed
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
|
5
|
1
|
use \' and \" instead of '' and "" only
|
edit |
It would be nice if
insert into tb1(1, 'something \'weird\' happens');
can be implemented
instead of only
insert into tb1(1, 'something ''weird'' happens'); |
The consensus on the mailing list is that this is a bad idea
and should be rejected. |
|
376 |
code
|
closed
|
2003 Jul
|
anonymous
|
BTree
|
2003 Aug
|
|
2
|
3
|
btree-1.1.1...../src/btree.c:2687: failed assertion `pPage->isInit'
|
edit |
Failed test: "make test"
btree-1.1.1...../src/btree.c:2687: failed assertion `pPage->isInit'
Also experienced
bigfile-1.1... Ok
**** Unable to create a file larger than 4096 MB. *****
bigrow-1.0... Ok
Don't know is the a bug or not.
Running on OS X 10.2.6 (Darwin). During normal operations things seem to be OK so I don't know how worried I should be with this failed test.
I would be happy to run the tests in gdb if that would help. Just tell me how to start up the tests from w/in gdb.
Thanks,
Jason |
This is a duplicate of ticket #369.
See that ticket for the resolution. |
|
375 |
new
|
closed
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
anonymous
|
4
|
4
|
I'm missing DB metadata.
|
edit |
I'm either unable to find any doc on the page or it's a missing feature.
I'm looking for a command(s) that return the DB metadata like tablenames, fieldnames and fieldtypes, index.
This would make it possable to create frontend GUI's using PHP for example. Or dyn. add missing fields a.s.o.
-- sam |
RTFFAQ: http://www.sqlite.org/faq.html#q9 |
|
374 |
code
|
closed
|
2003 Jul
|
anonymous
|
Pager
|
2003 Jul
|
|
1
|
1
|
btree crash in moveto - sqlitepager_get
|
edit |
I don't use the whole SQLite, just the Btrees. This bug only happens when I make a change in the database, close the transaction, open a new transaction, create a cursor a call sqliteBtreeMoveto(...). Then it crashes in sqlitepager_get(...) at this code:
if( pPager->aInJournal && (int)pgno<=pPager->origDbSize ){
sqliteCheckMemory(pPager->aInJournal, pgno/8);
assert( pPager->journalOpen );
pPg->inJournal = (pPager->aInJournal[pgno/8] & (1<<(pgno&7)))!=0;
pgno/8 is too big.
When I put another code working with Btree between the two transactions, the crash doesn't happen. |
Direct use of the btree layer is not supported. The btree interface
may change in unpredictable ways from one release to the next. If you
use the btree interface, you run the risk that a future version of
SQLite might break your code.
That said, we would still like to understand the problem you are
seeing. But without an actual test case or example code to produce
the error, there is not much we can do. |
|
372 |
event
|
closed
|
2003 Jul
|
anonymous
|
Unknown
|
2003 Jul
|
anonymous
|
1
|
1
|
tcl.h missing in windows source code
|
edit |
I have download windows source code from http://www.sqlite.org/download.html
I'm trying to build a C++ Builder Component (for borland fan) to make SQLite available inside C++ Builder EDI.
It seems that "tcl.h" is missing.
[C++ Error] tclsqlite.c(19): E2209 Unable to open include file 'tcl.h'
Where can I get full source code ?
(is SQLite community interested by such a component) |
Assuming you need TCL scripting integration then you can get it from here:
http://tcl.sourceforge.net/
If you're not interested in TCL integration then don't compile/link the files which need it.
I don't know who entered the remarks above, but they are
exactly right. If you don't want the TCL integration, don't
compile the files that use it. Case closed. |
|
371 |
event
|
closed
|
2003 Jul
|
anonymous
|
|
2003 Nov
|
|
1
|
1
|
crash in conflict.test
|
edit |
I have compiled sqlite 2.8.4 for windows
(using borland c++ 5.5) and while running the tests (all.test),
tcl (checked with both 8.4.2 and 8.4.3) crashed
while executing conflict.test.
the crash occurs in do_test_conflict-1.0 (it crashes before
the end of the execsql in that proc).
the lines are:
CREATE TABLE t1(a, b, c, UNIQUE(a,b));
CREATE TABLE t2(x);
SELECT c FROM t1 ORDER BY c;
i have checked, the same lines in memdb.test also
cause a crash.
regards,
s. boehme |
|
359 |
code
|
closed
|
2003 Jun
|
anonymous
|
|
2003 Jun
|
|
1
|
1
|
sum() returns incorrect value
|
edit |
The sum() statement on the 8th field below should return 0.00
sqlite> select * from gentrn where glt_cono = 1 and glt_acno = 6130;
1|6130|200203|20020331|4| 73|3.81|-1224.53|0.0|ACM|N|N|N
1|6130|200203|20020331|5| 302|3.71|74.60|0.0|DU B|N|N|Y
1|6130|200203|20020331|5| 302|3.71|590.43|0.0|marx|N|N|Y
1|6130|200203|20020331|5| 9980|3.71|244.5|0.0|kriel|N|N|Y
1|6130|200203|20020331|5|9909979|3.71|315.0|0.0|kriel|N|N|Y
1|6130|200205|20020531|4| 70|5.81|-92.10|0.0||N|N|N
1|6130|200205|20020531|5| 250302|5.71|92.10|0.0|MARX|N|N|Y
1|6130|200209|20020930|2| 270902|9.21|-284.80|0.0|mulligan|N|N|N
1|6130|200209|20020930|5| 902|9.71|284.80|0.0|DIETRICH|N|N|Y
sqlite> select sum(glt_tramt) from gentrn where glt_cono = 1 and glt_acno = 6130;
-1.13686837721616e-13
sqlite> |
A more lucid error report might have omitted all the irrelavent
fields. Like this:
SELECT glt_tramt FROM gentrn WHERE glt_cono=1 AND glt_acno=6130;
-1224.53
74.60
590.43
244.5
315.0
-92.10
92.10
-284.80
284.80
The answer you are getting is very close to zero. The difference
is due to the fact that several of the numbers you are adding
(ex: -1224.53) cannot be exactly represented in a finite-length
binary number. So your CPU is using an approximation. And when
you do a subtraction of two approximation, the error term gets
very big relative to the result.
If you only want two digits of precision in your result, use the
build-in SQLite function round(). Like this:
SQLITE round(sum(gmt_tramt),2) FROM ...
Works As Designed |
|
358 |
code
|
closed
|
2003 Jun
|
anonymous
|
Unknown
|
2003 Jun
|
|
1
|
1
|
Problems with inserting file (.bmp; .jpg) in BLOB field
|
edit |
create table pic (id integer, p blob);
insert into pic (id, p) values (1, 'c:/somedir/somefile.bmp'); //...or similar syntaxis - Don't work
copy pic(p) from 'c:/somedir/somefile.bmp' where id = 1; //...or similar syntaxis - Don't work |
Neither are suppose to work. See the documentation or ask questions
on the mailing list for additional help.
2005-Oct-03 02:47:54 by anonymous:
mind telling us how, then?
2005-Oct-03 05:53:52 by anonymous:
If you're reading this, you should see links entitled "documentation" and "mailing list" at the top of the page. Follow them.
Your problem is that you appear to expect that if you specify a filename as an argument to an INSERT statement involving a BLOB field, SQLite will insert the content of the file into the row. In fact, SQLite (or, for that matter, any SQL-based data management system) will insert the name of the file. If you want to insert the content, you'll have to first read it itself. |
|
344 |
event
|
closed
|
2003 Jun
|
anonymous
|
|
2003 Jun
|
|
1
|
1
|
select
|
edit |
SELECT
OBJECTID,
OBJECTTYPE,
VID_IMOT.name,
IMOTI.plsn_no,
IMOTI.no_kv,
IMOTI.parcel,
IMOTI.imm_area,
IMOTI.mestnost,
IMOTI.address,
IMOTI.komentar,
0,
IMOTI.MUNID,
IMOTI.KVID,
IMOTI.STRID,
IMOTI.STREETNUM,
IMOTI.BLOCK,
IMOTI.ENTR,
IMOTI.ET,
IMOTI.APART
FROM OBJECT_STATUS AS OS
INNER JOIN IMOTI ON OS.OBJECTID=IMOTI.IMOT_ID
INNER JOIN VID_IMOT ON IMOTI.VID = VID_IMOT.ID
WHERE DOC_ID IN(SELECT DOC_ID FROM DOKUMENTI
WHERE IZDATEL = 1 AND NO_AKT = '1' AND ENDDATE IS NULL)
AND DOC_ID IN (SELECT MAX(DOC_ID) FROM OBJECT_STATUS
WHERE OBJECTID = OS.OBJECTID AND DOC_ID <= 1000 AND ENDDATE IS NULL
AND TYPE = 1)
AND OS.type = 1AND OS.EndDate Is Null AND IMOTI.EndDate Is Null
AND OS.OBJECTTYPE <= 6
ORDER BY OBJECTID |
I do not understand what this ticket means. |
|
343 |
new
|
closed
|
2003 Jun
|
anonymous
|
Parser
|
2003 Jun
|
|
3
|
1
|
insert single quote value in SQL statement
|
edit |
I cannot insert value the single quote, "'".
sqlite> create table test(word varchar(30));
sqlite> insert into test values('test"');
sqlite> insert into test values('test2\'');
...>
...> ;
...> ;
I know the other RDBMS already support this, "\'".
Thanks. |
In standard SQL, the way to include a single quote in a string
is to double it, like in Pascal. Example:
INSERT INTO test VALUES('Hi, Y''all');
^^-- evaluates to a single
embedded quote.
The use of a backslash is nonstandard
and could (in theory) break well-formed SQL scripts.
Therefore, this change request is rejected. |
|
329 |
code
|
closed
|
2003 May
|
anonymous
|
Unknown
|
2003 May
|
|
3
|
3
|
sqlite_get_table() returns 1 row when there should be none
|
edit |
I have code which calls sqlite_get_table() with SQL like:
"select max(id) from people where id > 100 and id < 1000"
I get a row returned, which has the value NULL. I would expect to get nothing returned, since there is no id in the range. |
An aggregate without a HAVING clause should
always returns at least one row, I am told.
The current behavior is correct.
Perhaps you should try this:
SELECT id FROM people WHERE id>100 AND id<1000
ORDER BY id DESC LIMIT 1;
|
|
328 |
code
|
closed
|
2003 May
|
anonymous
|
Unknown
|
2003 May
|
|
2
|
1
|
Trigger accessing temp table now does not work
|
edit |
With Sqlite 2.8.0, regular table triggers had access to temp tables for selects and update/insert/delete functionality.
With Sqlite 2.8.2, the following error occurs (when attempting a select on a temp table from a regular table [non-temp, non-attached] trigger):
SQL error: table "Table_Name" is not in database "main"
Was this change in behaviour inadvertent or intentional? Obviously I am interested in preserving the previous behaviour if at all possible.
TIA,
Kevin |
The ability of 2.8.0 to access a temporary table from within
a non-temporary trigger was considered a bug and was fixed
for 2.8.2. TEMP triggers can access the main database, however.
Consider what could happen if these were not the case. Process
A could create a TEMP table X and a persistent trigger to fill
that table. Process B can see the persistent trigger but not
the table X. This means that whenever process B does anything
that fires the trigger, the trigger will fail and the operation
will abort. From the point of view of process B, the database
schema has been corrupted. Requiring that persistent triggers
not be able to access TEMP tables avoids this corruption.
What possible reason could you have for wanting things
to be otherwise? If you have a TEMP table that you want
to be filled or queried by a trigger, then make the trigger
TEMP too. That way, when the connection dies and the TEMP
objects are automatically deleted, the table and trigger
are dropped together and the database continues to work. |
|
325 |
code
|
closed
|
2003 May
|
anonymous
|
Parser
|
2003 May
|
|
3
|
3
|
Memory Leak with a cancelled sqlite_exec() using a callback routine
|
edit |
Memory leak:
Using sqlite_exec with a callback function, if false is returned in the callback (cancelling the query), 31 bytes are leaked. A new leak occurs everytime a query is cancelled in this manner. This leak occurs even if there is only 1 row to return and false is returned in the first callback.
Tested with a C++ application compiled with MSVC7 under WinXPsp1. Identical behaviour observed with versions 2.8.0 and 2.8.2. |
this was my own fault! I wasn't calling sqlite_freemem() on the returned error message from sqlite_exec(). Oops...
Just want to voice my appreciation for this product. It really is an awesome embedded database... |
|
324 |
todo
|
closed
|
2003 May
|
anonymous
|
VDBE
|
2005 Jan
|
|
1
|
4
|
ESCAPE clause in LIKE predicate not implemented
|
edit |
ESCAPE clause in LIKE predicate not implemented.
Syntax: SELECT ... WHERE col-name LIKE pattern [ESCAPE escape-char]
This is required to write a pattern containing a literal '_' or '%'.
where col like '@_%' escape '@'
should match rows where col begins with '_' |
|
320 |
doc
|
closed
|
2003 May
|
anonymous
|
|
2003 Jun
|
jplyon
|
5
|
3
|
PRAGMA documentation should include numeric values of settings
|
edit |
Documentation for PRAGMAs should include the numeric values since that is what the sqlite utility shows.
E.g.
sqlite> PRAGMA default_synchronous;
1
sqlite>
But the documentation shows values of FULL, NORMAL and OFF, doesn't mention which one of these is == 1. |
Documented all PRAGMA integer values. |
|
319 |
code
|
closed
|
2003 May
|
anonymous
|
Unknown
|
2003 May
|
|
1
|
1
|
Large Encoded Strings Get Truncated
|
edit |
Large strings get truncated. Is there an undocumented limitation on characters? |
There is a limit of 1MB of data per row. This is documented.
If you exceed the limit you get an error - nothing is ever
silently truncated.
Please provide additional information and include a test case
(as an attachment) so that your problem can be debugged.
In private correspondence, the originator reports that the problem
was caused by unencoded '\000' characters in the string.
Works as designed. |
|
314 |
event
|
closed
|
2003 May
|
anonymous
|
Unknown
|
2003 May
|
|
4
|
4
|
Memory usage
|
edit |
Hello. I recently began to use sqlite, but I'm stopped by the following consideration. Let's say we have a table created via
CREATE TABLE foobar (ID INTEGER PRIMARY KEY);
Then we do some inserts (of NULL value), e.g. 1000 transactions, each with 50 inserts. What struck me is that sqlite then have a memory consuption (according to top(1)) of 6.8% on a 256Mo-RAM system. Even MySQL stops to 3.7% after several days of intensive use :)
The problem is even more visible when using the Python bindings; for about 15000 inserts in one transaction, 20% of the memory is used, and isn't freed even when the connection object is destroyed. I cannot yet trace where it goes. I'm currently investigating this using Valgrind, but it doesn't show any memory leak.
So, is this normal, or is this really a "bug" ? Anyway, I'm going to try to analyze and fix it. After some heavy requests, my Python script uses up to 90% of the physical memory :)
Thanks for your work :)
BTW, my system is Slackware 8.1, with standard gcc (2.95-3) and glibc (2.2.5). |
I'm not able to reproduce this effect. Can you provide more
details?
In attempting to reproduce the result described above,
I ran a test which created a table as described above, then
did 5000 transactions each containing 250 INSERTs as follows:
INSERT INTO foobar VALUES(NULL);
That's a total of 1.25 million inserts. The final database
was 25MB in size. But at no time during the test did the
size of the SQLite process exceed 1468 pages (RSS and SIZE)
or 0.1% of memory.
Added by fraca7:
Sorry, false alert. The memory leak isn't in sqlite, and I was fooled by valgrind when trying to detect it :) |
|
304 |
code
|
closed
|
2003 May
|
anonymous
|
Shell
|
2003 May
|
|
3
|
3
|
DELETE on read-only db reporting error inconsistently
|
edit |
When a user does not have write permission on a database a "DELETE FROM table" statement in sqlite will fail silently, when using "DELETE FROM table WHERE col = 'x'" it fails with the error "SQL error: attempt to write a read-only database". I presume the second case is the correct one.
e.g.
sqlite> delete from draco_servers;
sqlite> delete from draco_servers where generation = 0;
SQL error: attempt to write a read-only database |
Unable to reproduce. |
|
287 |
new
|
closed
|
2003 Apr
|
anonymous
|
CodeGen
|
2005 Jan
|
drh
|
3
|
2
|
query execution time depend from tables order in FROM clause
|
edit |
create table t1(id integer primary key,a);
create table t2(id integer primary key,t1_id,b)
Insert 1000 records in t1 and for every record in master table t1 insert 1(one) record in t2. Create two queries:
Q1: select * from t2,t1 where t1.id=t2.t1_id
Q2: select * from t1,t2 where t1.id=t2.t1_id
Query Q2 is about 10 times slower than Q1! |
As currently implemented, the query optimizer for SQLite makes
no attempt to reorder the tables in a join. Perhaps this
should be documented.
2005-Jan-16 20:36:08 by drh:
There are no plans at this time to have SQLite try to reorder the
tables in the FROM clause of a query. |
|
283 |
code
|
closed
|
2003 Apr
|
anonymous
|
Parser
|
2003 Apr
|
|
3
|
1
|
Defect in sqlite_exec_vprintf
|
edit |
sqlite_exec_vprintf which I use in Delphi to process SQL statement with parameters causes sqlite.dll library (tested on 2.8.0) to crash when :
1. There is SQL statement with "like %" like:
select * from simpsons where LastName like '%burn%'
2 and valist is nil (no parameters ) seems that library improperly recognize % sign. |
When using sqlite_exec_vprintf() use two % symbols to generate a single
%. Like this:
SELECT * FROM simpsons WHERE lastname like '%%burn%%'
You only have to do this with sqlite_exec_vprintf() and the other
"printf"-style routines - not sqlite_exec(). This is a feature of
the printf-style interface, not a bug. |
|
274 |
code
|
closed
|
2003 Mar
|
anonymous
|
Unknown
|
2003 Apr
|
|
2
|
3
|
bug in sqlite_free_table
|
edit |
Hello! I've discovered what I believe is bug in sqlite (I use version 2.8.0, for Linux, compiled from source).
It looks like function sqlite_free_table is not working porperly. It doesn't nulify the pointer which I give to it; and if I call it twice with the same pointer it crash program with "Segmentation fault" message.... |
sqlite_free_table() works like the standard library function free().
It does not null its pointer (it can't because C uses call by value)
and it fails if you call it twice with the same pointer.
This is not a bug in SQLite - this is a bug in your program. |
|
267 |
code
|
closed
|
2003 Mar
|
anonymous
|
Unknown
|
2003 Mar
|
anonymous
|
1
|
4
|
sqlite.dll / sqlite.def does not export an Init function
|
edit |
My error: Gerhard Haering (PySQLite co-author) pointed out that
PySQLite is statically linked with sqlite - I was confusing things
by explicitly adding a naked copy of sqlite.dll
I removed that, it works. Case closed. Thanks.
I just downloaded the latest Windows binary DLL, filesize 102627.
Trying to use it with PySQLite & Python.
At
import sqlite
an error is raised:
Import error: dynamic module does not define init function (initsqlite)
I looked in sqlite.def and there is no reference to an init function being exported. I also looked in the .dll and son't see it there either. Is this an error in the DLL/def, or am I missing something?
Thanks.
John Hall. |
|
265 |
new
|
closed
|
2003 Mar
|
anonymous
|
Parser
|
2003 Mar
|
drh
|
2
|
3
|
SQLITE does not like prefixed columns
|
edit |
Queries like "SELECT <table>.<column> FROM <table>" perform OK. when you do the same with updates however, SQLITE does not like the prefixed columns and the query fails. i.e.: "UPDATE <table> SET <table>.<column> = <value>" will not work, while the statement "UPDATE <table> set <column> = <value>" works fine. |
SQL92 does not allow "SET <table>.<column> = <expr>". SQLite complies
with the standard. For that reason, I'm changing this into an
enhancement request.
You are right. I made use of some classes that were originally built for MySQL (which does support this). I amended the classes for use with ODBC/SQLITE and ran into this 'problem'.
It is not necessary to change SQLITE for this.
Thanks. |
|
264 |
code
|
closed
|
2003 Mar
|
anonymous
|
|
2005 Jan
|
|
5
|
4
|
Result of lseek for UNIX version of sqliteOsSeek() is not checked
|
edit |
G'day,
I've just been trying to get an sqlite build in my linux-based laptop to try a few modifications I have in mind, and ran the test suite for the first time on version 2.7.6. The second B-tree test failed on my machine (presumably because the big file support was not configured properly for some reason), reporting a malformed disk image.
Further invesigation showed that the first few characters of the database had been overwritten by "Hello, World!" which was used by test2.c to generate large files. The lseek had failed but sqliteOsSeek had returned SQLITE_OK. The code continued to execute and wrote the offending data into the wrong location in the file, thereby creating a malformed database. Presumably this won't affect anything else, much, but I thought it worth mentioning :)
Benjamin. |
2005-Jan-03 01:48:26 by drh:
Unix won't fail an lseek() if the file descriptor is valid. |
|
261 |
code
|
closed
|
2003 Mar
|
anonymous
|
Unknown
|
2003 Jul
|
|
2
|
3
|
Non Callback Finalize Bug
|
edit |
Using the non-callback api's I still need to "step" until the "eof" is triggered. Otherwise the "finalize" will fail. |
Unable to reproduce. I am able call sqlite_finalize() at any
time without problems.
>
Sorry, my fault. everything is ok for this report. |
|
260 |
doc
|
closed
|
2003 Mar
|
anonymous
|
|
2003 Mar
|
|
5
|
4
|
may i add a contributed by <mailadress> to the wiki HowToCompile ?
|
edit |
i just added the last two "HowToCompile" infos to the wiki and wondered why nobody let his contact adress like mail behind the contribution, may this be added or is this permitted ?
Bye
Bj�rn |
You should feel free to leave your own e-mail address on wiki
contributions if you like. Doing so is neither forbidden nor
required.
CVSTrac takes care to avoid exposing e-mail addresses to
anonymous users. This is done (in a likely vain attempt)
to prevent spammers from harvesting those addresses. But
if you are already on all the spam lists (like I am) and don't
mind making your e-mail address public, then by all means do
so. |
|
251 |
code
|
closed
|
2003 Feb
|
anonymous
|
|
2003 Mar
|
|
1
|
1
|
ORDER BY doesn't work on TIMESTAMP column type
|
edit |
Link http://sqlite.org/datatypes.html says sqlite supports TIMESTAMP type. I created table with TIMESTAMP column type. When I use "<" (less than) or ORDER BY clause on that column response is not expected.
ORDER BY on INTEGER or FLOAT works fine. Is it not supported for TIMESTAMP?
Following gives the steps I followed.
SQLite version 2.7.1
Enter ".help" for instructions
sqlite> create table date1(date timestamp, id INTEGER);
sqlite> select * from date1;
sqlite> insert into date1 values ('Feb 03 2003', 1);
sqlite> insert into date1 values ('Feb 02 2003', 2);
sqlite> insert into date1 values ('Jan 02 2003', 3);
sqlite> select * from date1 order by date;
date id
----------- ----------
Feb 02 2003 2
Feb 03 2003 1
Jan 02 2003 3
sqlite> select * from date1;
date id
----------- ----------
Feb 03 2003 1
Feb 02 2003 2
Jan 02 2003 3
sqlite> select * from date1 where date < 'Feb 03 2003';
date id
----------- ----------
Feb 02 2003 2
sqlite>
Thanks,
Latha |
SQLite works as designed.
Use the ISO-8601 date format to get SQLite to sort dates in
chronological order. |
|
248 |
code
|
closed
|
2003 Feb
|
anonymous
|
Unknown
|
2003 Nov
|
|
1
|
2
|
SQLColumn function in ODBC returns incorrect datatype
|
edit |
This is a bug in the ODBC driver for SQL Lite. The SQLColumn function returns a data of 'text' for every column and its size is set to 0. According to the SQLGetTypeInfo method, there is no type where the name is 'text'
We are the makers of WinSQL, an ODBC tool that allows users to connect to any ODBC compliant data source. You can download this tool from http://www.synametrics.com/winsql. One of our mutual client has submitted a bug on our site but since it is related to the ODBC driver, I wanted to submit a bug report here.
Thanks,
Imran. |
CHW writes:
As far as I understand, that is related to the ODBC driver only, but
is in consequence of the typelessness of SQLite. Using the SQLColumns()
ODBC API function a data source can be queried to obtain column information
of a table (data type, column name etc.) The column's data type is
reported as a data source specific string, 'text' in this case,
but normally what SQLite "pragma table_info('table')" returns.
The ODBC type which matches that data source specific type is
returned as an integer code, e.g. SQL_INTEGER, SQL_VARCHAR etc.
Another ODBC API function SQLGetTypeInfo() can be used to retrieve a
standardized result set describing the data types which the data source
knows about. That result set is hard wired in the ODBC driver and
does not have the mentioned 'text' type. Thus, the problem sits in
the schema of that specific database which does not have "create table"
statements which fit the hard wired SQLGetTypeInfo() information.
To fix it, I would have to "pragma table_info()" all tables of the
opened data base and construct a result set for SQLGetTypeInfo()
using some heuristic. However, it is questionable if this is worth
the work, since the default fallback type is always a ODBC string
type which fits SQLite perfectly.
|
|
228 |
event
|
closed
|
2003 Jan
|
anonymous
|
Unknown
|
2003 Jan
|
drh
|
1
|
1
|
The size of database file is not decreased .
|
edit |
After delete the records from the table,The size of the database file is not decreased. |
Correct. When information is deleted from the database, free
disk space
is added to a freelist within the database file and is reused again
as new information is added. But the free disk space is not returned
back to the operating system. SQLite database files can grow but not
shrink.
If you delete a lot of information from a database and want to shrink
it, do so as follows:
sqlite old.db .dump | sqlite new.db
|
|
214 |
code
|
closed
|
2003 Jan
|
anonymous
|
Unknown
|
2003 Jan
|
|
1
|
1
|
segmentation fault on ETRAX board - started in version 2.7.4
|
edit |
sqlite_exec constantly causes a segmentation fault on embedded ETRAX 100 (risc) board.
the exact same code works fine with version 2.7.3 - but fails with 2.7.4.
the OS is redhat linux - but the same code runs fine on the same linux running on a pc.
i cannot debug it on the embedded device - so i can't give much more info.
any idea? |
Could this be related to ticket #210?
Is the ETRAX a big endian processor?
this was due to a bug in the AXIS-ETRAX board support package - fixed. |
|
205 |
code
|
closed
|
2002 Dec
|
anonymous
|
VDBE
|
2002 Dec
|
|
4
|
4
|
select order by on a column with null values causes uninitialized-read
|
edit |
On Windows, compiled with Visual Studio C++ 7.0, sending SQLite the following statements:
create table x (y text, z text);
insert into x (y) values ('1');
insert into x (y) values ('2');
select * from x order by z desc;
causes an uninitialized read of memory in the file:
** $Id: util.c,v 1.50 2002/08/26 19:55:08 drh Exp $
at the end of the function:
int sqliteSortCompare(const char *a, const char *b)
within the line:
if (dir=='-' || dir=='D') res = -res;
because 'dir' is never initialized when the function is passed two empty (empty, not null) strings to compare.
I just changed it to:
if (res && (dir=='-' || dir=='D')) res = -res;
as res is initialized, but I didn't look very hard to see if something 'more bad' was happening (eg, was this function not supposed to receive empty strings...).
Thank you for the great lightweight SQL database. Have you ever run it through a memory profiler? I tried it on Windows with BoundsChecker and BC complained a few times about memory being lost -- not sure if it was a spurious report by BC or not though. |
This has already been fixed.
See check-in [757]
on 2002-Sep-29.
Compiling SQLite with the -DMEMORY_DEBUG=1 flag enables a built-in
memory profiler. The test suite does this and finds no memory leaks.
There are also provisions in the test code for simulating out-of-memory
conditions (when malloc() returns NULL). The test suite shows that
SQLite responds sensibly to such occurrances. |
|
201 |
doc
|
closed
|
2002 Dec
|
anonymous
|
Unknown
|
2003 Nov
|
|
1
|
1
|
it is very well if there is a table lock! but ...
|
edit |
it is very well if there is a table lock! but ... |
Don't know what this means.... |
|
199 |
new
|
closed
|
2002 Dec
|
anonymous
|
Unknown
|
2005 Jan
|
drh
|
4
|
4
|
Encryption
|
edit |
Congratulations on your wonderfull job.
I miss a table encryption feature. I know it is not easy, but can you tell me if it is in your plans?
I could try to do it my self but, unfortunately, your code generates hundrends of warnings in Borland's C++ Builder and a lot of errors, to the extend that even if I manage it to compile, it won't work. |
2005-Jan-16 20:00:48 by drh:
Encryption is available as an add-on.
2005-Feb-03 18:01:54 by anonymous:
What add-on can be used to add encryption? Where can you get it?
2005-Mar-01 06:34:27 by anonymous:
Nothing mentioned about from where to get SQLite add-on for encryption. Please mention somewhere.
2005-Mar-01 06:52:22 by anonymous:
Look here:
http://www.hwaci.com/sw/sqlite/prosupport.html
|
|
196 |
code
|
closed
|
2002 Nov
|
anonymous
|
BTree
|
2003 Jul
|
|
4
|
3
|
there are the same record in a table,why?
|
edit |
there are the same record in a table,why? how to do? |
I do not know what this ticket means... |
|
188 |
todo
|
closed
|
2002 Nov
|
drh
|
|
2002 Nov
|
|
1
|
1
|
Serialize disk I/O
|
edit |
Modify the pager so that when it flushes its buffers to the disk
it attempts to do so in sequential order. When two or more
adjacent pages are written, write them with a single write() call
instead of two writes() with an intervening lseek(). Check to see
if this improves performance. |
you are probably not going to get much improvement. I think what you are trying to do is called "elevator seeks" which is handled by the OS anyway.
You're right. I didn't get any noticable improvement. |
|
183 |
code
|
closed
|
2002 Oct
|
anonymous
|
|
2002 Nov
|
drh
|
1
|
1
|
Bug regarding grouping, left joining, aggregate functions
|
edit |
There is a bug regarding grouping, left joining, aggregate functions.
I sent a mail containing a database dump to drh@hwaci.com. |
Bug does not reproduce in version 2.7.3 |
|
182 |
event
|
closed
|
2002 Oct
|
anonymous
|
Unknown
|
2002 Oct
|
|
1
|
1
|
Win32 DBI Interface crashes Perl.exe
|
edit |
When I try to use the Perl DBI-Interface to SQlite (DBI:SQLite) Perl.exe is crashing. IF I use sqlite.dll from sqlite.org, a Perl error (boot___SQlite ..not found) is coming up. Does anybody ever used this Module? |
This appears to be a bug report against the SQLite DBI interface.
But that interface is a separate project that is not directly
affiliated with this site. So I'm closing this bug. |
|
181 |
code
|
closed
|
2002 Oct
|
anonymous
|
Unknown
|
2002 Oct
|
anonymous
|
5
|
5
|
MAX Function on NULL Values
|
edit |
MAX produces undefined output, if column has NULL values:
sqlite> SELECT partno,MAX(price),MIN(price),AVG(price) FROM quotations GROUP BY partno;
quotations MAX(price) MIN(price) AVG(price)
---------- ---------- ---------- ----------
.....
P207 pÄ♦ NULL 1735
|
This was fixed 5 months ago in version 2.5.0. |
|
170 |
code
|
closed
|
2002 Oct
|
anonymous
|
TclLib
|
2002 Oct
|
anonymous
|
2
|
2
|
Insert / select text with cp1250 characters
|
edit |
I have problem saving data in proper encoding using tclsql package. From the sqlite commad line inserts work perfectly, but if I try to insert the same in TCL script the row is inserted, unfortunately, some characters with diacritics are replaced by question marks '?'. Text is in Central European(Windows-1250). The same problem is also with UTF-8 encoding. This happens on MS Windows platform. |
I want to withdraw this ticket. The real problem is with inserting/selecting binary data (without nuls).
Wojtek |
|
167 |
new
|
closed
|
2002 Oct
|
anonymous
|
Shell
|
2002 Dec
|
|
5
|
4
|
Difficult to quickly quit sqlite
|
edit |
It would be nice if ctrl-C worked to quit from sqlite. It doesn't work on Debian GNU/Linux. |
Ctrl-D works.
Ctrl-D does not print a newline, so the shell prompt appears after the sqlite prompt (doesn't look "clean"). Though I appreciate the tip :) |
|
165 |
code
|
closed
|
2002 Oct
|
anonymous
|
VDBE
|
2002 Oct
|
anonymous
|
1
|
1
|
can create and change tickets, without logged in
|
edit |
I can also edit open tickets without logged in.
The top line shows 'Not logged in'
I use IE 5.0 on NT with SP6 |
This is a feature, not a bug. |
|
162 |
code
|
closed
|
2002 Oct
|
anonymous
|
Unknown
|
2002 Oct
|
anonymous
|
3
|
2
|
mismatch in response column and Group by column is ignored
|
edit |
In the select statement if response column name is not there in the group by clause sqlite is not giving error. It prints some values for that response column.
Ex:tbl1 has 2 columns (f1, f2)
sqlite>select * from tbl1;
f1 ------ f2
2 ------ 2
3 ------ 2
1 ------ 5
1 ------ 2
1 ------ 2
2 ------ 3
sqlite>select f2, sum(f2) from tbl1 group by f1;
f2 ------ sum(f2)
5 ------ 9
2 ------ 2
2 ------ 5
In the above case f2 is not in the group by clause. Still it is printing some value of f2.
In Oracle same query gives following error:
SQL>select f2, sum(f2) from tbl1 group by f1
*
ERROR at line 1:
ORA-00979: not a GROUP BY expression |
SQLite does not require the columns used in the GROUP BY clause
to be elements in the result set. This is a feature, not a bug. |
|
161 |
code
|
closed
|
2002 Oct
|
anonymous
|
Unknown
|
2003 Dec
|
|
1
|
1
|
Left join with 3 tables bug ?
|
edit |
On the sql statements bellow the first "left join" with 2 tables return one row but in the second with 3 tables no rows are returned but it's expected to return 1 as well.
Just in case of it's possible allow parentesis to define the join order when more than 2 tables are used will be nice.
drop table gl;
CREATE TABLE gl (
id integer primary key,
source text,
description text,
transdate date DEFAULT current_date,
employee_id int
);
drop table chart;
CREATE TABLE chart (
id integer primary key,
accno text NOT NULL,
description text,
charttype char(1) DEFAULT 'A',
category char(1),
link text,
gifi_accno text
);
drop table acc_trans;
CREATE TABLE acc_trans (
trans_id int,
chart_id int,
amount float,
transdate date DEFAULT current_date,
source text,
cleared bool DEFAULT 'f',
fx_transaction bool DEFAULT 'f'
);
insert into chart values(1,'0001','account 1','A','E','link','23');
insert into gl values(1, 's1', 'some description','01/01/2002',0);
select gl.id, gl.source, gl.description, acc_trans.transdate
from gl left join acc_trans on gl.id = acc_trans.trans_id;
select gl.id, gl.source, gl.description, acc_trans.transdate, chart.accno
from gl left join acc_trans on gl.id = acc_trans.trans_id
left join chart on acc_trans.chart_id = chart.id; |
Sorry but what happens in the second select with 3 tables is that one record is returned with only blank or null field values.
In the real database when records are added to de acc_trans table it works correctly.
And comparing the result of a explain when it works and when not it's identical so is something in the execution phase.
Unable to reproduce. No changes to code. |
|
158 |
code
|
closed
|
2002 Oct
|
anonymous
|
Unknown
|
2002 Oct
|
|
3
|
2
|
Union doesn't check for data types
|
edit |
I have two tables.First table has both the columns of type int and the second table has both the columns of type varchar.When I do a union on these two tables,I get no error message. |
This is a feature, not a bug.
See http://www.sqlite.org/datatypes.html |
|
157 |
code
|
closed
|
2002 Oct
|
anonymous
|
Unknown
|
2002 Oct
|
anonymous
|
3
|
2
|
Doesn't check for data types
|
edit |
I have created a table with two columns of type int.I get no error message,when I insert values of type string into this table. |
This is a feature, not a bug.
see http://www.sqlite.org/datatypes.html |
|
156 |
code
|
closed
|
2002 Oct
|
anonymous
|
Unknown
|
2002 Oct
|
|
1
|
1
|
Cannot log in to CVSTraq because no "create account page"
|
edit |
The one-line summary says it all. I cannot log in, and apparently, other users cannot, either, as there only seem to be "anonymous" reports. |
The CVSTrac bug tracking system is an independent project.
This bug already exists on that project.
See http://www.cvstrac.org/tktview?tn=18. |
|
149 |
new
|
closed
|
2002 Sep
|
anonymous
|
Unknown
|
2002 Sep
|
|
5
|
4
|
SELECT UNIQUE
|
edit |
It would be nice if Sqlite understood a SELECT UNIQUE construct, so that one could do a "SELECT UNIQUE x FROM table". Currently I'm using "SELECT x FROM table UNION SELECT x FROM table" to get a list of unique x's, and I know of no better way of accomplishing this.
Thanks! |
The correct syntax is SELECT DISTINCT. |
|
148 |
code
|
closed
|
2002 Sep
|
anonymous
|
Unknown
|
2002 Sep
|
anonymous
|
3
|
3
|
sqlHashFind() segfaults in a created function
|
edit |
In main:
Hash *re_cache;
re_cache = sqliteMalloc(sizeof(Hash *));
sqliteHashInit(re_cache, SQLITE_HASH_BINARY, 0);
sqlite_create_function(db, "matches", 2, matchFunc, re_cache);
sqlite_function_type (db, "matches", SQLITE_NUMERIC);
In matchFunc:
static void matchFunc(sqlite_func *context, int argc, const char **argv) {
Hash *re_cache;
pcre *re;
/* ... */
re_cache = (Hash *)sqlite_user_data(context);
re = (pcre *)sqliteHashFind(re_cache, argv[0], 1 + strlen(argv[0]));
/* ... */
}
Induce a segmentation fault:
zsh% make && ./sqlite TMP
SQLite version 2.6.3
Enter ".help" for instructions
sqlite> select matches('\d', '4445');
zsh: segmentation fault (core dumped) ./sqlite TMP
Get dump:
zsh% gdb ./.libs/lt-sqlite lt-sqlite.core
Core was generated by `lt-sqlite'.
Program terminated with signal 11, Segmentation fault.
(gdb) bt
0 findElementGivenHash (pH=0x805d140, pKey=0x806a210, nKey=3, h=5144)
at ./src/hash.c:213
1 0x2807f155 in sqliteHashFind (pH=0x805d140, pKey=0x806a210, nKey=3)
at ./src/hash.c:270
2 0x280809ba in matchFunc (context=0xbfbfe6dc, argc=2, argv=0x805e280)
at ./src/local_func.c:53
3 0x280919cf in sqliteVdbeExec (p=0x805c600, xCallback=0x8049254 <callback>,
pArg=0xbfbfea3c, pzErrMsg=0xbfbfe960, pBusyArg=0x0, xBusy=0)
at ./src/vdbe.c:1884
4 0x280764fc in sqliteExec (pParse=0xbfbfe94c) at ./src/build.c:73
5 0x28084fc5 in yy_reduce (yypParser=0x806b800, yyruleno=3) at parse.y:67
6 0x280865c3 in sqliteParser (yyp=0x806b800, yymajor=103, yyminor={
z = 0x80652dc ";", n = 1}, pParse=0xbfbfe94c) at parse.c:6633
7 0x2808cae6 in sqliteRunParser (pParse=0xbfbfe94c,
zSql=0x80652c0 "select matches('\\d', '4445');", pzErrMsg=0xbfbfe9f8)
at ./src/tokenize.c:456
8 0x28081971 in sqlite_exec (db=0x805c000,
zSql=0x80652c0 "select matches('\\d', '4445');",
xCallback=0x8049254 <callback>, pArg=0xbfbfea3c, pzErrMsg=0xbfbfe9f8)
at ./src/main.c:626
9 0x804ad5b in process_input (p=0xbfbfea3c, in=0x0) at ./src/shell.c:953
10 0x804b499 in main (argc=2, argv=0xbfbff390) at ./src/shell.c:1185
11 0x8048de9 in _start ()
(gdb) print pH->ht
$1 = (struct _ht *) 0x6374616d
(gdb) print pH->ht[0]
Cannot access memory at address 0x6374616d.
Not very familiar with C programming ... help. |
Should be:
re_cache = sqliteMalloc(sizeof(Hash));
^^^^----- No "*".
|
|
145 |
code
|
closed
|
2002 Aug
|
anonymous
|
Unknown
|
2002 Aug
|
|
1
|
1
|
Tests failing
|
edit |
I just compiled sqlite-2.7.0 on a Linux-2.4.19 ix86 box. The make test is failing as follows:
trans-8.3... Ok
trans-9.1...
Error: no such function: randstr
trans-9.2.1-0...
Error: cannot start a transaction within a transaction
trans-9.2.2-0...
Error: cannot start a transaction within a transaction
trans-9.2.9-0...
Error: no such function: randstr
trans-9.3.1-0...
Error: cannot start a transaction within a transaction
trans-9.3.2-0...
Error: cannot start a transaction within a transaction
trans-9.3.9-0...
Error: no such function: randstr
trans-9.4.1-0...
Error: cannot start a transaction within a transaction
trans-9.4.2-0...
Error: cannot start a transaction within a transaction
trans-9.4.9-0...
Error: no such function: randstr
trans-9.5.1-0...
Error: cannot start a transaction within a transaction
*** Giving up...
11 errors out of 6749 tests
Failures on these tests: trans-9.1 trans-9.2.1-0 trans-9.2.2-0 trans-9.2.9-0 trans-9.3.1-0 trans-9.3.2-0 trans-9.3.9-0 trans-9.4.1-0 trans-9.4.2-0 trans-9.4.9-0 trans-9.5.1-0
make: *** [test] Error 1
If you need more information, just email me... |
This was a problem in the Makefile, not in the code.
It's fixed now.
Works for me:
0 errors out of 7193 tests
|
|
144 |
new
|
closed
|
2002 Aug
|
anonymous
|
Unknown
|
2002 Aug
|
|
4
|
3
|
Read/Write Locks under Windows NT/2000/XP (simul. access)
|
edit |
SQLite doesn't allow multiple Threads/Processes simul. access to a SQLite database (if a transaction begins, the database is completely WRITE-Locked) under Windows.
A patch is availabe (http://groups.yahoo.com/group/sqlite/message/1577) that allows r/w locks at least under Windows NT/2000/XP.
Of course, I can send you the patch again via E-Mail. |
Reader/writer locks for windows have already been implemented
(see check-in [714]
).
When a transaction begins, the entire database is write-locked.
Always. This is not a windows thing. The rule for SQLite is that
there can be multiple readers or a single writer. It used to be
that under windows there could only be a single reader. That
restriction was lifted by check-in [714]
- now windows may have
multiple readers. But it has always been the case for all OSs
that SQLite would only allow a single process to write to the
database at one time. |
|
143 |
code
|
closed
|
2002 Aug
|
anonymous
|
Unknown
|
2002 Aug
|
anonymous
|
1
|
3
|
order by and null columns
|
edit |
The results of order by are inconsistent for the secondary sort
key if the primary sort key is null. Example sql code is below
which illustrates the problem. The first select returns
c
b
a
while the second returns
a
b
c
create table a (x, y);
insert into a values (null, 'a');
insert into a values (null, 'b');
insert into a values (null, 'c');
select * from a order by x, y;
select * from a order by y; |
This appears to be a duplicate of ticket #142 which was
fixed by check-in [730]
. |
|
141 |
code
|
closed
|
2002 Aug
|
anonymous
|
Unknown
|
2002 Aug
|
|
1
|
3
|
Using the incorrect format inhibits record update
|
edit |
If, inside a c code, you use something like:
"UPDATE TABLE PIPPO SET PLUTO=%d"
but PLUTO is defined float and you pass a float to the sqlite_exec_printf() that does the update, then the record is NOT updated and no error is reported. |
If you pass a float to a %d format string, you are going
to have problems. I'm not sure there is anything SQLite
can do about it. |
|
127 |
event
|
closed
|
2002 Jul
|
anonymous
|
Unknown
|
2003 Jan
|
|
4
|
5
|
testfixture crashes with bus error following misuse-5.3 test
|
edit |
While investigating another test failure, I recompiled sqlite 2.6.2 with -DSQLITE_TEST and MEMORY_DEBUG undefined. With just SQLITE_TEST defined, the quick test suite crashes testfixture just following the misuse-5.3 test.
misuse-5.3... Ok
make: *** [test] Bus error
The test appears to pass, then testfixture bus errors. From the stack trace, the crasher seems to appear during an attempt to manipulate a path in the file system. I'm using Tcl 8.4b4 on Mac OS X 10.1.5, and there may be bugs in it's implementation here.
Command: testfixture
PID: 28398
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000008
Thread 0 Crashed:
#0 0x70004460 in szone_malloc
#1 0x700042c8 in malloc_zone_malloc
#2 0x70004204 in malloc
#3 0x7000afe4 in __opendir2
#4 0x70038ebc in getcwd_physical
#5 0x7003f728 in realpath
#6 0x0a071b38 in TclpObjNormalizePath
#7 0x0a04a2ec in TclNormalizeToUniquePath
#8 0x0a04a21c in FSNormalizeAbsolutePath
#9 0x0a04b1c4 in Tcl_FSGetCwd
#10 0x0a04d09c in Tcl_FSGetNormalizedPath
#11 0x0a04d5b0 in Tcl_FSGetFileSystemForPath
#12 0x0a04aac8 in Tcl_FSStat
#13 0x0a04a744 in Tcl_FSEvalFile
#14 0x0a01aed8 in Tcl_SourceObjCmd
#15 0x0a00e508 in TclEvalObjvInternal
#16 0x0a00edcc in Tcl_EvalEx
#17 0x0a04a858 in Tcl_FSEvalFile
#18 0x0a01aed8 in Tcl_SourceObjCmd
#19 0x0a00e508 in TclEvalObjvInternal
#20 0x0a031f14 in TclExecuteByteCode
#21 0x0a03151c in TclCompEvalObj
#22 0x0a00f1d0 in Tcl_EvalObjEx
#23 0x0a0154a4 in Tcl_ForeachObjCmd
#24 0x0a00e508 in TclEvalObjvInternal
#25 0x0a00edcc in Tcl_EvalEx
#26 0x0a04a858 in Tcl_FSEvalFile
#27 0x0a049da0 in Tcl_EvalFile
#28 0x000156d4 in main
#29 0x00002054 in _start
#30 0x00001e84 in start
I'm submitting this FYI. Lots of folks have been using sqlite under Mac OS X with no apparent problems, so I'm not sure there's that much cause for concern. |
Methinks this is a TCL bug, not an SQLite bug. |
|
125 |
code
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Jul
|
|
2
|
1
|
Data and Category SELECT bug
|
edit |
I think this is a bug in the Btree, but who knows.
If a category's name is equal to the data within the field a SELECT statement doesnt work correctly. The value does get inserted however.
sqlite> select * from course;
id|category|shortname|longname|grp|units
1|CHEM|001A|GENERAL CHEMISTRY|A|5
2|CHEM|001A|GENERAL CHEMISTRY|B|5
sqlite> insert into course values (NULL, "category", "test", "test2", "A", 6);
sqlite> select * from course;
id|category|shortname|longname|grp|units
1|CHEM|001A|GENERAL CHEMISTRY|A|5
2|CHEM|001A|GENERAL CHEMISTRY|B|5
3|category|test|test2|A|6
sqlite> select id from course where category="category";
id
1
2
3
The last SQL statement should - in theory - return one record... This is running on windows and I have duplicated it on linux... |
Double-quoted strings are interpreted as column names if possible.
So your WHERE clause is the same as
category=category
which is always true.
Use a single-quoted string to mean a string literal. Like this
... WHERE category='category'
|
|
124 |
code
|
closed
|
2002 Jul
|
anonymous
|
Unknown
|
2002 Sep
|
anonymous
|
2
|
1
|
Segfault on a join using an INTEGER PRIMARY KEY.
|
edit |
The following SQL causes a segfault:
CREATE TABLE t5(a INTEGER PRIMARY KEY);
CREATE TABLE t6(a INTEGER);
INSERT INTO t6 VALUES(NULL);
INSERT INTO t6 VALUES(NULL);
INSERT INTO t6 SELECT * FROM t6;
INSERT INTO t6 SELECT * FROM t6;
INSERT INTO t6 SELECT * FROM t6;
INSERT INTO t6 SELECT * FROM t6;
INSERT INTO t6 SELECT * FROM t6;
INSERT INTO t6 SELECT * FROM t6;
SELECT * FROM t6 NATURAL JOIN t5;
|
|
123 |
new
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Jul
|
|
3
|
3
|
Would like Query type info
|
edit |
If I understand ticket #68 correctly, I would like to second it.
That is, it would be VERY useful to be able to get the type
info for a query that has been submitted (perhaps the same
kind of info you return for table_info). This would permit proper
formating of numbers (with commas, ...) etc. MySQL supplys a
programming API that returns this info in a nice format. |
Duplicate of ticket #68 |
|
122 |
new
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Jul
|
|
3
|
3
|
BLOB support needs only an escape_string() function.
|
edit |
It would be nice to be able to handle binary data in SQLite. Ticket
67 proposes a solution, but none of that is necessary. You just need
an escape_string() function (this is MySQL's name) that
takes arbritary data input, a length of the data, and outputs a
string that can be feed to SQLite. It seems to me that you need only
add a zero value to your current escape codes to make it work.
I.e. if you define that a zero is '0 where 0 is a binary zero, then
you have everything you need. |
Function already exists: sqlite_encode_binary() |
|
121 |
code
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Jul
|
|
1
|
1
|
Bug LEFT JOIN - GROUP BY
|
edit |
Create a database as follows:
BEGIN TRANSACTION;
create table a(id);
INSERT INTO a VALUES(1);
INSERT INTO a VALUES(2);
INSERT INTO a VALUES(3);
create table b(id);
INSERT INTO b VALUES(2);
INSERT INTO b VALUES(3);
INSERT INTO b VALUES(3);
INSERT INTO b VALUES(4);
INSERT INTO b VALUES(5);
INSERT INTO b VALUES(5);
INSERT INTO b VALUES(5);
INSERT INTO b VALUES(5);
INSERT INTO b VALUES(5);
INSERT INTO b VALUES(6);
INSERT INTO b VALUES(7);
create index ax on a(id);
create index bx on b(id);
COMMIT;
And for the following query:
select A.id from a LEFT JOIN b on a.id = b.id where A.ID = 3 group by a.id;
I get 2 rows.
I found (in a big database) a case like
select ... , count(x.id) from .... left join X on .... group by ...
the count is very big, but it must be 0 |
SQLite ignores the GROUP BY clause if there are no aggregate
functions in the result set. This is by design. |
|
120 |
code
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Jul
|
|
1
|
1
|
Strange comparison logic
|
edit |
I know that strings that are numbers are treated differently. But:
select 'a' < 'b';
returns 1, witch is OK
select 'a' < '1';
returns 0, witch is OK
select ' ' < '1';
returns 0, witch is BAD
select '1' < '2';
returns 1 witch is OK
select '12' < '2';
returns 0 witch is OK if you consider numbers, BAD, if you consider strings
select '2x' < '4x';
returns 1 which is OK
but:
select '2x' < '4';
returns 0 which is BAD.
Why if one of the operands is a number, than it is done a number comparison? I think that the correct way is to do a number comparison if BOTH operands are numbers. |
The comparison rules are as follows:
- If it looks like a number, treat it as a number.
- Anything that is not a number and is not NULL is a string.
- NULL comes before everything.
- Strings come after numbers and are ordered according to memcmp().
- Numbers come before strings and after NULL and
are ordered by value.
The comparisons in the description are consistent with these rules. Nothing
needs to be changed. |
|
119 |
doc
|
closed
|
2002 Jul
|
anonymous
|
|
2003 Jul
|
|
5
|
5
|
How to Compile Sqlite.dll With VC++
|
edit |
How to Compile Sqlite.dll With VC++
or Else Language |
This is documented for the current version of VC++ in the following web page:
http://cvs.hwaci.com/sqlite/wiki?p=HowToCompileWithVsNet |
|
118 |
code
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Jul
|
|
1
|
1
|
Under WinNT4.04 Call Opendatabase or Else Function Generate Error
|
edit |
Os is Win Nt4.04.
1. When Call Sqlite_Open Function Display Error Msg "No Such Table: Sqlite_Temp_Master".
2. When Call Sqlite_Exec Function Ok, But Call Sqlite_Get_Table Function Generate Fatal Error: 'ntdll.dll entry error' |
Unable to reproduce either problem.
The test suite for SQLite calls both of these functions many times
without error. I've just rerun the test suite under WinNT4 service
pack 4, and everything works fine. |
|
117 |
code
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Jul
|
|
1
|
1
|
run err with Hint Call msvcrt.dll.
|
edit |
under win98 use sqlite.dll display err, as Call msvcrt.dll Error |
Duplicate of #116. |
|
116 |
code
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Jul
|
|
1
|
1
|
run err with Hint Call msvcrt.dll.
|
edit |
under win98 use sqlite.dll display err, as Call msvcrt.dll Error |
Description is undecypherable. |
|
115 |
new
|
closed
|
2002 Jul
|
anonymous
|
Unknown
|
2003 Nov
|
|
1
|
5
|
table_info() missing datatypes
|
edit |
Asking SQLite for table information as in "PRAGMA table_info(sometable)" does not return the datatypes in the CallBack routine.
Setting "PRAGMA show_datatypes=ON" makes the CallBack return datatypes for column names for regular queries but this does not help the table_info call. |
2003-01-18: I'm not able to reproduce this now. There have been
a lot of fixes and enhancements since this issue was written.
I'm going to assume it is fixed. |
|
114 |
code
|
closed
|
2002 Jul
|
anonymous
|
Unknown
|
2002 Sep
|
|
2
|
3
|
Concurrency problem in sqlite_open when automatic upgrading
|
edit |
A code path exists which produces the error message
unable to upgrade database to the version 2.6 format: table sqlite_master already exists
during sqlite_open() when the database is currently locked by
another process/thread but is already in proper 2.6 format.
As far as I understand the sqlite_open() code there might be
an error in handling the situation when sqliteInit() returns
SQLITE_BUSY and later the sqlite.format field is checked for
the version of the database file in order to perform an upgrade
of the database format. |
|
113 |
doc
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Aug
|
|
5
|
5
|
Incorrect description of SQLite
|
edit |
The page http://www.hwaci.com/sw/index.html contains incorrect description of the product:
SQLite is a C library that functions as an SQL frontend to a GDBM database. |
|
112 |
code
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Sep
|
|
4
|
4
|
Segmentation fault in 2.5.5 when opening a 2.6.1 database
|
edit |
If you open a 2.6.1 database with version 2.5.5 (admittedly not
a very smart thing to do), you get a segmentation fault. I do not
consider this serious, but thought you might want to know since
might be able to avoid a future problem in examining this. |
This problem was fixed in check-in [688]
, which occurred after
version 2.5.5, unfortunately. |
|
111 |
doc
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Sep
|
|
1
|
3
|
2.6.1 does not permit SELECT within TRANSACTION whereas 2.5.5 did
|
edit |
In order to improve performance during a large number of INSERTs, I
enclose them 10,000 at a time within a BEGIN. At the same time, I
issue relatively small number of SELECT commands. In version 2.5.5
this all worked fine. In version 2.6.1, I get the following error:
rufus-dir: Job kernsave.2002-07-24.08:07:54 Error: sql_get.c:476 query SELECT PoolId, Name, NumVols, MaxVols, UseOnce, UseCatalog, AcceptAnyVolume, AutoPrune, Recycle, VolRetention, PoolType, LabelFormat FROM Pool WHERE Pool.PoolId=1 failed:
library routine called out of sequence
This error does not occur if I do not start the TRANSACTION
I'm not sure if this is a bug or a "feature", but it effectively
eliminates the possibility of using a TRANSACTION for a large
number of INSERTs (50,000-100,000). |
You must be running Linux and doing the SELECTs from a different
thread that the INSERTs, huh? There is a test added to 2.6.1 that
rejects attempts to access the database from a different process
than the one that started the transaction. This test was added to
prevent people from starting a transaction, doing a "fork()" then
trying to commit the transaction in the child. But under Linux,
depending on how you implement your threads, sometimes each thread
has a different processID and so the test fires in that case too.
From_author_of_bug:_Kern_Sibbald
I am doing the INSERTs and the SELECTs in a different thread from
the one that started the TRANSACTION, but both the INSERTs and the
SELECTs are done in the same thread. Under Linux (at least mine),
all threads have a different process id -- always.
I guarantee that only one thread at a time calls SQLite, and they
all use exactly the same open packet.
Is there any way I can turn this new behavior off?
Answer: No. You will need to start the transaction in the same
thread that does the INSERTs and SELECTs. Well, maybe. If you
make a bootleg change so that the sqliteOsProcessId() function
always returns a constant, you will effectively disable the check.
But I'm not sure doing so is a good idea. You really should do
the entire transaction from a single thread.
The resolution of this ticket is to update the documentation to
explain that LinuxThreads (because they do not follow the Posix
standard) do not allow transactions to be started in one thread
and completed in another. |
|
110 |
new
|
closed
|
2002 Jul
|
anonymous
|
Unknown
|
2002 Sep
|
anonymous
|
5
|
4
|
Refuse multiple begin transaction or commit
|
edit |
Sqlite allows multiple begin transaction or commit commands, or commits without a transaction open, to be issued without reporting an error. I think that if an error would be reported it would be useful, especially during application development where multiple commands may be issued by mistake. |
|
109 |
new
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Jul
|
|
5
|
4
|
Can the build process include a way to make a static library?
|
edit |
I am building an ocaml interface to sqlite (and it works GREAT!). I would like to have a static libsqlite.a built for me.
I have worked around the problem now by adding :
libsqlite.a: $(LIBOBJ)
$(LIBTOOL) $(TCC) -o libsqlite.a -static $(LIBOBJ)
libtclsqlite.a: tclsqlite.lo libsqlite.la
$(LIBTOOL) $(TCC) -o libtclsqlite.a tclsqlite.lo \
libsqlite.la $(LIBTCL) -static
to Makefile.in...
I also changed all: to include these two targets.
BTW, I have had a great time and success using sqlite... Thank you for working so diligently on this!!!
bob |
Switched to using Makefile.template... That seems to be the standard way of doing things. It worked just fine.
Thanx |
|
108 |
code
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Sep
|
|
1
|
1
|
Sqlite's Windows Dll Version Still Is 2.56
|
edit |
Please Update Download Page's Windows Dll Files |
|
107 |
code
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Sep
|
|
1
|
1
|
Incorrect query results
|
edit |
The following script generates an output of 1 instead of 0:
create table t( a int );
create index idx on t(a);
insert into t values ('');
select count(*) from t where a = 123;
|
The problem appears to be a design flaw in the structure of
SQLite indices that goes all the way back to version 2.1.0.
An incompatible database format change will (probably) be
required to fix the problem. Work on this change is underway
now.
The problem is expressed when an empty string is used in data that
is indexed. Since this problem has not be noticed before, I suppose
not many people use empty strings in indexed columns... |
|
106 |
code
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Jul
|
|
1
|
1
|
Bad handling of nulls
|
edit |
x = null returns null.
Equality/inequality must return a boolean value: 0 or 1
For example:
select 1 when null returns 1 and it must not return anything
select 1 when null = 1 returns 1 and it must not return anything |
The current behavior of SQLite is correct
select 1 when null;
This is a syntax error. It does not return 1.
select 1 where null;
This returns 1 because it ignores the WHERE clause. A WHERE
clause is only processed if you have a table to read.
select 1 from t1 where null;
This returns nothing, as it should. |
|
105 |
code
|
closed
|
2002 Jul
|
anonymous
|
CodeGen
|
2002 Sep
|
|
2
|
1
|
Assertion fails on UPDATE of indexed table with subquery in WHERE
|
edit |
The following script results in an assertion failure:
create table t1(a,b);
insert into t1 values(1,2);
create index i1 on t1(a);
create index i2 on t1(b);
update t1 set b=b+1 where a in (select a from t1);
Assertion failed: pParse->nTab==base+i+1, file update.c, line 273 |
|
104 |
code
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Sep
|
|
1
|
2
|
error in trigger on view after closing and reopening database
|
edit |
An insert trigger on a view works ok before and returns an error
after closing and reopening the database.
The following code demonstrates the problem
rm -f /tmp/test.sqlite
sqlite /tmp/test.sqlite
create table test1(id integer primary key,a);
create table test2(id integer,b);
create view test as
select test1.id as id,a as a,b as b
from test1 join test2 on test2.id = test1.id;
create trigger I_test instead of insert on test
begin
insert into test1 (id,a) values (NEW.id,NEW.a);
insert into test2 (id,b) values (NEW.id,NEW.b);
end;
insert into test (id,a,b) values(1,'t1','t2');
select * from test;
.q
sqlite /tmp/test.sqlite
insert into test (id,a,b) values(2,'t2-1','t2-2');
returns the error: "SQL error: table test has no column named id" |
This problem isn't about triggers, it's about views implemented by SELECT statements that use the new join syntax. Here is some more empirical data:
370 ~/cvs/bld$ ./sqlite db
SQLite version 2.5.6
Enter ".help" for instructions
sqlite> create table test1(id integer primary key, a);
sqlite> create table test2(id integer, b);
sqlite> create view test_old_syntax as select test1.id, a, b from test1, test2 where test1.id = test2.id;
sqlite> create view test_new_syntax as select test1.id, a, b from test1 join test2 on test2.id = test1.id;
sqlite> select * from test_old_syntax;
sqlite> select * from test_new_syntax;
sqlite> .quit
371 ~/cvs/bld$ ./sqlite db
SQLite version 2.5.6
Enter ".help" for instructions
sqlite> select * from test_old_syntax;
sqlite> select * from test_new_syntax;
SQL error: no such column: test_.ew
sqlite>
I did this with the released 2.5.6 version.
The bug concerning old and new syntax you are testing for
is already fixed in newer versions: #100.
The problem in this ticket is about the insert trigger that returns
an error. This problem remains even when using the old syntax. Your
code does a select and not an insert after reopening, so the bug
is not triggered. I have noticed now that when doing a select on the
view after reopening and before doing an insert, the insert works.
Without the select after reopening, the insert fails! |
|
103 |
code
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Jul
|
|
2
|
1
|
Memory Leak in the Server
|
edit |
In a client/server environment using rudp as a protocol (Reliable UDP), a memory leak occured in the server side when inserting in the database. The language used is tcl. |
The originator of this ticket is unable to supply a script to
reproduce this bug. We'll have to assume the problem is not
in SQLite. |
|
102 |
code
|
closed
|
2002 Jul
|
drh
|
|
2002 Sep
|
|
1
|
1
|
ORDER BY ignored in subquery
|
edit |
A subquery in the FROM clause of a SELECT ignores its ORDER BY
clause. This can lead to incorrect answers, such as in the following:
SELECT avg(x) FROM (SELECT x FROM tbl1 ORDER BY x DESC LIMIT 2);
|
|
101 |
new
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Jul
|
|
3
|
3
|
builtin functions do not work properly with LIMIT clause
|
edit |
The limit clause seem to be ignored when used with built in functions. For example taking the average of a column with the LIMIT clause result in the entire column being averaged instead of just the limited results. |
Works as designed.
The current behavior is the same as with PostgreSQL. It is different
from MySQL, but MySQL is not noted for its standards compliance so it
is probably better to emulate PostgreSQL rather than MySQL when the
two disagree. Furthermore, the MySQL behavior can be simulated
using a subquery such as the following:
(Later:) The real problem here is described in ticket #102.
SELECT avg(x) FROM (SELECT x FROM tbl LIMIT 5); |
|
100 |
code
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Sep
|
|
1
|
2
|
view not properly restored after closing and reopening database
|
edit |
The view in the code works before closing the database,
and gives an error after closing and reopening. (code not included
for an error in an insert trigger on the view, as this is probably
related) The following code demonstrates the error:
sqlite /tmp/test.sqlite
create table test1(id integer primary key,a);
create table test2(id integer,b);
create view test as
select test1.id as id,a as a,b as b
from test1 join test2 on test2.id = test1.id;
select * from test;
This works (returns nothing), after closing:
sqlite /tmp/test.sqlite
select * from test;
results in "SQL error: no such column: t"
|
The problem is in the use of the USING clause in the join. A similar
problem will occur if ON is used to specify the columns to be joined. |
|
99 |
todo
|
closed
|
2002 Jul
|
drh
|
|
2002 Sep
|
|
1
|
1
|
Document and export the sqlite_mprintf() API.
|
edit |
Add documentation on the sqlite_mprintf() API. Make sure this
routine is exported in windows DLLs. |
|
95 |
code
|
closed
|
2002 Jul
|
drh
|
CodeGen
|
2002 Sep
|
|
1
|
1
|
DROP INDEX on an automatically created internal index is allowed
|
edit |
Create a new table with a UNIQUE column or a PRIMARY KEY. This
will automatically create an index to handle the uniqueness
constraint. Then drop that automatically created index.
Leave the shell and bring it back up again, then try to
insert a value into the new table. An error results.
CREATE TABLE ex1(a unique, b primary key);
DROP INDEX '(ex1 autoindex 1)';
-- stop and restart the sqlite shell program
INSERT INTO ex1 VALUES(1,2);
|
|
94 |
code
|
closed
|
2002 Jul
|
drh
|
Pager
|
2002 Sep
|
|
1
|
1
|
ROLLBACK fails to restore all pages
|
edit |
When a page is added to a freelist then removed from the freelist
and reused during the same transaction, it does not get journaled.
This leads to database corruption during a rollback. |
More rollback problems found and fixed by checking [663]
|
|
92 |
code
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Sep
|
|
2
|
2
|
max() looks boggus in a view
|
edit |
in a view 'select max(x) + max(y) from t'
acts as 'select max(x) + max(x) from t'.
As a clue 'max(x) - max(y)' returns 0 and 'max(x) + max(x)' returns '2*max(x)'.
Note: I use 2.4 or 2.5.4 on NT
CREATE table dummy(foo,bar);
insert into dummy values(10,20);
insert into dummy values(5,25);
select * from dummy;
10|20
5|25
select max(foo) - max(bar) from dummy;
-15
CREATE view v as select * from dummy where ( foo == 10 or foo == 5 );
select * from v;
10|20
5|25
select max(foo) - max(bar) from v;
0
select max(foo) + max(bar) from v;
20
|
|
91 |
todo
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Sep
|
|
4
|
3
|
A command-line program for windows
|
edit |
There is no compiled 'sqlite' command line program for windows. |
|
90 |
code
|
closed
|
2002 Jul
|
anonymous
|
|
2002 Sep
|
|
1
|
1
|
table aliases in select commands stopped working
|
edit |
Hello,
I have been useing 2.4.12 and the table aliases used to work just fine (eg. select t1.col1, t2.col2 from table1 t1, table2 t2 where ...). When I have switched to 2.5.3 the old selects using the above syntax stopped working (the error is "Syntax error near "t1" if there is a single table or "Syntax error near ," if there are more tables in the FROM clause). Switching to the old version makes them work again but there is the possibility of data corruption error which makes me a little bit scared.
The code example goes below:
select kd.id_kat,kd.id_dok,dok.nazev from KAT_DOK kd, DOKUMENT dok where kd.id_dok=dok.id_dok order by kd.id_kat,dok.nazev
Without table aliases, the self-joins are not possible and it is also major pain to code the joined selects (and it also breaks almost all the SQL code in my existing apps).
Thank you for your marvellous software, I hope your day goes well.
Feel free to contact me.
Roman |
|
89 |
new
|
closed
|
2002 Jun
|
chw
|
Parser
|
2002 Sep
|
|
1
|
4
|
table aliases broken
|
edit |
Table aliases seem to be broken in SQLite 2.5.0 and above:
$ sqlite test
sqlite> create table test(field integer);
sqlite> insert into test values(1);
sqlite> select field from test;
1
sqlite> select t0.field from test t0;
SQL error: near ";": syntax error
|
SQLite requires the "AS" keyword in between the table name
and its alias.
select t0.field from test as t0;
^^
Making this keyword optional will require adding at least
7 new keywords to the language, as well as a host of other
parser complications. |
|
88 |
doc
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Sep
|
|
4
|
4
|
Typo on web page
|
edit |
On the page http://www.hwaci.com/sw/sqlite/sqlite.html (emphasis mine):
The sqlite program is able to show the results of a query in FIVE
different formats: "line", "column", "list", "html", and "insert". You can use the ".mode" dot command to switch between these THREE output formats. |
|
87 |
new
|
closed
|
2002 Jun
|
anonymous
|
|
2005 Jan
|
|
1
|
4
|
ORDER BY & ISO 8859-2
|
edit |
ORDER BY don't work correctly for data from ISO 8859-2 page. |
2005-Jan-16 19:59:55 by drh:
Use the COLLATE clause of SQLite version 3.0 to correct this. |
|
85 |
todo
|
closed
|
2002 Jun
|
drh
|
|
2003 Apr
|
|
1
|
1
|
Document and test the sqlite_open_aux_file() API.
|
edit |
The sqlite_open_aux_file() API needs to be documented and test cases
for this API need to be added to the test suite. |
Overcome by events. The sqlite_open_aux_file() API has been
removed. Equivalent functionality is now available using
the ATTACH command. |
|
84 |
code
|
closed
|
2002 Jun
|
drh
|
|
2002 Sep
|
|
1
|
1
|
Complex left outer joins might give the wrong answer
|
edit |
If the number of WHERE, ON, and USING clause terms in a left-outer
join exceeds 32, then the join might not be computed correctly.
It use to be that the result was incorrect if there were both
WHERE clause terms and USING terms, but that problem was fixed
in check-in [639]
. But [639]
only works if the total number of
terms is 32 or less. The fix needs to be extended to work with
any number of terms. |
|
83 |
todo
|
closed
|
2002 Jun
|
drh
|
|
2002 Sep
|
drh
|
1
|
1
|
Add test cases
|
edit |
New test cases are needed in the test scripts. Especially needed
are cases to test for the bugs fixed by check-ins [643]
and [639]
. |
|
80 |
code
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Sep
|
|
2
|
2
|
Heap corruption on select with ORDER BY, LIMIT, and OFFSET
|
edit |
Attempt the following script in the shell from an empty database.
It is a bunch of identical inserts into a new table followed by a select statment that has WHERE i=0 ORDER BY j LIMIT 5 OFFSET 275 clauses.
CREATE TABLE test (i, j, k);
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
INSERT INTO test (i,j,k) VALUES (0,'hbhj bhjb dshjfvb hjvsdhjfb jhsbdfhvseyjbgy beryugb yudb gyubsdhjkjkvsdfsdkbfbhjkvsdbjkvsdbfhjkvbsdhjkfb hjksdfkb fsdbhjkhjksdfbvhjk sdbhjk bfsdjkhvb hjksdfb sdhjbvhj sdfbvhjsdfbhjkbjk bsdhjkfbv hjksdfbhjkvbdhjkfsb h','bhchjsbchjb hjadbjk bhj asdbchj basdhjkc asdjb cdbhj basdhjcaskk asdbchj bsdchj basdhjcsj adcbhjkasdbchjkbasdhjkcb asdhjkcbjhasdbchjksadvjkhbcjhkbfcacyuabvweurcbvasdhjkgbvhjkgasdcjkasdbvchjkabvchjkbvasdhjkcvbasdhcjkg vasdbchjvashjkdbvcjkhasbchjkbashjkcasdhj');
SELECT * FROM test WHERE i=0 ORDER BY j LIMIT 5 OFFSET 275; |
|
79 |
code
|
closed
|
2002 Jun
|
drh
|
|
2002 Sep
|
|
1
|
1
|
Tables are not being dropped correctly under certain circumstances.
|
edit |
The following script fails:
BEGIN;
CREATE TABLE t1(a INTEGER PRIMARY KEY, b, c);
CREATE INDEX i1 ON t1(b,c);
INSERT INTO t1 VALUES(0,1,2);
END;
BEGIN;
DROP INDEX i1;
DROP TABLE t1;
CREATE TABLE t1(a INTEGER PRIMARY KEY, b, c);
INSERT INTO t1 VALUES(0,1,2);
END;
|
|
78 |
code
|
closed
|
2002 Jun
|
drh
|
CodeGen
|
2002 Sep
|
|
1
|
1
|
Assertion failure when closing database in the middle of a transaction
|
edit |
The following script causes an assertion failure:
create table t1(x,y);
begin;
drop table t1;
.exit
|
|
77 |
code
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Sep
|
|
2
|
2
|
more than one LIMIT on nested select shows 0 rows
|
edit |
First at all: you have done a great job with SQLite.
Now the bitter part, suppose a statement like:
select whatever_you_want from table1,
( select whatever_again from table2 where some_logic_condition LIMIT 5 ) as virtualTable
LIMIT 10;
The result shows 0 records
Removing any of the "LIMIT" keyword the result is not empty.
I didn't find anywhere in the documentation that LIMIT is not supported in nested selects.
Alexandru Faliboga,
alexandru.faliboga@deuromedia.ro |
|
76 |
code
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Sep
|
|
1
|
3
|
sqlite corruption possibly relating to drop of index
|
edit |
G'day,
I was hoping to ask describe this problem on the yahoo groups before issuing a formal bug report, but yahoo doesn't seem to want me to join the group using netscape (or perhaps it's just broken right now). I have a reproducable problem I noticed with sqlite version 2.4.12 both on my linux machine (installed via the debian package) and on my solaris 2.5.1 machine which I've built by hand. I've had a bit of a look around the code but it hasn't been immediately obvious where this kind of problem comes from.
Here is the code to reproduce the problem on both of my machines:
BEGIN TRANSACTION;
DROP INDEX Trend;
DROP TABLE Disturbance;
CREATE TABLE Disturbance (Entry INTEGER PRIMARY KEY,Identity
INTEGER,Sample DOUBLE,Good BOOLEAN,Time DOUBLE);
CREATE INDEX Trend ON Disturbance (Identity, Time);
INSERT INTO Disturbance VALUES(0,3271,5,1,1023781501.678765);
END TRANSACTION;
To see the corruption run twice:
> rm fred*
> sqlite fred < crash
DROP INDEX Trend;
SQL error: no such index: Trend
DROP TABLE Disturbance;
SQL error: no such table: Disturbance
> sqlite fred < crash
INSERT INTO Disturbance VALUES(0,3271,5,1,1023781501.678765);
SQL error: database disk image is malformed
I noticed this problem when running peformance tests of sqlite gainst other free databases for a commercial product I'm working on. Although I haven't seen anything like this in the prototypical applications I've written the fact that it has shown up leads me to want it resolved before I feel completely safe with sqlite :)
The problem appears goes away if I take away the begin/end transaction pair, or if I take out the drop/create index pair.
Benjamin.
P.S. The public domain status of this product is an idea I like very much: Congratulations. It's good to see products of such high calibre being made so readily available no matter what the user situation. sqlite is also by -far- the fastest database system I've tested for my very simple purposes. Even though it's based on a file locking system it still outperforms everything else I've tried when it comes to a large number of insertions with some simultaneous queries. |
This bug has been around since version 2.0.0. |
|
75 |
code
|
closed
|
2002 Jun
|
drh
|
CodeGen
|
2002 Sep
|
|
1
|
1
|
Auto-increment not working on an INSERT from a SELECT
|
edit |
If you try to insert a NULL into an INTEGER PRIMARY KEY column
using a VALUES clause in an INSERT statement, the primary key
is filled with the next available integer. Ex:
INSERT INTO x(pk,y) VALUES(NULL, 5);
But if you do a similar insert were the source of data is
a SELECT instead of a VALUES clause, the primary key is not
automatically generated:
INSERT INTO x(pk,y) SELECT NULL, a FROM z;
|
|
73 |
code
|
closed
|
2002 Jun
|
drh
|
CodeGen
|
2002 Sep
|
drh
|
1
|
1
|
ORDER BY clause is ignored on subqueries
|
edit |
The ORDER BY clause of a SELECT is ignored if the output of the
SELECT is sent to a table as in a subquery. Usually this does not
matter, but it makes a difference if there is also a LIMIT clause. |
|
72 |
code
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Sep
|
|
1
|
1
|
malloc test in testbed fails Win32 build of 2.4.12
|
edit |
This is a bit of curly problem in that there are actually a number of issues being compounded into one, so please bear with me.
I have been using sqlite 2.4.1 for some time now without any hitch. I noticed that 2.4.12 and had some nice features, so I decided to have deeper look into it.
Using the 2.4.12 source release of sqlite, I ran the configure script from my build directory, and then compiled it successfully on cygwin, using gcc 2.95.3-5 and make 3.79.1 (successful only if you ignore the linker warnings about undefined symbols not allowed in shared libraries). I then ran the TCL test via 'make test' - no problems (testfixture was compiled with tcltk 20001125-1).
I decided to run the fulltest, so I modified the Makefile to include the -DNDEBUG=1 and -DMEMORY_DEBUG=1 preprocessor directives and ran 'make fulltest'. The test scripts happily did their job, until malloc-1.77 (found in test/malloc.test) which failed with a 'database is locked' message.
Upon further investigation, I found that the call to the Win32 function LockFile() was failing which causes the above message being returned when the SQL statement is evaluated.
It is also very curious, seeing as there is only one instance of testfixture running, in which case LockFile() shouldn't fail as the lock is owned by the testfixture process instance. I investigated further to discover that there is a flaw in the testbed itself - any errors that occur while deleting files are silently discarded. This is issue 1.
This means that the database is locked some point earlier in the testing and it is only by chance that the 'database is locked' message is obtained.
By modifying the testbed scripts (test/*.test) to assert that the file does not exist whenever a file deletion occurs, I ascertained that the offending read lock first began at malloc-1.63 and was not released during the failure of the sqlite_open() call.
Upon closer analysis it appears that during the call of sqlite_open() the Btree is opened successfully via a call to sqliteBtreeOpen(), which opens the database file for read and write. Then sqliteInit() is called, which fails because of an "out of memory" error. As there was a sqlite malloc failure, sqlite_close() is called to cleanup. Because sqlite.magic has a value of SQLITE_MAGIC_BUSY, the sqlite safety checks fail and sqliteBtreeClose() is never called and hence the sqlite db structure is never freed. This is issue 2.
In fact, if sqliteInit() should fail for any reason, the same locking problem will eventually exhibit. This is issue 3.
Seeing as I'm still getting a feel for the workings of sqlite and its clearly a state analysis issue, I felt it best that I leave the solution to the experts. |
The patch corrects issue 3.
To ensure that something this complex is caught, perhaps the *.test files should be updated to so that any file deletion that does not succeed should report and stop further testing? |
|
71 |
code
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Sep
|
drh
|
2
|
4
|
"COPY table FROM file" expects lines to end with LF.
|
edit |
The sqlite SQL statement "COPY table FROM file" reads delimited fields from each line in a file and writes a corresponding record containing those read fields into the table.
The mechanism that reads a line from the file assumes that the end of the record in the file is delimited by a LF character. This mechanism relies upon repeatedly calling fgets() to obtain from the open file a line that ends with a LF character. Unfortunately, fgets() uses a platform-specific EOL marker.
If sqlite is compiled for Cygwin or Linux the EOL marker that fgets() uses is LF. If sqlite is compiled for Win32 (using the Win32 source and Visual C++) the EOL marker that fgets() uses is CRLF. If sqlite was compiled for a Mac environment the EOL marker that fgets() would use would be CR.
This means that if the fgets() EOL marker is not the LF character that sqlite uses, the "COPY table FROM file" operation will not be as expected.
There are three solutions:
1) Force fopen() to open the file for reading using text mode in the OP_FileOpen section of code in the src/vdbe.c file.
ie:
From this
p->pFile = fopen(pOp->p3, "r");
To this
p->pFile = fopen(pOp->p3, "rt");
This will cause fgets() to translate the various forms of EOL markers read from the file to a LF character, at the cost of not being able to copy in binary data.
2) Replace the fgets() call with a less platform specific mechanism so that a consistent EOL marker be used across platforms, suitable for copying in binary data.
3) Provide in the SQL statement a mechanism to specify what sqlite should use as the end of record delimiter when reading from the file.
Steps to reproduce (Cygwin example):
Using gcc 2.95.3-5, make 3.79.1, and tcltk 20001125-1, issue from the build directory a 'make fulltest'. The build directory must reside within a mount point that has been mounted in binmode. The test "copy-3.2" should fail, because this Cygwin release of Tcl implements EOL marker as CRLF and fgets() uses LF as the EOL marker.
If the build directory resides on a mount point that has been mounted in textmode, the tests in test/copy.test will succeed. |
|
70 |
doc
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Sep
|
|
5
|
5
|
Error in online documentation for DROP VIEW
|
edit |
The online documentation at "http://www.hwaci.com/sw/sqlite/lang.html" for DROP VIEW has a cut-and-paste error.
The DROP VIEW statement consists of the keywords "DROP TABLE"
followed by the name of the view.
This should be "DROP VIEW". |
|
69 |
new
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Jun
|
|
5
|
4
|
Sequences (some sort of auto-incremental fields...)
|
edit |
A better way to have an unique value other than rowid would be having GENERATORS or SEQUENCES or something like that.
As we have triggers, it would be easy to get the next sequence value inside the trigger and update the field.
There's a workaround to accomplish (almost) the same result on the current version. It would be 1) create a new table, to record the sequences; 2) increment the sequence before the INSERT; 3) use an INSERT+SELECT statement do insert the row
create table a(name text, id int);
create table b(another_name text, another_id int);
-- create and initiate the sequences table
create table sequences(a_id int, b_id int);
insert into sequences values(0,0);
-- before any insert, increment the proper sequence
update sequences set a_id=a_id+1;
-- use a compound INSERT to get the value from the sequence
insert into a(name,id) select "Mary Anne", a_id from sequences;
-- a second insert requires a new update of the sequence
update sequences set a_id=a_id+1;
-- use a compound INSERT to get the value from the sequence
insert into a(name,id) select "Joe Doe", a_id from sequences;
It makes you work a little more, and also there's no garrantee that no other user updated the sequence value just before you insert the new row, thus both might get the same sequence value.
So, it would be very nice to have some mechanism to generate and manage the sequences built in the triggers mechanism.
What you think? |
See http://www.hwaci.com/sw/sqlite/faq.html#q1 |
|
66 |
code
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Sep
|
drh
|
1
|
2
|
LIMIT clause ignored in subselects
|
edit |
This should work:
gerhard@lilith:~$ sqlite /tmp/db
SQLite version 2.4.7
Enter ".help" for instructions
sqlite> create table test(id);
sqlite> insert into test(id) values (1);
sqlite> insert into test(id) values (2);
sqlite> insert into test(id) values (3);
sqlite> select id from test;
1
2
3
sqlite> select id from test limit 2;
1
2
sqlite> delete from test where id in (select id from test limit 2);
sqlite> select id from test;
[nada]
I just verified that the problem still exists in 2.4.12.
As you can see, there is some bug in SQLite so that this statement
deletes all rows instead of only these with id=1 or id=2 :-( |
Yeah. The LIMIT and ORDER BY clauses are both ignored on
a subselect. For an ORDER BY this is ok, but as you point
out, LIMIT should not be ignored. I'll have to make some
changes. |
|
65 |
code
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Sep
|
|
2
|
2
|
Error in .dump'ed INSERT statements
|
edit |
For columns containing a long string which appear to be an
integer number but are not representable in 32 bit (eg
004001001000) the .dump command of the sqlite shell does
not output a proper INSERT statement which quotes these
strings. This results in a dump file which can't be reloaded
into an sqlite database.
Test case:
CREATE TABLE station (
name char(15) UNIQUE NOT NULL,
place char(15) UNIQUE NOT NULL
);
INSERT INTO station VALUES('S01',001001001000);
INSERT INTO station VALUES('S02',002001001000);
INSERT INTO station VALUES('S03',003001001000);
INSERT INTO station VALUES('S04',004001001000);
|
|
64 |
code
|
closed
|
2002 Jun
|
danielk1977
|
Shell
|
2002 Sep
|
|
5
|
5
|
TEMP tables in a read-only db using the shell tool
|
edit |
When you try and create an (ordinary, not TEMP) table in a read-only database using the shell tool no error is returned. This looks like a bug in the shell, not the library, as testcase temptable-6.3 demonstrates that the library returns an error. The cut-and-paste from a terminal below shows the behaviour.
1979 ~/cvs2/bld$ ./sqlite a
SQLite version 2.4.12
Enter ".help" for instructions
sqlite> create table tbl(a);
sqlite> select * from tbl;
SQL error: no such table: tbl
sqlite> .exit
1980 ~/cvs2/bld$ ./testfixture
% sqlite db a
134636032
% db eval {CREATE TABLE tbl(a)}
Error: attempt to write a readonly database
%
|
|
63 |
new
|
closed
|
2002 Jun
|
drh
|
CodeGen
|
2002 Sep
|
|
3
|
3
|
Add optimizations for "WHERE rowid IN (SELECT...)"
|
edit |
Add optimizations to the where.c module that will efficiently
handle a WHERE clause that consists of a single IN operator.
For example:
UPDATE t1 SET c1=NULL
WHERE rowid IN
(SELECT t1.rowid FROM t1 NATURAL JOIN t2 WHERE t2.c2>10)
|
|
62 |
code
|
closed
|
2002 Jun
|
danielk1977
|
VDBE
|
2002 Sep
|
|
3
|
4
|
TEMP tables with a read-only database
|
edit |
When using a read-only database, you can't create TEMP tables. It would be useful to be able to do so. |
|
61 |
new
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Jun
|
|
1
|
1
|
Enhancement Request: Capability to Specify Table Join Type
|
edit |
It doesn't appear possible to specify the table join type as part of a SQL operation. In particular, LEFT OUTER JOIN's are extremely common in most business applications that use a relational database.
If implementing this feature, it would be preferable if done via ANSI JOIN syntax, rather than the old-school +/- on each side of the WHERE clause column joins. |
See ticket #58 |
|
60 |
new
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Jun
|
|
3
|
4
|
UPDATE Statement with FROM Clause FAILS
|
edit |
The SQL syntax:
UPDATE
Table1
SET
Column = Value
FROM
Table1, Table2
WHERE
Table1.Column1 = Table2.Column
AND (condition)
fails due to the FROM clause. |
This is not valid SQL syntax according to the SQL92 spec.
You can do the same thing in SQLite as follows:
UPDATE Table1 SET Column = Value WHERE rowid IN
(SELECT Table1.rowid FROM Table1, Table2
WHERE Table1.Column1 = Table2.Column AND (condition));
See also ticket #63. |
|
59 |
doc
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Sep
|
|
3
|
4
|
Undocumented Concatenation Operator
|
edit |
The concatenation operator || appears to be missing from the documentation on expressions in:
http://hwaci.com/sw/sqlite/lang.html |
|
58 |
new
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Jun
|
|
4
|
4
|
Table JOIN Syntax Not Recognized
|
edit |
JOIN syntax such as:
SELECT
Table1.Column,
Table2.Column
FROM Table1
INNER JOIN Table2 ON Table1.Column = Table2.Column
AND (condition)
WHERE
(condition)
is not recognized and produces are parsing error. |
Already implemented. See check-in [587]
. |
|
57 |
code
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Jun
|
|
4
|
4
|
UPDATE Command Fails When Table Name is Part of SET Statement
|
edit |
For the SQL statement:
UPDATE
Table
SET
Table.Column = Value
WHERE
(condition)
fails unless the table name is ommited in SET operator. The SQL statement must be written such as:
UPDATE
Table
SET
Column = Value
WHERE
(condition) |
This is not valid SQL syntax according to the SQL92 spec. |
|
54 |
todo
|
closed
|
2002 Jun
|
anonymous
|
|
2002 Sep
|
|
2
|
2
|
win32 binaries are missing symbols
|
edit |
In the win32 binaries, the DLL and DEF file are missing symbols, in particular the
sqlite_set_result_* functions and the
sqlite_user_data,
sqlite_create_aggregate
sqlite_create_function
Maybe others, too.
I finally managed to build my own Windows binaries with MSYS + mingw32, so this isn't very pressing. But it also means that the win32 binaries are useless, if you need the above symbols, which I do. |
|
53 |
new
|
closed
|
2002 May
|
anonymous
|
|
2002 Sep
|
|
5
|
4
|
Single checkpoint file enhancement
|
edit |
I have made some changes on pager.c that allows the use of a single temporary checkpoint file instead of a checkpoint file for each checkpoint. The checkpoint file is created when the pager is opened and closed when the pager is closed (and so automatically deleted by the OS). On checkpoint commit or rollback the file is just truncated. This leads to a performance increase of about 3/4 % on Win32 (tested under Win98), especially on big transactions. It also works for Linux but I haven't tested performances on it, so the code is enabled by a define (SQLITE_FAST_CKPT) on top of pager.c. For sure this change put less load on the operating system so I expect some performance increase also under Unix. |
I implemented this differently that shown in the patch. The
checkpoint journal file is closed when the transaction ends because
I do not want to leave open file descriptors hanging around
unnecessarily. The checkpoint journal is truncated when it is
committed (or rolled back) rather than when the next checkpoint
starts. The checkpoint journal is not initially opened until the
start of the first checkpoint. |
|
52 |
new
|
closed
|
2002 May
|
anonymous
|
|
2002 Sep
|
|
5
|
4
|
Backslash check on temporary file names under Win32
|
edit |
This is just a paranoid check, but it is always a good check to do under Win32. Furthermore there was a unneeded '/' appended to the temp path. It worked, but I don't know how. Tested patch for os.c follows.
--- os.c.orig Wed Mar 20 01:00:30 2002
+++ os.c Wed May 29 13:04:01 2002
@@ -432,11 +432,14 @@
"abcdefghijklmnopqrstuvwxyz"
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"0123456789";
- int i, j;
+ int i, j, tl;
char zTempPath[SQLITE_TEMPNAME_SIZE];
- GetTempPath(SQLITE_TEMPNAME_SIZE-30, zTempPath);
+ tl = GetTempPath(SQLITE_TEMPNAME_SIZE-30, zTempPath);
for(;;){
- sprintf(zBuf, "%s/sqlite_", zTempPath);
+ if (zTempPath[tl - 1] == '\\')
+ sprintf(zBuf, "%ssqlite_", zTempPath);
+ else
+ sprintf(zBuf, "%s\\sqlite_", zTempPath);
j = strlen(zBuf);
for(i=0; i<15; i++){
int n = sqliteRandomByte() % sizeof(zChars);
|
|
51 |
doc
|
closed
|
2002 May
|
danielk1977
|
CodeGen
|
2002 May
|
danielk1977
|
5
|
3
|
Triggers problem with INTEGER PRIMARY KEY
|
edit |
When a trigger program updates the INTEGER PRIMARY KEY field of a row which is to be subsequently deleted or updated by the statement causing the trigger to fire, the code assumes that the row has been deleted by the trigger program and so doesn't execute the update or delete for that row. Example follows:
CREATE TABLE aa(a INTEGER PRIMARY KEY, b);
INSERT INTO aa VALUES(1, 2);
CREATE TRIGGER at BEFORE DELETE ON aa BEGIN
UPDATE aa SET a = a + 1;
END;
DELETE FROM aa;
SELECT * FROM aa; |
This will just be documented as a problem for now, not fixed. This is given a low priority as it should be easy for users to avoid configuring triggers that modify INTEGER PRIMARY KEY values. |
|
50 |
code
|
closed
|
2002 May
|
drh
|
|
2002 Sep
|
|
3
|
2
|
Memory leak in triggers on TEMP tables
|
edit |
When a trigger is attached to a TEMP table and the TEMP table is
automatically delete when the DB connection closes, the memory
used to hold the trigger is not cleaned up. |
|
49 |
code
|
closed
|
2002 May
|
drh
|
CodeGen
|
2002 Sep
|
|
2
|
1
|
DELETE Trigger causes extra rows to be deleted
|
edit |
When the body of a DELETE trigger deletes rows that were later to
be deleted by the original statement, then the original statement
deletes rows that follow the ones it was originally to delete.
For example, in the following program, the table t1 should be left
with two rows: {2,'b'} and {4,'d'}. But as currently implemented,
the {4,'d'} row is deleted incorrectly.
create table t1(a,b);
insert into t1 values(1,'a');
insert into t1 values(2,'b');
insert into t1 values(3,'c');
insert into t1 values(4,'d');
create trigger r1 after delete on t1 for each row begin
delete from t1 WHERE a=old.a+2;
end;
delete from t1 where a in (1,3);
select * from t1;
|
A similar problem occurs on an UPDATE trigger when subsequent rows
in the change set are deleted. Both problems are now fixed. |
|
47 |
code
|
closed
|
2002 May
|
anonymous
|
|
2002 Sep
|
|
5
|
4
|
Compiler Warning using MingW/gcc
|
edit |
C:\sqlite\build>gcc -c -O2 ..\src\hash.c -I.
..\src\hash.c: In function `sqliteHashInsert':
..\src\hash.c:323: warning: assignment discards qualifiers from pointer target type
C:\sqlite\build>gcc -v
Reading specs from C:/MSYS/1.0/MINGW/BIN/../lib/gcc-lib/mingw32/2.95.3-6/specs
gcc version 2.95.3-6 (mingw special) |
|
46 |
code
|
closed
|
2002 May
|
drh
|
CodeGen
|
2002 Sep
|
|
3
|
2
|
CREATE TABLE accepts duplicate column names
|
edit |
The SQL statement shown below is accepted and the new table is
created. This is wrong. An error should be issued because two
or more columns share the same name.
CREATE TABLE bug1(a,a,a);
|
|
45 |
code
|
closed
|
2002 May
|
anonymous
|
|
2002 Sep
|
|
4
|
4
|
Unique constraint problem on updating PRIMARY KEY column
|
edit |
When you update a table with an INTEGER PRIMARY KEY column,
the uniqueness constraint fails if you are updating that column
to its same value [that is, not actually changing THAT column
at all in the update]. |
|
44 |
code
|
closed
|
2002 May
|
anonymous
|
|
2002 Sep
|
|
3
|
3
|
UNIQUE constraint (incorrectly) applies to NULL
|
edit |
My understanding of SQL9X is that NULL values are not considered equal for the purpose of a UNIQUE constraint.SQLITE on the other hand appears to consider NULL a value to be constrained like any other non-null value.
My work-around for now is to remove UNIQUE from the column(s) concerned and enforce the contraint in my application. I would prefer however that the database enforce the constraint itself to eliminate the possibility of non-null duplicates occuring. |
SQLite treats NULL as just another value. This behavior is at odds
with every SQL standard out there, but it is not likely to change
any time soon. |
|
42 |
doc
|
closed
|
2002 May
|
drh
|
|
2002 Sep
|
|
1
|
1
|
Add comments to Trigger structures in sqliteInt.h
|
edit |
The structures associated with trigger need to be carefully commented. |
|
41 |
code
|
closed
|
2002 May
|
drh
|
|
2002 Sep
|
|
1
|
2
|
sqlite_complete() failure
|
edit |
In the "sqlite" shell program, enter the following SQL:
create table misc(name,value);
create table backend(a,b,c);
create trigger t1 on backend begin
update misc set value=value+1 where name='chngcnt';
The shell should issue a continuation prompt waiting on
the completion of the CREATE TRIGGER statement. But instead,
it gets confused, thinks the semicolon at the end of the
UPDATE is the end of the CREATE TRIGGER, tries to execute the
incomplete SQL statement, and reports a syntax error. |
|
40 |
code
|
closed
|
2002 May
|
drh
|
|
2002 Sep
|
|
3
|
3
|
Compiler warnings on RedHat 7.2
|
edit |
There are compiler warnings on RedHat 7.2 that need to be fixed. |
|
39 |
todo
|
closed
|
2002 May
|
drh
|
|
2002 Sep
|
|
5
|
1
|
Reformat the TRIGGER code for consistent style.
|
edit |
The newly inserted TRIGGER code does not conform stylistically
to the rest of the code. It needs to be brought into compliance.
Among the areas where there is stylistic deviation:
(1) Spacing on "if" statements and on pointer declarations,
(2) Variable naming conventions,
(3) Indentation of procedure definitions,
(4) The body of "if" and "while" statements are not always
enclosed in {...}. |
Also add detailed comments to the beginning of every new
function. |
|
37 |
code
|
closed
|
2002 May
|
anonymous
|
|
2004 Nov
|
|
3
|
3
|
can't open dbfile by apache process under mod_perl env.
|
edit |
# sorry if it's faq..
apache process can't open db file. but in shell, i can do it.
(means sql statement may be right.) mod_perl is a enhanced module
for apache web server, and i use the Apache::DBI module that provides persistent connection to database. humm..
error-log below.
DBD::SQLite::db do failed: unable to open database file at /usr/local/lib/perl5/site_perl/5.005/Apache/DumpHeaders/SQLite.pm line 77.
thanx for reading :-) |
This probably means that access permissions are not set right
on the database file. It does not appear to be a bug in SQLite.
It is no SQLite bug, but maybe you should put this into the FAQ:
In order to lock a database the directory has to have the same permissions as the db file, for the lock files to be generated.
This is of course very relevant for Apache subprocesses with different uid/gid. I recomment a seperate directory for every database. |
|
36 |
code
|
closed
|
2002 May
|
anonymous
|
|
2002 May
|
|
4
|
3
|
drop table doesn't clean up database
|
edit |
If I drop a table , the table will be removed from schema, but the records remain in the database. VACUUM doesn't help.
The effect: The size of database is the same as before. |
The pages of data that used to hold the deleted data have been
added to a list of free pages and will be reused the next time
there is an INSERT or CREATE TABLE. SQLite does not leak disk
space. This can be verified using the integrity_check pragma.
If you need to minimize the size of an SQLite database, do this:
sqlite old.db .dump | sqlite new.db
mv new.db old.db
|
|
35 |
code
|
closed
|
2002 May
|
drh
|
CodeGen
|
2002 Sep
|
|
1
|
1
|
An ORDER BY clause on a subquery causes a segfault
|
edit |
Placing an ORDER BY clause on a subquery can result in a segfault.
For example:
create table t1(a,b);
insert into t1 values(1,2);
select a from (select a,b from t1 union
select b,a from t1 order order by b, a);
|
Fix this by simply ignoring the ORDER BY clause on a subquery. |
|
34 |
code
|
closed
|
2002 May
|
drh
|
CodeGen
|
2002 Sep
|
|
1
|
1
|
Segfault when a VIEW contains an ORDER BY clause
|
edit |
When the definition of a VIEW contains an ORDER BY clause, attempting
to access the view can cause a segfault. For example, the following
code fails:
create table t1 as select 1 as 'a', 2 as 'b';
create view v1 as
select b, a from t1
union select a, b from t1
order by a, b;
.header on
select a from v1;
|
This problem is fixed by getting views to ignore their ORDER BY
clause. This is a reasonable constraint, I think, because a view
is suppose to simulate a table and tables are unordered. My question
is: should putting an ORDER BY on a view definition raise an error,
or should it just be silently ignored. SQL Server raises an error.
MySQL does not support views. I don't know what Oracle, Informix,
or PostgreSQL do. |
|
33 |
code
|
closed
|
2002 May
|
drh
|
CodeGen
|
2002 Sep
|
|
1
|
1
|
Segfault when a VIEW contains a compound SELECT with an ORDER BY
|
edit |
The following command sequence causes a segfault:
create table t1 as select 1 as 'a', 2 as 'b';
create view v1 as select a from t1 union select b from t1 order by b;
.header on
select * from v1;
|
|
32 |
code
|
closed
|
2002 May
|
drh
|
|
2002 Sep
|
|
1
|
1
|
Columns in views are not always named correctly.
|
edit |
Create a veiw like this:
CREATE VIEW v1 AS SELECT f AS 'g' FROM t1;
When we do a "SELECT * FROM v1" we would expect the name of the
column to be 'g'. But instead it comes out as 'f'. |
|
31 |
code
|
closed
|
2002 Apr
|
danielk1977
|
CodeGen
|
2002 Sep
|
|
4
|
4
|
SELECT without FROM
|
edit |
Trivial issues with SELECT statements that don't have FROM clauses:
"SELECT * FROM (SELECT 1);" does a segfault.
"SELECT 1 WHERE 0;" returns a single row. This is not really incorrect, just wierd. |
|
28 |
code
|
closed
|
2002 Apr
|
anonymous
|
|
2002 Sep
|
drh
|
3
|
1
|
sqlite_changes not exported in sqlite.def in SQLite_source.zip
|
edit |
"sqlite_changes" is not listen in the .def file for the Windows DLL.
And thus the function is not linkable through the DLL import library. |
|
27 |
code
|
closed
|
2002 Apr
|
anonymous
|
|
2002 Apr
|
drh
|
2
|
2
|
incorrect result when doing select using quotes in where
|
edit |
the following sql does not return a result (where it should):
create table test (
"id" varchar(5),
"value" varchar(10)
);
insert into "test" values ('test','test it');
select * from "test" where "id" = 'test';
The following query does work, so it is probably an error in the parser
select * from "test" where id = 'test'; |
SQLite is correct. The expression "id" is a string and it is
not equal to the string 'test'. If you want the value of the
id column, either omit the double-quotes, or put the name of the
table in front separated by a dot.
select * from test where id='test';
select * from test where 'test'.'id' = 'test';
|
|
26 |
doc
|
closed
|
2002 Apr
|
anonymous
|
|
2002 Sep
|
drh
|
5
|
4
|
Proc-1 Not Refresh Newer SQLITE_MASTER Info After Proc-2 CreateTable
|
edit |
For Example:
Two Processes, First Open A Database File, then 2nd Open the Same Database File, Create Table Named 'demo', 1st Execute 'select * from demo', Error Show 'no such table: demo' |
This behavior is intentional. Documentation saying as much has
been added to the FAQ. |
|
25 |
code
|
closed
|
2002 Apr
|
anonymous
|
|
2002 Apr
|
drh
|
1
|
1
|
continu ticket 23, I Direct Access Sqlite.dll
|
edit |
I'm Sorry, My Desciption not a good detail.
I'm China User, Use Chinese Char and Direct Access Your's Sqlite.dll, the Error As Ticket23, So you can copy follow sql Statement to test:
1, create table test (Óû§Ãû,ÃÜÂë);
2, insert into test values ('Óû§Ãû','ÃÜÂë');
2, select rowid, Óû§Ãû, ÃÜÂë from test;
3, sqlite_exec(Handle, Sql, Callback, ErrMsg);
4, Data of Result is Correct, but FieldName not Same as Above.
I think, because you OS not Surpport Chinese, so you can compare fieldname's Byte, you can find the problem.
else I Ask How to Change to Utf-8 charset. |
I am unable to reproduce this problem. I have tried the sequence
of commands above, using versions of SQLite compiled for both
ISO8859 and UTF-8 and they all work perfectly. |
|
24 |
code
|
closed
|
2002 Apr
|
anonymous
|
|
2002 Apr
|
drh
|
4
|
3
|
Make "update ... where ..." fail if where clause is false.
|
edit |
It would be of great help to software using SQLite if update´s fails if a given where clause is false. |
If you need to know if the WHERE clause was false for all
rows of an UPDATE, you can use the sqlite_changes() API
to see how many rows were changed. |
|
23 |
code
|
closed
|
2002 Apr
|
anonymous
|
|
2003 Aug
|
drh
|
1
|
1
|
FieldName Returned Not Correct When Use Fast-East Chararctor Set
|
edit |
When SqlText = 'Select RowId, SC;'C{, C\Bk From Test';
SQLite_GetTable;
The Return FieldName not Equal Above FieldName in Select StateMent |
Unable to reproduce. UTF-8 field names are returned correctly
in my tests.
"SQLite_GetTable" is not an SQLite API function. Could it be that
you are using a third-party wrapper library (for VB, Perl, or Python)
that is causing the problem? |
|
22 |
code
|
closed
|
2002 Apr
|
anonymous
|
|
2002 Sep
|
drh
|
2
|
1
|
compound selects as expressions
|
edit |
(All on Windows2K)
Given the two tables:
CREATE TABLE pictures (id INTEGER PRIMARY KEY,filename varchar(255),import_date date,fileDateTime date,fileSize long);
CREATE TABLE pictures_categories (picture integer, category integer);
Having some records in pictures and some in pictures_categories I now want a select on pictures of the pictures NOT having an entry in the pictures_categories table
I try:
select * from pictures where id in (select id from pictures except select picture as id from pictures_categories);
The result is as expected when done from the commandline interface, but if I do a ".header on" or use SQLite as a lib in my application I get a windows memory protection error.
If I only select the .filename column the commandline writes "id" as the column header (depending on the "as" in the last select in the compound) this can be changed.
It seems to me as if only the headers from the right most select is written. |
|
21 |
code
|
closed
|
2002 Apr
|
anonymous
|
Shell
|
2002 May
|
|
1
|
1
|
2.4.8 SQLITE.EXE: out of memory! (Windows98)
|
edit |
Installed 2.4.8 pre-compiled downloads (sqlite.zip, sqlitedll.zip). At command prompt (Windows98) ran the sqlite command. Got error message:
SQLITE.EXE: out of memory!
Same files for 2.4.7 worked fine.
I am attempting to recompile the sqlite_source.zip sources using MingW verions 1.0.6. |
Unable to reproduce. But I think the problem was that the sqlite.exe
was unable to find the users home directory. This is now fixed. We
can reopen the bug if original problem turns out to be something
different. |
|
20 |
code
|
closed
|
2002 Apr
|
anonymous
|
|
2002 Apr
|
drh
|
1
|
1
|
Order By clause not sorting correctly for string columns
|
edit |
I have a string column called seqID with the following values (0.3, 0.1.1, 0.1) I perform "select seqID from table order by seqID" using sqlite command-line tool and receive the recods in the following order (0.1, 0.3, 0.1.1) This is contrary to every other SQL implementation I could try (including SQL Server). Should be (0.1, 0.1.1, 0.3) My app depends on having the right sequence and is broken. |
Works as designed.
The 0.1 and 0.3 are interpreted as numbers. These sort in numerical
order and come before all strings. 0.1.1 is not a well-formed number
so it is interpreted as a string and sorts after all numbers.
You can work around this problem by forcing the comparision to always
be between strings. Do this by prepending a single non-numeric
character to the column to be sorted. For example:
SELECT * FROM table ORDER BY 'x' || key;
The 'x'|| prepends a single 'x' character to the sort key and thus
forces all keys to be compared as strings. |
|
19 |
new
|
closed
|
2002 Apr
|
danielk1977
|
BTree
|
2002 May
|
|
3
|
4
|
synchronous pragma does not effect TEMP tables
|
edit |
The default_synchronous or synchronous pragmas don't seem to effect the behaviour of tables created in the temporary database file (ie. with CREATE TEMP TABLE ...). Note that I'm only basing this on empirical testing.
Would it be safe to always open the temporary data file as if default_synchronous was set to OFF, regardless of pragma settings? |
Yes, it is safe to treat TEMP tables as synchronous=OFF. And there
was an attempt in the code already to do just that. But I missed
a couple of cases. It should be working now. |
|
18 |
event
|
closed
|
2002 Apr
|
anonymous
|
|
2002 Apr
|
drh
|
1
|
1
|
The sqlite server does not run under windows xp
|
edit |
The sqlite server does not run under windows xp, it does not start. |
There must be some misunderstanding. SQLite is not a server.
One does not "start" SQLite. |
|
17 |
new
|
closed
|
2002 Apr
|
anonymous
|
|
2002 Sep
|
drh
|
5
|
5
|
Enhancement of %q in sqlite...printf API
|
edit |
The %q format specifier needs to be enclosed in single quotes
and produces '(NULL)' for string arguments passed as NULL pointers.
For some applications it would be nice to have an alternate
form (let's call it %Q) with slightly different behaviour:
- does implicit single quote enclosure
- expands to NULL when associated argument
is a NULL pointer
- thus allows to safely enter NULL values
in insert or update statements
Examples:
Old (%q):
insert into foo values(1, '%q')
with argument NULL expands to
insert into foo values(1, '(NULL)')
New (%Q):
insert into foo values(1, %Q)
with argument NULL expands to
insert into foo values(1, NULL)
with argument ba'r expands to
insert into foo values(1, 'ba''r')
|
|
16 |
code
|
closed
|
2002 Apr
|
anonymous
|
CodeGen
|
2002 May
|
|
2
|
2
|
sqlite cores
|
edit |
I have a TABLE created with.
create table sequence (id INTEGER, v);
If I give sqlite this (bad) SQL statement it generates a core file.
echo "INSERT INTO sequence (v) VALUES (p());" | sqlite dpc.db
sqlite: ./src/expr.c:843: sqliteExprCode: Assertion `pDef!=0' failed.
Aborted (core dumped)
Yes its bad SQL but IMHO it should come back with a "syntax error". |
|
15 |
code
|
closed
|
2002 Apr
|
anonymous
|
CodeGen
|
2002 May
|
|
5
|
4
|
getting the number of affected lines is harder than necessary
|
edit |
while wrapping sqlite into a plugin for the qt framework (www.troll.no),
I found that there is no simple way to get the number of modified rows after a call to get_table(), but the framework requires it.
The currently available solution, using the pragma, doesn t quite work
when using get_table() because no callback is called, and get_table()
does make many other aspects of the project easier.
So, it is currently a choice between making my code more complex using exec() or not report the affected rows accurately.
Proposed solution: implement a funtion
int sqlite_affected(sqlite *)
that returns the number of rows affected by the last call to exec() |
Add a new API function:
int sqlite_changes(sqlite*);
This function returns the number of rows that were changed by
the most recent call to sqlite_exec() or sqlite_get_table(). |
|
14 |
new
|
closed
|
2002 Apr
|
anonymous
|
|
2002 Apr
|
drh
|
5
|
4
|
decouple the BTREE implementaion from sqlite
|
edit |
decouple the BTREE implementaion from sqlite. So one can use Berkley DB, NDB or any other DB for data storage. MySQL did it in their implementation and it would make room for multi platform databases. |
This is already the case. The BTREE module has a well defined
interface to the rest of the system. It should be a (relatively)
simple matter to construct a wrapper around BDB, or any other
B-Tree implementation, that will seamlessly replace the existing
BTREE module. |
|
11 |
code
|
closed
|
2002 Apr
|
drh
|
CodeGen
|
2002 May
|
|
1
|
1
|
Wrong number of inserts reported after an IGNORE
|
edit |
When the COUNT_CHANGES pragma is one and one does an
INSERT OR IGNORE, the rows that are ignored get counted. |
|
10 |
code
|
closed
|
2002 Apr
|
drh
|
VDBE
|
2002 May
|
|
1
|
1
|
Stack grows without bound on UPDATE OR IGNORE
|
edit |
Everytime the IGNORE action is taken on an UPDATE OR IGNORE
statement, the depth of the VDBE stack grows by one. |
|
9 |
new
|
closed
|
2002 Apr
|
anonymous
|
BTree
|
2002 Sep
|
|
1
|
3
|
platform-independent db files
|
edit |
Trying to create an application that will run in a heterogeneous envioronment of x86, sparc, mips, and alpha machines running a variety of operating systems. User's home directories and data files are shared across all platforms. I'd like to use SQLite in an application but I want users to be able to share a database file across all platforms.
The "simple" fix is to change all database reads/writes to use Network Byte Order for the on-disk file format, and convert to local byte-order for in-memory use. This might be more of a problem due to the fact that SQLite is untyped. If you don't know that data is an integer vs. a string, you may not know the appropriate byte order. OTOH, if you store everything as strings, then you must have some way to convert the integer "10" to the two-byte string "10", and back, so the only byte-order issue would be data lengths.
Unfortunately SQLite is useless to me without portable data files.
Thanks, |
Changing the database file format to be byteorder independent is
a reasonable request. However, it is also a major rewrite of
the BTree layer. We'll put this off for the time being.
OK. It turned out to be easier than expected.
The first fix is incomplete. The journal file still is byte-order
dependent. So if a big-endian machine tries to rollback a transaction
started by a little-endian machine, it will fail.
Numbers are now written into the rollback journal as big-endian,
regardless of the byte-order of the host machine. There is a new
magic number at the beginning of journal files to identify them
as such. Old journals can still be rolled back, but only by
a process on the same byte-order machine as the journal was
originally created on. |
|
8 |
code
|
closed
|
2002 Apr
|
danielk1977
|
CodeGen
|
2002 May
|
|
2
|
1
|
More problems with where.c
|
edit |
There's still a small problem in where.c.
Some parts of the code assume that
only binary operators may be part of WHERE clauses, and
thus expressions may be evaluated outside of table-scan
loops that they depend on. Examples:
CREATE TABLE aa(a);
CREATE TABLE bb(b);
SELECT * from aa, bb WHERE b;
SELECT * from aa, bb WHERE max(a, b);
SELECT * from aa, bb WHERE CASE WHEN a = b THEN 1 END;
|
|
7 |
code
|
closed
|
2002 Apr
|
danielk1977
|
VDBE
|
2002 May
|
|
5
|
2
|
VDBE trace prints out garbage for P3 of Function opcodes
|
edit |
When the vdbe_trace pragma is active, and the VDBE executes a Function opcode, garbage is printed out for P3. eg:
5 Function 0 0 `@
The EXPLAIN command deals with this nicely. |
|
6 |
code
|
closed
|
2002 Apr
|
danielk1977
|
CodeGen
|
2002 May
|
|
1
|
1
|
Query optimizer does not consider function arguments
|
edit |
The query optimizer in "where.c" is slightly broken.
The code that determines the list of tables which an expression (Expr) depends on only considers the pLeft and pRight expressions, where it should consider pLeft, pRight and pList. It occurs all throughout the file.
For example, exprTableUsage() should add the following:
if (p->pList)
for (int ii = 0; ii < p->pList->nExpr; ii++)
mask |= exprTableUsage(base, p->pList->a[ii].pExpr);
To produce an illustration of the problem:
CREATE TABLE aa (a);
CREATE TABLE bb (b);
EXPLAIN SELECT * FROM aa, bb WHERE max(a, b);
0 ColumnCount 2 0
1 ColumnName 0 0 aa.a
2 ColumnName 1 0 bb.b
3 Open 0 3 aa
4 Ver
|
|
5 |
code
|
closed
|
2002 Mar
|
anonymous
|
|
2002 May
|
|
3
|
4
|
Bug submitter ignores severity/priority
|
edit |
Ticket 3 was submitted with a severity of 2 and a priority of 3, neither of which seemed to stick. Please investigate. (Note, this ticket was submitted with a severity of 3 and a priority of 4, for reference.) |
This is (or was) a bug in CVSTrac, not SQLite. The problem has
already been fixed. Thanks for noticing it, though. |
|
4 |
new
|
closed
|
2002 Mar
|
persicom
|
Shell
|
2002 May
|
|
2
|
3
|
Change prompt of 'sqlite' query tool.
|
edit |
I'm using SQLite as the storage for configuration data. I would like to have the facility to change the prompts 'sqlite> ' and ' ...> ' to something that more accurately reflects the system it's part of. You could do this as part of the "config" process like you handle UTF-8 or ISO-8859. |
Fixed in shell.c 1.53 by persicom |
|
3 |
code
|
closed
|
2002 Mar
|
anonymous
|
Parser
|
2002 May
|
|
1
|
1
|
Rejects "view" as column name
|
edit |
Neither CREATE TABLE nor SELECT parse "view" as a column name properly; it is rejected as a syntax error before processing.
Test SQL:
"SELECT col1,view,col3 FROM dummytable"
errmsg contains 'near "view": syntax error' and returns 1. |
|
2 |
new
|
closed
|
2002 Mar
|
drh
|
CodeGen
|
2002 May
|
|
2
|
3
|
Add support for TABLE.* in a query
|
edit |
SQLite supports "SELECT * FROM TABLE" but it does not
support "SELECT TABLE.* FROM TABLE". The latter needs to
be added. |
|
1 |
new
|
closed
|
2002 Mar
|
drh
|
VDBE
|
2005 Feb
|
|
3
|
4
|
Make the LIKE operator a user-installable function
|
edit |
The LIKE operator is currently a special VDBE opcode. Change this
so that LIKE is implemented by a user-installable function. That
way, users can change the functionality of LIKE if desired (for
example to make it case sensitive.) |
Also made the GLOB operator a function. |
|
2917 |
code
|
active
|
2008 Feb
|
anonymous
|
|
2008 Feb
|
|
4
|
4
|
Tcl interface - busy callback confusion script/procedure
|
edit |
In the Tcl interface the "busy" method doesn't work if a script is supplied instead of a procedure:
% package req sqlite3
3.5.1
% sqlite3 db hl7journal.db
% db busy {puts busy; expr 0}
% db eval {select count(*) from incoming}
busy
database is locked
Here the callback script is only invoked once, even though it returns 0. If we put this code in a procedure it works as desired/expected:
% proc b args {puts busy; after 1000; expr 0}
% db busy b
% db eval {select count(*) from incoming}
busy
busy
busy
^C
|
2008-Feb-01 12:31:45 by anonymous:
After researching this a little it appears this happens because the busy callback is invoked with an extra argument. The extra argument leads to an error but that error is only visible through errorInfo, not the result.
I humbly suggest the following changes:
* mention the extra argument in the documentation of the Tcl interface
* forward the error from the busy callback to Tcl (replacing the "database is locked")
* enhance errorInfo to make the invokation of the busy callback apparent.
Currently, I'm getting this errorInfo:
% db busy {puts hi; after 1000; return 0}
% db eval "select count(*) from incoming"
hi
database is locked
% set errorInfo
bad option "0": must be -code, -errorcode, or -errorinfo
while executing
"return 0 0"
invoked from within
"db eval "select count(*) from incoming""
It would be nicer to get something like
bad option "0": must be -code, -errorcode, or -errorinfo
while executing
"return 0 0"
from busy callback
"puts hi; after 1000; return 0 0"
invoked from within
"db eval "select count(*) from incoming""
|
|
2916 |
code
|
active
|
2008 Feb
|
anonymous
|
|
2008 Feb
|
|
1
|
1
|
sqlitedll-3_5_5.zip is older 3.5.4 binary
|
edit |
sqlitedll-3_5_5.zip in download section is same with old 3.5.4 binary. |
2008-Feb-01 12:13:04 by anonymous:
Yes , I can confirm it |
|
2915 |
build
|
active
|
2008 Feb
|
pweilbacher
|
|
2008 Feb
|
|
4
|
3
|
fix Makefile for platforms that need .exe extension
|
edit |
There are some targets that need a $(TEXE) added in Makefile.in. Otherwise a platform that needs a .exe extension cannot run e.g. tests. |
|
2914 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
3
|
3
|
ATTACH returns SQLITE_ERROR when it means SQLITE_BUSY
|
edit |
I'm seeing the same behavior as in #2096, with SQLite 3.5.4. ATTACH DATABASE fails with SQLITE_ERROR rather than SQLITE_BUSY when the database to be attached, or the main database of the connection being attached to, is EXCLUSIVE-locked by another database connection. For added confusion, sqlite3_errmsg() says "database is locked" when the ATTACH is done via sqlite3_exec(), but "SQL logic error or missing database" when the ATTACH is done via sqlite3_step().
As a result of this bug, it is difficult to distinguish between fatal and transient ATTACH errors, particularly when sqlite3_step() is used.
I am attaching a test program that demonstrates the problem. |
|
2912 |
new
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
5
|
4
|
merge join
|
edit |
Would it be possible to implement merge joins? |
|
2911 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
2
|
2
|
Adding parentheses to a FROM clause
|
edit |
Hi,
Parentheses in a FROM statement seem to mess with the ability to use table aliases in the "what" part. Here is an example:
Start SQLite:
$ sqlite3 employee.db
SQLite version 3.5.4
Enter ".help" for instructions
create a couple of tables and populate them with test data:
sqlite> create table person (id integer, name text, employerid integer);
sqlite> create table employer (id integer, name text);
sqlite> insert into person (id, name, employerid) values (1, "Dave", 1);
sqlite> insert into employer (id, name) values (1, "ACME");
Run a simple query with no parentheses in the FROM statement:
sqlite> select b.id from person as a inner join employer as b on a.employerid = b.id;
1
Everything works as expected. Now, repeat that query with parentheses:
sqlite> select b.id from (person as a inner join employer as b on a.employerid = b.id);
SQL error: no such column: b.id
There you have it.
This may be related to ticket #1822, although that ticket deals with aliases and subqueries. This problem seems to be more fundamental.
Many thanks,
-- Dave |
|
2909 |
build
|
active
|
2008 Jan
|
aswift
|
|
2008 Jan
|
aswift
|
4
|
4
|
Omit the _XOPEN_SOURCE 500 define on Mac OS-X (check for __APPLE__)
|
edit |
sqliteInt.h attempts to avoid setting _XOPEN_SOURCE on MacOSX by checking if __DARWIN__ is defined, however on Leopard (as of Mac OS X 10.5) this test fails and should be enhanced by testing for both __DARWIN__ and __APPLE__
Building sqlite succeeds with _XOPEN_SOURCE defined, but it causes _POSIX_C_SOURCE to be defined which leads to failing to define F_FULLFSYNC which prevents use of the fullfsync pragma. |
|
2908 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
3
|
3
|
Add support to examine whether statements modify the database
|
edit |
Currently there is no way to check whether a compiled statement will modify the database when being executed. Of course, there is the work-around of misusing the authorizer callback for this purpose, but this is kinda error prone and causes quite some overhead for such a simple purpose. |
|
2907 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
1
|
1
|
Issues of sqlite3 with Windows Mobile 5/6
|
edit |
hi. we are currently using sqlite3 for our mobile application. it has been running without a hitch on pocket pc 2003 and previous versions. come windows mobile 5 and 6 we have been getting errors, although not consistent yet. one example is 'EXCEPTION_DATATYPE_MISALIGNMENT'. another is 'SELECT STATMENTS TO THE LEFT AND RIGHT OF UNION ARE NOT EQUAL'. i was wondering if you have any known compatibility issues of your product with this version of windows mobile.
thanks in advance. |
2008-Jan-28 13:26:26 by anonymous:
EXCEPTION_DATATYPE_MISALIGNMENT is thrown when you try to use and Odd pointer address. I wrote a custom allocator for WinCE/ARM platform, and I have to take care about memory alignment (I used to align at 2 bytes, and at that time it solved the problem) |
|
2905 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
pweilbacher
|
2
|
2
|
mutex_os2.c - incorrect mutex implementation
|
edit |
The OS/2 version of sqlite3_mutex_alloc() is badly broken.
It creates named mutexes which, by design, are global rather than process-specific as intended. This might be minimally acceptable except that the function reuses the same name every time it attempts to create a SQLITE_MUTEX_FAST or SQLITE_MUTEX_RECURSIVE.
The result is that every call returns the exact same semaphore to every thread in every process using sqlite3. Once this mutex is owned by one process, other processes calling sqlite3_mutex_enter() will be blocked. Much the same is true for the static mutexes. Every process ends up using the exact same SQLITE_MUTEX_STATIC_MASTER, SQLITE_MUTEX_STATIC_MEM, etc.
There's another flaw that is fairly minor compared with the above: in an attempt to avoid concurrency when creating the static mutexes, this function uses an API call that is thoroughly deprecated.
The attached patch remedies all of these issues. Since the logic that protects the creation of the static mutexes may not be self-evident, here's an explanation:
The existence (or non-existence) of a given named mutex is itself a semaphore. If the isInit flag is false, the code attempts to create a mutex whose name is unique to that process. If the attempt is successful, there are two possibilities:
(1) either the current thread is the first to reach this code & may proceed;
(2) or while the current thread was making its preparations, another thread created the mutex, did the init, then closed the mutex.
Testing isInit immediately after creating the mutex determines which possibility is valid.
If mutex creation fails due to a duplicate name, then another thread is currently performing the init. In this case, the current thread simply has to wait a while until the other thread is done & isInit becomes true.
Submitted by Rich Walsh (richATe-vertise.com) |
|
2903 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
2
|
2
|
tclinstaller.tcl fails on path and permissions issue
|
edit |
When compiling using custom PREFIX, pointing to private directory, tclinstaller.tcl fails, because it tries to remove contents from /usr/share/tcl8.4/sqlite3.
./configure --prefix=/my/private/sqlite/sqlite-3.5.4
... # success
make
... # success
make install
...
tclsh ./tclinstaller.tcl 3.5
error deleting "/usr/share/tcl8.4/sqlite3": not owner
while executing
"file delete -force $LIBDIR/sqlite3"
(file "./tclinstaller.tcl" line 17)
make: *** [tcl_install] Error 1
I've found two work-arounds:
- If you run make install as root.
- If you use ./configure --disable-tcl
|
2008-Jan-28 17:47:39 by anonymous:
I also ran into this problem.
make install as root will end up copying files into the system's library directory and is almost certainly not what you want if you specified your own --prefix. |
|
2902 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
drh
|
3
|
3
|
Add watch support to SQLite
|
edit |
SQLite currently provides only TRIGGERs and the update_hook() as a way for applications to stay informed about changes to the database. But both of these alternatives do not provide enough details about the actual changes to the underlying database file(s).
We've prepared a patch for SQLite 3.5.x to allow applications to install a watch_hook into the database, that will be invoked everytime the database is changed with exact details about the change that was performed. |
2008-Jan-22 16:06:59 by anonymous:
Great idea and nice job. This functionality is very useful.
2008-Jan-31 18:27:16 by anonymous:
Any chance to get this committed for the next release (i.e. 3.5.6)?
2008-Jan-31 19:38:35 by drh:
Unlikely, for two reasons:
- I am unconvinced that this patch solves a problem that needs
solving. It is vitally important to a project like SQLite that
we work to avoid clutter and cruft. That means that any change
must have a compelling rational or else it is rejected.
- The patches are against version 3.5.4. There were many changes
to the core for 3.5.5 and the patches no longer work.
2008-Jan-31 20:58:55 by anonymous:
We can (and will) port the changes to 3.5.5, so the second point will be done. First the first point, I'm not sure how many projects will actually need this functionality, but I guess there are quite a lot of projects that would benefit, and for the others, there's zero overhead due to this patch.
2008-Jan-31 21:21:30 by drh:
There is a lot of overhead for me because if I accept this patch,
that means I have to maintain it forever. Most of the work is
in maintenance, not coming up with the original patch. |
|
2901 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
3
|
3
|
ROLLBACK and COMMIT statements should not expire
|
edit |
Currently, whenever a statement changes the schema of the database, all prepared statements will be expired, no matter whether they actually need to be prepared again or not. This is especially problematic for ROLLBACK statements in a multi-statement transaction. Currently there is no way to guaranty that a multi-statement transaction can at least be rolled back in case of an error, because one has to (re)prepare the ROLLBACK statement to roll back the transaction, which can fail because of OOM (in a multi-threaded application). |
|
2899 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
4
|
4
|
sqlite3_reset() after exec() takes > 100 ms to complete
|
edit |
I'm not entirely sure whether this is a bug or not... I'm not familiar enough with SQLite to know if this is way too unconventional, but I noticed today that running exec() in conjunction with a prepared statement really kills the performance of sqlite3_reset(), if it's called after exec():
// init
sqlite3_prepare_v2( db,
"SELECT [file_id],[file_name],[file_mime],[file_type],"
"[file_size],[date_created],[date_accessed],[data] "
"FROM file_cache WHERE [file_id] = ? LIMIT 1;",
-1, &sqQueryStatement, &unused );
// query function -- called repeatedly (usually second or third run starts to cause big delays)
/* begin function */
sqlite3_reset( sqQueryStatement );
sqlite3_bind_int( sqQuerystatement, 1, 292 );
sqlite3_step( sqQueryStatement );
bla = sqlite3_column_int( sqQueryStatement, 0 );
/* ... */
char *erm;
sqlite3_exec( db, "UPDATE file_cache SET [date_accessed] = DATETIME( 'NOW', 'LOCALTIME' ) WHERE [file_id] = 292", NULL, NULL, &erm );
/* ... */
sqlite3_clear_bindings( sqQueryStatement );
/* end function */
If sqlite3_exec() is commented out, consecutive calls to the function run in less than a millisecond. With sqlite3_exec() included, sqlite3_reset() call in this function takes > 100 ms to complete.
Tested: Windows Vista Ultimate 32 bit, Visual Studio 2005 8.0.50727.876 |
|
2898 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
1
|
1
|
Latest CVS for 3.5.4 fails to build test1.c
|
edit |
gcc -pipe -O3 -g -Wall -DSQLITE_DISABLE_DIRSYNC=1 -I. -I../src -DNDEBUG -I/usr/include -DSQLITE_THREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DTCLSH=1 -DSQLITE_TEST=1 -DSQLITE_CRASH_TEST=1 -DSQLITE_NO_SYNC=1 -DTEMP_STORE=1 -o .libs/testfixture ../src/attach.c ../src/btree.c ../src/build.c ../src/date.c ../src/expr.c ../src/func.c ../src/insert.c ../src/malloc.c ../src/os.c ../src/os_os2.c ../src/os_unix.c ../src/os_win.c ../src/pager.c ../src/pragma.c ../src/prepare.c ../src/printf.c ../src/select.c ../src/test1.c ../src/test2.c ../src/test3.c ../src/test4.c ../src/test5.c ../src/test6.c ../src/test7.c ../src/test8.c ../src/test9.c ../src/test_autoext.c ../src/test_async.c ../src/test_btree.c ../src/test_config.c ../src/test_hexio.c ../src/test_malloc.c ../src/test_md5.c ../src/test_onefile.c ../src/test_schema.c ../src/test_server.c ../src/test_tclvar.c ../src/test_thread.c ../src/tokenize.c ../src/utf.c ../src/util.c ../src/vdbe.c ../src/vdbeapi.c ../src/vdbeaux.c ../src/vdbemem.c ../src/where.c parse.c ../src/tclsqlite.c ./.libs/libsqlite3.so -L/usr/lib64 -ltcl8.4 -ldl -lpthread -lieee -lm -Wl,--rpath -Wl,/common/pkgs/sqlite-3.5.4.3/lib
../src/build.c: In function 'sqlite3RefillIndex':
../src/build.c:2275: warning: cast to pointer from integer of different size
../src/func.c: In function 'trimFunc':
../src/func.c:919: warning: cast from pointer to integer of different size
../src/func.c: In function 'sqlite3RegisterBuiltinFunctions':
../src/func.c:1464: warning: cast to pointer from integer of different size
../src/func.c:1483: warning: cast to pointer from integer of different size
../src/insert.c: In function 'sqlite3GenerateConstraintChecks':
../src/insert.c:1200: warning: cast to pointer from integer of different size
../src/insert.c:1034: warning: 'j2' may be used uninitialized in this function
../src/insert.c: In function 'sqlite3Insert':
../src/insert.c:373: warning: 'regFromSelect' may be used uninitialized in this function
../src/test1.c: In function 'test_collate_func':
../src/test1.c:2085: warning: cast from pointer to integer of different size
../src/test1.c: In function 'test_collate_needed_cb':
../src/test1.c:2209: warning: cast to pointer from integer of different size
../src/test1.c: In function 'alignmentCollFunc':
../src/test1.c:2258: warning: cast from pointer to integer of different size
../src/test1.c:2259: warning: cast from pointer to integer of different size
../src/test8.c: In function 'echoBestIndex':
../src/test8.c:722: warning: 'nRow' may be used uninitialized in this function
../src/vdbe.c: In function 'sqlite3VdbeExec':
../src/vdbe.c:502: warning: 'pOut' may be used uninitialized in this function
../src/vdbe.c:501: warning: 'pIn3' may be used uninitialized in this function
../src/vdbe.c:501: warning: 'pIn2' may be used uninitialized in this function
../src/vdbe.c:501: warning: 'pIn1' may be used uninitialized in this function
../src/vdbeaux.c: In function 'sqlite3VdbeChangeP4':
../src/vdbeaux.c:529: warning: cast from pointer to integer of different size
../src/vdbemem.c: In function 'sqlite3ValueText':
../src/vdbemem.c:911: warning: cast from pointer to integer of different size
/tmp/ccsuOeus.o: In function `reset_prng_state':
/build/work/sqlite-3.5.4.3/bld/../src/test1.c:4280: undefined reference to `sqlite3ResetPrngState'
/tmp/ccsuOeus.o: In function `restore_prng_state':
/build/work/sqlite-3.5.4.3/bld/../src/test1.c:4267: undefined reference to `sqlite3RestorePrngState'
/tmp/ccsuOeus.o: In function `save_prng_state':
/build/work/sqlite-3.5.4.3/bld/../src/test1.c:4254: undefined reference to `sqlite3SavePrngState'
collect2: ld returned 1 exit status
make: *** [testfixture] Error 1 |
2008-Jan-17 23:54:58 by anonymous:
Problem appears to be here in libsqlite.3.so.0.8.6 as shown by:
nm -A .libs/libsqlite3.so.0.8.6 | grep sqlite3ResetPrngState
which shows no entry point. And:
nm -A .libs/random.o | grep sqlite3ResetPrngState
which also shows no entry point.
2008-Jan-17 23:56:55 by anonymous:
Ah... It appears -DSQLITE_TEST should be passed when building test1.c and left off when building prior to install.
2008-Jan-21 20:16:00 by anonymous:
In the makefile the right flag appears to be set, it's just not
making it through to the compile for some reason.
2008-Jan-21 20:16:24 by anonymous:
Still fails the same based on today's cvs update.
2008-Jan-23 03:14:49 by anonymous:
This bug fixed as of latest cvs pull |
|
2897 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
1
|
1
|
String or BLOB exceed size limit
|
edit |
This error was shown after attemp to read script from SQLite 3.5.4 shell in order to recreate old DB. Details:
1. Database was created with SQLite 3.3.4. Around 20 standard fieds and one BLOB.
2. The only one existed table was dumped with shell of SQLite 3.5.4. SQL script seems to be coorrect.
3. Opened SQLite 3.5.4 and read script in new DB. The error "String or BLOB exceed size limit" are sown for several lines. Many records missing.
4. Attempted to dump table with shell of version 3.3.6 (have no more 3.3.4 shell) and read into new DB with 3.5.4 shell The same errors are shown.
The same steps was attempted with 3.3.6. shell only. All seems to be correct. |
2008-Jan-17 20:23:25 by drh:
This size limit on BLOBs in SQLite version 3.5.4 is 1GB.
How big is your blob, exactly?
2008-Jan-17 22:22:24 by anonymous:
BLOB in each record is no more than few MB. Mostly it is few KB (e-client and news application). Whole DB have around 200MB.
2008-Jan-18 02:28:11 by drh:
This issue is probably resolved by check-in [4636]
, then.
2008-Jan-18 14:28:13 by anonymous:
If directive SQLITE_MAX_SQL_LENGTH is not defined it is set to 1,000,000 (10^6) in amalgamation code of 3.5.4. |
|
2893 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
1
|
1
|
incorrect integer range tests
|
edit |
recently a function that performs integer range tests was added to the cvs (check-in [4706]
), but if i am correct there is a problem in the return value of the function in the file vdbemem.c:
static i64 doubleToInt64(double r){
...
if( r<(double)minInt ){
return minInt;
}else if( r>(double)maxInt ){
return minInt; <-- is this correct, shouldn't it be maxInt?
}else{
return (i64)r;
}
}
|
2008-Jan-16 17:33:56 by drh:
See the remarks on ticket #2280. The code duplicates the
behavior of the FPU on x86.
2008-Jan-16 18:21:28 by anonymous:
did you mean ticket #2880? didn't read that ticket before, but since there was no comment regarding that behavior in the function it seemed (to my eyes) that it was a mistake.
maybe adding a small comment in there would clarify this issue
2008-Jan-16 18:39:42 by anonymous:
Just because the double to int overflow behavior happens to be that way with GCC on x86, is it desirable? |
|
2892 |
new
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
5
|
5
|
There should be a way in the api to read more precise error message.
|
edit |
Currently all errors in sql queries issued via C,C++ api result in error code SQLITE_ERROR = 1 and message "SQL error or missing database".
That leaves user completely clueless what mistake in his sql he actually made.
Some evidence of confusion can be found here:
http://bugs.php.net/bug.php?id=33117 |
2008-Jan-16 17:41:00 by drh:
SQLite gives detailed error information for SQL syntax or logic
errors. (Try, for example, entering invalid SQL into the CLI.)
I think perhaps that PHP is simply failing to to access
those errors and is instead picking up some other error indication
from someplace else.
2008-Jan-16 21:59:17 by anonymous:
Well I shall retest it, but I got the same error message upon a duplicate key in Delphi. Although I'm aware of an enhanced api to get the errormessage.
2008-Jan-17 00:05:58 by drh:
What error message do you get from the CLI? |
|
2886 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
3
|
3
|
testfixture: -fPIC needed when building extension(s)
|
edit |
(this fix/change is probably needed in older versions too, i meant to send this in earlier)
-fPIC is needed when building extensions (some platforms don't need this or don't care --- x86-64 does)
diff --git a/test/loadext.test b/test/loadext.test
index 81e152f..2a7fa2e 100644
--- a/test/loadext.test
+++ b/test/loadext.test
@@ -64,7 +64,7 @@ if {![file exists $testextension]} {
set srcdir [file dir $testdir]/src
set testextsrc $srcdir/test_loadext.c
if {[catch {
- exec gcc -Wall -I$srcdir -I. -g -shared $testextsrc -o $testextension
+ exec gcc -Wall -fPIC -I$srcdir -I. -g -shared $testextsrc -o $testextension
} msg]} {
puts "Skipping loadext tests: Test extension not built..."
puts $msg
|
|
2885 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
4
|
4
|
(minor) fulltest failures
|
edit |
Minor noise in fulltest on a 64-bit machine (everything seems to work otherwise though):
4 errors out of 61527 tests
Failures on these tests: exclusive-ioerr-2.280.4
exclusive-ioerr-2.281.4 exclusive-ioerr-2.282.4 incrvacuum-ioerr-1.31.4
All memory allocations freed - no leaks
details:
exclusive-ioerr-2.280.3... Ok
exclusive-ioerr-2.280.4...
Expected: [8ee59fe0b5bc391ecc5002539379b063]
Got: [35e56178ad878809d4789c5797265a23]
exclusive-ioerr-2.281.1... Ok
exclusive-ioerr-2.281.2... Ok
exclusive-ioerr-2.281.3... Ok
exclusive-ioerr-2.281.4...
Expected: [95762fb35ef83ddba65f681325346ef2]
Got: [1c20c63d975ad85b395a5e7701d785c2]
exclusive-ioerr-2.282.1... Ok
exclusive-ioerr-2.282.2... Ok
exclusive-ioerr-2.282.3... Ok
exclusive-ioerr-2.282.4...
Expected: [2c5ea7db8424f38d17cdff41056da0e0]
Got: [c02841c40d3e6e0579922745bd9c0260]
exclusive-ioerr-2.283.1... Ok
[...]
incrvacuum-ioerr-1.31.4...
Expected: [ea55042a449c3b4759730a882e8271a0]
Got: [9951814984696d0811cacbe862060af8]
incrvacuum-ioerr-1.32.1... Ok
|
2008-Jan-19 00:56:30 by anonymous:
A test from 20 minutes ago passes cleanly. This could be closed. |
|
2884 |
new
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
4
|
4
|
Way to find out limits
|
edit |
The page http://www.sqlite.org/limits.html shows some limits that SQLite has. They are consts in the code, and defaults are listed, but there doesn't seem to be any way to find out what values a particular binary was built with.
For example, I've gotten SQLite as part of my OS or another program, and I don't know what value of SQLITE_MAX_COLUMN was used to compile this SQLite. I'm trying to track down a bug in my code, and if this value was too small, that would explain it. (In truth, it's probably not the cause, but I'd like to rule it out.)
I'd like a way to print the value of these limits at runtime. It doesn't have to have a stable API -- it would mostly be useful for debugging. If the command-line client had a command ".limits" that printed all of these values, that would be super. |
|
2882 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
3
|
3
|
fulltest failure: ./testfixture: wrong # args: should be "cksum db"
|
edit |
exclusive-ioerr-2.2.1... Ok
./testfixture: wrong # args: should be "cksum db"
while executing
"ifcapable vacuum {
do_ioerr_test ioerr-2 -cksum true -sqlprep {
BEGIN;
CREATE TABLE t1(a, b, c);
INSERT INTO t1 VALUES(1, randstr(50,..."
(file "../test/ioerr.test" line 58)
invoked from within
"source $testdir/ioerr.test"
(file "../test/exclusive3.test" line 50)
invoked from within
"source $testfile"
("foreach" body line 5)
invoked from within
"foreach testfile [lsort -dictionary [glob $testdir/*.test]] {
set tail [file tail $testfile]
if {[lsearch -exact $EXCLUDE $tail]>=0} continue
..."
("for" body line 7)
invoked from within
"for {set Counter 0} {$Counter<$COUNT && $nErr==0} {incr Counter} {
if {$Counter%2} {
set ::SETUP_SQL {PRAGMA default_synchronous=off;}
} else ..."
(file "..//test/all.test" line 85)
|
2008-Jan-14 23:25:49 by anonymous:
The latest code seems to have fixed this. I would close this but I don't see how to do that. |
|
2881 |
build
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
1
|
1
|
Latest sqlite-3.5.4 build fail on latest Fedora 2.6.23.12-52.fc7
|
edit |
Two test cases fail.
io-4.1...
Expected: [3]
Got: [2]
io-4.2.1... Ok
io-4.2.2... Ok
io-4.2.3...
Expected: [3]
Got: [2]
io-4.3.1... Ok
Let me know how to run individual test cases and how this might
be fixed.
Here's how I built sqlite using latest CVS. If something is
wrong here, let me know and I'll rebuild/retest.
I'm building on latest Fedora fc7.
Thanks.
_______
net1#uname -a
Linux net1.coolsurf.com 2.6.23.12-52.fc7 #1 SMP Tue Dec 18 20:27:10 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
net1#build_sqlite
mkdir -p /build/work/sqlite-3.5.4
cd /build/work/sqlite-3.5.4
unset CDPATH
export CFLAGS='-pipe -O3 -g -DSQLITE_DISABLE_DIRSYNC=1 -Wall'
rm -rf bld
cvs -d :pserver:anonymous@www.sqlite.org:/sqlite -r update .
mkdir bld
cd bld
../configure --prefix=/common/pkgs/sqlite-3.5.4 --enable-tcl --with-tcl=/usr/lib64 --enable-threadsafe --enable-threads-override-locks
make
groupadd vuser || /bin/true
useradd -M -g vuser -d /vhost/davidfavor.com/users/david -s /bin/zsh david || /bin/true
useradd -M -g vuser -d /vhost/livefeast.com/users/yemiah -s /bin/zsh yemiah || /bin/true
chown david:vuser -R ..
su -c "make test" david
|
2008-Jan-11 17:18:52 by anonymous:
Same tests still fail with CVS of today around 11AM CST.
2008-Jan-11 17:41:55 by drh:
FWIW, both those test cases pass on SuSE 10.1. I do not understand
why they are failing on Fedora. But in any event, the tests in
question are verifying logic that implements an optimization
that is not used on Fedora, ever. So the failures are of no
consequence. If those are the only two tests that fail, then
you can safely use the build for whatever it is you are trying
to do.
2008-Jan-11 19:16:19 by anonymous:
Failures when 'make fulltest' built with CFLAGS of
'-pipe -O3 -g -Wall -DSQLITE_DISABLE_DIRSYNC=1 -DSQLITE_MEMDEBUG'
exclusive-malloc-1.transient.746...make: *** [fulltest]
Segmentation fault
Failures when 'make fulltest' built with CFLAGS of
'-pipe -O3 -g -Wall -DSQLITE_DISABLE_DIRSYNC=1'
Skipping malloc tests: not compiled with -DSQLITE_MEMDEBUG...
6 errors out of 61998 tests
Failures on these tests: exclusive-ioerr-2.280.4
exclusive-ioerr-2.281.4 exclusive-ioerr-2.282.4
incrvacuum-ioerr-1.31.4 io-4.1 io-4.2.3
All memory allocations freed - no leaks
Maximum memory usage: 14376554 bytes
Pre 3.5.x builds work fine on Fedora. If you're open to debugging all
these, I'd like to go through and resolve all these one by one, so
Fedora has a clean build/fulltest.
Please let me know how to run each test individually and I'll try to
figure out the problem with each.
Thanks. |
|
2879 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
anonymous
|
4
|
3
|
VACUUM enters temporary sequence numbers in sqlite_sequence
|
edit |
I have two TEMPORARY tables added to a database, that both contain an INTEGER PRIMARY KEY AUTOINCREMENT field.
After issuing a VACUUM command, the maximum value of these fields is added to the sqlite_sequence table. And stay there after the connection closes. |
|
2878 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
1
|
1
|
Memory leaks with latest CVS [4693]
|
edit |
This SQL leaks memory with CVS [4693]
:
CREATE TABLE x(id integer primary key, a TEXT NULL);
INSERT INTO x (a) VALUES ('first');
CREATE TABLE tempx(id integer primary key, a TEXT NULL);
INSERT INTO tempx (a) VALUES ('t-first');
CREATE VIEW tv1 AS SELECT x.id, tx.id FROM x JOIN tempx tx ON tx.id=x.id;
One leak is caused by "CREATE TABLE tempx", a second one by "CREATE VIEW tv1".
The above SQL is a digest of select7.test, select7-2.1. |
2008-Jan-14 17:51:11 by anonymous:
I have tested again with CVS [4711]
and it does no longer show the original leaks.
I therefore consider this issue fixed and I will now close this ticket.
2008-Jan-14 23:56:34 by anonymous:
Doing a fulltest with -MSQLITE_MEMDEUG I see reports of memory leaks. I assume these are of little or minimal interest at present because of the amount of code flux.
If you do want details, please let me know (I'll recheck this ticket tomorrow I guess).
2008-Jan-15 08:23:56 by anonymous:
Thanks for the follow-up. I am not running the original test-suite but have have ported a great number of them to Delphi.
If you could just let me know which tests caused the leaks you fixed in [4712]
I'd be more than glad the port these test as well and let you know my findings.
2008-Jan-19 00:56:17 by anonymous:
A test from 20 minutes ago passes cleanly. This could be closed. |
|
2875 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
3
|
2
|
LIKE does not work with lowercase swedish characters
|
edit |
Swedish letters å,ä,ö is not supported by the LIKE statement. When trying to perform a query like
SELECT * FROM table WHERE name LIKE "å%"
we will not get a match for names starting on Å (which is uppercase for å).
To recreate:
SQLite version 3.5.4
Enter ".help" for instructions
sqlite> CREATE TABLE TestingTable(Name varchar(20));
sqlite> INSERT INTO TestingTable values ('Sweden');
sqlite> INSERT INTO TestingTable values ('sweden');
sqlite> INSERT INTO TestingTable values ('Åland');
sqlite> INSERT INTO TestingTable values ('åland');
sqlite> SELECT * FROM TestingTable;
Sweden
sweden
Åland
åland
sqlite> SELECT * FROM TestingTable WHERE Name LIKE "swe%";
Sweden
sweden
sqlite> SELECT * FROM TestingTable WHERE Name LIKE åla%";
åland
|
|
2874 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
1
|
1
|
THREADSAFE #define HAVE_LOCALTIME_R, HAVE_GMTIME_R in os_unix.c
|
edit |
The precompiled shared sqlite3 library for Linux on sqlite.org which appears to be built with pthread support is using localtime and gmtime which are not threadsafe.
For THREADSAFE builds could either configure be changed to detect the functions gmtime_r and localtime_r or change os_unix.c to explicitly #define HAVE_LOCALTIME_R and HAVE_GMTIME_R? |
|
2873 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
1
|
1
|
HAVE_USLEEP, HAVE_FDATASYNC=1 detected but not used by configure; make
|
edit |
I noticed that a couple of open source projects were not picking up usleep() for recent sqlite builds and used the coarser grained sleep() instead. Around 11 months ago something changed in sqlite's build process.
It seems that both -DHAVE_USLEEP=1, -DHAVE_FDATASYNC=1 and -DOS_UNIX=1 are detected correctly by configure but not used by the generated Makefile. As result, UNIX builds of sqlite3 via ./configure do not use usleep() and fdatasync() and do not define OS_UNIX.
I don't know whether the lack of fdatasync() versus the default fsync() affects anyone.
Please apply the following patch which corrects the problem with "./configure && make". Thank you.
Index: configure
===================================================================
RCS file: /sqlite/sqlite/configure,v
retrieving revision 1.45
diff -u -3 -p -r1.45 configure
--- configure 27 Nov 2007 14:50:07 -0000 1.45
+++ configure 5 Jan 2008 07:41:00 -0000
@@ -18520,9 +18520,9 @@ if test "$TARGET_EXEEXT" = ".exe"; then
OS_UNIX=0
OS_WIN=0
OS_OS2=1
- TARGET_CFLAGS="$TARGET_CFLAGS -DOS_OS2=1"
+ CFLAGS="$CFLAGS -DOS_OS2=1"
if test "$ac_compiler_gnu" == "yes" ; then
- TARGET_CFLAGS="$TARGET_CFLAGS -Zomf -Zexe -Zmap"
+ CFLAGS="$CFLAGS -Zomf -Zexe -Zmap"
BUILD_CFLAGS="$BUILD_CFLAGS -Zomf -Zexe"
fi
else
@@ -18530,14 +18530,14 @@ if test "$TARGET_EXEEXT" = ".exe"; then
OS_WIN=1
OS_OS2=0
tclsubdir=win
- TARGET_CFLAGS="$TARGET_CFLAGS -DOS_WIN=1"
+ CFLAGS="$CFLAGS -DOS_WIN=1"
fi
else
OS_UNIX=1
OS_WIN=0
OS_OS2=0
tclsubdir=unix
- TARGET_CFLAGS="$TARGET_CFLAGS -DOS_UNIX=1"
+ CFLAGS="$CFLAGS -DOS_UNIX=1"
fi
@@ -19392,7 +19392,7 @@ fi
echo "$as_me:$LINENO: result: $ac_cv_func_usleep" >&5
echo "${ECHO_T}$ac_cv_func_usleep" >&6
if test $ac_cv_func_usleep = yes; then
- TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_USLEEP=1"
+ CFLAGS="$CFLAGS -DHAVE_USLEEP=1"
fi
@@ -19491,7 +19491,7 @@ fi
echo "$as_me:$LINENO: result: $ac_cv_func_fdatasync" >&5
echo "${ECHO_T}$ac_cv_func_fdatasync" >&6
if test $ac_cv_func_fdatasync = yes; then
- TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_FDATASYNC=1"
+ CFLAGS="$CFLAGS -DHAVE_FDATASYNC=1"
fi
Index: configure.ac
===================================================================
RCS file: /sqlite/sqlite/configure.ac,v
retrieving revision 1.31
diff -u -3 -p -r1.31 configure.ac
--- configure.ac 27 Nov 2007 14:50:07 -0000 1.31
+++ configure.ac 5 Jan 2008 07:41:00 -0000
@@ -310,9 +310,9 @@ if test "$TARGET_EXEEXT" = ".exe"; then
OS_UNIX=0
OS_WIN=0
OS_OS2=1
- TARGET_CFLAGS="$TARGET_CFLAGS -DOS_OS2=1"
+ CFLAGS="$CFLAGS -DOS_OS2=1"
if test "$ac_compiler_gnu" == "yes" ; then
- TARGET_CFLAGS="$TARGET_CFLAGS -Zomf -Zexe -Zmap"
+ CFLAGS="$CFLAGS -Zomf -Zexe -Zmap"
BUILD_CFLAGS="$BUILD_CFLAGS -Zomf -Zexe"
fi
else
@@ -320,14 +320,14 @@ if test "$TARGET_EXEEXT" = ".exe"; then
OS_WIN=1
OS_OS2=0
tclsubdir=win
- TARGET_CFLAGS="$TARGET_CFLAGS -DOS_WIN=1"
+ CFLAGS="$CFLAGS -DOS_WIN=1"
fi
else
OS_UNIX=1
OS_WIN=0
OS_OS2=0
tclsubdir=unix
- TARGET_CFLAGS="$TARGET_CFLAGS -DOS_UNIX=1"
+ CFLAGS="$CFLAGS -DOS_UNIX=1"
fi
AC_SUBST(BUILD_EXEEXT)
@@ -565,13 +565,13 @@ AC_SUBST(TARGET_DEBUG)
#########
# Figure out whether or not we have a "usleep()" function.
#
-AC_CHECK_FUNC(usleep, [TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_USLEEP=1"])
+AC_CHECK_FUNC(usleep, [CFLAGS="$CFLAGS -DHAVE_USLEEP=1"])
#--------------------------------------------------------------------
# Redefine fdatasync as fsync on systems that lack fdatasync
#--------------------------------------------------------------------
-AC_CHECK_FUNC(fdatasync, [TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_FDATASYNC=1"])
+AC_CHECK_FUNC(fdatasync, [CFLAGS="$CFLAGS -DHAVE_FDATASYNC=1"])
#########
# Generate the output files.
|
2008-Jan-05 08:24:29 by anonymous:
It appears that http://www.sqlite.org/sqlite3-3.5.4.bin.gz and http://www.sqlite.org/sqlite-3.5.4.so.gz use sleep and fsync even though usleep and fdatasync are available on Linux.
On the Linux man page, it claims that fdatasync is more efficient than fsync:
"Unfortunately, fsync() will always initiate two write
operations: one for the newly written data and another one in order to
update the modification time stored in the inode. If the modification
time is not a part of the transaction concept fdatasync() can be used
to avoid unnecessary inode disk write operations." |
|
2872 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
4
|
4
|
Some table scan operations could use an index for better data density
|
edit |
If a suitable index covers a column being during a table scan, it makes sense to use the index for IO not the table pages themselves for speed.
As (contrived) example:
CREATE TABLE t1 ( c1 blob, c2 integer, c3 integer );
CREATE INDEX i1 on t1(c2,c3);
CREATE INDEX i2 on t1(c3);
T1 populated with 4096 rows, c1 being 64K random blobs (to make c2, c3 access slower in this case), c2 and c3 being small random integers.
Now:
sqlite> select sum(c3) from t1;
sum(c3)
----------
519895
is very slow (several seconds). A table scan is done.
Forcing use of an index, in a way that I know all rows will be included:
sqlite> select sum(c3) from t1 where c2<1000;
sum(c3)
----------
519895
This is instantaneous.
It seems to me that if a table scan has to be performance, it makes sense to grab the data from an index whenever possible. ideally the most densely packed index.
(BTW; this is contrived, I know putting the blob as the last column will greatly speed things up). |
|
2869 |
new
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
5
|
5
|
add "sqlite3_open16_v2" to the C API
|
edit |
I'm using UTF-16, and if the database file does not exist, "sqlite3_open16" will create a new one, but i wish it fails in such conditions.
I notice that there's a "sqlite3_open_v2", but it doesn't support UTF-16, although i can implement a "sqlite3_open16_v2" myself, I think it should exists in the offical releases. |
|
2867 |
code
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
2
|
2
|
doesn't build on Cygwin - wrong sqlite3 exe suffix
|
edit |
The new Makefile used $(EXE), which doesn't seem to be defined (typo?) |
2008-Jan-02 11:12:39 by anonymous:
Same on mingw:
Following patch fixes things:
--- sqlite-3.5.4/Makefile.in Thu Dec 13 19:17:42 2007
+++ sqlite-3.5.4-mingw-fix/Makefile.in Wed Jan 2 11:37:50 2008
@@ -322,7 +322,7 @@
-o $@ $(TOP)/src/shell.c libsqlite3.la \
$(LIBREADLINE) $(TLIBS)
-sqlite3$(EXE): $(TOP)/src/shell.c sqlite3.c sqlite3.h
+sqlite3$(TEXE): $(TOP)/src/shell.c sqlite3.c sqlite3.h
$(LTLINK) $(READLINE_FLAGS) -o $@ \
-DSQLITE_MAX_SQL_LENGTH=1000000000 \
-USQLITE_THREADSAFE -DSQLITE_THREADSAFE=0 \
@@ -577,7 +577,7 @@
-e 's,$$,\\n",' \
$(TOP)/tool/spaceanal.tcl >spaceanal_tcl.h
$(LTLINK) -DTCLSH=2 -DSQLITE_TEST=1 $(TEMP_STORE)\
- -o sqlite3_analyzer$(EXE) $(TESTSRC) $(TOP)/src/tclsqlite.c \
+ -o sqlite3_analyzer$(TEXE) $(TESTSRC) $(TOP)/src/tclsqlite.c \
libtclsqlite3.la $(LIBTCL)
|
|
2866 |
build
|
active
|
2008 Jan
|
anonymous
|
|
2008 Jan
|
|
1
|
3
|
Problems building Windows native in cygwin/mingw environment
|
edit |
Trying to build Windows native version using the Cygwin build environment.
$ gcc -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
$
$ CFLAGS=-mno-cygwin ./configure --disable-tcl --enable-threadsafe
$ make
A) The make appears to build sqlite3.exe just fine, without errors or warnings. This binary does work from cmd.exe, BUT not from within the bash cygwin shell for some reason, unlike other Windows native binaries I've built.
Next...
$ make install
B) The
cc sqlite3.c -o sqlite3
fails to rebuild sqlite3.exe correctly with the -mno-cygwin option. The output follows:
rm -rf tsrc
mkdir -p tsrc
cp ./src/alter.c ./src/analyze.c ./src/attach.c ./src/auth.c ./src/btmutex.c ./src/btree.c ./src/btree.h ./src/build.c ./src/callback.c ./src/complete.c ./src/date.c ./src/delete.c ./src/expr.c ./src/func.c ./src/hash.c ./src/hash.h ./src/insert.c ./src/journal.c ./src/legacy.c ./src/loadext.c ./src/main.c ./src/malloc.c ./src/mem1.c ./src/mem2.c ./src/mem3.c ./src/mutex.c ./src/mutex_os2.c ./src/mutex_unix.c ./src/mutex_w32.c ./src/os.c ./src/os_unix.c ./src/os_win.c ./src/os_os2.c ./src/pager.c ./src/pager.h ./src/parse.y ./src/pragma.c ./src/prepare.c ./src/printf.c ./src/random.c ./src/select.c ./src/shell.c ./src/sqlite.h.in ./src/sqliteInt.h ./src/table.c ./src/tclsqlite.c ./src/tokenize.c ./src/trigger.c ./src/utf.c ./src/update.c ./src/util.c ./src/vacuum.c ./src/vdbe.c ./src/vdbe.h ./src/vdbeapi.c ./src/vdbeaux.c ./src/vdbeblob.c ./src/vdbefifo.c ./src/vdbemem.c ./src/vdbeInt.h ./src/vtab.c ./src/where.c ./ext/fts1/fts1.c ./ext/fts1/fts1.h ./ext/fts1/fts1_hash.c ./ext/fts1/fts1_hash.h ./ext/fts1/fts1_porter.c ./ext/fts1/fts1_tokenizer.h ./ext/fts1/fts1_tokenizer1.c sqlite3.h ./src/btree.h ./src/btreeInt.h ./src/hash.h ./src/sqliteLimit.h ./src/mutex.h opcodes.h ./src/os.h ./src/os_common.h ./src/sqlite3ext.h ./src/sqliteInt.h ./src/vdbe.h parse.h ./ext/fts1/fts1.h ./ext/fts1/fts1_hash.h ./ext/fts1/fts1_tokenizer.h ./src/vdbeInt.h tsrc
cp: warning: source file `./src/btree.h' specified more than once
cp: warning: source file `./src/hash.h' specified more than once
cp: warning: source file `./src/sqliteInt.h' specified more than once
cp: warning: source file `./src/vdbe.h' specified more than once
cp: warning: source file `./ext/fts1/fts1.h' specified more than once
cp: warning: source file `./ext/fts1/fts1_hash.h' specified more than once
cp: warning: source file `./ext/fts1/fts1_tokenizer.h' specified more than once
cp: warning: source file `./src/vdbeInt.h' specified more than once
rm tsrc/sqlite.h.in tsrc/parse.y
cp parse.c opcodes.c keywordhash.h tsrc
tclsh ./tool/mksqlite3c.tcl
cc sqlite3.c -o sqlite3
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab): undefined reference to `_WinMain@16'
collect2: ld returned 1 exit status
make: *** [sqlite3] Error 1
$ |
|
2865 |
code
|
active
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
1
|
2
|
FTS3 does not build with amalgamation in CVS
|
edit |
Grab the latest CVS sources, then run:
./configure
make sqlite3.c
grep sqlite3Fts3Init sqlite3.c
extern int sqlite3Fts3Init(sqlite3*);
rc = sqlite3Fts3Init(db);
If you compile sqlite3.c with -DSQLITE_ENABLE_FTS3, then sqlite3Fts3Init is unresolved.
For some reason, sqlite3Fts3Init and fts3.c was not included in the sqlite3.c amalg.
It used to work correctly in 3.5.4. |
2007-Dec-30 18:17:57 by anonymous:
Nevermind, "make sqlite3.c" has never built with the fts3 sources in 3.5.4 or before.
You have to run ext/fts3/mkfts3amal.tcl
2007-Dec-30 18:20:56 by anonymous:
It seems that the sqlite3+fts3 amalg can only be built from main.mk, not Makefile. |
|
2864 |
doc
|
active
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
5
|
3
|
ext/fts3/README.txt
|
edit |
File ext/fts3/README.txt reads:
This folder contains source code to the second full-text search [...]
Shouldn't that be:
This folder contains source code to the third full-text search [...] |
2007-Dec-30 18:27:08 by anonymous:
Oh, after Googl'ing a little bit, I found that fts3 really is fts2-with-rowid-fixed.
If both fts2 and fts3 are considered to be the "second full-text search extension for SQLite", the README files could maybe explain the situation. |
|
2863 |
code
|
active
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
2
|
3
|
test cast-3.14, cast-3.18 and cast-3.24 fail
|
edit |
test cast-3.{14,18,24} fail on freebsd-6.3-PRERELEASE2:
cast-3.14...^M
Expected: [9223372036854774784]^M
Got: [9223372036854773760]^M
cast-3.18...^M
Expected: [-9223372036854774784]^M
Got: [-9223372036854773760]^M
cast-3.24...^M
Expected: [9223372036854774784]^M
Got: [9223372036854773760]^M
I used tcl8.4 from ports with no threads and here was the config line:
../sqlite-3.5.4/configure --prefix=/home/marc/local --with-tcl=/usr/local/lib/tcl8.4/
This was built on an ibm t30 laptop |
|
2860 |
todo
|
active
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
3
|
1
|
Database file fragmentation
|
edit |
Adding data in database file increases file fragmentation. for example my file which size is 1G, consists of 20000 pieces. (NTFS)
This happens because truncation of '-journal' file.
I see some ways to reduce fragmentaion:
1. Increase database file size by greater pieces (not by PAGESIZE).
2. SQLite can save '-journal' file in another folder(logical disc).
3. Preallocation of database file(must increase INSERT speed). |
|
2859 |
code
|
active
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
drh
|
3
|
2
|
Inconsistent column names with DISTINCT
|
edit |
Given the following SQL:
CREATE TABLE foo(a,b);
INSERT INTO foo (a, b) VALUES (1,2);
SQLite returns inconsistent column names when using the DISTINCT clause:
SELECT DISTINCT foo.A, foo.B FROM foo;
foo.A|foo.B
1|2
SELECT DISTINCT a, b FROM foo;
a|b
1|2
SELECT DISTINCT * FROM foo;
a|b
1|2
SELECT DISTINCT foo.* FROM foo;
a|b
1|2
Compared with SELECT without DISTINCT:
SELECT foo.A, foo.B FROM foo;
a|b
1|2
SELECT a, b FROM foo;
a|b
1|2
SELECT * FROM foo;
a|b
1|2
SELECT foo.* FROM foo;
a|b
1|2
|
|
2857 |
code
|
active
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
2
|
2
|
GROUP BY cost estimate wrong with WHERE clause
|
edit |
There seems to be an issue with the sqlite cost heuristic with
an INDEX present on GROUP BY with certain types of WHERE clauses.
Given the database formed by running these statements:
create table stuff(a,b,c,d);
insert into stuff values(1,2,3,4);
create temp view v1 as select random()%100,
random()%100, random()%1000, random()%10000
from stuff x, stuff y;
insert into stuff select * from v1;
insert into stuff select * from v1;
insert into stuff select * from v1;
insert into stuff select * from v1;
insert into stuff select * from v1;
create index stuff_b on stuff(b);
create index stuff_c on stuff(c);
create index stuff_d on stuff(d);
analyze;
Using sqlite.org's sqlite3-3.5.4.bin, this query takes 47 seconds:
select c from stuff where a=23 group by c;
while this query takes just 2 seconds:
select c from stuff where a=23 group by +c;
It is more efficient in this case to do a full table scan instead
of using the INDEX on column c. |
2007-Dec-23 23:14:06 by anonymous:
The queries above both run in a couple of seconds with this naive patch:
--- src/where.c 12 Dec 2007 17:42:53 -0000 1.266
+++ src/where.c 23 Dec 2007 22:48:37 -0000
@@ -1514,6 +1514,12 @@ static double bestIndex(
flags = 0;
}
+ if( pWC && pWC->nTerm>0 && pOrderBy ){
+ /* Reduce cost if both an ORDER/GROUP BY exists with a WHERE. */
+ cost /= 100; /* A very rough guess. */
+ WHERETRACE(("... WHERE + ORDER BY decreases cost to: %.9g\n", cost));
+ }
+
/* If the table scan does not satisfy the ORDER BY clause, increase
** the cost by NlogN to cover the expense of sorting. */
if( pOrderBy ){
But it has not been tested on queries with more than one table. Its logic could be flawed.
2007-Dec-24 00:09:00 by drh:
The complaint is centered around these two queries:
/* 1 */ SELECT c FROM stuff WHERE a=23 GROUP BY c;
/* 2 */ SELECT c FROM stuff WHERE a=23 GROUP BY +c;
Query 1 runs in about 40 seconds and query 2 in about 1.5
seconds on my macbook. But with the patch, both queries
run in about 1.5 seconds. Fair enough. But now consider
these two queries:
/* 3 */ SELECT c FROM stuff WHERE a!=23 GROUP BY c;
/* 4 */ SELECT c FROM stuff WHERE a!=23 GROUP BY +c;
In this case, query 3 runs in 42 seconds on an unpatched version of
3.5.4 and query 4 runs in about 109 seconds. So in cases where
the WHERE clause is not particularly selective, the first version
is faster than the second by a good margin. On a patched version
of 3.5.4, both queries 3 and 4 run in about 110 seconds.
So it seems to me that the patch is robbing Peter to pay Paul.
It makes ORDER BY queries with very selective WHERE clauses
run faster but at the expense of making queries with unselective
WHERE clauses running slower.
But notice this: in the current (unpatched) implementation, the
programmer at least has the ability to select a different algorithm
by the judicious placement of a "+" sign. After the patch, this is
no longer possible. The patch forces the second algorithm to
be used in all cases, even cases where it is slower.
It seems to me to be better to leave things as they are since the
current approach at least allows the programmer to override
SQLite's algorithm selection if SQLite chooses incorrectly.
The only way, it seems to me, to automatically choose the correct
algorithm is to devise some test that will determine (in advance)
whether or not the WHERE clause weeds out many or few rows from
the result set. I'm thinking that determination is going to be very
hard (or impossible) to do without first doing a full table scan.
2007-Dec-24 05:40:47 by anonymous:
It think it would be surprising to average users that adding an index (on column C in this case) may significantly decrease query performance for some queries. It was surprising to me, at least. In my opinion, a query being 20 times slower in a default bad guess situation is worse than a query only being 2.5 times slower with a default bad guess in a worst case scenario. It's a question of relative magnitude of the difference. This is why I think that the database should err on the side of the WHERE clause having a more selective bias.
(Side note: the query timings difference is less pronounced if you use PRAGMA temp_store=memory, in which case query 3 running on an unpatched 3.5.4 takes just 50% more time to run than query 4 on my machine.)
But you raise a good point in that if there's a wrong guess in the selectivity bias it would be nice to be able to manually override it.
How much do you hate this type of syntax that some other databases use?
select c from stuff where a!=23 group by /*+stuff_c*/ c;
SQLite does not currently offer a way to pick a specific index. I think it would be quite useful.
2007-Dec-24 17:05:16 by anonymous:
Another option is to collect WHERE clause statistics in a table like
create table sqlite_stat2(
where_clause_md5 BLOB primary key,
where_clause TEXT,
rows_examined INT,
rows_true INT
);
where the last 2 columns are cumulative for each query. The statistics option could be enabled/disabled via a PRAGMA sqlite_collect_statistics.
The where_clause column could be a string generated fairly easily from the walking the parse tree of the resolved Select statement's pWhere. This way the where_clause is normalized and a single query with many subselects could generate more than 1 where_clause, and different queries that happen to use the same normalized where clause would update the same entry in the stat2 table. where_clause normalization would strip off aliases and only refer to the original table and column names.
For example the 2 queries below:
-- CREATE TABLE t1(a, b);
-- CREATE TABLE t2(b, c);
SELECT t1.a*c as AC, t2.b-a as BA FROM t1, t2 WHERE AC>BA;
SELECT *, t1.a Foo FROM t2, t1 WHERE Foo*c > t2.b - t1.a;
would generate the same normalized where_clause string "(T1.A*T2.C)>(T2.B-T1.A)". The table information is already encoded within it.
The generated VDBE code would have to generate Mem counters that would be incremented by each WHERE test, and lazily updated at the end of transactions or periodically written to the stat2 table to minimize disk use, as this information is not critical.
One could also manually set the stat2 table with statistical values they would like their queries to use even if PRAGMA sqlite_collect_statistics=off;
Any time the schema is changed, the entire sqlite_stat2 table would be cleared. |
|
2856 |
doc
|
active
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
anonymous
|
4
|
3
|
SQLite Documentation - Tcl API - Link broken
|
edit |
On the page "The Tcl Interface to the SQLite library", the link "enable load extension" does not work. |
|
2853 |
new
|
active
|
2007 Dec
|
anonymous
|
|
2008 Jan
|
|
2
|
3
|
optimizer fails to use an index on MAX subquery
|
edit |
i have these 2 identical queries with an index on (place_id,visit_date), the second query is about 2x fast the the first, while i'd expect that the MAX is faster than a limited order by clause... It's like the index is mis-used with MAX
SELECT h.id, h.url, h.title, h.rev_host, h.visit_count,
(SELECT MAX(visit_date) FROM moz_historyvisits WHERE place_id = h.id
AND visit_type NOT IN(0,4)),
f.url, null, null
FROM moz_places h
LEFT OUTER JOIN moz_favicons f ON h.favicon_id = f.id
WHERE h.id IN
(SELECT DISTINCT p.id
FROM moz_places p
JOIN moz_historyvisits ON place_id = p.id
WHERE hidden <> 1 AND visit_type NOT IN (0,4)
ORDER BY visit_date DESC
LIMIT 10)
ORDER BY 6 DESC;
SELECT h.id, h.url, h.title, h.rev_host, h.visit_count,
(SELECT visit_date FROM moz_historyvisits WHERE place_id = h.id
AND visit_type NOT IN(0,4) ORDER BY visit_date DESC LIMIT 1),
f.url, null, null
FROM moz_places h
LEFT OUTER JOIN moz_favicons f ON h.favicon_id = f.id
WHERE h.id IN
(SELECT DISTINCT p.id
FROM moz_places p
JOIN moz_historyvisits ON place_id = p.id
WHERE hidden <> 1 AND visit_type NOT IN (0,4)
ORDER BY visit_date DESC
LIMIT 10)
ORDER BY 6 DESC;
|
2007-Dec-20 04:13:44 by anonymous:
Can you supply the schema of these tables and all related indexes?
2007-Dec-20 10:55:29 by danielk1977:
Correct. SQLite does not use the index to optimize the max() in the first query. But it does use it to optimize ORDER BY in the second.
2007-Dec-21 00:54:10 by anonymous:
the schema is that of mozilla firefox 3 places.sqlite, with an added index on moz_historyvisits(place_id,visit_date), this is extracted from a i bug i was working on.
Do you need that i append the full schema here?
Will this be fixed to use the index with max or is that the expected behaviour?
2007-Dec-21 15:59:58 by drh:
We will be enhancing the min()/max() optimization to be able
to cover the case you describe above. But this will take some
time to get right. If you are in a hurry, it seems like modifying
your SQL is the easiest way to go.
The current optimizer recognizes queries of the form:
SELECT min(x) FROM table;
SELECT max(x) FROM table;
And it causes special VDBE code to be generated for these
cases. The presence of a WHERE clause defeats the current
optimization. We need to modify the optimizer to recognize
queries of the form:
SELECT min(x) FROM table WHERE expr
And convert them into:
SELECT x FROM table WHERE expr AND x NOT NULL
ORDER BY x LIMIT 1
But we only want to do this optimization if the ORDER BY
can be evaluated using an index. If we have to accumulate
the entire result set, sort it, then take the largest
entry, that is more work than just keeping track of the
largest entry as we loop through the result set.
Notice the addition of the "x NOT NULL" term in the
WHERE clause. This is critical to preserving correct
semantics. The query optimizer currently does not know
how to deal with a NOT NULL. It just evaluates all
rows, tests them individually for NULL, and throws out
those that match. This would work in most cases, but
would slow down in a min() where there were many NULL
entries. The current implemention of the min() optimization
knows to skip over the NULL entries in a single operation.
The WHERE generator part of the optimizer will need to
be enhanced to recognize NOT NULL constraints and skip
over them.
All of this is a substantial change. The min()/max()
optimization function will be rewritten from scratch.
Significant and non-trivial modifications will need to
be made to the code that looks for indices and generates
the WHERE clause constraints. There are many opportunities
to make coding mistakes, so we will need to spend a lot
of time in testing before we put these changes into production.
So, we will be working the problem. But do not expect
an overnight fix.
I suppose that while we are redesigning the min/max optimizer,
we might as well also fix it so that
SELECT arbitrary_expr(max(x)) FROM table WHERE expr;
gets converted into
SELECT arbitrary_expr(x) FROM table WHERE expr AND x NOT NULL
ORDER BY x DESC LIMIT 1;
2007-Dec-31 06:41:03 by anonymous:
Regarding:
SELECT min(x) from table WHERE expr
being converted to:
SELECT x FROM table WHERE expr AND x NOT NULL ORDER BY x LIMIT 1
There's no need for the "x NOT NULL" condition considering NULL is returned by min() (or max for that matter) when no rows match.
sqlite> .nullvalue <null>
sqlite> select min(a) from (select 123 as a) where a=7;
<null>
sqlite> select min(a) from (select NULL as a) where a=7;
<null>
Even with this in mind, you can see that the rewritten query still does not return the same result in this case:
sqlite> select a from (select 123 as a) where a=7 order by 1 limit 1;
-- no rows returned
Logic would have to be added to return a NULL row in the event the WHERE clause matches no rows.
2007-Dec-31 07:06:22 by anonymous:
Given:
SELECT min(x) from table WHERE expr
If column x or the WHERE expr can make use of an index, then the min query should be converted to:
SELECT x from (
SELECT x FROM table WHERE expr
ORDER BY x LIMIT 1
) UNION ALL SELECT NULL LIMIT 1
which ought to cover all the corner cases, even if the WHERE matches no rows.
2008-Jan-01 19:21:51 by anonymous:
This ticket is related to WHERE cost estimation in ticket #2857.
Given:
create table stuff(a,b,c,d);
insert into stuff values(1,2,3,4);
create temp view v1 as select random()%100,
random()%100, random()%1000, random()%10000
from stuff x, stuff y;
insert into stuff select * from v1;
insert into stuff select * from v1;
insert into stuff select * from v1;
insert into stuff select * from v1;
insert into stuff select * from v1;
create index stuff_b on stuff(b);
create index stuff_c on stuff(c);
create index stuff_d on stuff(d);
analyze;
In the following example the existing min() implementation which uses a full table scan:
sqlite> explain query plan select min(c) from stuff where a=12345;
0|0|TABLE stuff
sqlite> select min(c) from stuff where a=12345;
(null)
CPU Time: user 1.388087 sys 0.216014
is faster than performing the select min->order by/limit transform which uses an index:
sqlite> explain query plan select c from stuff where a=12345 order by 1 limit 1;
0|0|TABLE stuff WITH INDEX stuff_c ORDER BY
sqlite> explain query plan select c from (select c from stuff where a=12345 order by c limit 1) union all select null limit 1;
0|0|TABLE stuff WITH INDEX stuff_c ORDER BY
0|0|TABLE AS sqlite_subquery_82F83F8_
CPU Time: user 0.000000 sys 0.000000
sqlite> select c from (select c from stuff where a=12345 order by c limit 1) union all select null limit 1;
(null)
CPU Time: user 15.880993 sys 15.400962
Note that a=12345 is always false in this data set.
Had a=23 been used instead, we can see that the transformed select would be much faster than the original min() select:
sqlite> select min(c) from stuff where a=23;
-999
CPU Time: user 1.552097 sys 0.148009
sqlite> select c from (select c from stuff where a=23 order by c limit 1) union all select null limit 1;
-999
CPU Time: user 0.004001 sys 0.000000
I don't think WHERE clause cost estimation can be done accurately without using a statistical method based on historical WHERE clause hit percentages.
2008-Jan-05 18:15:39 by anonymous:
I appreciate that you have more refinements pending, but this query in particular has regressed from sqlite 3.5.4 using the schema mentioned above:
-- sqlite 3.5.4
sqlite> select min(c) from stuff where a=12345;
(null)
CPU Time: user 1.532095 sys 0.132008
-- as of Check-in [4687]
sqlite> select min(c) from stuff where a=12345;
(null)
CPU Time: user 23.041440 sys 16.369023
|
|
2847 |
new
|
active
|
2007 Dec
|
anonymous
|
|
2008 Jan
|
|
5
|
4
|
Include major, minor, and patch version numbers in sqlite.h
|
edit |
Hi, I'm working on a project where sqlite is being compiled into a DLL. Currently, sqlite.h makes the version number available as both an x.y.z string and an integer value in the form of x*1000000 + y*1000 + z.
Unfortunately, neither of these options works particularly well when trying to create a resource file so that the DLL can display the proper version information within Windows. I've tried many different ways of disassembling the integer version number, but limitations in the resource compiler unfortunately prevent them from working.
As a result, I've been forced for the time being to define SQLITE_VERSION_MAJOR, SQLITE_VERSION_MINOR, and SQLITE_VERSION_PATCH with manually-given values of x, y, and z respectively in order to accomplish this task. It would be really nice if these could be generated automatically for sqlite.h when running configure in the same way that VERSION and VERSION_NUMBER are so that setting the values manually wouldn't be required for the future.
Would you be willing to do that? Thanks in advance. |
2007-Dec-17 13:30:22 by anonymous:
You could invoke this awk script in your make file:
#
## extrvers.awk
## Extract verison parts from sqlite3.h
#
## Usage:
# %GNU_AWK% -f extrvers.awk sqlite3.h >sqlite3.h.new
# rm / del sqlite3.h
# mv / ren sqlite3.h.new sqlite3.h
#
#
## Ignore any previous defines
/^#define SQLITE_VERSION_(MAJOR|MINOR|PATCH)/{
next
}
## generate extra #define MAJOR/MINOR/PATH lines
/^#define[[:blank:]]+SQLITE_VERSION[[:blank:]]/{
split(substr($3,2,length($3) - 2),tmp,".")
print "#define SQLITE_VERSION_MAJOR " tmp[1]
print "#define SQLITE_VERSION_MINOR " tmp[2]
print "#define SQLITE_VERSION_PATCH " tmp[3]
}
## Repeat all other lines untouched
{
print
}
2007-Dec-18 00:06:53 by anonymous:
Original poster here. Thanks for the useful script! I'm assuming you're granting a license for this (or a modified version of it) to be included in the source tree if the powers that be are willing to accept it? This would be for the Mozilla project.
2007-Dec-18 00:21:52 by drh:
First off, I didn't post the script. I don't know who
"anonymous" is.
Secondly, if you are working for Mozilla, you will get much faster
service if you identify yourself as such.
2007-Dec-18 00:39:38 by anonymous:
I just want to make sure I'm not running afoul of anybody by using their work without proper permission.
To whoever posted it, you can contact me at ryanvm [at] gmail [dot] com. Thanks again for help!
2007-Dec-26 19:06:27 by anonymous:
I'm the poster of the script. Of course I don't mind it being used.
For the peace of mind of anyone using it: please prepend the code with:
# Copyright (C) 2007 by Kees Nuyt, Rotterdam, Netherlands
# The author of this code dedicates any and all copyright
# interest in this code to the public domain. I make this
# dedication for the benefit of the public at large and
# to the detriment of my heirs and successors. I intend
# this dedication to be an overt act of relinquishment in
# perpetuity of all present and future rights to this
# code under copyright law.
#
Cheers! "Kees Nuyt" <k [dot] nuyt [at] zonnet [dot] nl>
2007-Dec-27 02:32:44 by anonymous:
Declaring a copyright and putting it into the public domain is not compatible.
2008-Jan-11 04:55:22 by anonymous:
Original poster here: FYI, I ended up writing a Python script to parse sqlite3.h for what we needed. The Mozilla bug for the work was
You can see the final script here:
http://mxr.mozilla.org/mozilla/source/db/sqlite3/src/sqlite-version.py
At this point, you can close the bug if you want. I'll leave that up to you to decide. |
|
2844 |
build
|
active
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
4
|
1
|
lemon is being built without respecting LDFLAGS
|
edit |
lemon is being built without respecting LDFLAGS.
I'm attaching a patch which fixes this bug.
In other words, why should we fix this? What problem is
it causing? |
2007-Dec-17 16:22:19 by drh:
Why is this important? What LDFLAGS settings might a user want to
carry through into lemon?
2007-Dec-17 18:00:59 by anonymous:
> Why is this important?
It is considered to be be good practice to respect user's LDFLAGS.
A user might want to have all executables and libraries built with identical LDFLAGS.
> What LDFLAGS settings might a user want to carry through into lemon?
A user might have LDFLAGS="-Wl,-O1,--hash-style=gnu,--sort-common"
You can read http://lwn.net/Articles/192082/.
Users can also use some other flags.
> In other words, why should we fix this? What problem is it causing?
It slightly increases the size of lemon executable and it slightly decreases performance.
2007-Dec-17 18:04:31 by drh:
lemon is used as an intermediate build tool in part of the
SQLite build process. It is not a deliverable.
If it runs a little slower or uses a
little more memory, nobody cares. We only care if it gets the
wrong answer.
Is it ever possible that the lack of LDFLAGS support might result
in lemon getting the wrong answer?
2007-Dec-17 18:27:33 by anonymous:
Can you comment on Lemon bug in #2835? It produces 2 different sqlite3.c files depending on your malloc implementation.
2007-Dec-17 19:19:01 by anonymous:
> lemon is used as an intermediate build tool in part of the
> SQLite build process. It is not a deliverable. If it runs a
> little slower or uses a little more memory, nobody cares.
CFLAGS are respected when lemon is being built, so for consistency LDFLAGS also should be respected.
(The comment above was not created by me.) |
|
2842 |
code
|
active
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
1
|
1
|
.import does not recongnise NULL values
|
edit |
.import function fails to see NULL values in csv files as NULL values...instead they are treated as the string "NULL".
This is with .mode list and separator ,
But behaves similarly for .mode csv
Also if one outputs a table with NULL values to a file, then re-imports that file, again .import does not recognise the values as NULL, but as "NULL".
Everything here also applies to empty strings in files, e.g. instead of "NULL" using nothing...
This is a showstopper for us since we want to import a large amount of data with many tables containing NULL values. I can't see any valid reason for .import not to recognise the same syntax as the command line.
Note that something like:
sqlite3 my.db insert into MY_TABLE values (1,"foo","bar",NULL)
..works fine. It is just .import that appears to be broken. |
2007-Dec-14 16:39:51 by rdc:
.import only inserts string values into database tables. If your column has a declared type that changes the columns affinity to numeric or integer, then those strings will be converted to numeric values by the SQLIte library.
The workaround is to simply insert a unique string where ever you want a NULL value, and then run an update that replaces those strings with real NULL values. If you inserted the string 'NULL' then do this after the .import
update t set field = null where field = 'NULL';
You will have to repeat this for each field in your table that might contain the 'NULL' string. |
|
2841 |
todo
|
active
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
1
|
1
|
The sqlite mailing list has become overrun by trolls
|
edit |
The sqlite mailing list is very useful. The S/N is at times a little high but nonetheless quite manageable.
Recently (see the DeviceSQL thread) it got really bad. Would moderation be unacceptable during these periods of time where people feel the need to protect their ego's?
The sqlite mailing list is primarily about sqlite (well, and lemon), not a marketing vector for other products? Surely they have their own lists and resources for that? |
|
2831 |
new
|
active
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
3
|
4
|
alter view
|
edit |
View can't be used after ALTER RENAME TO:
SQLite version 3.5.3
Enter ".help" for istructions
sqlite> create table t(a);
sqlite> create view v1 as select * from t;
sqlite> alter table v1 rename to v2;
sqlite> select * from v2;
SQL error: no such table: v2
sqlite> select * from v1;
SQL error: no such table: v1
sqlite> .schema
CREATE TABLE t(a);
CREATE VIEW v1 as select * from t;
sqlite> select * from sqlite_master;
table|t|t|2|CREATE TABLE t(a)
view|v1|v1|0|CREATE VIEW v1 as select * from t
|
This is a feature request, not a bug.
2007-Dec-11 18:40:17 by anonymous:
Notice that alter table doesn't return an error. After the command neither v1 nor v2 can be used.
2007-Dec-13 08:18:16 by danielk1977:
[4623]
improves the situation by returning an error when the user attempts to rename a view.
One reason this feature (renaming views) is not a high priority is because a view can be dropped and recreated with a different name efficiently. This was not the case with tables. |
|
2825 |
code
|
active
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
3
|
3
|
FormatMessage (win32) should use extra flag and convert from Unicode
|
edit |
The call to FormatMessageA in the win32 source code needs to have the flags changed from:
FORMAT_MESSAGE_FROM_SYSTEM
to
FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS
This ensures that any system messages that expect arguments do not try to grab the argument from some random memory location.
ref: http://blogs.msdn.com/oldnewthing/archive/2007/11/28/6564257.aspx |
2007-Dec-06 14:07:53 by anonymous:
I also noticed that the result is NOT converted to UTF-8.
FormatMessageA returns the text in the local ANSI codepage. FormatMessageW should be used on NT systems, and either result should be converted to the SQLite UTF-8 default.
2007-Dec-11 00:34:37 by anonymous:
to simplify what is meant even more...
http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/os_win.c&v=1.118
Search for FormatMessageA (only 1 instance)
- FORMAT_MESSAGE_FROM_SYSTEM,
+ FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
No breakage, ensures that no crashes with some messages (e.g. filesystem errors). The encoding issue should be addressed separately.
2007-Dec-11 01:27:07 by anonymous:
The function should be changed to the following to correctly handle the conversion from Unicode/MBCS.
static void winDlError(sqlite3_vfs *pVfs, int nBuf, char *zBufOut){
int error = GetLastError();
#if OS_WINCE
if( error>0x7FFFFFF ){
sqlite3_snprintf(nBuf, zBufOut, "OsError 0x%x", error);
}else{
sqlite3_snprintf(nBuf, zBufOut, "OsError %d", error);
}
#else
if( isNT() ){
LPWSTR zWinTemp = NULL;
DWORD dwLen = FormatMessageW(
FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
error,
0,
(LPWSTR) &zWinTemp,
0,
0
);
if (dwLen > 0) {
char * zOut = unicodeToUtf8(zWinTemp);
LocalFree(zWinTemp);
sqlite3_snprintf(nBuf, zBufOut, "%s", zOut);
free(zOut);
}
}else{
LPSTR zWinTemp = NULL;
DWORD dwLen = FormatMessageA(
FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
error,
0,
(LPSTR) &zWinTemp,
0,
0
);
if (dwLen > 0) {
char * zOut = mbcsToUtf8(zWinTemp);
LocalFree(zWinTemp);
sqlite3_snprintf(nBuf, zBufOut, "%s", zOut);
free(zOut);
}
}
#endif
}
|
|
2821 |
new
|
active
|
2007 Dec
|
anonymous
|
|
2007 Dec
|
|
3
|
4
|
hashtable indicies
|
edit |
It would be nice to implement non btree indices. I.e. CREATE INDEX ON table(rowid) AS HASH. Using a hashtable's O(1) properties, you could use the index for very quick lookups when one result is expected. This does have the tradeoff that a hashtable index has no ordering properties (can not be used for sorts or non-equality searching). However, it would be a huge win when you have 250,000 rowids in memory, and you want to go fetch another column in the database for each one of those rowids (SELECT * FROM table WHERE rowid=?). |
2007-Dec-03 21:58:01 by anonymous:
For 250,000 rows I doubt you would see that much of an improvement (try it.)
You'll almost certainly find log_n is going to be fairly fast (especially for large n.)
I personally would prefer some sort of 'virtual' index though, that could be a hash or actually from a user-supplied function so that I can index large blobs by some function (i.e. a hash).
And yes, this would be an incompatible file-format change and it's not clear how to update an index when the function isn't loaded (i.e. db reopened with that function.) Perhaps mark the index as 'stale' and ignore it until the function loads then you can do the updates.
Of course this starts to get quite complicated.
2007-Dec-03 22:12:17 by anonymous:
Everything in sqlite depends on btree indexes. You're talking a major rewrite if you support hash-based or other indexing. |
|
2814 |
code
|
active
|
2007 Nov
|
anonymous
|
|
2007 Dec
|
|
3
|
3
|
_XOPEN_SOURCE again
|
edit |
Ideally setting _XOPEN_SOURCE should be an opt-in detected by configure, rather than a hardcoded opt-out as it is now. I find you create more problems in setting it than just leaving it out on modern platforms.
Can you please give users the option of not defining _XOPEN_SOURCE at all?
+#ifndef SQLITE_DONT_DEFINE_XOPEN_SOURCE
#if !defined(_XOPEN_SOURCE) && !defined(__DARWIN__) && SQLITE_THREADSAFE
# define _XOPEN_SOURCE 500 /* Needed to enable pthread recursive mutexes */
#endif
+#endif
|
2007-Dec-01 09:23:15 by anonymous:
Also when using Python, it sets _XOPEN_SOURCE to 600. No idea what the 500 vs 600 difference is about.
2007-Dec-01 15:58:28 by anonymous:
I've used a couple of different Linux OSes and _XOPEN_SOURCE is not needed. Maybe it's for OSes more than 5 years old. Recursive mutexes are pretty much standard these days since the popularity of Java which uses them extensively.
2007-Dec-01 17:21:05 by drh:
See also tickets #2673, #2681, and #2741.
2007-Dec-02 02:08:26 by anonymous:
On Linux, PTHREAD_MUTEX_RECURSIVE is the same as PTHREAD_MUTEX_RECURSIVE_NP:
PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP,
Since PTHREAD_MUTEX_RECURSIVE_NP is always available, you could avoid defining _XOPEN_SOURCE and use this code instead:
- pthread_mutexattr_settype(&recursiveAttr, PTHREAD_MUTEX_RECURSIVE);
+ pthread_mutexattr_settype(&recursiveAttr,
+#ifdef linux
+ PTHREAD_MUTEX_RECURSIVE_NP
+#else
+ PTHREAD_MUTEX_RECURSIVE
+#endif
+ );
2007-Dec-02 02:17:22 by anonymous:
A quick google search reveals how various projects deal with this recursive mutex declaration problem (in no particular order):
- #define _XOPEN_SOURCE 500 and use PTHREAD_MUTEX_RECURSIVE
- #define _XOPEN_SOURCE 600 and use PTHREAD_MUTEX_RECURSIVE
- #define _GNU_SOURCE and use PTHREAD_MUTEX_RECURSIVE
- don't define anything and use PTHREAD_MUTEX_RECURSIVE_NP on linux, and PTHREAD_MUTEX_RECURSIVE elsewhere.
Unfortunately, since PTHREAD_MUTEX_RECURSIVE is an enum on Linux, so you can't use the #ifdef PTHREAD_MUTEX_RECURSIVE compile-time technique. |
|
2813 |
build
|
active
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
1
|
1
|
compile error on Windows CE
|
edit |
environment:
visual c++ 2005
window ce 6.0 customize sdk
sqlite-amalgamation-3_5_3
I get error:
Error 27 error C2040: 'localtime' : 'tm *(const time_t *)' differs in levels of indirection from 'int ()' d:\SubProjects\Sqlite\sqlite3.c 18574
but if I add code in line 7095:
struct tm *__cdecl localtime(const time_t *t);
then Success! |
|
2810 |
code
|
active
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
1
|
1
|
Unregistered collation problems with simple subselects
|
edit |
As discussed on the mailing-list:
Imagine that a SQLite3 database opened in a custom application with a registered a collation sequence named "unknown" has created the following table:
CREATE TABLE a (b COLLATE unknown);
Now open this table in the default SQLite3 CLI. Up to here, everything works as expected. Simple queries like "SELECT * FROM a;" work fine.
But subselects, in their most basic form and with no sorting or comparisons, result in an error:
sqlite> INSERT INTO a VALUES ('one');
sqlite> SELECT * FROM a, (SELECT * FROM a);
SQL error: no such collation sequence: unknown
sqlite> SELECT * FROM (SELECT * FROM a);
SQL error: no such collation sequence: unknown
sqlite> SELECT *, * FROM a;
one|one
This is surprising because the collation sequence should not matter to the queries. In fact, the union without the subselect works just fine and without errors.
To demonstrate, here is the explain output of a table with a registered collation sequence. No mention of the collation name here:
sqlite> CREATE TABLE b (b collate nocase);
sqlite> EXPLAIN SELECT * FROM b, (SELECT * FROM b);
0|Goto|0|17|
1|Integer|0|0|
2|OpenRead|0|3|
3|SetNumColumns|0|1|
4|Integer|0|0|
5|OpenRead|2|3|
6|SetNumColumns|2|1|
7|Rewind|0|14|
8|Rewind|2|13|
9|Column|0|0|
10|Column|2|0|
11|Callback|2|0|
12|Next|2|9|
13|Next|0|8|
14|Close|0|0|
15|Close|2|0|
16|Halt|0|0|
17|Transaction|0|0|
18|VerifyCookie|0|4|
19|TableLock|0|3|b
20|Goto|0|1|
21|Noop|0|0|
|
|
2809 |
code
|
active
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
1
|
1
|
PRAGMA collation_list shows unregistered collations
|
edit |
As presented on the mailing list:
Imagine that a SQLite3 database opened in a custom application with a registered a collation sequence named "unknown" has created the following table:
CREATE TABLE a (b COLLATE unknown);
Now open this table in the default SQLite3 CLI. Up to here, everything works as expected.
Next issue "PRAGMA collation_list;" and notice that "unknown" lists next to the other registered collations, even though "unknown" is not registered with the default SQLite3 CLI:
sqlite> PRAGMA collation_list;
0|unknown
1|NOCASE
2|BINARY
Responses from the mailing list indicate that this is not the expected behaviour. "PRAGMA collation_list;" should list registered collations only. |
2007-Nov-28 16:12:17 by anonymous:
I don't think this is a bug. If the CLI is not aware of the collation, it should not process the query that makes use of the collation because it would certainly be wrong if it simply ignored the collation. This is not unlike a user-registered SQL function that does not exist in the CLI. I would not expect or want the sqlite3 CLI to ignore the unknown function, nor would I want the CLI to process queries ignoring the custom collation. |
|
2808 |
doc
|
active
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
4
|
2
|
Documentation GIF images take up too much space
|
edit |
The GIF format used for the documentation images takes up too much space. I believe that this is in strict contrast to the "small" feature of SQLite.
Converting the GIFs to PNG images saves up to 181 KB (64%) of the documentation storage space:
Documentation images as is (mostly GIF): 381 KB == 100%
Documentation images as PNG: 292 KB == 77%
Documentation images as PNG 16 colors: 137 KB == 36%
16 colors are more than plenty -- the diagrams show no visibility degradation. You might even cut it down to 8 colors to save even more ... |
|
2793 |
code
|
active
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
3
|
3
|
fts3 lacks scoping
|
edit |
It would be nice if the fts3 symbols could optionally be made private/static as the rest of the sqlite3 library. Not sure why sqlite3_api becomes public when used with the amalgamation, for that matter.
make TOP=`pwd` BCC=gcc TCC=gcc AR=ar RANLIB=echo NAWK=gawk -f \
main.mk sqlite3.h sqlite3.c fts3amal.c
cat fts3amal.c >> sqlite3.c
gcc -DSQLITE_THREADSAFE -DSQLITE_API=static -DSQLITE_PRIVATE=static \
-DSQLITE_EXTERN=static -DSQLITE_ENABLE_FTS3 -c sqlite3.c
nm sqlite3.o | grep -v ' [trUbd] '
00000004 C sqlite3_api
00064da2 T sqlite3Fts3HashClear
000652a4 T sqlite3Fts3HashFind
00064d60 T sqlite3Fts3HashInit
0006533b T sqlite3Fts3HashInsert
00064b4c T sqlite3Fts3Init
00066b34 T sqlite3Fts3InitHashTable
000669bd T sqlite3Fts3PorterTokenizerModule
0006702d T sqlite3Fts3SimpleTokenizerModule
|
|
2791 |
code
|
active
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
1
|
1
|
Allow building FTS[123] as part of sqlite library with configure
|
edit |
See attached patch. |
|
2787 |
build
|
active
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
4
|
5
|
sqlite3.pc is not remade
|
edit |
the subject says it all, there is no make rule to rebuild the sqlite3.pc from the .in file. it is only possible by hand (./config.status sqlite3.pc) |
2007-Nov-22 12:17:50 by drh:
I don't know what the sqlite3.pc file does. I certainly do not use it
for any of my builds on Linux, Mac OSX, or windows. Why should I
leave it in the source tree? Isn't the best solution to this problem to
simply delete the file?
2007-Nov-22 17:14:27 by anonymous:
It is indirectly used by pkgconfig. Here's some info on pkgconfig:
http://pkg-config.freedesktop.org/wiki/
2007-Nov-23 15:22:32 by drh:
Could somebody who understands what the sqlite3.pc file
is used for suggest a makefile rule for rebuilding it? |
|
2776 |
warn
|
active
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
5
|
1
|
mailing list
|
edit |
sqlite-users-digest doesn't work.
It remembers registered addresses but doesn't send any emails. |
|
2771 |
code
|
active
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
4
|
4
|
Lemon: Generated parser needs stdlib.h (not in default template)
|
edit |
I tested a simple do-nothing parser just to get lemon output, and this
doesn't compile (if warnings treated as errors) because of non declaration of the memset() function for the following statment:
memset(&yygotominor, 0, sizeof(yygotominor));
(added for the resolution of SQLite ticket #2172).
The lempar.c just include stdio.h , it would suffice to add stdlib.h to get the memset() declaration (even if all real parsers must include stdlib.h to get something really working). |
2007-Nov-14 21:02:25 by anonymous:
Sorry, the needed header is string.h , not stdlib.h :-) |
|
2770 |
code
|
active
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
1
|
1
|
Problem with BLOB in 3.5.x ?
|
edit |
After I've switched from 3.3.18 to 3.5.2, selecting from table which contains BLOB LONGER THAN ABOUT 990 BYTES returns error "SQL logic error or missing database" after call to _sqlite3_step().
I'm using preprocessed sources downloaded from here.
DEBUG build of preprocessed sources works correctly, problem is only in RELEASE build.
I'm using VC6.0 to compile.
Any idea what could be wrong?
Thank you! |
Can you try to reproduce this with the sqlite shell tool? Thanks.
Large blobs work for me with both release and debug builds (not msvc though, gcc/linux).
2007-Nov-12 18:41:37 by anonymous:
sqlite3.exe provided here works with the database.
Problem is only with release build (static library linked into test application).
Here is test app which exits with "Error 1" in release build:
int main(int argc, char* argv[])
{
int rc;
sqlite3* db;
sqlite3_stmt* stmt;
rc = sqlite3_open("n2.db3", &db);
rc = sqlite3_prepare(db, "CREATE TABLE [ttt] ([bbb] BLOB)", -1, &stmt, 0 );
rc = sqlite3_step(stmt);
rc = sqlite3_reset(stmt);
char text[10000],query[20000];
strnset(text,'a',sizeof(text)-1);
sprintf(query,"insert into [ttt] values (?)");
rc = sqlite3_prepare(db, query, -1, &stmt, 0 );
rc = sqlite3_bind_blob(stmt,1,text,sizeof(text), SQLITE_TRANSIENT);
rc = sqlite3_step(stmt);
rc = sqlite3_reset(stmt);
rc = sqlite3_prepare(db, "select * from ttt", -1, &stmt, 0 );
rc = sqlite3_step(stmt);
if (rc == SQLITE_ROW)
{
printf("%s: OK",sqlite3_column_text(stmt,1));
}
else
if (rc == SQLITE_DONE)
{
printf("DONE");
}
else
{
printf("Error %d",rc);
}
return 0;
}
2007-Nov-12 18:56:24 by drh:
You should be using sqlite3_finalize() instead of sqlite3_reset().
You are leaking memory. Also, you should use sqlite3_prepare_v2()
to avoid problems with changing schemas.
But even without those fixes, I cannot reproduce the problem on
Linux.
2007-Nov-12 19:39:31 by anonymous:
Suggested fixes didn't help.
I've tried to debug it.
It fails in btree.c, line 3056:
if( offset+amt > nKey+pCur->info.nData ){
/* Trying to read or write past the end of the data is an error */
return SQLITE_ERROR;
}
there seems to be different values in release mode. My debugger does not show values of variables in release mode, so I can be wrong, but it seems in release offset is 5 and in debug it is 4.
There can be something wrong with compilation, I'll try to figure this out tomorrow.
BTW compilation of static libraty in VC6.0 gives 185 warnings. I don't know if it is ok, it haven't caused problems in older sqlite
2007-Nov-13 08:47:28 by anonymous:
I've turned off "Maximize Speed" option - this is causing the problem. No optimizations and optimize for size seems to be working.
But it still makes me nervous :(( I really don't need corrupted database and now I hope it won't slow down too much.
Unfortunately old library does not implement replace function so I don't want to switch back.
This could be warning to others, I'm using VC++ 6.0 SP 6.
Thank you for your time.
2007-Nov-22 17:20:31 by anonymous:
I have exactly the same problem here (win XP, vc6 SP2) when I link against my sqlite static or dynamic library in release.
I have also used boundschecker to check sqlite, and it detects many dangling pointers ! But the strange thing is that I cannot find why these pointers are dangling, here an example:
In prepare.c@188
pTab = sqlite3FindTable(db, zMasterName, db->aDb[iDb].zName);
Boundchecker say that zMasterName is a dangling pointer, previously released here:
in build.c@711:
void sqlite3StartTable(
Parse *pParse, /* Parser context */
Token *pName1, /* First part of the name of the table or view */
Token *pName2, /* Second part of the name of the table or view */
int isTemp, /* True if this is a TEMP table */
int isView, /* True if this is a VIEW */
int isVirtual, /* True if this is a VIRTUAL table */
int noErr /* Do nothing if table already exists */
){
}
It does not make sens for me, maybe it a false positive from boundchecker, but it is weird.
I don't know if these "errors" are related to the "blob" bug in release mode. I will try to debug these error with some "printf" in release mode.
Note: The provided dll (the one from the sqlite site) does not have this "bug".
2007-Nov-22 18:27:35 by anonymous:
More info: It seems that there is a bug in the VC6 (SP6) compiler.
In btree.c, line 3056:
if( offset+amt > nKey+pCur->info.nData ){
/* Trying to read or write past the end of the data is an error */
return SQLITE_ERROR;
}
After adding some printf around, It seems that the "speed optimization" compilation flag of VC6 changes the code order in a way that the offset variable is miss incremented !!
Two remarks:
- I've traced the calling function, sqlite3BtreeData, and the it call accessPayload with the good offset value
- VC6 produces an internal error: "fatal error C1001: INTERNAL COMPILER ERROR" in the accessPayload function, if I try to access the offset value before this line:
aPayload = pCur->info.pCell + pCur->info.nHeader;
A dirty workaround could be to change the code order or the local var usage. I'm trying .... |
|
2766 |
code
|
active
|
2007 Nov
|
drh
|
|
2007 Nov
|
|
1
|
1
|
TCL transaction started from within a query does not commit
|
edit |
This is a problem with the TCL interface. Consider the
following TCL script:
file delete -force test.db test.db-journal
sqlite3 db test.db
db eval {
CREATE TABLE t1(x,y);
INSERT INTO t1 VALUES(1,2);
CREATE TABLE t2(a,b);
INSERT INTO t2 VALUES(8,9);
}
db eval {SELECT * FROM t1} {
db transaction {
db eval {UPDATE t2 SET a=a*2}
}
}
The [db transaction] statement starts a transaction and it
is suppose to commit the tranaction at the end of the code
block. But because the transaction started while a query
was active, the tranaction is unable to commit. The TCL
interface never commits the tranaction nor does it give any
kind of error indication.
It is unclear if an error should be returned or if the
commit should be deferred until outer query finishes.
If the code within the [db transaction] block throws an
error, we really need the transaction to rollback right
away. Perhaps there should be a new API that cancels
all pending queries. Perhaps a call to sqlite3_interrupt()
would suffice for this. Need to investigate further.... |
|
2763 |
build
|
active
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
4
|
4
|
AIX build failure due to explicit _XOPEN_SOURCE definition
|
edit |
Our AIX machine has started having problems building the new sqlite 3.5.2 source. I'm no AIX expert, but I did some digging and I think it's due to sqliteInt.h defining _XOPEN_SOURCE without also defining _ALL_SOURCE.
AIX system header files usually define this themselves (in /usr/include/ standards.h) but only if _XOPEN_SOURCE was previously undefined.
Has anyone else come across this bug? I'm willing to believe it's our build system if not; we can work around it by setting _ALL_SOURCE on the command-line, but I thought it might be useful to raise a bug anyway. |
See also tickets #2673, #2681, and #2741.
I do not have access to an AIX machine and so have no ability
to debug this problem. If you have suggested patches we will
consider them. Otherwise, there is not much we can do about
this ticket. |
|
2761 |
code
|
active
|
2007 Nov
|
anonymous
|
|
2007 Dec
|
|
3
|
3
|
CLI (shell.c) should be bundled with amalgamation
|
edit |
The CLI (shell.c) should be bundled with the amalgamation for database administrative purposes without downloading the matching shell.c from the full source tree. |
I second that! Qt ships with the amalgamated source files, but we also ship shell.c, whch we have to retrieve from the non-amalgamated source files.
2007-Dec-26 15:20:04 by anonymous:
I also agree. It is inconvenient to retrieve the matching shell.c from the source tree. |
|
2760 |
new
|
active
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
5
|
4
|
request: sqlite3_unlink() to delete db files.
|
edit |
Hi!
Today i came across a use case where i would like client code to be able to delete an underlying sqlite3 db, but that code doesn't have immediate access to the file name of that db (without refactoring the db wrapper code).
An interesting feature addition would, IMO, be:
int sqlite3_unlink( sqlite3 * db, bool closeTheFile );
Unlinks the file associated with the given database. It does not alter the database in any way (thus is it a no-op on a :memory: database). The closeTheFile flag specifies whether the file handle associated with db should also be closed (and thus db must also be closed), or just unlinked (e.g., as temporary databases are unlinked right after creation but kept open).
After browsing through the VFS API a bit, i see that there is an xDelete function, but i'm not sure if its semantics require that the underlying file handle be closed. i don't see an extra xClose member of VFS, so i assume that xDelete also handles closing the file handle. If these were split into two features, sqlite3_unlink() could be implemented very easily.
:) |
|
2756 |
new
|
active
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
1
|
1
|
allow vacuum to change pragma setting instead of using existing ones
|
edit |
we've got databases created with page_size of 1k, and we'd like to change that setting to 4k.
vacuum creates a temporary db, attach it to the current connection,
creates the tables (based on what's in the old db), and then selects from the old db and inserts into the new one.
vacuum does exactly what we need (creating a new db from an old one), but it re-uses the existing pragmas for page size, auto vacuum and reserved page size.
from sqlite.c, see sqlite3RunVacuum()
sqlite3BtreeSetPageSize(pTemp, sqlite3BtreeGetPageSize(pMain),
sqlite3BtreeGetReserve(pMain));
dr hipp points out that the the operands to vacuum are unused. from sqlite.c:
sqlite3VdbeAddOp(v, OP_Vacuum, 0, 0);
one solution would be to allow the user to specify the page
size, reserve page size, and autovacuum as optional params to vacuum.
he had an idea of using the signedness of the first operand to
represent the autovacuum setting (since after a table is created, you can change the setting from auto to incremental, but you can't change it from none to auto (or none to incremental) |
|
2755 |
code
|
active
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
|
3
|
3
|
trace interfere with transaction Tcl interface
|
edit |
When using the transaction method of the Tcl interface to the SQLite with a registered "trace" function, the stack trace is lost in case an error occurs inside the transaction.
As an example I provide two outputs, the first one without a registered trace function and the second one with one (in which it cannot be seen where the exception cames from):
First:
> ./a.tcl
vorher
BUMMM
while executing
"a"
invoked from within
"db transaction {
puts "vorher"
a
puts "nachher"
}"
("uplevel" body line 1)
invoked from within
"uplevel 1 [list db transaction {
puts "vorher"
a
puts "nachher"
}]"
(procedure "b" line 2)
invoked from within
"b"
(file "./a.tcl" line 28)
Second:
> ./a.tcl
BEGIN
vorher
ROLLBACK
while executing
"db transaction {
puts "vorher"
a
puts "nachher"
}"
("uplevel" body line 1)
invoked from within
"uplevel 1 [list db transaction {
puts "vorher"
a
puts "nachher"
}]"
(procedure "b" line 2)
invoked from within
"b"
(file "./a.tcl" line 28)
********
A scritp that demostrates this behaviour is attached. The only workaround is not to trace.
Thanks |
|
2753 |
code
|
active
|
2007 Nov
|
anonymous
|
|
2007 Nov
|
drh
|
3
|
3
|
Master journal files sometimes not deleted
|
edit |
In the 3.4.1 amalgamation, in vdbeCommit, the master journal file is created, and deleted at the end or if there is an error.
But it looks like there is one case where it gets closed but not deleted. The code is:
for(i=0; rc==SQLITE_OK && i<db->nDb; i++){
Btree *pBt = db->aDb[i].pBt;
if( pBt && sqlite3BtreeIsInTrans(pBt) ){
rc = sqlite3BtreeCommitPhaseOne(pBt, zMaster);
}
}
sqlite3OsClose(&master);
if( rc!=SQLITE_OK ){
sqliteFree(zMaster);
return rc;
}
It seems like that last bit should be:
if( rc!=SQLITE_OK ){
sqlite3OsDelete(zMaster);
sqliteFree(zMaster);
return rc;
}
|
2007-Nov-01 19:26:28 by anonymous:
Should have read the comment above that code segment closer. Looks like this was by design. Trying to figure out what to do with the client that has hundreds of orphaned master journal files... |
|
2749 |
warn
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
3
|
4
|
SQLITE_OMIT_FLOATING_POINT, int constants too large
|
edit |
Hiya!
i'm working from the 3.5.1 (CVS version) of the amalgamation. The code was pulled from CVS sometime around Oct 27th 2007.
Platform: Kubuntu Linux 7.04, i386-32, gcc 4.1.2.
The compiler output says it all:
gcc -c -DSQLITE_OMIT_FLOATING_POINT sqlite3.c
sqlite3.c: In function 'bestVirtualIndex':
sqlite3.c:65531: warning: integer constant is too large for 'long' type
sqlite3.c: In function 'bestIndex':
sqlite3.c:65600: warning: integer constant is too large for 'long' type
sqlite3.c: In function 'sqlite3WhereBegin':
sqlite3.c:66223: warning: integer constant is too large for 'long' type
sqlite3.c:66248: warning: integer constant is too large for 'long' type
sqlite3.c:66254: warning: integer constant is too large for 'long' type
These warnings would seem to indicate potentially serious problems, though i admittedly have not investigated whether overflows are really fatal in the affected contexts. |
|
2748 |
warn
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
4
|
4
|
amalgamation: SQLITE_OMIT_ALTERTABLE warnings
|
edit |
Hiya!
i'm working from the 3.5.1 (CVS version) of the amalgamation. The code was pulled from CVS sometime around Oct 27th 2007.
The compiler output says it all:
gcc -c -DSQLITE_OMIT_ALTERTABLE sqlite3.c
sqlite3.c:6909: warning: 'sqlite3AlterRenameTable' used but never defined
sqlite3.c:6916: warning: 'sqlite3AlterFinishAddColumn' used but never defined
sqlite3.c:6917: warning: 'sqlite3AlterBeginAddColumn' used but never defined
The relevant code is:
sed -ne '6909p;6916p;6917p' sqlite3.c
SQLITE_PRIVATE void sqlite3AlterRenameTable(Parse*, SrcList*, Token*);
SQLITE_PRIVATE void sqlite3AlterFinishAddColumn(Parse *, Token *);
SQLITE_PRIVATE void sqlite3AlterBeginAddColumn(Parse *, SrcList *);
Platform: Kubuntu Linux 7.04, i386, gcc 4.1.2. |
|
2736 |
build
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
2
|
2
|
build problems on freebsd
|
edit |
on freebsd:
--disable-threads does not work. it is accepted as a valid option but no defs are added to the makefile
-lgcc needs to be included in SHLIB_LD_LIBS
pkgIndex.tcl is not built when -DSQLITE_THREADSAFE=0 is added manually, this causes the install target to fail. |
2007-Oct-17 21:16:23 by anonymous:
I forgot to mention this is with the TEA version |
|
2729 |
doc
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
Lemon: %fallback, %wildcard, and @X uncodumented
|
edit |
I noticed that the lemon documentation does not mention the %fallback and %wildcard directives. Both are in the code and are apparently doing useful work in SQLite's parse.y. Can other users benefit from them as well?
The symbol @X is also undocumented. From a source code comment I read that it "If the argument is of the form @X then substituted the token number of X, not the value of X". A short documentation example would help to understand where and how it can be useful to apply this syntax.
Are there other nice but undocumented Lemon goodies lacking documentation? |
|
2728 |
code
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
4
|
4
|
Some indexes could contain pointers not the data
|
edit |
It would be nice if there was a class of index(-column) that would contain a reference to the data in (in the table) rather than a copy of the data.
This is useful where you have a need to index large strings or blobs and the size penalty of having 2+ copies ends up being very expensive.
Consider the cost of the implied index on:
create table t1 ( c1 BLOB UNIQUE);
and store 100s of 1MB objects. The raw file ends up being twice as large as you ideally would like it to be.
WHEN to use such indexes isn't entirely clear to me, not is the syntax for doing it in general, 30s of thought I can come up with:
create table t1 ( c1 BLOB &UNIQUE);
and say
create index idx1 on t2(c1, &c2, c3);
(meaning c2 would be done via reference, c1 & c3 as copies of the data). It's FAR from clear what other databases do here (I didn't look).
This would also be useful in cases where I have multiple indexes on tables like email (headers) and values which can be very large (100s of bytes in some cases (Subject:) and I might have 5 or more indexes, means a 100-byte column will take over 600 bytes (+ padding)). Allowing for references would be slower in some cases but faster in others because of the smaller footprint and much grater CPU cache utilization. |
2007-Oct-14 15:27:12 by anonymous:
This enhacement has been discussed on the mailing list before, and would break sqlite3 file format compatability.
2007-Oct-15 02:42:02 by anonymous:
This is non standard sql.
Also, the random access to pages to check indexes constraints (unique indexes, also primary keys) will trash the entire database performance.
If you need small index disk usage, consider using hashes to your data keys. it´s the best that you could do to solve your problem.
2007-Oct-18 06:07:58 by anonymous:
Using a hash is what I've tried doing in a couple of cases. It's not very ideal. For one thing is ordering is messed up.
I wonder about a virtual index concept, where you can define a function that takes the column value and returns something to actually store in the index?
I'm told oracle has this feature, so whilst it's non-standard there is some precedent (albeit in a very different space). |
|
2727 |
build
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
4
|
4
|
building with -malign-double causes strange behavior
|
edit |
sqlite 3.5.1 amalgamation has problems when enabling a wide set of compiler features on gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) on linux/i686 /w glibc-2.5 strange behavior occurs.
typical strangeness is that SQLITE_FULL is returned from sqlite3_prepare_v2() (called immediately after a statement was created with sqlite3_mprintf). This happens even though there is a reasonable amount of disk space free (6G).
the compile line looks like:
cc -g -pg -O1 -march=i686 -msse2 -malign-double -m128bit-long-double -momit-leaf-frame-pointer -minline-all-stringops -D_XOPEN_SOURCE=520 '-DVERSION="0.10r276M"' -Isqlite/ -DSQLITE_OMIT_LOAD_EXTENSION -DTHREADSAFE=0 -DSQLITE_OMIT_EXPLAIN -DSQLITE_ENABLE_COLUMN_METADATA -c -o sqlite/sqlite3.o sqlite/sqlite3.c
and valgrind reports:
==15323== Use of uninitialised value of size 4
==15323== at 0x80585B7: insertElement (sqlite3.c:13072)
==15323== by 0x807366E: sqlite3HashInsert (sqlite3.c:13290)
==15323== by 0x809FE72: unixOpen (sqlite3.c:15403)
==15323== by 0x80579A7: sqlite3OsOpen (sqlite3.c:8210)
==15323== by 0x806B12F: sqlite3BtreeFactory (sqlite3.c:21317)
==15323== by 0x80767BA: openDatabase (sqlite3.c:71237)
==15323== by 0x8076BD1: sqlite3_open (sqlite3.c:71337)
==15323== by 0x804BEAE: db_init (dbmgr.c:81)
==15323== by 0x804CE64: main (main.c:59)
my dbmgr.c:81:db_init() is:
res=sqlite3_open(filename, &system_db);
and system_db=NULL and filename="zomg.sqlite" (string literal). so the parameters seem normal. if I turn off -malign-double everything works fine. (this "bug" also seems to be on 3.4.1 amalgamation) |
2007-Oct-14 04:35:16 by anonymous:
This is a compiler issue. -malign-double creates problems for most programs. What are you trying to accomplish? |
|
2725 |
code
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
memory leak in sqlite3_open_v2() when it fails
|
edit |
only happens with
flags = SQLITE_OPEN_READWRITE;
and when
res = sqlite3_open_v2(sourcename, &conn, flags, NULL);
seems to leak 674 bytes per call |
2007-Oct-15 07:07:07 by danielk1977:
Are you calling sqlite3_close(conn) after the error occurs?
All calls to sqlite3_open_v2() need to be matched by a call to sqlite3_close(), even if an error occurs. |
|
2721 |
code
|
active
|
2007 Oct
|
anonymous
|
|
2007 Dec
|
|
2
|
1
|
if db file is in a folder with non-ansi character some functions fail
|
edit |
If database file is located in directory with some non-ANSI characters (in my case with a Russian subdirectory c:\Мои документы\Data_Jobs), or it's name is non-ansi. Some functions fail to execute sql.
For example (with defined UNICODE):
TCHAR sql[512];
_stprintf(sql, _T("INSERT INTO tab_SurveyedPoints (name, comment, code,")
_T("coordinatetype, b, l, h, solutiontype, sigmah, sigmav)")
_T(" VALUES ('%s','%s','%s',0,%lf,%lf,%lf,0,%lf,%lf);"),
point.m_name.c_str(), point.m_description.c_str(), point.m_code.c_str(),
point.m_coordinates.b, point.m_coordinates.l, point.m_coordinates.h,
point.m_sigmah, point.m_sigmav);
int rc1 = sqlite3_prepare16(m_db, sqlfmt, -1, &stmt, (const void**)&pszTail);
rc != SQLITE_OK
But if I move the file to c:\My documents\Data_Jobs this works ok.
It's improbable behaviour, but I can't work around yet. Although, prepare() functions work ok as well in both cases.
Yuri Noyanov. |
2007-Oct-11 19:33:34 by drh:
All string arguments to SQLite, and especially filename arguments,
must be UTF-8 or UTF-16 (depending on the function). If you use
string parameters which are not UTF-8 or UTF-16 (as appropriate)
then the behavior of SQLite is undefined and probably not what
you want.
2007-Oct-12 04:25:56 by anonymous:
but ALL programs to handle SQLite DBs (SQLIteBrowser, SQLite Control) fail to handle the files as well. Till I move the file to different directory !!!
2007-Oct-12 04:27:54 by anonymous:
Also I must note, that I CAN open the database, I CAN execute some SQLs with sqlite_prepare function OK. But sqlite_prepare16 FAILS if I just rename my database !!!
2007-Oct-12 04:31:46 by anonymous:
Also note to make my issue clearer:
sqlite_prepare16() with the same code either works OK either doesn't work. depends on database filename or folder path.
The database is opened OK in both cases (I used utf8 conversion).
sql_prepare() works ok in both cases.
2007-Oct-13 06:37:43 by anonymous:
That appears to be only with INSERT sql statement. Both SELECT and UPDATE work fine with sqlite_prepare16. |
|
2716 |
new
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
5
|
1
|
Create Clear Command
|
edit |
I want a command caled "clear" like in MySQL. This command should erase the screen and then put the sqlite pointer on top of the screen |
2007-Oct-11 07:41:45 by anonymous:
How about a cookie instead?
2007-Oct-30 08:02:04 by anonymous:
Clearing the screen and moving the cursor are platform-dependent operations. On Unix they are not only platform-dependent, but also terminal-dependent. Thus such a feature does not really belong in the cross-platform and minimalistic sqlite3 shell (in my opinion). |
|
2715 |
code
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
no authorization needed to remove authorizer
|
edit |
there should be a new auth code created and the auth function should be consulted for permission for removal. |
2007-Oct-10 01:08:48 by drh:
I'm assuming that this feature request comes from
RockShox and
that the development language is Tcl.
No. If your adversary has the ability to invoke the interface
that removes an authorizer, then you system is already pwned.
What you really need is the ability to [interp alias] the
eval method into a safe interpreter. That way you can:
- Open the database in the main interpreter
- Set up the authorizer in the main interpreter
to invoke a script in the main interpreter
- Set up the [interp alias] so that the safe
interpreter can do [db eval ...] but not
[db auth ...]
It seems like an "-interp" option on the "eval" method of
the database connection object would likely be the right
interface. Or perhaps there should be separate "safeeval"
method. Either way, it has been years and years since I have
done anything with safe interpreters so I will have to look
into what needs to be done to make that happen.
2007-Oct-17 20:11:23 by anonymous:
ok i think i agree with that.
currently you cannot use an interp alias since the target command runs in the target interp and all your variables and commands are in the wrong scope. this means one needs to load sqlite again in the new interp, and sqlite will not load in a safe interp so a regular interp is required.
to be useful, a -interp flag would need to execute in the current scope of the interp and not the global scope. |
|
2714 |
code
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
drh
|
3
|
4
|
Shell cannot import large files greater than 2 GB [patch]
|
edit |
If I issue an .import command within the SQLite shell and the file size is larger than 2 GB, the shell gives the error message "cannot open file: foo.txt".
Putting #define _FILE_OFFSET_BITS 64 before the #include statements in shell.c fixes this problem under Linux.
I tested this solution with a 2.6 GB file under Ubuntu Feisty Fawn 7.04 with Linux kernel 2.6.20-16-generic. |
2007-Oct-12 18:48:35 by drh:
I'm not convinced SQLite should be able to import files larger
than 2GiB. Does anybody really ever need to read more than
2GiB of SQL text? That is a lot of SQL, don't you think?
Is this really a desirable feature?
Can you not split it up into two or more smaller files?
2007-Oct-14 09:25:42 by anonymous:
I'm not 100% certain about this but:
#define _FILE_OFFSET_BITS 64
isn't necessarily correct, better to tweak the makefile(s):
CFLAGS += $(shell getconf LFS_CLFAGS)
(similar for LDFLAGS) should work on 32/64 bit machines and different platforms.
For shell.c I really wouldn't bother and think this should be left alone. Using .import for load more than 2GB makes me things the shell should be fleshed out and extended for this sort of abuse, handy as it is right now, it's not a full SQL shell but a minimalist shell and a useful example).
2007-Oct-16 14:08:09 by anonymous:
I am the original poster. I use the shell to import CSV files in the 3-4 GiB range on a daily basis. I don't see the point of splitting the files or writing my own importer when the shell does a perfectly fine job once large file support has been activated.
With all due respect, I don't understand the reluctance to enable a useful feature. Shouldn't the user decide whether it is reasonable for his application to import big files? I work in the health care industry processing insurance claims for several very large companies. There's nothing broken or wrong with my application -- big files are just the nature of the data I'm handling.
Neither of you has proposed any disadvantage to enabling LFS in the shell. If there are no drawbacks, why not turn it on? If the core library can open large database files, why shouldn't the shell be able to import large ones?
2007-Oct-16 16:24:22 by anonymous:
For reasons also unknown to me, the authors appear to regard the shell as a largely unused sample program. Based on my personal experience in talking to various sqlite library users, it is the primary administrative front-end for sqlite. In particular, doing backups and merging databases. |
|
2708 |
code
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
4
|
2
|
SQL error:disk I/O error
|
edit |
I cross-compile sqlite to embedded Linux,but after I insert data to the table ,it failed.the warning is "SQL error:disk I/O error". |
2007-Oct-09 05:12:28 by anonymous:
Why do you think it is SQLite error ??
2007-Oct-09 05:46:06 by danielk1977:
We'll need a bit more data than that to figure this out. Did earlier SQLite versions work? Can you post the entire output of the compile process so that we can see if there are any clues there? Can you run strace so that we can see if there really is an IO error, or at least when SQLite believes there to be one? |
|
2705 |
code
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
4
|
4
|
testfixture unresolved externals with SQLITE_OMIT_GET_TABLE
|
edit |
Cannot build/run "make test" with -DSQLITE_OMIT_GET_TABLE due to testfixture link error:
In function `test_get_table_printf':
./src/test1.c:526: undefined reference to `sqlite3_get_table'
./src/test1.c:541: undefined reference to `sqlite3_free_table'
collect2: ld returned 1 exit status
make: *** [testfixture] Error 1
|
|
2704 |
code
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
4
|
4
|
"make test" aborts before completion with SQLITE_OMIT_BLOB_LITERAL
|
edit |
When compiled with -DSQLITE_OMIT_BLOB_LITERAL make test aborts with this error:
substr-2.5.2... Ok
./testfixture: near "'61626364656667'": syntax error
while executing
"db eval "
DELETE FROM t1;
INSERT INTO t1(b) VALUES(x'$hex')
""
(procedure "subblob-test" line 2)
invoked from within
"subblob-test 3.1 61626364656667 1 1 61"
(file "./test/substr.test" line 86)
invoked from within
"source $testfile"
("foreach" body line 5)
invoked from within
"foreach testfile [lsort -dictionary [glob $testdir/*.test]] {
set tail [file tail $testfile]
if {[lsearch -exact $EXCLUDE $tail]>=0} continue
if..."
(file "./test/quick.test" line 93)
make: *** [test] Error 1
|
|
2703 |
code
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
3
|
4
|
make test does not work with SQLITE_OMIT_FLOATING_POINT
|
edit |
make test cannot run with SQLITE_OMIT_FLOATING_POINT. Shouldn't these tests be skipped?
./src/test1.c:1255: warning: passing argument 3 of ‘Tcl_GetDouble’ from incompatible pointer type
./src/test1.c: In function ‘sqlite3_mprintf_scaled’:
./src/test1.c:1284: warning: passing argument 3 of ‘Tcl_GetDouble’ from incompatible pointer type
./src/test1.c: In function ‘test_bind_double’:
./src/test1.c:2607: warning: passing argument 3 of ‘Tcl_GetDoubleFromObj’ from incompatible pointer type
./src/tclsqlite.c: In function ‘tclSqlFunc’:
./src/tclsqlite.c:728: warning: passing argument 3 of ‘Tcl_GetDoubleFromObj’ from incompatible pointer type
./src/tclsqlite.c: In function ‘DbObjCmd’:
./src/tclsqlite.c:1609: warning: passing argument 3 of ‘Tcl_GetDoubleFromObj’ from incompatible pointer type
...
$ ./testfixture test/select1.test
select1-1.1... Ok
select1-1.2... Ok
select1-1.3... Ok
select1-1.4... Ok
select1-1.5... Ok
select1-1.6... Ok
select1-1.7... Ok
select1-1.8... Ok
select1-1.8.1... Ok
select1-1.8.2... Ok
select1-1.8.3... Ok
./testfixture: near ".": syntax error
while executing
"db eval {INSERT INTO test2(r1,r2) VALUES(1.1,2.2)}"
("uplevel" body line 1)
invoked from within
"uplevel [list $db eval $sql]"
(procedure "execsql" line 3)
invoked from within
"execsql {INSERT INTO test2(r1,r2) VALUES(1.1,2.2)}"
(file "test/select1.test" line 69)
|
|
2701 |
new
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
5
|
5
|
Make INSERT-ing multiple rows MySQL-compatible
|
edit |
SQLite syntax allows to insert only one row with
insert into test (a, b, c) values (1, 2, 3);
MySQL allows to insert multiple with
insert into test (a, b, c) values (1, 2, 3), (4, 5, 6), (7, 8, 9) -- etc
But SQLite is also capable of inserting multiple by using INSERT...SELECT:
insert into test (a, b, c) select 1, 2, 3 union select 4, 5, 6 -- etc
It would be nice to make INSERT statement syntactically compatible with MySQL, allowing to insert multiple rows with VALUES clause.
It can be implemented by simply translating multiple 'VALUES ()()()' to 'select union' - no serious change required at all. |
2007-Oct-08 21:45:05 by anonymous:
You mean "UNION ALL", not "UNION".
UNION would remove duplicate rows, and create an ephemeral table that you don't want because it's less efficient.
Your idea is a good one and could be implemented largely in the parser. The number of VDBE opcodes would be quite large for such a statement. I wonder if that would present a problem.
2007-Oct-14 08:12:11 by anonymous:
Patch implementing multi-row INSERT statements against 3.5.1 source tree:
http://www.mail-archive.com/sqlite-users%40sqlite.org/msg28337.html |
|
2684 |
code
|
active
|
2007 Oct
|
anonymous
|
|
2007 Oct
|
|
1
|
1
|
Accessing sqlite from an NT service will lock the complete databse.
|
edit |
Accessing sqlite from a NT service (application 1) will lock the complete database. Any other process trying to open an sqlite db (application 2) will get error "80004005 unable to lock database"
If application 1 runs as normal application, started by local user, this problem doesnt occur and both applications can open the db. |
2007-Oct-02 15:48:05 by anonymous:
SQLite has no knowledge of Windows services. How do you propose to work around this Windows anachronism?
2007-Oct-02 17:20:38 by anonymous:
Suggesion: Try running the service in the same account as the other program that needs to access the database.
Anachronism? Service is just another word for daemon.
-knu-
2007-Oct-02 17:33:56 by anonymous:
Re: Anachronism, the OP suggested there was something fundamentally different about file access using a service. You've pointed out that it's just a file permissions issue.
2007-Oct-05 14:45:07 by drh:
Two points:
- The error message "80004005 unable to lock database" is not generated
by SQLite. There must be some middleware someplace that is
producing this message. The problem might be in that middleware
and not in SQLite.
- None of the SQLite developers run windows. Consequently any fixes
for this problem
will need to come from the community. Please append patches to
this ticket if you find a fix. Or close the ticket if you discover
that the problem is outside of SQLite.
|
|
2677 |
new
|
active
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
danielk1977
|
5
|
3
|
CREATE TRIGGER .. {databaseevent ON ... }+ for multiple events
|
edit |
I have to write triggers which react on either INSERT or UPDATE of a specific field in a table. In some SQL syntax descriptions I found a possibility to combine the trigger events for more than one condition but not in SQLite3. Isn't there a possibility to use one trigger definition for more than one event or didn't I find the trick? Do I have to copy the whole definition for each event; even if the body text is exactly the same?
Suggestion: On INSERT event use the OLD.fieldnames filled with NULL content to avoid problems with UPDATE event. - If not possible please explain why not for my better understanding. Thank you. |
|
2674 |
code
|
active
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
3
|
4
|
NFS fails without lock manager
|
edit |
Problem:
SQLite fails entirely if the NFS lock manager is not running on the share hosting the DB -- even when all access to the DB is serialized.
Under these circumstances, it becomes difficult to create applications that are capable of running in a multitude of environments because restrictions are now imposed upon the storage location.
Reproduction:
- setup an NFS share
- disable the lock manager
- attempt to perform any transactions on a db on that share
- start the lock manager
- perform the same operations
Request:
- Make a change to the error handling, as necessary, to allow processes to access a DB over an NFS share without use of a lock manager.
- Make a big bold flashing sign in the FAQ about this failure-mode. The wording of the current FAQ led us to believe that the transaction would go through, but protection from other processes was not guaranteed.
Shameless Fanmail:
Love the product!
Screenshot:
dev-srs08 ~ # <cmd>
[__db_init <file>.c:384] Statement:
CREATE TABLE
versions (
id INTEGER PRIMARY KEY AUTOINCREMENT,
version INTEGER,
tbl CHAR(256)
);
Failed with error:
database is locked
[main <file>.c:1096] Unable to init output DB: /mnt/nfs/o
dev-srs08 ~ # /etc/init.d/nfslock start
Starting NFS statd: [ OK ]
dev-srs08 ~ # <cmd>
dev-srs08 ~ #
|
2007-Sep-28 04:35:00 by anonymous:
Yet another reason to avoid using SQLite on remote shares.
2007-Sep-29 18:04:19 by anonymous:
Make a change to the error handling, as necessary, to allow processes to access a DB over an NFS share without use of a lock manager.
By design the SQLite library guarantees ACID. It can't provide that without file locks. In my opinion a non-ACID version would be a custom version, which you can (should) build yourself. The source is available, or there might already be a compilation option to accomplish that.
Make a big bold flashing sign in the FAQ about this failure-mode. The wording of the current FAQ led us to believe that the transaction would go through, but protection from other processes was not guaranteed.
FAQ (5) "When any process wants to write, it must lock the entire database file for the duration of its update." seems to be quite clear.
-knu- |
|
2671 |
code
|
active
|
2007 Sep
|
shess
|
|
2007 Sep
|
shess
|
2
|
4
|
Fts field-based queries are not correctly case-insensitive.
|
edit |
CREATE VIRTUAL TABLE t USING fts2(A, B);
-- At the SQL level, things are case-insensitive:
INSERT INTO t (A, b) VALUES ('Test', 'Columns');
INSERT INTO T (a, B) VALUES ('Second', 'Test');
-- Unfortunately, fts cannot do field-level queries:
SELECT rowid FROM t WHERE t MATCH 'test'; -- works
SELECT rowid FROM t WHERE b MATCH 'test'; -- works
SELECT rowid FROM t WHERE t MATCH 'b:test'; -- no results
SELECT rowid FROM t WHERE t MATCH 'B:test'; -- no results
It doesn't work because fts is keeping the column name as 'B', but the query parsing uses the results from the tokenizer, which are case-folded, and 'b' != 'B'.
I'm thinking on the solution. A quick fix would be to make the azColumn storage be lowercase, but the core problem is that field names probably shouldn't be run through the tokenizer in the first place. |
|
2664 |
code
|
active
|
2007 Sep
|
danielk1977
|
|
2007 Sep
|
|
1
|
1
|
attaching the same db twice in shared-cache mode fails
|
edit |
The following SQL script can cause an assert() to fail in shared-cache mode.
ATTACH 'db' AS aux1;
ATTACH 'db' AS aux2;
CREATE TABLE aux1.abc(a, b, c);
CREATE TABLE aux2.abc(a, b, c);
|
See also #2653 |
|
2653 |
code
|
active
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
3
|
4
|
Exclusive Transactions do not work with a Database File attached twice
|
edit |
Regarding the docs, it is possible to attach the same database file multiple times.
After doing so, I wanted to begin an exclusive transaction. Unfortunately, this fails ("database is locked") and surprises me as I did not find any notice on this particular situation and possible side-effects neither in the attach nor in the transaction/locking documentation.
If this behaviour is seen as an error, It would be useful to have it error fixed, because if one reads a list of (possibly duplicate) database files but with unique identifiers, it would be helpful to use these defined identifiers when accessing the databases (and that in an exclusive transaction).
Real-world case: Each "module" uses its own database file. Some modules share a database file. So there is a list of module -> database file assignments. Now an update process gets some database update scripts from the modules. Every module wants its changes to be done in the right database, so it relies on having its own database attached with an unique identifier - the module's name. On the other hand, the update process need exclusive access to the databases and starts a transaction -- bummer. |
|
2652 |
code
|
active
|
2007 Sep
|
drh
|
|
2007 Sep
|
|
1
|
1
|
Aggregate function cannot be used from within a subquery
|
edit |
The following SQL fails:
CREATE TABLE t1(x,y);
INSERT INTO t1 VALUES(1,2);
CREATE TABLE t2(z);
INSERT INTO t2 VALUES(1);
SELECT (SELECT y FROM t1 WHERE x=min(z)) FROM t2;
Problem reported on the mailing list. |
2007-Sep-23 16:01:09 by anonymous:
Your syntax appears to be incorrect.
SQLite v3.4.2
CREATE TABLE t1(x,y);
CREATE TABLE t2(z);
INSERT INTO t1 VALUES(1,21);
INSERT INTO t1 VALUES(2,22);
INSERT INTO t1 VALUES(3,23);
INSERT INTO t2 VALUES(3);
INSERT INTO t2 VALUES(2);
INSERT INTO t2 VALUES(1);
What you wanted to do:
SELECT y FROM t1 WHERE x=(SELECT min(z) FROM t2);
21 -- works as expected
What you did:
SELECT (SELECT y FROM t1 WHERE x=min(z)) FROM t2;
SQL error near line []: misuse of aggregate function min()
|
|
2651 |
new
|
active
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
5
|
4
|
Add support for overriding home directory location
|
edit |
Currently, the history file's and the rc file's location is hard-wired to $HOME . It would be nice if this could be overridden. One way is to look for a SQLITE_HOME environment variable that points to the location to use. This can be achieved by a simple addition to find_home_dir() in src/shell.c . |
|
2649 |
new
|
active
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
4
|
4
|
Add an "--enable-extensions" (default=no) to the configure script
|
edit |
The attached patch adds "--enable-extensions" to the configure script, but is disabled by default (because of the security considerations of having it enabled). |
|
2645 |
build
|
active
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
5
|
4
|
Conflict between tclConfig.sh and tclinstaller.tcl
|
edit |
I'm using a non-standard location for Tcl:
--with-tcl=/home/scott/lib
The build process finds and uses the tclConfig.sh file from /home/scott/lib just fine, but tclinstaller.tcl is called without an explicit path and uses the system's tclsh instead of the one in /home/scott/bin and thus tries to install that portion of code into the system's area.
While I can change my path to resolve this, I think it makes more sense for tclinstaller.tcl to use the path information that's embedded in tclConfig.sh to be consistent.
/s. |
|
2634 |
code
|
active
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
3
|
3
|
.schema uses incorrect ORDER BY giving wrong dependency order
|
edit |
When the schema is exported, views are sorted by name instead of by dependency. If there are nested views, the schema may be invalid when used to re-create the database.
sqlite3
create table t ( f text );
create view v2 as select f from t;
create view v1 as select f from v2;
.output test.txt
.schema
.exit
sqlite3
.read test.txt
SQL error near line 2: no such table: main.v2
|
2007-Sep-07 15:33:06 by anonymous:
Use .dump instead as a workaround. Unlike .schema, .dump does not use ORDER BY in its queries on sqlite_master and it outputs its rows in order of entry.
SQLite version 3.5.0
Enter ".help" for instructions
sqlite> create table t ( f text );
sqlite> create view v2 as select f from t;
sqlite> create view v1 as select f from v2;
sqlite>
sqlite> .schema
CREATE TABLE t ( f text );
CREATE VIEW v1 as select f from v2;
CREATE VIEW v2 as select f from t;
sqlite>
sqlite> .dump
BEGIN TRANSACTION;
CREATE TABLE t ( f text );
CREATE VIEW v2 as select f from t;
CREATE VIEW v1 as select f from v2;
COMMIT;
Suggested patch:
Index: src/shell.c
===================================================================
RCS file: /sqlite/sqlite/src/shell.c,v
retrieving revision 1.167
diff -u -3 -p -r1.167 shell.c
--- src/shell.c 7 Sep 2007 01:12:32 -0000 1.167
+++ src/shell.c 7 Sep 2007 15:28:24 -0000
@@ -1411,8 +1411,7 @@ static int do_meta_command(char *zLine,
"SELECT sql FROM "
" (SELECT * FROM sqlite_master UNION ALL"
" SELECT * FROM sqlite_temp_master) "
- "WHERE tbl_name LIKE shellstatic() AND type!='meta' AND sql NOTNULL "
- "ORDER BY substr(type,2,1), name",
+ "WHERE tbl_name LIKE shellstatic() AND type!='meta' AND sql NOTNULL",
callback, &data, &zErrMsg);
zShellStatic = 0;
}
@@ -1421,8 +1420,7 @@ static int do_meta_command(char *zLine,
"SELECT sql FROM "
" (SELECT * FROM sqlite_master UNION ALL"
" SELECT * FROM sqlite_temp_master) "
- "WHERE type!='meta' AND sql NOTNULL AND name NOT LIKE 'sqlite_%'"
- "ORDER BY substr(type,2,1), name",
+ "WHERE type!='meta' AND sql NOTNULL AND name NOT LIKE 'sqlite_%'",
callback, &data, &zErrMsg
);
}
after patch:
SQLite version 3.5.0
Enter ".help" for instructions
sqlite> create table t ( f text );
sqlite> create view v2 as select f from t;
sqlite> create view v1 as select f from v2;
sqlite> .schema
CREATE TABLE t ( f text );
CREATE VIEW v2 as select f from t;
CREATE VIEW v1 as select f from v2;
sqlite> .q
|
|
2629 |
doc
|
active
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
4
|
4
|
typo in os_unix.c for nolock
|
edit |
Index: src/os_unix.c
===================================================================
RCS file: /sqlite/sqlite/src/os_unix.c,v
retrieving revision 1.165
diff -u -3 -p -r1.165 os_unix.c
--- src/os_unix.c 5 Sep 2007 13:56:32 -0000 1.165
+++ src/os_unix.c 6 Sep 2007 17:53:47 -0000
@@ -2126,7 +2126,7 @@ static const sqlite3_io_methods sqlite3D
/*
** This vector defines all the methods that can operate on an sqlite3_file
-** for unix with dotlock style file locking.
+** for unix with nolock style file locking.
*/
static const sqlite3_io_methods sqlite3NolockLockingUnixIoMethod = {
1, /* iVersion */
|
|
2627 |
code
|
active
|
2007 Sep
|
anonymous
|
|
2007 Sep
|
|
3
|
2
|
Improper parsing of nested JOIN
|
edit |
SQLite has a problem with multiple nested JOINs. The only way to get it workig is to remove the surrounding brackets. Removing the brackets unfortunately do not work in other DB systems such as MS SQL, mysql etc.
This does not work:
Select ContactPhone.* From (ContactPhone LEFT OUTER JOIN ContactLocation ON ContactPhone.PHNLCT_ID = ContactLocation.LCT_ID) LEFT OUTER JOIN ContactItem ON ContactLocation.LCTITM_ID = ContactItem.ITM_ID
(It complains about LCT_ID or similar)
This works after removing the brackets:
Select ContactPhone.* From ContactPhone LEFT OUTER JOIN ContactLocation ON ContactPhone.PHNLCT_ID = ContactLocation.LCT_ID LEFT OUTER JOIN ContactItem ON ContactLocation.LCTITM_ID = ContactItem.ITM_ID
All other major DB systems require the surrounding brackets. Do you think it is possible to fix it? Apart from this little little SQLite is an awesome project.
Thank you
Jakub Klos |
2007-Sep-06 13:07:32 by anonymous:
I don't have access to MS SQL Server, but MySQL and Oracle have no issue with the query without parentheses:
create table x1(a int, b int);
create table x2(c int, d int);
create table x3(e int, f int);
mysql> select x1.* from x1 left join x2 on x1.a=x2.c left join x3 on x2.d=x3.e;
Empty set (0.00 sec)
2007-Sep-06 19:03:33 by anonymous:
MSSQL also has no problems without the parens. As a matter of fact, the only DB that I know of that requires them is MS Access (JET).
2007-Sep-06 20:11:31 by anonymous:
I guess he had no luck filing a JET bug.
2007-Sep-11 17:22:28 by anonymous:
True, MS access requires the parens but all other major DBs support the query syntax with the parens. So why SQLite does not like it? It should simply ignore them if possible. Thank you |
|
2613 |
code
|
active
|
2007 Sep
|
anonymous
|
|
2008 Jan
|
drh
|
3
|
3
|
replace doesn't work with blobs containing \x0, otherwise it does
|
edit |
The replace expression function does not work with blobs in case of contained zero terminator character; but it does if there is not this special character included. I expected the function to work similar like substr with blob-safety in case of type is blob only. X'nnnn' is of type blob, so following example should have returned a blob type result X'0102FF0405' in the 2nd and 3rd line. How to get to this result?
SQLite version 3.4.2
Enter ".help" for instructions
sqlite> select hex(replace(X'0102030405',X'03',X'FF'));
0102FF0405
sqlite> select hex(replace(X'0102000405',X'00',X'FF'));
sqlite> select typeof(replace(X'0102000405',X'00',X'FF'));
null
sqlite>
|
2007-Sep-03 04:21:12 by anonymous:
Replace was designed to work with strings.
However, working with blobs would be an interesting extension.
2007-Oct-18 06:13:10 by anonymous:
I've seen a similar situation where I can't reliably store stings with nulls in the middle of them as TEXT.
I can convert them to blobs, in which case length(...) works correctly. I if convert them back to strings, length(...) treats them as C-strings.
Is this the expected behavior? I notice the entire column is preserved even when it's has TEXT affinity, I can append data to it as a string, cast back to a blob and see everything (am I explaining this poorly?)
This all seems a bit counter intuitive in some ways. Perhaps strings shouldn't treat NULL characters as special?
2007-Oct-27 16:45:41 by anonymous:
Treatment of length operator is - as fas as I know - dependent on type:
As text it is the length number of UTF-8 characters and as blob it is the number of bytes. As long as all the UTF-8 characters out of the lower half ASCII char-set (127 of them), this is identical beside the fact of different 0-terminator interpretation.
To append is something different than using the replace operator. My suggestion would be to make the replace operator work with bytes (not UTF-8) in case of all 3 parameters are of type blob.
Another suggestion: the UTF aware functions are Private declared and not usable from within a loadable extension dll/so. This should be changed.
2008-Jan-28 19:36:39 by anonymous:
Will there come a solution for this with the next release? It is really not fair to handle a blob only like text which cannot contain a zero terminator. With this unique useful function a zero-containing blob could be formed into a normal text string without loosing the part behind the zero terminator. It would be really a step forward without too much effort. |
|
2607 |
event
|
active
|
2007 Aug
|
anonymous
|
|
2007 Sep
|
|
2
|
1
|
Data loss, continuation to Re: [sqlite] how to flush database to disk?
|
edit |
See that mailing list.
The originator message :
I've just lost a couple of days' worth of data when my app crashed. (Well, the
data wasn't a total loss thanks to backup plans, but the database itself
essentially reverted to its state of 2 days ago.) This is despite my app doing
a COMMIT after every modification of the DB.
It's acting as though all the changes were held in memory, or somehow
journaled, and when the crash happened, the changes were all lost or rolled
back. What I need is a way to force the database to save its data to disk
while my app is running, so that in the event of a crash, I lose little or no
data. How can I do this? I presume that closing the database would do the
trick, but is there a less heavy-handed way?
The exact like that data loss occured at me too. Three times, non-repropucible regualrilly.
What common in these losses ?
{Editing+committing} in the main thread then {navigating, bof/eof checking, reading data} from within different threads then return to the main thread for {editing+committing}. |
2007-Aug-31 19:38:26 by drh:
The COMMIT does not actually occur until you call
sqlite3_reset() and/or sqlite3_finalize() on all your
prepared statements. Any prepared statement that has
not been reset or finalized is still running, is
incomplete, and is thus still holding the transaction
open. I'm guessing that you have an unreset and
unfinialized statement in your application.
I wonder what would happen if we changed the definition
of COMMIT so that it returned an error if there were
active prepared statements. This is, technically, an
incompatibility. But we are coming up on a release with
several other minor incompatibilities, so now might be
a good time to insert such a change.
2007-Aug-31 19:45:36 by drh:
I looked in the code, and it turns out we already do this.
Perhaps the application is not checking the return code
from the COMMIT to see that it is failing?
2007-Aug-31 20:40:47 by anonymous:
No error reports came from COMMIT.
The data loss were noticed after UPDATE & COMMIT after massive reading of results of SQL addressing the same virtual (ATTACHed) tables, from within another thread.
2007-Aug-31 20:53:48 by anonymous:
Is it possible that a pending transaction survive app shutdown & then OS restart ?
Is yes, then any DB error would cause rollback to the data on last BEGIN, isn't ?
2007-Aug-31 21:00:18 by anonymous:
But me committed each smallest change to dat,a then saw these refreshed data in the tables. And on the next day these data were present.
Only reading (with full scrolling ) the affected virtual tables from within another thread then new editing then committing caused the loss.
2007-Sep-01 23:12:31 by anonymous:
You mention virtual tables. Their data is not maintained by the SQLite engine, but by your own module. If that doesn't implement ACID, you're out of luck.
By definition:
A virtual table is an interface to an external storage or computation engine that appears to be a table but does not actually store information in the database file.
references:
CreateVirtualTable
VirtualTables
2007-Sep-04 04:51:15 by anonymous:
Me was wrong. These were't true virtual tables. Me used a LEFT OUTER query to several tables residing in different ATTACHed databases.
2007-Sep-04 04:52:01 by anonymous:
were't => were not, above. |
|
2604 |
new
|
active
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
4
|
4
|
CREATE VIRTUAL TABLE does not allow IF NOT EXISTS
|
edit |
CREATE VIRTUAL TABLE vt IF NOT EXISTS; would help with development since creating a virtual table that exists returns error 1 - as do several "Real" errors. |
|
2595 |
doc
|
active
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
4
|
4
|
sqlite3_commit_hook doc typo
|
edit |
src/main.c:
-** Register a function to be invoked when a transaction comments.
+** Register a function to be invoked when a transaction commits.
|
|
2587 |
build
|
active
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
3
|
4
|
Build problem when using the SQLITE_OMIT_FLOATING_POINT define.
|
edit |
I apologize in advance if the values I chose above are not appropriate.
If I define SQLITE_OMIT_FLOATING_POINT=1 and try to build a Windows DLL, I get two errors in loadext.c, line 116 and 192. "error C4028: formal para
meter 3 different from declaration"
I believe you want to change the include order at the top of loadext.c from:
#include "sqlite3ext.h"
#include "sqliteInt.h"
to:
#include "sqliteInt.h"
#include "sqlite3ext.h"
Reversing the order of include fixes my build.
Yes, I know there is no real reason to disable floating point for the Windows DLL. I'm actually porting SqLite for use in an NT kernel mode driver and avoiding floating point operations will save a lot of time if I don't really need them and I don't. So I made sure this was a problem with a supported platform like the Windows DLL and griped about that instead of my insanity. ;-)
You can email questons to mspiegel@vipmail.com. If you want to discuss this over the phone, shoot me an email and I'll send you phone numbers. |
|
2582 |
doc
|
active
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
anonymous
|
5
|
5
|
documenation clarification
|
edit |
docs for topic `Set A Busy Timeout`
int sqlite3_busy_timeout(sqlite3*, int ms);
http://sqlite.org/capi3ref.html#sqlite3_busy_timeout
the wording "The handler will sleep multiple times until at least "ms" milliseconds of sleeping have been done"
implies it will wait the total amount regardless of the lock status, it should perhaps indicate in the same sentence that it will exit early if the lock becomes available. |
|
2580 |
code
|
active
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
anonymous
|
1
|
2
|
Can't open a query if text to search is Greek
|
edit |
for example:
SELECT * FROM mytable WHERE mycolumn LIKE '%some greek text%'
I get wrong results, using the 3.4.2 version. No problem instead using other earlier version. I tested only in Windows. |
|
2568 |
new
|
active
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
3
|
3
|
TEMP_STORE is ignored in some cases
|
edit |
It seems that sometimes TEMP_STORE is ignored. I've tried to force SQLite to always use memory by setting TEMP_STORE=3, but some etilqs_* temp files are still being created. The call stack that's causing these file to be created is:
sqlite3PagerOpentemp(OsFile * *)
sqlite3PagerStmtBegin(Pager *)
sqlite3BtreeBeginStmt(Btree *)
sqlite3VdbeExec(Vdbe *)
sqlite3Step(Vdbe *)
sqlite3_step(sqlite3_stmt *)
It looks like the temp files are being used to store information for undoing earlier parts of a transaction if a later part fails. I'm assuming the fact this part of the code ignores TEMP_STORE is an over site? |
2007-Aug-13 15:03:19 by drh:
The TEMP_STORE compile-time option only changes the storage
for temporary database files. The statement journal is not
a databaes file and thus does not come under the control
of TEMP_STORE. There is currently no mechanism to force the
statement journal into memory instead of onto disk.
I will reclassify this ticket as a "feature request".
2007-Aug-22 10:42:50 by anonymous:
Okay, thank you. |
|
2567 |
build
|
active
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
3
|
2
|
Build fails to install
|
edit |
I compile under MinGW with Msys. A build error occurs during 'make install'. After checking the makefile. The 'install' target depends on 'sqlite3', when it should be 'sqlite3$(TEXE)'.
The workaround is, after configure, edit makefile for target install, and replace 'sqlite3' with 'sqlite3${TEXE}' where needed. I did not have this problem with 3.3.17. I assume this could be fixed just by fixing the configure to produce correct makefile. |
2007-Aug-12 04:41:12 by anonymous:
Do you have a patch? |
|
2566 |
build
|
active
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
2
|
1
|
fts2 broken after vacuum
|
edit |
Hi there, I'm testing your database and I'm having problems with fts2:
sqlite> select * from distB where distB match "MARIANO";
Assertion failed: *pData!='\0', file fts2amal.c, line 16790
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Steps:
1) Create a new .db
2) Import data in new distA table
3) Import data in new distB table
4) Create a new distC virtual table (dts2)
5) insert into distC (rowid, f1, f2, f3) select rowid, f1, f2, f3 from DistB
Everything working like a charm until here!!! The fts2 works very well, but after
6) vacuum;
the fts seems broken... doing a select throws the error I paste at the post of the topic
If you want the .db file I can send it to you (607MB)
Thanks.- |
|
2559 |
code
|
active
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
4
|
4
|
"make clean" does not delete sqlite3.c and tsrc/
|
edit |
Index: Makefile.in
===================================================================
RCS file: /sqlite/sqlite/Makefile.in,v
retrieving revision 1.179
diff -u -3 -p -r1.179 Makefile.in
--- Makefile.in 27 Aug 2007 23:38:43 -0000 1.179
+++ Makefile.in 28 Aug 2007 01:25:55 -0000
@@ -724,7 +724,7 @@ clean:
rm -f testfixture$(TEXE) test.db
rm -rf doc
rm -f common.tcl
- rm -f sqlite3.dll sqlite3.lib sqlite3.def
+ rm -rf sqlite3.dll sqlite3.lib sqlite3.def sqlite3.c tsrc
distclean: clean
rm -f config.log config.status libtool Makefile config.h sqlite3.pc
|
|
2558 |
code
|
active
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
2
|
3
|
Multiple JOIN USING() gives incorrect results
|
edit |
I'm having a problem joining multiple tables with USING. It appears
to work, but the results are incorrect. Here is an example to
illustrate the problem. I believe the three SELECT statements should
be equivalent, but they produce three different results.
.header on
.mode column
CREATE TABLE Main (pk INTEGER PRIMARY KEY, name VARCHAR);
CREATE TABLE OptA (pk INTEGER PRIMARY KEY, alpha VARCHAR);
CREATE TABLE OptB (pk INTEGER PRIMARY KEY, beta VARCHAR);
INSERT INTO Main VALUES (1, 'One');
INSERT INTO Main VALUES (2, 'Two');
INSERT INTO Main VALUES (3, 'Three');
INSERT INTO Main VALUES (4, 'Four');
INSERT INTO OptA VALUES (1, 'Alpha1');
INSERT INTO OptA VALUES (4, 'Alpha4');
INSERT INTO OptB VALUES (2, 'Beta2');
INSERT INTO OptB VALUES (4, 'Beta4');
SELECT * FROM Main LEFT JOIN OptA USING (pk) LEFT JOIN OptB USING (pk);
SELECT * FROM Main LEFT JOIN OptB USING (pk) LEFT JOIN OptA USING (pk);
SELECT Main.pk, name, alpha, beta
FROM Main LEFT JOIN OptA ON Main.pk = OptA.pk
LEFT JOIN OptB ON Main.pk = OptB.pk;
Joining Main, OptA, and OptB omits Beta2:
pk name alpha beta
---------- ---------- ---------- ----------
1 One Alpha1
2 Two
3 Three
4 Four Alpha4 Beta4
Joining Main, OptB, and OptA omits Alpha1:
pk name beta alpha
---------- ---------- ---------- ----------
1 One
2 Two Beta2
3 Three
4 Four Beta4 Alpha4
Only by using ON instead of USING do we get the correct results:
pk name alpha beta
---------- ---------- ---------- ----------
1 One Alpha1
2 Two Beta2
3 Three
4 Four Alpha4 Beta4
I think this is basically the same issue as ticket #1637, but it's a
more serious example. In that one, the query simply failed to
compile. In this case, it seems to work, but gives you the wrong
results.
I've also tried this script in PostgreSQL 8.0.13. All three queries
give (the same) correct results. |
2007-Aug-08 17:34:27 by anonymous:
The problem is that SQLite is transforming
SELECT * FROM Main LEFT JOIN OptA USING (pk) LEFT JOIN OptB USING (pk);
into
SELECT Main.pk, name, alpha, beta
FROM Main LEFT JOIN OptA ON Main.pk = OptA.pk
LEFT JOIN OptB ON OptA.pk = OptB.pk;
Here is a workaround to this bug that makes use of a subquery:
select * from (SELECT * FROM Main LEFT JOIN OptA USING (pk))
LEFT JOIN OptB USING (pk);
Conceivably all LEFT JOIN chains could be transformed into the above form, but that would decrease performance due to the intermediate result set of the subquery. Having it work without the subquery is tricky since sqlite must deduce that the last USING (pk) is equivalent to the first pk in the chain of joined tables, namely Main.pk, and not OptA.pk.
Joe Wilson |
|
2555 |
new
|
active
|
2007 Aug
|
anonymous
|
|
2007 Aug
|
|
1
|
1
|
FTS index without original text
|
edit |
Is it possible to build FTS index without storing original text? I want to use fts index without features of snippets etc. I just want to find ID of the record not the content of indexed phrase. I suppose that the table myname_content stores this content. I have tried to update all columns of myname_content and set its values to “xyz” (without one column in which I store ID of the record). After this operation FTS search works good, but unfortunately the table isn’t smaller (I cant’t use vacuum on FTS tables). Is there any other way to have pure text indexes without source level changes? |
|
2547 |
code
|
active
|
2007 Aug
|
danielk1977
|
|
2007 Aug
|
|
5
|
3
|
Changing db encoding of an attached db can confuse shared cache mode.
|
edit |
This is quite obscure, but in shared-cache mode:
1) Open db A, attach empty db B.
2) Using another connection from the same thread, set the
encoding of B to be different from that of A. Add some
data to B.
3) Using the original connection, access database B. It assumes
the encoding of A (and therefore mangling any text data).
The correct response is to return an error - "attached databases
must use the same text encoding as main database". |
|
2545 |
code
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
4
|
Group by returns table name with field name
|
edit |
imaginate a table:
create table test (
id INTEGER PRIMARY KEY,
name varchar(50) not null,
age integer not null
);
Then:
insert into test (name,age) values ('foo',22);
insert into test (name,age) values ('foo',23);
insert into test (name,age) values ('bar',22);
insert into test (name,age) values ('bar',35);
insert into test (name,age) values ('bar',72);
Now try this;
sqlite> .headers on
sqlite> select test.name, test.age from test order by name;
name|age
bar|22
bar|35
bar|72
foo|22
foo|23
sqlite> select test.name, test.age from test group by name;
test.name|test.age
bar|72
foo|23
You see ? if i use "GROUP BY", the field name contains tablename. Because i use "SELECT test.name" and not "SELECT name".
If i set an alias, i get alias, that's ok.
The trouble appears to be very high on Copix (http://wwW.copix.org). We create some DAO (Data Access Objects) automatically. The "groupBy" method doesn't works with SQLite...
Is this normal ? Mysql, PostgreSql, Oracle... doesn't need to create alias. |
2007-Jul-31 15:54:52 by anonymous:
There's probably 4 other tickets reporting this. I don't think it will get fixed. The workaround is to use aliases (AS "whatever") for the selected columns.
2007-Jul-31 23:02:19 by anonymous:
Ok, we have created a special support for SQLite.
PS: I love this database :) Simple, nice, usefull, quick and easy
Regards |
|
2543 |
code
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
1
|
Chinese charset not support??
|
edit |
when i create a table.
the table name is "
" (chinese)
after this
"alter table
add column aaa text null"
error
why??/
thank you |
|
2540 |
code
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
5
|
4
|
Display dlopen() errors for errors when loading modules on Unix system
|
edit |
If there is an error loading a module the message "unable to open shared library..." is displayed. In the Unix world the dlopen() error could be display to help diagnose the problem (e.g. missing external refs, etc). I have implemented it in our install of SQLite, I'm sure there is a Windows analog. Here is the patch for loadext.c.
- Chris -
Christopher Hailey
Sr. Software Engineer
Maxim Systems
::::::::::::::
loadext.c.patch
::::::::::::::
*** ./src/loadext.c.orig 2007-07-22 00:11:35.000000000 -0700
--- ./src/loadext.c 2007-07-22 00:12:07.000000000 -0700
***************
*** 292,298 ****
handle = sqlite3OsDlopen(zFile);
if( handle==0 ){
if( pzErrMsg ){
! *pzErrMsg = sqlite3_mprintf("unable to open shared library [%s]", zFile);
}
return SQLITE_ERROR;
}
--- 292,298 ----
handle = sqlite3OsDlopen(zFile);
if( handle==0 ){
if( pzErrMsg ){
! *pzErrMsg = sqlite3_mprintf("unable to open shared library [%s]: %s", zFile,dlerror());
}
return SQLITE_ERROR;
|
|
2539 |
code
|
active
|
2007 Jul
|
anonymous
|
|
2007 Sep
|
|
2
|
2
|
WinCE: Temporary etilqs_ files are not removed from temporary folder
|
edit |
Hi, when temporary etilqs_* files are created during SQLite work on Windows CE devices, they are not removed at all.
Temporary folder at CE devices: /Application Data/Volatile
I've research that it winClose(os_win.c) function has been changed at do not remove this file, assuming it to be removed at winceDestroyLock(os_win.c), so if no lock was happened then files will stay here forever.
Has fixed it in my local copy, with hope that it will be fixed when new cool versions of SQLite will be available.
My fix at os_win.c:
static int winClose(OsFile **pId){
winFile *pFile;
int rc = 1;
if( pId && (pFile = (winFile*)*pId)!=0 ){
int rc, cnt = 0;
OSTRACE2("CLOSE %d\n", pFile->h);
do{
rc = CloseHandle(pFile->h);
}while( rc==0 && cnt++ < MX_CLOSE_ATTEMPT && (Sleep(100), 1) );
#if OS_WINCE
winceDestroyLock(pFile);
// fix begin
if( pFile->zDeleteOnClose ){
DeleteFileW(pFile->zDeleteOnClose);
sqliteFree(pFile->zDeleteOnClose);
}
// fix end
#endif
OpenCounter(-1);
sqliteFree(pFile);
*pId = 0;
}
return rc ? SQLITE_OK : SQLITE_IOERR;
}
Thanks,
Fedor |
2007-Jul-28 16:41:41 by anonymous:
The solution is to revert checkin 3836 and re-open ticket #2294.
Looking at the wince locking mechanism, the only time we ever use the zDeleteOnClose flag is when we've opened a database for exclusive access in sqlite3WinOpenExclusive. To save time and resources (and because its not necessary) we never bother creating a locking mechanism for exclusively-opened files. So pFile->hMutex is NULL when hitting winceDestroyLock(), and the file is never deleted.
Is it possible that the original poster of #2294 was trying to close the same connection on multiple threads at the same time?
2007-Jul-31 05:32:39 by anonymous:
This is actually a duplicate of #2533
2007-Sep-21 14:20:05 by anonymous:
So when the fix of [3836]
was applied, the code to delete the file was only put in the section that is called when we have a mutex. I wonder, if the deletion of the file should also take place if there was no mutex. Works for me at least:
static void winceDestroyLock(winFile *pFile){
if (pFile->hMutex){
/* Acquire the mutex */
winceMutexAcquire(pFile->hMutex);
/* The following blocks should probably assert in debug mode, but they
are to cleanup in case any locks remained open */
if (pFile->local.nReaders){
pFile->shared->nReaders --;
}
if (pFile->local.bReserved){
pFile->shared->bReserved = FALSE;
}
if (pFile->local.bPending){
pFile->shared->bPending = FALSE;
}
if (pFile->local.bExclusive){
pFile->shared->bExclusive = FALSE;
}
/* De-reference and close our copy of the shared memory handle */
UnmapViewOfFile(pFile->shared);
CloseHandle(pFile->hShared);
* if( pFile->zDeleteOnClose ){
* DeleteFileW(pFile->zDeleteOnClose);
* sqliteFree(pFile->zDeleteOnClose);
* pFile->zDeleteOnClose = 0;
* }
/* Done with the mutex */
winceMutexRelease(pFile->hMutex);
CloseHandle(pFile->hMutex);
pFile->hMutex = NULL;
}
+ else
+ {
+ if( pFile->zDeleteOnClose ){
+ DeleteFileW(pFile->zDeleteOnClose);
+ sqliteFree(pFile->zDeleteOnClose);
+ pFile->zDeleteOnClose = 0;
+ }
+ }
}
The code marked with * was put there in |
|
2530 |
code
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
2
|
3
|
Unable to write to windows share, even with exclusive lock
|
edit |
It has been mentioned that the file locking does not work on windows shared network drives (Samba or SMB drives from Windows or Linux). It seems that an exclusive lock should be a workaround for this problem if you need to write to a shared drive. Currently a more complicated locking is being attempted and failing on network drives.
With an exclusive lock, SQLite could resort to simply holding a open write or append enabled file handle to the database as a more primitive locking system that is more likely to work on network drive. No other process could open the database but that would be expected with an exclusive lock. The following case should then function:
grudy@gamma:~$ mount | grep Files
//winserver/FileDump on /mnt/Files type cifs (rw,mand,noexec,nosuid,nodev)
grudy@gamma:~$ touch /mnt/Files/i_have_write_permissions.txt; rm /mnt/Files/i_have_write_permissions.txt
grudy@gamma:~$ sqlite3 /mnt/Files/foo.sqlite
SQLite version 3.3.17
Enter ".help" for instructions
sqlite> PRAGMA locking_mode = EXCLUSIVE;
exclusive
sqlite> create table bar (foobar);
SQL error: database is locked
sqlite>
|
|
2520 |
new
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
4
|
1
|
User defined aggregate functions are not reentrant
|
edit |
When an aggregate function is defined using sqlite3_create_function, it is not possible to execute any sql statement inside the step part or the finalizer. This is due to the fact that aggregate functions are not reentrant. |
2007-Jul-20 02:32:36 by anonymous:
related: Ticket #2242: sqlite3 authorizer is not reentrant |
|
2517 |
code
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
dflam
|
1
|
1
|
exception on reading text in vista but not xp
|
edit |
My companies sqlite 3.1 db works perfectly on Win XP but when we moved to Vista (I'm using Vista 64)it is trowing an exception when I access a text field that contains this data:
'A/C Pressure Sensor, raw1 = A/C on, 0 = A/C off (A/C status determines which IACTx cell is used)'
Interestingly when I view data I've inserted using sqliteman3 it has unprintable characters added to it.
(A/C status determines which IACTx cell is used)9
If I define the field as Char[512] this artifact goes away. But reading your literature this isn't supposed to make a difference because everything is char.
I've changed the values in the error column, but the error seems to be depending on length rather than value.
Any help appreciatied!
Jim |
2007-Jul-19 15:13:41 by drh:
We will be better able to help you with your problem on
the SQLite mailing list.
See http://www.sqlite.org/support.html for instructions
on joining the mailing list. |
|
2512 |
code
|
active
|
2007 Jul
|
shess
|
|
2007 Jul
|
|
1
|
1
|
FTS virtual table name quoting problem
|
edit |
All table names should be quoted in the FTS module code.
with TRACE enabled in ext/fts2/fts2.c:
sqlite> create virtual table "a b c" using fts2 (t);
FTS2 Create
FTS2 sql: CREATE TABLE main.a b c_content(c0t)
SQL error: vtable constructor failed: a b c
|
2007-Jul-18 06:44:21 by anonymous:
A similar problem shows if a FTS column has the same name as the FTS table:
CREATE VIRTUAL TABLE a USING fts2 (a);
Returns "vtable constructor failed: a.". |
|
2511 |
code
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
drh
|
3
|
2
|
Inconsistent Pragma output
|
edit |
Pragma output is inconsistent when setting the value. Most do not generate any output and silently set the value, while others generate a singleton row with the set value. Here is a list of pragmas that generate output while setting the values:
sqlite> PRAGMA locking_mode = NORMAL;
normal
sqlite> PRAGMA max_page_count = 100000;
100000
The following do not generate any output upon query:
PRAGMA case_sensitive_like;
PRAGMA incremental_vacuum;
Sqlite was built from almagamation using the following configuration flags: --enable-threadsafe --disable-tcl --enable-tempstore |
|
2510 |
code
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
1
|
Vacuum modified FTS2 rowids
|
edit |
VACUUM modifies FTS2 rowids. Here is the test:
drop table if exists a;
create virtual table a using fts2 (t);
insert into a (t) values ('one');
insert into a (t) values ('two');
insert into a (t) values ('three');
select rowid, * from a;
delete from a where t = 'two';
vacuum;
select rowid, * from a;
Unfortunately there is no workaround since table a is auto-generated by the FTS2 module. |
2007-Jul-17 14:05:58 by anonymous:
http://www.sqlite.org/cvstrac/chngview?cn=4157
2007-Jul-17 14:24:29 by anonymous:
Yes, this behavior has been recently documented, but there is no user workaround like PRIMARY KEY for FTS2 rowids. Therefore I consider this as a bug which should be fixed in fts2.c.
2007-Jul-17 14:55:57 by anonymous:
Should virtual tables be VACUUMable? What exactly is being vacuumed here - an internal table?
2007-Jul-17 16:34:55 by shess:
I agree, I think this is a bug. Rather severe, too, the entire fts system implicitely depends on rowids not changing, this means that vacuum will break fts tables (fts1 or fts2).
drop table if exists t;
create virtual table t using fts2;
insert into t (content) values ('This is a test');
insert into t (content) values ('This is a string');
insert into t (content) values ('That was a test');
insert into t (content) values ('A random string');
select content from t where t MATCH 'test';
delete from t where content = 'This is a string';
vacuum;
select content from t where t MATCH 'test';
The first select outputs 'This is a test' and 'That was a test'. The second select outputs 'This is a test', and 'A random string'.
2007-Jul-17 17:27:21 by anonymous:
This patch seems to address the FTS2 VACUUM problem and passes all fts2 tests.
It adds an INTEGER PRIMARY KEY docid column to the hidden %_content table.
Note: this new table format is not backwards compatible with existing FTS2 databases.
-Joe Wilson
Index: ext/fts2/fts2.c
===================================================================
RCS file: /sqlite/sqlite/ext/fts2/fts2.c,v
retrieving revision 1.40
diff -u -3 -p -r1.40 fts2.c
--- ext/fts2/fts2.c 2 Jul 2007 10:16:50 -0000 1.40
+++ ext/fts2/fts2.c 17 Jul 2007 17:19:49 -0000
@@ -1769,9 +1769,9 @@ typedef enum fulltext_statement {
*/
static const char *const fulltext_zStatement[MAX_STMT] = {
/* CONTENT_INSERT */ NULL, /* generated in contentInsertStatement() */
- /* CONTENT_SELECT */ "select * from %_content where rowid = ?",
+ /* CONTENT_SELECT */ "select * from %_content where docid = ?",
/* CONTENT_UPDATE */ NULL, /* generated in contentUpdateStatement() */
- /* CONTENT_DELETE */ "delete from %_content where rowid = ?",
+ /* CONTENT_DELETE */ "delete from %_content where docid = ?",
/* BLOCK_INSERT */ "insert into %_segments values (?)",
/* BLOCK_SELECT */ "select block from %_segments where rowid = ?",
@@ -1860,14 +1860,14 @@ static struct fulltext_vtab *cursor_vtab
static const sqlite3_module fts2Module; /* forward declaration */
/* Return a dynamically generated statement of the form
- * insert into %_content (rowid, ...) values (?, ...)
+ * insert into %_content (docid, ...) values (?, ...)
*/
static const char *contentInsertStatement(fulltext_vtab *v){
StringBuffer sb;
int i;
initStringBuffer(&sb);
- append(&sb, "insert into %_content (rowid, ");
+ append(&sb, "insert into %_content (docid, ");
appendList(&sb, v->nColumn, v->azContentColumn);
append(&sb, ") values (?");
for(i=0; i<v->nColumn; ++i)
@@ -1878,7 +1878,7 @@ static const char *contentInsertStatemen
/* Return a dynamically generated statement of the form
* update %_content set [col_0] = ?, [col_1] = ?, ...
- * where rowid = ?
+ * where docid = ?
*/
static const char *contentUpdateStatement(fulltext_vtab *v){
StringBuffer sb;
@@ -1893,7 +1893,7 @@ static const char *contentUpdateStatemen
append(&sb, v->azContentColumn[i]);
append(&sb, " = ?");
}
- append(&sb, " where rowid = ?");
+ append(&sb, " where docid = ?");
return stringBufferData(&sb);
}
@@ -2027,15 +2027,15 @@ static int sql_step_leaf_statement(fullt
return rc;
}
-/* insert into %_content (rowid, ...) values ([rowid], [pValues]) */
-static int content_insert(fulltext_vtab *v, sqlite3_value *rowid,
+/* insert into %_content (docid, ...) values ([docid], [pValues]) */
+static int content_insert(fulltext_vtab *v, sqlite3_value *docid,
sqlite3_value **pValues){
sqlite3_stmt *s;
int i;
int rc = sql_get_statement(v, CONTENT_INSERT_STMT, &s);
if( rc!=SQLITE_OK ) return rc;
- rc = sqlite3_bind_value(s, 1, rowid);
+ rc = sqlite3_bind_value(s, 1, docid);
if( rc!=SQLITE_OK ) return rc;
for(i=0; i<v->nColumn; ++i){
@@ -2047,7 +2047,7 @@ static int content_insert(fulltext_vtab
}
/* update %_content set col0 = pValues[0], col1 = pValues[1], ...
- * where rowid = [iRowid] */
+ * where docid = [iRowid] */
static int content_update(fulltext_vtab *v, sqlite3_value **pValues,
sqlite_int64 iRowid){
sqlite3_stmt *s;
@@ -2075,7 +2075,7 @@ static void freeStringArray(int nString,
free((void *) pString);
}
-/* select * from %_content where rowid = [iRow]
+/* select * from %_content where docid = [iRow]
* The caller must delete the returned array and all strings in it.
* null fields will be NULL in the returned array.
*
@@ -2101,10 +2101,10 @@ static int content_select(fulltext_vtab
values = (const char **) malloc(v->nColumn * sizeof(const char *));
for(i=0; i<v->nColumn; ++i){
- if( sqlite3_column_type(s, i)==SQLITE_NULL ){
+ if( sqlite3_column_type(s, i+1)==SQLITE_NULL ){
values[i] = NULL;
}else{
- values[i] = string_dup((char*)sqlite3_column_text(s, i));
+ values[i] = string_dup((char*)sqlite3_column_text(s, i+1));
}
}
@@ -2120,7 +2120,7 @@ static int content_select(fulltext_vtab
return rc;
}
-/* delete from %_content where rowid = [iRow ] */
+/* delete from %_content where docid = [iRow ] */
static int content_delete(fulltext_vtab *v, sqlite_int64 iRow){
sqlite3_stmt *s;
int rc = sql_get_statement(v, CONTENT_DELETE_STMT, &s);
@@ -2870,7 +2870,7 @@ static int fulltextCreate(sqlite3 *db, v
if( rc!=SQLITE_OK ) return rc;
initStringBuffer(&schema);
- append(&schema, "CREATE TABLE %_content(");
+ append(&schema, "CREATE TABLE %_content(docid INTEGER PRIMARY KEY, ");
appendList(&schema, spec.nColumn, spec.azContentColumn);
append(&schema, ")");
rc = sql_exec(db, spec.zDb, spec.zName, stringBufferData(&schema));
@@ -3731,8 +3731,8 @@ static int fulltextFilter(
TRACE(("FTS2 Filter %p\n",pCursor));
- zSql = sqlite3_mprintf("select rowid, * from %%_content %s",
- idxNum==QUERY_GENERIC ? "" : "where rowid=?");
+ zSql = sqlite3_mprintf("select * from %%_content %s",
+ idxNum==QUERY_GENERIC ? "" : "where docid=?");
sqlite3_finalize(c->pStmt);
rc = sql_prepare(v->db, v->zDb, v->zName, &c->pStmt, zSql);
sqlite3_free(zSql);
2007-Jul-18 00:13:56 by shess:
BTW, AFAICT this only happens for sqlite3.4. Older versions don't seem to have the problem.
2007-Jul-18 01:31:49 by anonymous:
The rowid changing after VACUUM predates 3.4.0...
SQLite version 3.3.7
Enter ".help" for instructions
sqlite> CREATE TABLE t(a);
sqlite> INSERT INTO "t" VALUES('one');
sqlite> INSERT INTO "t" VALUES('two');
sqlite> INSERT INTO "t" VALUES('three');
sqlite> select rowid, * from t;
1|one
2|two
3|three
sqlite> delete from t where a = 'one';
sqlite> select rowid, * from t;
2|two
3|three
sqlite> vacuum;
sqlite> select rowid, * from t;
1|two
2|three
SQLite version 3.2.0
Enter ".help" for instructions
sqlite> CREATE TABLE t(a);
sqlite> INSERT INTO "t" VALUES('one');
sqlite> INSERT INTO "t" VALUES('two');
sqlite> INSERT INTO "t" VALUES('three');
sqlite> select rowid, * from t;
1|one
2|two
3|three
sqlite> delete from t where a = 'one';
sqlite> select rowid, * from t;
2|two
3|three
sqlite> vacuum;
sqlite> select rowid, * from t;
1|two
2|three
2007-Jul-18 15:59:24 by anonymous:
As you may know, INTEGER PRIMARY KEY indexes are the ROWID, so I must supect they would change after a VACUUM.
The best workaround is to put docid as INTEGER, then adding a PRIMARY KEY index for the docid column. |
|
2509 |
code
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
1
|
SQLITE_DATE
|
edit |
SELECT CAST(MyDate AS DATE), CAST(MyTime AS TIME) FROM MyData
I hope, it will result/return DATE, TIME.
Please support to SQLITE_DATE and SQLITE_TIME.
Thanks. |
|
2508 |
code
|
active
|
2007 Jul
|
anonymous
|
|
2007 Dec
|
|
1
|
1
|
utf8ToUnicode() does not work on some WinCE devices
|
edit |
On some WinCE devices first call to MultiByteToWideChar() in utf8ToUnicode() always fails. Tried calling GetLastError() after it fails and it returns error code 87 -- ERROR_INVALID_PARAMETER .
To fix this had to change code page from CP_UTF8 to CP_ACP -- no idea why this works.
Original utf8ToUnicode()
static WCHAR *utf8ToUnicode(const char *zFilename)
{
int nChar;
WCHAR *zWideFilename;
nChar = MultiByteToWideChar(CP_UTF8, 0, zFilename, -1, NULL, 0);
zWideFilename = sqliteMalloc( nChar*sizeof(zWideFilename[0]) );
if( zWideFilename==0 ){
return 0;
}
nChar = MultiByteToWideChar(CP_UTF8, 0, zFilename, -1, zWideFilename, nChar);
if( nChar==0 ){
sqliteFree(zWideFilename);
zWideFilename = 0;
}
return zWideFilename;
}
Fixed utf8ToUnicode()
static WCHAR *utf8ToUnicode(const char *zFilename)
{
int nChar;
WCHAR *zWideFilename;
nChar = MultiByteToWideChar(CP_ACP, 0, zFilename, -1, NULL, 0);
if( nChar == 0 )
{
DWORD dwError = GetLastError();
OSTRACE2("MultiByteToWideChar() failed, last error: %d\n", dwError);
return 0;
}
zWideFilename = sqliteMalloc( nChar*sizeof(zWideFilename[0]) );
if( zWideFilename==0 ){
return 0;
}
nChar = MultiByteToWideChar(CP_ACP, 0, zFilename, -1, zWideFilename, nChar);
if( nChar==0 ){
sqliteFree(zWideFilename);
zWideFilename = 0;
}
return zWideFilename;
}
|
2007-Jul-17 23:56:10 by anonymous:
unicodeToUtf8() needs to be fixed the same way.
Before:
static char *unicodeToUtf8(const WCHAR *zWideFilename){
int nByte;
char *zFilename;
nByte = WideCharToMultiByte(CP_UTF8, 0, zWideFilename, -1, 0, 0, 0, 0);
zFilename = sqliteMalloc( nByte );
if( zFilename==0 ){
return 0;
}
nByte = WideCharToMultiByte(CP_UTF8, 0, zWideFilename, -1, zFilename, nByte,
0, 0);
if( nByte == 0 ){
sqliteFree(zFilename);
zFilename = 0;
}
return zFilename;
}
After:
static char *unicodeToUtf8(const WCHAR *zWideFilename){
int nByte;
char *zFilename;
nByte = WideCharToMultiByte(CP_ACP, 0, zWideFilename, -1, NULL, 0, NULL, NULL);
if ( nByte == 0 )
{
DWORD dwError = GetLastError();
OSTRACE2("WideCharToMultiByte() failed, last error = %d\n", dwError);
return 0;
}
zFilename = sqliteMalloc( nByte );
if( zFilename==0 ){
return 0;
}
nByte = WideCharToMultiByte(CP_ACP, 0, zWideFilename, -1, zFilename, nByte,
0, 0);
if( nByte == 0 ){
sqliteFree(zFilename);
zFilename = 0;
}
return zFilename;
}
Note that while original code with CP_UTF8 works on Windows and SOME WinCE devices, this modified code works well and Windows and all WinCE devices I've tested so far.
2007-Jul-18 16:01:21 by anonymous:
Why not using the conversions from SQLite internals ? It can change a UTF-16 to UTF-8 and vice-versa.
Or using UTF-16 variants in windows ce should be the best case.
2007-Aug-09 20:47:04 by anonymous:
Why not using the conversions from SQLite internals ? It can change a UTF-16 to UTF-8 and vice-versa.
Or using UTF-16 variants in windows ce should be the best case.
Not so simple. unicodeToUtf8() is used a lot internally regardless of what whether you use UTF-16 or UTF-8 yourself. For example, unicodeToUtf8() is used by sqlite3WinTempFileName() which is in turn used by sqlite3PagerOpentemp() -- I think you get the idea.
2007-Dec-20 00:29:33 by anonymous:
We've found that using CP_UTF8 fails on WinCE kernels that don't include SYSGEN_CORELOC (http://msdn2.microsoft.com/en-us/library/ms903883.aspx). To make the code handle any device it should be changed to:
static WCHAR *utf8ToUnicode(const char *zFilename)
{
int nChar;
WCHAR *zWideFilename;
nChar = MultiByteToWideChar(CP_UTF8, 0, zFilename, -1, NULL, 0);
if( nChar == 0 )
{
nChar = MultiByteToWideChar(CP_ACP, 0, zFilename, -1, NULL, 0);
if( nChar == 0 )
{
DWORD dwError = GetLastError();
OSTRACE2("MultiByteToWideChar() failed, last error: %d\n", dwError);
return 0;
}
}
zWideFilename = sqliteMalloc( nChar*sizeof(zWideFilename[0]) );
if( zWideFilename==0 )
{
return 0;
}
nChar = MultiByteToWideChar(CP_UTF8, 0, zFilename, -1, zWideFilename, nChar);
if( nChar==0 )
{
nChar = MultiByteToWideChar(CP_ACP, 0, zFilename, -1, zWideFilename, nChar);
if( nChar==0 )
{
sqliteFree(zWideFilename);
zWideFilename = 0;
}
}
return zWideFilename;
}
|
|
2506 |
new
|
active
|
2007 Jul
|
anonymous
|
|
2008 Jan
|
|
3
|
2
|
New API to retrieve ROWID from SQLite3_stmt structire
|
edit |
Is it too much trouble to allow an API to retrieve ROWID for non-aggeregate queries directly from SQLite3_stmt structire? It would be very useful to create updatable non aggregate query results for situations when actually internal PK (ROWID) is not gived explicitly in SQL statement nor actual table's PK (if any). |
SELECT queries that join two or more tables together
would be a problem also.
2007-Jul-16 16:51:18 by anonymous:
It's more of a multi-step process. First you have to enumerate the open cursors on the sqlite3_stmt object. Then you need to resolve the table each cursor goes to, and then fetch the rowid for each active cursor. Of course this may get confusing when you've joined a table onto itself.
2008-Jan-19 10:32:59 by anonymous:
This is far to old active ticket. Is it in consideration to be implemented in the near future? |
|
2503 |
code
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
3
|
4
|
sqlite3PagerReleaseMemory does not decrement page count
|
edit |
When cached pages are released by sqlite3PagerReleaseMemory the number of pages (pPager->nPage) is not decremented.
This also subsequently affects the maximum value at pPager->nMaxPage.
This does not affect the operation of sqlite (but does upset my statistic gathering).
Although only tested with 3.3.8, the problem does not appear to have been corrected in version 3.4.0 |
Actually this will affect the handling of cache_size as the pager will think there are more pages cached than is the case, and may unnecessarily release some.
2007-Jul-18 15:54:29 by anonymous:
Do you have a simple test case that demonstrates this?
Put a print statement in pager.c if necessary. |
|
2498 |
code
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
3
|
2
|
sqlite memory org on linux
|
edit |
(related ticket #2473)...
he sample programme that I run(wrote) in tty1 and there I operate the command of ps at tty2, there seems two items from the programme of ps command.
This error was not at the version 3.3.13 but now it is happening at sqlite versions
although i change nothing from the programme, If I turn to old versions, there is seen only one item again.
When I upgrade to version 3.3.13 or later,
there is seen two items again
Is it normal or there is any mistake?
(excuse my poor english) |
2007-Jul-11 16:44:22 by anonymous:
So you are seeing 2 processes instead of 1 on Linux?
Linux 2.4 and earlier kernels show threads as seperate processes with unique process IDs. Is your program creating any threads?
The only place where SQLite creates threads is the function below - but it joins with the thread right away.
/*
** This procedure attempts to determine whether or not threads
** can override each others locks then sets the
** threadsOverrideEachOthersLocks variable appropriately.
*/
static void testThreadLockingBehavior(int fd_orig){
int fd;
struct threadTestData d[2];
pthread_t t[2];
fd = dup(fd_orig);
if( fd<0 ) return;
memset(d, 0, sizeof(d));
d[0].fd = fd;
d[0].lock.l_type = F_RDLCK;
d[0].lock.l_len = 1;
d[0].lock.l_start = 0;
d[0].lock.l_whence = SEEK_SET;
d[1] = d[0];
d[1].lock.l_type = F_WRLCK;
pthread_create(&t[0], 0, threadLockingTest, &d[0]);
pthread_create(&t[1], 0, threadLockingTest, &d[1]);
pthread_join(t[0], 0);
pthread_join(t[1], 0);
close(fd);
threadsOverrideEachOthersLocks = d[0].result==0 && d[1].result==0;
}
If you post a small C program demonstrating what you're seeing, someone may be able to offer a suggestion.
2007-Jul-11 16:47:10 by anonymous:
I suppose it's not inconceivable that the join failed. Perhaps these pthread_join calls' return codes should be examined for errors.
2007-Jul-11 18:53:36 by anonymous:
If you're playing games with tty's and you've got an early Linux 2.6 kernel, it's possible that processes are dying because of http://lkml.org/lkml/2004/10/21/119. It was, last I checked, fixed in 2.6.10.
The SIGHUP being generated might also interfer with a pthread_join() , although pthread_join() doesn't say anything about ever generating EINTR ...
c.
2007-Jul-12 06:12:28 by anonymous:
my example program is very simple, i not use threading-multithreading structure...
If I turn to old versions of sqlite, there is seen only one item again, when I upgrade to version 3.3.13 or later, there is seen two items again Is it.
note:
/lib/libpthread.so.0 linked to /lib/libpthread-0.10.so (size 55468 byte)
2007-Jul-12 11:36:37 by anonymous:
Your description of the problem isn't clear enough, so the answers you're getting are just guesses.
You may have more luck by describing the problem (with as much detail as possible) in your native language and hoping someone in the SQLite community can add a translation. I know you're doing your best with the english you speak, but it's not working well enough for someone to help with your problem.
Adding code samples and command-line output would also help considerably, since that sort of this is mostly language independent. |
|
2496 |
code
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
5
|
4
|
"No such column" error should include table information
|
edit |
It'd be nice if the "no such column" error included the table/view that SQLite was searching for the column.
no such column: ChecklistID
Thanks,
Sam |
|
2491 |
code
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
1
|
Mingw Warnings w/ 3.4.0 Amalgamation
|
edit |
When compiling the 3.4.0 amalgamation sqlite3.c file w/ no defines, you get the following warnings:
sqlite3/sqlite3.c: In function `sqlite3BtreeFindCell':
sqlite3/sqlite3.c:23249: warning: unused variable `data'
sqlite3/sqlite3.c: In function `vxprintf':
sqlite3/sqlite3.c:8488: warning: 'xtype' might be used uninitialized in this function
sqlite3/sqlite3.c: In function `sqlite3BtreeOpen':
sqlite3/sqlite3.c:19488: warning: 'nameLen' might be used uninitialized in this function
sqlite3/sqlite3.c: In function `getOverflowPage':
sqlite3/sqlite3.c:25386: warning: 'rc' might be used uninitialized in this function
sqlite3/sqlite3.c: In function `sqlite3Select':
sqlite3/sqlite3.c:56300: warning: 'pEList' might be used uninitialized in this function
sqlite3/sqlite3.c:56301: warning: 'pTabList' might be used uninitialized in this function
sqlite3/sqlite3.c: At top level:
sqlite3/sqlite3.c:16020: warning: 'sqlite3GenericAllocationSize' defined but not used
sqlite3/sqlite3.c:6188: warning: 'sqlite3Utf16Substr' declared `static' but never defined
sqlite3/sqlite3.c:6307: warning: 'sqlite3Get2byte' declared `static' but never defined
sqlite3/sqlite3.c:6309: warning: 'sqlite3Put2byte' declared `static' but never defined
sqlite3/sqlite3.c:23248: warning: 'sqlite3BtreeFindCell' defined but not used
sqlite3/sqlite3.c:63547: warning: 'sqlite3ParserAlloc' defined but not used
sqlite3/sqlite3.c:63673: warning: 'sqlite3ParserFree' defined but not used
sqlite3/sqlite3.c:65286: warning: 'sqlite3Parser' defined but not used
I know the uninitialized warnings are false warnings but the defined functions that aren't used seem to be an error in building the amalgamation. |
|
2488 |
new
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
5
|
4
|
autosize on column output mode in sqlite3 program
|
edit |
It would be nice if sqlite3 program has a autosizecolumn mode for displaying queries, because it truncates values, and to calculate and use .width size for each column is tedious. |
2007-Jul-07 11:42:03 by drh:
In order to do this, we would have to either run the
query twice or load the entire result set into memory.
Otherwise, there would be no way to determine the longest
element of each column. Neither approach seems attractive
for large and complex queries.
2007-Jul-28 07:05:56 by anonymous:
every query should internally detect the longest column sizes and a new command should enable the user to set these values for any repetition or similar queries. At the end the queries run twice or more but only the first trial would have cause irritations on output. And this solution should be easy enough to implement it.
Even the core of sqlite could calculate the maximum length of each column and a new API function could make this available.
It would be really nice to get such an enhancement!
2007-Jul-28 18:37:36 by anonymous:
while you don't move to next row, sqlite doesn't know the contents, so it will be impossible to do, only if you cache the text entirely in memory, but this is ugly, imagine a 1GB recordset into RAM...
have you tried .mode tabs ? here, i have correct column width |
|
2487 |
code
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
1
|
1
|
SQLite database locked error on NFS mounted home dir
|
edit |
I have a c program using the provided API. My home directory is NFS mounted, Im using SQLite 3.3.17. I open a new database using "sqlite3_open", then strcpy () a SQL command to create a table, and run "sqlite3_exec" with this string. I get a return code of 5=database locked. I then tried to manually (command line using sqlite3) create a table within a database in my home dir, that fails too.
===========
x@y> sqlite3 db2
SQLite version 3.3.17
Enter ".help" for instructions
sqlite> create table test (Lastname varchar);
SQL error: database is locked
sqlite>
==============
If I try this on my local machine (a Mac), it works fine, but I need it to work in my home directory mounted via NFS as that is where the output of our program goes |
2007-Jul-06 19:04:15 by anonymous:
If you're using a Mac, compile sqlite with SQLITE_ENABLE_LOCKING_STYLE in os_unix.c
2007-Jul-07 11:51:10 by drh:
This is a problem with your NFS implementation - it does not appear
to support posix advisory locking. There is nothing much that
SQLite can do about this.
Anonymous above suggests making use of the dot-locking mechanism
contributed by Apple. This might be an effective work-around.
But remember that there is performance impact. Also remember that
an SQLite database that uses dot-locking is subtly imcompatible
with a standard SQLite database. The file format itself is the
same, but if two processes try to access the database file at the
same time and one uses dot-locks and the other uses posix advisory
locks, you will end up with corruption.
2007-Jul-07 12:44:09 by anonymous:
It's very odd that Apple does not fix their Mac OSX POSIX locks for NFS given their resources. |
|
2484 |
new
|
active
|
2007 Jul
|
anonymous
|
|
2007 Jul
|
|
5
|
4
|
Support for RETURNING
|
edit |
I was recently trying to get HTSQL (http://htsql.org) to work with SQLite, especially since it'd be nice to work out-of-the-box with Python. One of the hiccups was the lack of a RETURNING clause, this is especially important once you have auto-incremented keys. For example..
INSERT INTO TABLE some_table (a_column) values ('value')
RETURNING (serial_column);
This acts like a SELECT following the INSERT returning the requested columns on the affected rows. It is quite helpful for cases like UPDATE or DELETE when more than one row is affected. While this feature isn't critical for SQLite, it reduces client-side code significantly. Thank you for your kind consideration. |
|
2479 |
code
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
1
|
WinCE regression on some systems. Any db open fails.
|
edit |
Because Windows CE is a modular system, meaning many parts of it can be optionally ommited by the system builder, some don't include the CP_UTF8 conversion algorithms for MultiByteToWideChar and family. I believe Windows 95 and early 98 systems can also lack this encoding if not updated with a later Internet Explorer version.
Solution is to just use the sqlite internal functions that already know how to do the same thing.
Attached is an untested patch to os_win.c (I don't have a windows machine nor a cross-compiler set up) to show where the problem is and a possible (sub-optimal) solution.
I believe the right thing to do would be to just drop the utf8ToUnicode and unicodeToUtf8 functions, add the sqlite3Utf8to16 equivalent to utf.c and use them instead.
~Nuno Lucas |
2007-Jun-29 14:54:11 by anonymous:
The title is wrong. It should say "Any db open using the UTF-8 API", as using the open16 API will work. |
|
2476 |
todo
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
4
|
3
|
SQLite3 ignores ORDER BY clause when performing SELECT ... GROUP BY
|
edit |
I found that sqlite3 ignores the ORDER BY clause when performing SELECT ... GROUP BY ... ORDER BY ...
Table schema:
CREATE TABLE events (
id integer not null primary key,
title integer
);
Data:
Query:
SELECT title, id
FROM events
GROUP BY title
ORDER BY id ASC;
Result:
Expected result:
Note: I don't think this should even work in the first place, because id is not a grouped column, but MySQL and SQLite doesn't seem to have a problem with it. Oracle complains. |
2007-Jun-29 07:46:00 by danielk1977:
In SQL, the sorting specified by the ORDER BY clause is
performed (logically) after the grouping specified by the
GROUP BY clause. In this case a single row - the ORDER BY
clause is redundant.
So the problem is that SQLite and MySQL are implementing
the non-standard SQL extension of allowing an expression
that is neither an aggregate or a part of the GROUP BY
clause in the result-set of the SELECT in a different
way. |
|
2474 |
new
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
5
|
4
|
Multiple-record comma-delineated INSERT command
|
edit |
I believe that both MySQL and DB2 support this feature. Instead of using separate commands for multiple INSERTS, you could use one command, and delineate the separate INSERT data with commas. Having support for this type of INSERT would make migrating MySQL or DB2 files to SQLite easier.
Regular INSERT method:
INSERT INTO foo VALUES ('Title1',26,NULL);
INSERT INTO foo VALUES ('Title2',24,NULL);
INSERT INTO foo VALUES ('Title3',12,NULL);
Delineated INSERT method:
INSERT INTO foo VALUES
('Title1',26,NULL),
('Title2',24,NULL),
('Title3',12,NULL);
|
2007-Jun-29 12:32:45 by anonymous:
From the parsing point of view this is a bit interesting. Imagine the multi-insert statement is 100,000 lines long. Do you parse the entire statement for correctness first and hold this entire parsed tree in memory? Or do you begin a transaction, and try to process each sub-insert row by row and rollback if there's any error? I'd think the latter would be better from both a time and memory point of view.
Actually, this multi-insert statement could be optimized to work around the sqlite slow bulk insert issue with multiple keys. |
|
2473 |
warn
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
anonymous
|
3
|
2
|
sqlite memory org. on linux
|
edit |
i use sqlite on linux (2.4.35) and on FreePascal...
i write an simple example code on linux_&_sqlite_&_freepascal.
when working my example code on tty1, i run ps command on tty2; multiple process id showing about my example program...
my example code is very simple...
before v3.3.13 : no problem; but v3.3.17 and later is wrong...
(excuse my poor english) |
2007-Jun-28 13:10:10 by anonymous:
There is no bug mentioned in this ticket.
2007-Jun-28 14:09:36 by drh:
I think I see a hint of a bug report in the description where it
says "before v3.3.13: no problem; but v3.3.17 and later is wrong".
But that is not anything near enough information to isolate and
fix the problem.
halukduman09: Please find a friend or coworker who speaks good
English and ask that person to translate for you. We can only
help you if we can understand what you are saying. Thanks. |
|
2469 |
build
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jul
|
|
1
|
1
|
test fails on Solaris
|
edit |
I have a problem running the test suite on Solaris 9. Build was done using gcc 4.2.0. The build completes without error but many tests fail. I've created my own minimal test that exhibits the problem:
set testdir [file dirname $argv0]
source $testdir/tester.tcl
db close
file delete -force test.db test.db-journal
sqlite db test.db
do_test tdb-1 {
execsql {
PRAGMA auto_vacuum = 1;
BEGIN;
CREATE TABLE t1(a, b);
}
execsql {
COMMIT;
}
} {}
integrity_check tdb-2
finish_test
When running this test I get the following output:
tdb-1... Ok
tdb-2...
Expected: [ok]
Got: [{*** in database main ***
List of tree roots: 2nd reference to page 1
Page 3 is never used}]
Thread-specific data deallocated properly
1 errors out of 3 tests
Failures on these tests: tdb-2
This error happens on lots of, but not all, tests.
I'm happy to do whatever is necessary to help debug this.
Thanks,
Tim. |
2007-Jun-27 10:44:14 by anonymous:
Further to this, it appears to be related to gcc 4.2.0. It works fine with gcc 3.4.6.
2007-Jun-28 09:54:35 by anonymous:
Further more, it doesn't appear to be specific to Solaris. The same problem occurs on Linux with gcc 4.2.0.
So I guess the subject of this ticket should be changed to "build/test problems with gcc 4.2.0".
This is probably a significant problem - the build completes find but the resultant code is broken. People may not notice this until it's too late.
2007-Jun-28 12:24:05 by drh:
I installed gcc 4.2.0 on my SuSE linux i686 desktop and
built test harnesses under three different configurations:
gcc420 -g -O0 -Wall -fstrict-aliasing
gcc420 -g -O3 -Wall
gcc420 -g -O3 -fstrict-aliasing -fomit-frame-pointer
The first two configurations used separate source files. The
third configuration was built using the amalgamation.
I ran the "quick" test under all configurations. All tests
ran to completion with no errors.
2007-Jun-28 13:22:20 by anonymous:
Two ideas:
1. Compile with gcc 4.2.0 using -O0 instead of -O2 and see what happens. Disable any other optimizations you may have.
2. Run truss with full read/write buffer display on the gcc 3.4.6 compiled testfixture running your simple test case and compare its output to the gcc 4.2.0 compiled test case.
2007-Jul-01 19:00:40 by anonymous:
I've done tests with optimisation, and this appears to tickle the problem.
With no optimisation, -O, -O0, -O1 and -03 it works.
With -O2 and -Os it's broken.
I was compiling with -O2 when I submitted the initial report.
Tim.
2007-Jul-01 19:54:54 by drh:
I can reproduce the problem now on Linux when compiling
as follows:
gcc420 -g -O2 -Wall
2007-Jul-01 21:50:42 by drh:
This appears to be a bug in GCC 4.3.0. A work-around is to
compile with the -fno-tree-vrp option.
GCC appears to miscompile a single loop within the logic
that implements the integrity_check PRAGMA. The code that
gets miscompiled is in the file vdbe.c (lines numbers added):
4308 for(j=0; j<nRoot; j++){
4309 aRoot[j] = pTos[-j].u.i;
4310 }
4311 aRoot[j] = 0;
It is line 4309 that appears to be miscompiled. The pTos
pointer points to the top of the stack in virtual machine.
The loop attempts to load the array with integer values that
have been pushed onto the stack.
Running this code in GDB and setting a breakpoint on line
4311, we get the following output:
Breakpoint 1, sqlite3VdbeExec (p=0x80ca708) at ../sqlite/src/vdbe.c:4311
4311 aRoot[j] = 0;
(gdb) print nRoot
$1 = 2
(gdb) print aRoot[0]@2
$2 = {1, 1}
(gdb) print pTos[0].u.i
$3 = 1
(gdb) print pTos[-1].u.i
$4 = 2
As you can see above, two values have been pushed onto
the virtual machine stack. (nRoot==2). But instead of
loading each value into aRoot[], the top-most value is
loaded multiple times. aRoot[] ends up holding {1, 1}
instead of the correct values of {1, 2}.
I will submit a bug report to GCC shortly...
2007-Jul-01 22:09:23 by drh:
Bug reported filed with GCC:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32575
2007-Jul-05 13:33:09 by anonymous:
Could the test case at the top of this ticket be checked in with a comment pointing to this ticket? Other people may be experiencing this problem and not realizing it.
2007-Jul-21 10:00:56 by anonymous:
I can confirm this is still broken with gcc 4.2.1 and sqlite 3.4.1.
Tim.
2007-Jul-21 12:53:40 by drh:
The bug is in GCC, not SQLite The work-around is to compile without
optimization. See the comments above.
2007-Jul-21 14:10:43 by anonymous:
The problem is that this is a compiler in widespread use, and you'll likely see randomly corrupted databases in the wild as result of this.
Are you able to create a smaller test case so that GCC will still exhibit this bug? (Assuming it is verified to be a compiler bug).
2007-Jul-21 16:12:42 by anonymous:
Yup - I know it's a GCC bug. I just wanted to note that the recent gcc 4.2.1 release doesn't fix the issue.
2007-Jul-21 18:55:33 by anonymous:
Simple way to detect if your copy of sqlite3 is broken:
echo "CREATE TABLE t(x); pragma integrity_check;" | ./sqlite3
If it is broken it will output:
*** in database main ***
List of tree roots: 2nd reference to page 1
Page 2 is never used
If fine:
ok
2007-Jul-21 19:20:07 by anonymous:
This patch works around the problem with gcc-4.2.1 and sqlite 3.4.1 and allows "make test" to run cleanly. I'd appreciate if you'd apply it as gcc 4.2.x is a widely distributed compiler, and the default sqlite3 ./configure build will result in this bug.
Joe
RCS file: /sqlite/sqlite/src/vdbe.c,v
retrieving revision 1.636
diff -u -3 -p -r1.636 vdbe.c
--- src/vdbe.c 1 Jul 2007 21:18:40 -0000 1.636
+++ src/vdbe.c 21 Jul 2007 19:10:13 -0000
@@ -4306,7 +4306,8 @@ case OP_IntegrityCk: {
pnErr = &p->aMem[j];
assert( (pnErr->flags & MEM_Int)!=0 );
for(j=0; j<nRoot; j++){
- aRoot[j] = pTos[-j].u.i;
+ /* See Ticket #2469. Was: aRoot[j] = pTos[-j].u.i; */
+ aRoot[j] = (pTos-j)->u.i;
}
aRoot[j] = 0;
popStack(&pTos, nRoot);
2007-Jul-21 20:31:01 by anonymous:
Not verified, but these debug trace lines follow the same pattern and may be problematic under gcc 4.2.x -O2.
src/vdbe.c: fprintf(p->trace, " si:%lld", pTos[i].u.i);
src/vdbe.c: fprintf(p->trace, " i:%lld", pTos[i].u.i);
This line's code appears to be generated okay under -O2:
src/vdbe.c: nArg = pTos[-1].u.i;
2007-Jul-23 13:33:55 by anonymous:
Two other GCC 4.2.1 -O2 bug workarounds are shown below which may help in the search for the optimization bug.
Joe.
(1)
int ZZZ = 0; // must be a global variable
...
for(j=0; j<nRoot; j++){
aRoot[j] = pTos[ZZZ-j].u.i;
}
(2)
int ZZZ = 0; // must be a global variable
...
for(j=ZZZ; j<nRoot; j++){
aRoot[j] = pTos[-j].u.i;
}
|
|
2467 |
code
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
4
|
4
|
changes() not reporting correctly after DELETE FROM table
|
edit |
Similar to the problem reported in #2459, this was originally reported by someone else in the PHP manual for sqlite_changes(). I looked into the description, and produced a live example of the bug here:
The original bug description is here:
EDIT: I found this "bug" noted on the site while browsing random documentation. It seems that this is, in fact, just how the method was designed. Please do correct me if I am wrong. Also, does specifying "WHERE 1" in the "DELETE FROM" statement cause it to delete records individually? Documentation noting this is here:
|
2007-Jun-27 20:32:31 by anonymous:
yeah. delete from [table_name] drops and reconstructs the table again. |
|
2459 |
code
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
4
|
4
|
changes() not reporting correctly after "failed" multiline INSERT
|
edit |
I have described this bug at http://www.php.net/manual/en/function.sqlite-exec.php#75962. |
2007-Jun-25 23:37:22 by drh:
The bug reports says "If you run a multiline ... and there is
a SQL error in any of the lines..." but in the accompanying
example code, there are no errors. So I do not understand what
the problem is.
I do not know what SQLite function the PDO method changes()
is bound to. Let us assume that it is bound to sqlite3_changes().
In that case, it returns the number rows that changed in the
most recent SQL statement - the last line of the multiline
input. This is what SQLite is suppose to do. If you want
to know the total number of changes across all the lines in
your multiline input, then you have to call sqlite3_total_changes()
before and after the multiline SQL and take the difference.
2007-Jun-26 00:10:08 by anonymous:
The error is in the $ins_query variable. The third INSERT is incorrectly spelled as "INSECT". This will cause an error. If you correct the spelling and run the code, changes() will return the integer result "3" to indicate that 3 records have been changed.
2007-Jun-26 00:29:56 by drh:
OK. I generated the following test case:
CREATE TABLE t1(x INTEGER PRIMARY KEY, name CHAR(255));
SELECT total_changes();
INSERT INTO t1(name) VALUES('Ilia1');
INSERT INTO t1(name) VALUES('Ilia2');
INSECT INTO t1(name) VALUES('Ilia3');
SELECT total_changes(), changes();
SELECT * from t1;
Notice the changes of R->C in the last INSERT. This
script appears to do the correct thing when handed
in batch to sqlite3_exec() by the command-line shell.
0
SQL error near line 5: near "INSECT": syntax error
2|1
1|Ilia1
2|Ilia2
Can you suggest revisions
to this script that might induce the error? Do you know
how PHP implements its "changes()" method? What is the
"changes()" method suppose to show? Do you know that
the "changes()" method is implemented correctly in PHP?
2007-Jun-26 05:52:57 by anonymous:
I am not using a command-line interface, and I am not using SQLite 3 (so would sqlite3_exec and my exec operate differently?). I am running these commands from PHP on a web server.
phpinfo() returns this information:
PHP Version: |
5.1.6 |
System: |
SunOS snail 5.9 sun4u |
Server API: |
Apache |
I have created a working version of my initial example, as well as ported your example to my environment:
EDIT: I am aware that my port of your example produces a warning for "no such function". What I do not know is why; I was hoping that you could tell me if total_changes() is something supported only in a command line (TCL, C, C++, or other) environment, if it is not supported in SQLite 2.8.17, or if there is another reason you may be aware of.
EDIT2: I have provided an additional live example of what the server I'm using does with changes() when there is not an error. To clarify, if a multiline query contains no errors, changes() will show that multiple records have been changed, not just the one record affected by the last line of the statement. What I had expected is that, in this scenario, either changes() would report that there HAVE been rows changed, or that a multiline query with an error would not run, or that sqlite would undo the statements that DID execute in a multiline statement once it encountered an error. If there are ways that this CAN be done in SQLite 2.8.17, let me know. Otherwise, I will probably write up some logic in PHP to create the same functionality.
2007-Jun-27 00:25:10 by drh:
I did not notice before that you were talking about 2.8.17.
That version of SQLite is in maintenance mode. We will leave
this ticket open for reference, but because 2.8.17 is so very
very old and because this is not a serious bug, the problem
will likely not be fixed anytime soon. Had this been a bug
that was a security vulnerability or could lead to database
corruption, we would look into it. But the policy with 2.8.17
is that minor things like this go unfixed. We feel that it is
better to focus our efforts on the 3.x series.
You are encouraged to find a work-around. In this case, a
good work-around seems to be to not enter invalid SQL...
2007-Jun-27 04:02:33 by anonymous:
Naturally, not entering invalid SQL would be a great idea, but I do not expect everyone to enter perfect SQL statements every time, so I want to try to anticipate possible errors and write in logic that would handle such errors. However, I will find some way to get this to work without changes() working as I desired it to.
Thank you for your help.
2007-Jun-27 11:04:11 by anonymous:
"What I had expected is that, in this scenario, either changes() would report that there HAVE been rows changed, or that a multiline query with an error would not run, or that sqlite would undo the statements that DID execute in a multiline statement once it encountered an error. If there are ways that this CAN be done in SQLite 2.8.17, let me know. Otherwise, I will probably write up some logic in PHP to create the same functionality."
I have determined that I can prevent a multiline query with an error from having its correct statements prior to the one with the error affecting the database by using "BEGIN TRANSACTION", "COMMIT TRANSACTION", and "ROLLBACK TRANSACTION" statements manually in combination with the queryExec method and PHP IF statements. There is a live example with source here:
I could also produce a way to calculate rows changed in such a transaction, by storing the number of records before and after the transaction and doing a simple subtraction. However, this would require me to not use ROLLBACK, so I do not see a benefit to writing such a function.
2007-Jun-30 07:45:12 by anonymous:
Oh, I just realized that I never mentioned what I was wanting this functionality for. I was writing an SQL command-line interface in PHP so that I could work with SQLite that was installed on a remote server. I needed a way to execute SQL commands or batch files without having to put it in a PHP page just to get an error and need to reupload everything. |
|
2457 |
build
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
drh
|
1
|
2
|
Build fails with internal compiler error (Windows, MS VC++ 6.0)
|
edit |
I can't say much. Using the TEA tarball for sqlite 3.4.0 and trying to build this on a windows box using MS VC++ 6.0 the compilation aborts with an 'INTERNAL COMPILER ERROR'.
I will attach the log as a remark. There are lots of warnings as well, about double/int conversion, argument int size mismatches. Most worrying is a series of warnings with negative line numbers!. Given that I am actually not even sure if the location where it fails is correct.
... Yes, when I tried to exclude the reported line (25589, amalgamation) via -DSQLITE_OMIT_INCRBLOB the compiler still crashes, but now in line 25555 of the amalgamation.
Note: v3.3.17 builds fine (again tea tarball, amalgamation).
I wonder ... Is it possible to provide a TEA tarball without amalgamation ? I would like to see if that compiles, maybe the amalgamation has become so large that it is hitting some compiler limit. |
2007-Jun-25 20:04:23 by anonymous:
Ok, reducing the size of the amalgamation by actually stripping out comments does not help. While the negative line numbers in the warnings go away, ditto the warnings about terminating line number generation, it still runs into the Internal Error.
2007-Jun-25 20:22:41 by anonymous:
Even a version of gcc chokes on the amalgamation when I compile with -g -O3. Try compiling without debug information. If that still fails, you have to build sqlite directly from the sources.
2007-Jun-25 21:16:07 by anonymous:
Which version of gcc is failing? It seems to work fine here:
gcc -I. -g -O6 -c ./sqlite3.c
gcc -I. -g -O6 -DHAVE_READLINE=1 -c ../src/shell.c
gcc -I. -o amalg-sqlite -g ./shell.o ./sqlite3.o -ldl -lpthread -lreadline
works fine. It might be worth filing a gcc bug if you see something radically different with gcc.
2007-Jun-25 21:18:52 by anonymous:
AK
Regarding GCC. We are here not using GCC on Windows, so the comment regarding 'gcc -O3' does not apply.
2007-Jun-25 21:20:47 by drh:
The comment above about being unable to compile using gcc -g -O3
is not from the originator of this problem report. I do not
have any problem compiling with gcc -g -O3 here on SuSE Linux
with gcc 4.1.0. Will the person who reports problems compiling
the amalgamation with gcc -g -O3 please add details, such as
the operating system and the version of gcc being used?
2007-Jun-25 21:22:31 by anonymous:
AK
Using the exploded sources the compiler error was still present, in the file btree.c. Same code line as in the amalgamation, just different line numbers.
So the thinking that this is a problem of the amalgamation is a red herring. It is something deeper.
Getting all the revisions of btree.c between releases 3.3.17 and 3.40, and bisecting I find that the trouble starts for me with revision 1.382 of that file. Some functions where replaced by macros.
Creating a revers patch and applying it to revision 3.88 (in release 3.4.0) gets this revisions to compile as well.
Which means I now have a workaround, sa a variant of the revers patch can be applied to the amalgamation as well.
2007-Jun-25 21:26:36 by drh:
Reversing patch [4015]
results in a performance hit. I am
unwilling to fold in a performance hit for all platforms in
order to work around a bug in MSVC++ 6.0. Can anybody suggest
a better fix?
2007-Jun-25 21:35:55 by anonymous:
AK
My specific built of MSVC++ 6.0 is
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
2007-Jun-25 21:57:04 by anonymous:
Install Service pack 6 of Visual Studio 6.0. The KB article that I'm pretty sure covers this bug is:
http://support.microsoft.com/kb/890892
2007-Jun-25 22:16:32 by anonymous:
After hunting down and installing VC6 ServicePack 6 the compiler reports:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
So, it has changed.
Even so, the internal compiler error is still present.
2007-Jun-25 22:33:38 by anonymous:
Reboot of the machine is no help.
2007-Jun-25 22:38:18 by anonymous:
VC 6.0 - what compile flags are you using?
2007-Jun-25 23:11:59 by anonymous:
I thought that cygwin gcc-3.4.4 fails with -O3 -g, but it's just 1800 warning messages. No error, as it turns out.
$ gcc -I`pwd` -O3 -g sqlite3.c src/shell.c -o sqlite3
/cygdrive/c/tmp/cc2D7Vgb.s: Assembler messages:
/cygdrive/c/tmp/cc2D7Vgb.s:30139: Warning: .stabn: description field '103ff' too big, try a different debug format
/cygdrive/c/tmp/cc2D7Vgb.s:30145: Warning: .stabn: description field '103fa' too big, try a different debug format
/cygdrive/c/tmp/cc2D7Vgb.s:30170: Warning: .stabn: description field '103fa' too big, try a different debug format
/cygdrive/c/tmp/cc2D7Vgb.s:30174: Warning: .stabn: description field '103fc' too big, try a different debug format
/cygdrive/c/tmp/cc2D7Vgb.s:30184: Warning: .stabn: description field '103fd' too big, try a different debug format
/cygdrive/c/tmp/cc2D7Vgb.s:30190: Warning: .stabn: description field '103fe' too big, try a different debug format
/cygdrive/c/tmp/cc2D7Vgb.s:30194: Warning: .stabn: description field
...1800 more lines of the same...
2007-Jun-25 23:25:41 by anonymous:
AK
Compile Flags: -O2 -W2 -MD.
According to a poster on the sqlite ML the btree.c can be compiled using -Ow is instead of O2.
Went through the options and O1, O2, Ox, Og all run into the error, the others don't.
2007-Jun-26 02:00:23 by anonymous:
FYI, MinGW gcc version 3.4.2 also produces the same 1800 warnings when you compile with -O3 -g. Still produces an object file okay, it's just annoying. No warning when only -O3 used.
gcc -c -I. -I.. -g -O3 sqlite3.c
c:\tmp/ccuuaaaa.s: Assembler messages:
c:\tmp/ccuuaaaa.s:31474: Warning: .stabn: description field '1001c' too big, try a different debug format
c:\tmp/ccuuaaaa.s:31480: Warning: .stabn: description field '10017' too big, try a different debug format
c:\tmp/ccuuaaaa.s:31505: Warning: .stabn: description field '10017' too big, try a different debug format
c:\tmp/ccuuaaaa.s:31509: Warning: .stabn: description field '10019' too big, try a different debug format
c:\tmp/ccuuaaaa.s:31519: Warning: .stabn: description field '1001a' too big, try a different debug format
c:\tmp/ccuuaaaa.s:31525: Warning: .stabn: description field '1001b' too big, try a different debug format
c:\tmp/ccuuaaaa.s:31529: Warning: .stabn: description field '1001e' too big, try a different debug format
c:\tmp/ccuuaaaa.s:31615: Warning: .stabs: description field '10017' too big, try a different debug format
...1800 lines of this...
|
|
2456 |
new
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
5
|
5
|
REQ: use index where applicable instead of full table scan
|
edit |
There are times when you need information from a table that's held entirely in an index. Would it not make sense to scan over the index in these cases as those are likely to be more densely packed and therefore faster and more cache friendly?
sqlite> .sc
CREATE TABLE t1 ( c1 integer, c2 text, c3 text );
CREATE INDEX idx1 on t1(c1);
so here SELECT SUM(c1) from t1 could be satisfied by scanning over idx1, which might be a lot smaller & more dense than t1. |
|
2448 |
new
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
4
|
3
|
SQLITE needs to identify public exported symbols
|
edit |
A number of platforms allow source code tagging of functions which are meant to be public functions exported in a shared library (most notably windows and platforms that use GCC 4.0 and above).
This tagging is usually accomplished through some define placed in front of the function declaration and definition (SQLITE3_PUBLIC sqlite3_open() for example), and SQLITE3_PUBLIC is set to the proper declaration for the given platform. Example:
windows it would be: __declspec(dllexport)
GCC it would be: __attribute__ ((visibility("default")))
see http://gcc.gnu.org/wiki/Visibility for more information. |
|
2443 |
new
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
3
|
3
|
sqlite should return different exit codes for different errors
|
edit |
sqlite should return different exit codes for different errors reported.
sqlite always returns exit code 0 or 1. It would be helpful to have different codes.
I/O error, locked, interrupted, busy etc. should declare defined return codes. If sqlite is executed from a shell script it is difficult to handle plain text that could change or be reformatted in a later version.
Thanks. |
2007-Jun-21 19:59:41 by anonymous:
Just run sqlite3 -batch -bail and grep for the error in the last line. |
|
2442 |
doc
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
4
|
mailing list link doesn't always exist in website header
|
edit |
The header at the website doesn't always show the "mailing list" link. It is shown on http://www.sqlite.org/contrib but not on the front page. Other problems exist, like the header graphic at http://www.sqlite.org/contrib doesn't link to the top page.
It would be best to have the menu consistent over all pages that it exists on, and to have the graphic link back to the top page. |
|
2440 |
code
|
active
|
2007 Jun
|
rse
|
|
2007 Jun
|
|
2
|
2
|
pkg-config(1) script "sqlite.pc" does not provide Autoconf's LIBS
|
edit |
On some platforms it isn't sufficient to link a library just against "-lsqlite". For instance under Solaris one needs "-lsqlite -lrt"
because of the use of "fdatasync()". The SQLite Autoconf glue already contains the necessary check for this in order to correctly build SQLite and especially link its sqlite(1). But this information is not passed through to the applications which use pkg-config(1) to build against SQLite. Possible fix from OpenPKG's "sqlite" package is following:
Index: sqlite3.pc.in
--- sqlite3.pc.in.orig 2004-07-19 06:25:47 +0200
+++ sqlite3.pc.in 2007-06-20 18:09:00 +0200
@@ -8,5 +8,5 @@
Name: SQLite^M
Description: SQL database engine^M
Version: @VERSION@^M
-Libs: -L${libdir} -lsqlite3^M
+Libs: -L${libdir} -lsqlite3 @LIBS@^M
Cflags: -I${includedir}^M
|
|
2438 |
new
|
active
|
2007 Jun
|
rse
|
|
2007 Jun
|
|
3
|
3
|
More easily allow the building of SQLite with FTS1 and FTS2
|
edit |
I don't know what the intended way is to build SQLite with FTS1 and/or FTS2, but for the OpenPKG "sqlite" package I at least now use the following change -- as I was unable to find any other automated solution. I know that FTS1 and FTS2 are experimental extensions, but if it is too complicated for people to build SQLite with them, they certainly will never become non-experimental ;-) So I recommend to at least provide some build-time glue for them. In the OpenPKG "sqlite" package I now use the following patch which at least provides
this glue (one still has to enable it, of course):
Index: Makefile.in
--- Makefile.in.orig 2007-06-14 22:54:38 +0200
+++ Makefile.in 2007-06-20 18:09:00 +0200
@@ -130,6 +130,18 @@
vdbe.lo vdbeapi.lo vdbeaux.lo vdbeblob.lo vdbefifo.lo vdbemem.lo \
where.lo utf.lo legacy.lo vtab.lo
+# FTS1 support
+ifdef FTS1
+TCC += -DSQLITE_ENABLE_FTS1
+LIBOBJ += fts1.lo fts1_hash.lo fts1_porter.lo fts1_tokenizer1.lo
+endif
+
+# FTS2 support
+ifdef FTS2
+TCC += -DSQLITE_ENABLE_FTS2
+LIBOBJ += fts2.lo fts2_hash.lo fts2_porter.lo fts2_tokenizer1.lo
+endif
+
# All of the source code files.
#
SRC = \
@@ -498,6 +510,23 @@
-o testfixture $(TESTSRC) $(TOP)/src/tclsqlite.c \
libsqlite3.la $(LIBTCL)
+fts1.lo: $(TOP)/ext/fts1/fts1.c $(HDR)
+ $(LTCOMPILE) -c $(TOP)/ext/fts1/fts1.c
+fts1_hash.lo: $(TOP)/ext/fts1/fts1_hash.c $(HDR)
+ $(LTCOMPILE) -c $(TOP)/ext/fts1/fts1_hash.c
+fts1_porter.lo: $(TOP)/ext/fts1/fts1_porter.c $(HDR)
+ $(LTCOMPILE) -c $(TOP)/ext/fts1/fts1_porter.c
+fts1_tokenizer1.lo: $(TOP)/ext/fts1/fts1_tokenizer1.c $(HDR)
+ $(LTCOMPILE) -c $(TOP)/ext/fts1/fts1_tokenizer1.c
+
+fts2.lo: $(TOP)/ext/fts2/fts2.c $(HDR)
+ $(LTCOMPILE) -c $(TOP)/ext/fts2/fts2.c
+fts2_hash.lo: $(TOP)/ext/fts2/fts2_hash.c $(HDR)
+ $(LTCOMPILE) -c $(TOP)/ext/fts2/fts2_hash.c
+fts2_porter.lo: $(TOP)/ext/fts2/fts2_porter.c $(HDR)
+ $(LTCOMPILE) -c $(TOP)/ext/fts2/fts2_porter.c
+fts2_tokenizer1.lo: $(TOP)/ext/fts2/fts2_tokenizer1.c $(HDR)
+ $(LTCOMPILE) -c $(TOP)/ext/fts2/fts2_tokenizer1.c
fulltest: testfixture$(TEXE) sqlite3$(TEXE)
./testfixture $(TOP)/test/all.test
|
|
2427 |
doc
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
4
|
3
|
HTML Tidy warnings on new capi3ref.html
|
edit |
HTML Tidy (http://tidy.sourceforge.net) produces a large number of warnings on the newly generated http://www.sqlite.org/capi3ref.html.
The warnings could cause problems with certain HTML browsers. It might be worth fixing the auto-generation script accordingly.
Here is the list:
line 1 column 1 - Warning: missing <!DOCTYPE> declaration
line 2 column 1 - Warning: inserting implicit <body>
line 3 column 1 - Warning: discarding unexpected <body>
line 336 column 1 - Warning: missing </a> before <h2>
line 337 column 5 - Warning: inserting implicit <a>
line 338 column 13 - Warning: inserting implicit <a>
line 338 column 13 - Warning: missing </a> before <pre>
line 352 column 1 - Warning: missing </a> before <h2>
line 353 column 5 - Warning: inserting implicit <a>
line 354 column 13 - Warning: inserting implicit <a>
line 354 column 13 - Warning: missing </a> before <pre>
line 368 column 1 - Warning: missing </a> before <h2>
line 369 column 5 - Warning: inserting implicit <a>
line 370 column 13 - Warning: inserting implicit <a>
line 370 column 13 - Warning: missing </a> before <pre>
line 380 column 1 - Warning: missing </a> before <h2>
line 381 column 5 - Warning: inserting implicit <a>
line 382 column 13 - Warning: inserting implicit <a>
line 382 column 13 - Warning: missing </a> before <pre>
line 398 column 6 - Warning: inserting implicit <p>
line 402 column 1 - Warning: missing </a> before <h2>
line 403 column 5 - Warning: inserting implicit <a>
line 404 column 13 - Warning: inserting implicit <a>
line 404 column 13 - Warning: missing </a> before <pre>
line 415 column 1 - Warning: missing </a> before <h2>
line 416 column 5 - Warning: inserting implicit <a>
line 417 column 13 - Warning: inserting implicit <a>
line 417 column 13 - Warning: missing </a> before <pre>
line 434 column 1 - Warning: missing </a> before <h2>
line 435 column 5 - Warning: inserting implicit <a>
line 436 column 13 - Warning: inserting implicit <a>
line 436 column 13 - Warning: missing </a> before <pre>
line 454 column 1 - Warning: missing </a> before <h2>
line 455 column 5 - Warning: inserting implicit <a>
line 456 column 13 - Warning: inserting implicit <a>
line 456 column 13 - Warning: missing </a> before <pre>
line 473 column 1 - Warning: missing </a> before <h2>
line 474 column 5 - Warning: inserting implicit <a>
line 475 column 13 - Warning: inserting implicit <a>
line 475 column 13 - Warning: missing </a> before <pre>
line 485 column 1 - Warning: missing </a> before <h2>
line 486 column 5 - Warning: inserting implicit <a>
line 487 column 13 - Warning: inserting implicit <a>
line 487 column 13 - Warning: missing </a> before <pre>
line 504 column 1 - Warning: missing </a> before <h2>
line 505 column 5 - Warning: inserting implicit <a>
line 506 column 13 - Warning: inserting implicit <a>
line 506 column 13 - Warning: missing </a> before <pre>
line 515 column 1 - Warning: missing </a> before <h2>
line 516 column 5 - Warning: inserting implicit <a>
line 517 column 13 - Warning: inserting implicit <a>
line 517 column 13 - Warning: missing </a> before <pre>
line 525 column 1 - Warning: missing </a> before <h2>
line 526 column 5 - Warning: inserting implicit <a>
line 527 column 13 - Warning: inserting implicit <a>
line 527 column 13 - Warning: missing </a> before <pre>
line 544 column 7 - Warning: inserting implicit <p>
line 554 column 1 - Warning: missing </a> before <h2>
line 555 column 5 - Warning: inserting implicit <a>
line 556 column 13 - Warning: inserting implicit <a>
line 556 column 13 - Warning: missing </a> before <pre>
line 569 column 1 - Warning: missing </a> before <h2>
line 570 column 5 - Warning: inserting implicit <a>
line 571 column 13 - Warning: inserting implicit <a>
line 571 column 13 - Warning: missing </a> before <pre>
line 589 column 1 - Warning: missing </a> before <h2>
line 590 column 5 - Warning: inserting implicit <a>
line 591 column 13 - Warning: inserting implicit <a>
line 591 column 13 - Warning: missing </a> before <pre>
line 648 column 1 - Warning: missing </a> before <h2>
line 649 column 5 - Warning: inserting implicit <a>
line 650 column 13 - Warning: inserting implicit <a>
line 650 column 13 - Warning: missing </a> before <pre>
line 666 column 1 - Warning: missing </a> before <h2>
line 667 column 5 - Warning: inserting implicit <a>
line 668 column 13 - Warning: inserting implicit <a>
line 668 column 13 - Warning: missing </a> before <pre>
line 694 column 1 - Warning: missing </a> before <h2>
line 695 column 5 - Warning: inserting implicit <a>
line 696 column 13 - Warning: inserting implicit <a>
line 696 column 13 - Warning: missing </a> before <pre>
line 707 column 1 - Warning: missing </a> before <h2>
line 708 column 5 - Warning: inserting implicit <a>
line 709 column 13 - Warning: inserting implicit <a>
line 709 column 13 - Warning: missing </a> before <pre>
line 722 column 1 - Warning: missing </a> before <h2>
line 723 column 5 - Warning: inserting implicit <a>
line 724 column 13 - Warning: inserting implicit <a>
line 724 column 13 - Warning: missing </a> before <pre>
line 735 column 1 - Warning: missing </a> before <h2>
line 736 column 5 - Warning: inserting implicit <a>
line 737 column 13 - Warning: inserting implicit <a>
line 737 column 13 - Warning: missing </a> before <pre>
line 749 column 1 - Warning: missing </a> before <h2>
line 750 column 5 - Warning: inserting implicit <a>
line 751 column 13 - Warning: inserting implicit <a>
line 751 column 13 - Warning: missing </a> before <pre>
line 764 column 1 - Warning: missing </a> before <h2>
line 765 column 5 - Warning: inserting implicit <a>
line 766 column 13 - Warning: inserting implicit <a>
line 766 column 13 - Warning: missing </a> before <pre>
line 796 column 1 - Warning: missing </a> before <h2>
line 797 column 5 - Warning: inserting implicit <a>
line 798 column 13 - Warning: inserting implicit <a>
line 798 column 13 - Warning: missing </a> before <pre>
line 837 column 1 - Warning: missing </a> before <h2>
line 838 column 5 - Warning: inserting implicit <a>
line 839 column 13 - Warning: inserting implicit <a>
line 839 column 13 - Warning: missing </a> before <pre>
line 855 column 1 - Warning: missing </a> before <h2>
line 856 column 5 - Warning: inserting implicit <a>
line 857 column 13 - Warning: inserting implicit <a>
line 857 column 13 - Warning: missing </a> before <pre>
line 876 column 1 - Warning: missing </a> before <h2>
line 877 column 5 - Warning: inserting implicit <a>
line 878 column 13 - Warning: inserting implicit <a>
line 878 column 13 - Warning: missing </a> before <pre>
line 889 column 1 - Warning: missing </a> before <h2>
line 890 column 5 - Warning: inserting implicit <a>
line 891 column 13 - Warning: inserting implicit <a>
line 891 column 13 - Warning: missing </a> before <pre>
line 907 column 1 - Warning: missing </a> before <h2>
line 908 column 5 - Warning: inserting implicit <a>
line 909 column 13 - Warning: inserting implicit <a>
line 909 column 13 - Warning: missing </a> before <pre>
line 928 column 1 - Warning: missing </a> before <h2>
line 929 column 5 - Warning: inserting implicit <a>
line 930 column 13 - Warning: inserting implicit <a>
line 930 column 13 - Warning: missing </a> before <pre>
line 948 column 1 - Warning: missing </a> before <h2>
line 949 column 5 - Warning: inserting implicit <a>
line 950 column 13 - Warning: inserting implicit <a>
line 950 column 13 - Warning: missing </a> before <pre>
line 976 column 1 - Warning: missing </a> before <h2>
line 977 column 5 - Warning: inserting implicit <a>
line 978 column 13 - Warning: inserting implicit <a>
line 978 column 13 - Warning: missing </a> before <pre>
line 989 column 1 - Warning: missing </a> before <h2>
line 990 column 5 - Warning: inserting implicit <a>
line 991 column 13 - Warning: inserting implicit <a>
line 991 column 13 - Warning: missing </a> before <pre>
line 1004 column 1 - Warning: missing </a> before <h2>
line 1005 column 5 - Warning: inserting implicit <a>
line 1006 column 13 - Warning: inserting implicit <a>
line 1006 column 13 - Warning: missing </a> before <pre>
line 1017 column 1 - Warning: missing </a> before <h2>
line 1018 column 5 - Warning: inserting implicit <a>
line 1019 column 13 - Warning: inserting implicit <a>
line 1019 column 13 - Warning: missing </a> before <pre>
line 1069 column 1 - Warning: missing </a> before <h2>
line 1070 column 5 - Warning: inserting implicit <a>
line 1071 column 13 - Warning: inserting implicit <a>
line 1071 column 13 - Warning: missing </a> before <pre>
line 1083 column 1 - Warning: missing </a> before <h2>
line 1084 column 5 - Warning: inserting implicit <a>
line 1085 column 13 - Warning: inserting implicit <a>
line 1085 column 13 - Warning: missing </a> before <pre>
line 1107 column 1 - Warning: missing </a> before <h2>
line 1108 column 5 - Warning: inserting implicit <a>
line 1109 column 13 - Warning: inserting implicit <a>
line 1109 column 13 - Warning: missing </a> before <pre>
line 1166 column 1 - Warning: missing </a> before <h2>
line 1167 column 5 - Warning: inserting implicit <a>
line 1168 column 13 - Warning: inserting implicit <a>
line 1168 column 13 - Warning: missing </a> before <pre>
line 1198 column 36 - Warning: discarding unexpected </p>
line 1198 column 40 - Warning: using <br> in place of <p>
line 1198 column 40 - Warning: replacing <p> by <br>
line 1203 column 7 - Warning: inserting implicit <p>
line 1215 column 7 - Warning: inserting implicit <p>
line 1222 column 1 - Warning: missing </a> before <h2>
line 1223 column 5 - Warning: inserting implicit <a>
line 1224 column 13 - Warning: inserting implicit <a>
line 1224 column 13 - Warning: missing </a> before <pre>
line 1238 column 1 - Warning: missing </a> before <h2>
line 1239 column 5 - Warning: inserting implicit <a>
line 1240 column 13 - Warning: inserting implicit <a>
line 1240 column 13 - Warning: missing </a> before <pre>
line 1259 column 1 - Warning: missing </a> before <h2>
line 1260 column 5 - Warning: inserting implicit <a>
line 1261 column 13 - Warning: inserting implicit <a>
line 1261 column 13 - Warning: missing </a> before <pre>
line 1286 column 1 - Warning: missing </a> before <h2>
line 1287 column 5 - Warning: inserting implicit <a>
line 1288 column 13 - Warning: inserting implicit <a>
line 1288 column 13 - Warning: missing </a> before <pre>
line 1299 column 1 - Warning: missing </a> before <a>
line 1300 column 1 - Warning: missing </a> before <a>
line 1301 column 1 - Warning: missing </a> before <a>
line 1302 column 1 - Warning: missing </a> before <a>
line 1303 column 1 - Warning: missing </a> before <a>
line 1304 column 1 - Warning: missing </a> before <a>
line 1305 column 1 - Warning: missing </a> before <a>
line 1306 column 1 - Warning: missing </a> before <a>
line 1307 column 1 - Warning: missing </a> before <a>
line 1308 column 1 - Warning: missing </a> before <a>
line 1309 column 1 - Warning: missing </a> before <a>
line 1310 column 1 - Warning: missing </a> before <a>
line 1311 column 1 - Warning: missing </a> before <a>
line 1312 column 1 - Warning: missing </a> before <a>
line 1313 column 1 - Warning: missing </a> before <a>
line 1314 column 1 - Warning: missing </a> before <a>
line 1315 column 1 - Warning: missing </a> before <a>
line 1316 column 1 - Warning: missing </a> before <a>
line 1317 column 1 - Warning: missing </a> before <a>
line 1318 column 1 - Warning: missing </a> before <a>
line 1319 column 1 - Warning: missing </a> before <a>
line 1320 column 1 - Warning: missing </a> before <a>
line 1321 column 1 - Warning: missing </a> before <a>
line 1322 column 1 - Warning: missing </a> before <a>
line 1323 column 1 - Warning: missing </a> before <a>
line 1324 column 1 - Warning: missing </a> before <a>
line 1325 column 1 - Warning: missing </a> before <a>
line 1326 column 1 - Warning: missing </a> before <a>
line 1327 column 1 - Warning: missing </a> before <h2>
line 1328 column 5 - Warning: inserting implicit <a>
line 1329 column 13 - Warning: inserting implicit <a>
line 1329 column 13 - Warning: missing </a> before <pre>
line 1370 column 1 - Warning: missing </a> before <a>
line 1371 column 1 - Warning: missing </a> before <a>
line 1372 column 1 - Warning: missing </a> before <a>
line 1373 column 1 - Warning: missing </a> before <a>
line 1374 column 1 - Warning: missing </a> before <a>
line 1375 column 1 - Warning: missing </a> before <a>
line 1376 column 1 - Warning: missing </a> before <a>
line 1377 column 1 - Warning: missing </a> before <a>
line 1378 column 1 - Warning: missing </a> before <a>
line 1379 column 1 - Warning: missing </a> before <a>
line 1380 column 1 - Warning: missing </a> before <a>
line 1381 column 1 - Warning: missing </a> before <a>
line 1382 column 1 - Warning: missing </a> before <a>
line 1383 column 1 - Warning: missing </a> before <a>
line 1384 column 1 - Warning: missing </a> before <a>
line 1385 column 1 - Warning: missing </a> before <a>
line 1386 column 1 - Warning: missing </a> before <a>
line 1387 column 1 - Warning: missing </a> before <a>
line 1388 column 1 - Warning: missing </a> before <a>
line 1389 column 1 - Warning: missing </a> before <a>
line 1390 column 1 - Warning: missing </a> before <a>
line 1391 column 1 - Warning: missing </a> before <a>
line 1392 column 1 - Warning: missing </a> before <a>
line 1393 column 1 - Warning: missing </a> before <a>
line 1394 column 1 - Warning: missing </a> before <a>
line 1395 column 1 - Warning: missing </a> before <a>
line 1396 column 1 - Warning: missing </a> before <a>
line 1397 column 1 - Warning: missing </a> before <a>
line 1398 column 1 - Warning: missing </a> before <a>
line 1399 column 1 - Warning: missing </a> before <a>
line 1400 column 1 - Warning: missing </a> before <a>
line 1401 column 1 - Warning: missing </a> before <h2>
line 1402 column 5 - Warning: inserting implicit <a>
line 1403 column 13 - Warning: inserting implicit <a>
line 1403 column 13 - Warning: missing </a> before <pre>
line 1455 column 1 - Warning: missing </a> before <a>
line 1456 column 1 - Warning: missing </a> before <a>
line 1457 column 1 - Warning: missing </a> before <a>
line 1458 column 1 - Warning: missing </a> before <a>
line 1459 column 1 - Warning: missing </a> before <a>
line 1460 column 1 - Warning: missing </a> before <h2>
line 1461 column 5 - Warning: inserting implicit <a>
line 1462 column 13 - Warning: inserting implicit <a>
line 1462 column 13 - Warning: missing </a> before <pre>
line 1476 column 1 - Warning: missing </a> before <a>
line 1477 column 1 - Warning: missing </a> before <a>
line 1478 column 1 - Warning: missing </a> before <a>
line 1479 column 1 - Warning: missing </a> before <h2>
line 1480 column 5 - Warning: inserting implicit <a>
line 1481 column 13 - Warning: inserting implicit <a>
line 1481 column 13 - Warning: missing </a> before <pre>
line 1501 column 6 - Warning: inserting implicit <p>
line 1507 column 1 - Warning: missing </a> before <a>
line 1508 column 1 - Warning: missing </a> before <h2>
line 1509 column 5 - Warning: inserting implicit <a>
line 1510 column 13 - Warning: inserting implicit <a>
line 1510 column 13 - Warning: missing </a> before <pre>
line 1523 column 1 - Warning: missing </a> before <a>
line 1524 column 1 - Warning: missing </a> before <a>
line 1525 column 1 - Warning: missing </a> before <a>
line 1526 column 1 - Warning: missing </a> before <a>
line 1527 column 1 - Warning: missing </a> before <a>
line 1528 column 1 - Warning: missing </a> before <a>
line 1529 column 1 - Warning: missing </a> before <a>
line 1530 column 1 - Warning: missing </a> before <a>
line 1531 column 1 - Warning: missing </a> before <a>
line 1532 column 1 - Warning: missing </a> before <a>
line 1533 column 1 - Warning: missing </a> before <h2>
line 1534 column 5 - Warning: inserting implicit <a>
line 1535 column 13 - Warning: inserting implicit <a>
line 1535 column 13 - Warning: missing </a> before <pre>
line 1569 column 1 - Warning: missing </a> before <a>
line 1570 column 1 - Warning: missing </a> before <h2>
line 1571 column 5 - Warning: inserting implicit <a>
line 1572 column 13 - Warning: inserting implicit <a>
line 1572 column 13 - Warning: missing </a> before <pre>
line 1589 column 1 - Warning: missing </a> before <a>
line 1590 column 1 - Warning: missing </a> before <h2>
line 1591 column 5 - Warning: inserting implicit <a>
line 1592 column 13 - Warning: inserting implicit <a>
line 1592 column 13 - Warning: missing </a> before <pre>
line 1615 column 1 - Warning: missing </a> before <a>
line 1616 column 1 - Warning: missing </a> before <a>
line 1617 column 1 - Warning: missing </a> before <a>
line 1618 column 1 - Warning: missing </a> before <h2>
line 1619 column 5 - Warning: inserting implicit <a>
line 1620 column 13 - Warning: inserting implicit <a>
line 1620 column 13 - Warning: missing </a> before <pre>
line 1635 column 1 - Warning: missing </a> before <a>
line 1636 column 1 - Warning: missing </a> before <a>
line 1637 column 1 - Warning: missing </a> before <a>
line 1638 column 1 - Warning: missing </a> before <a>
line 1639 column 1 - Warning: missing </a> before <a>
line 1640 column 1 - Warning: missing </a> before <a>
line 1641 column 1 - Warning: missing </a> before <a>
line 1642 column 1 - Warning: missing </a> before <a>
line 1643 column 1 - Warning: missing </a> before <h2>
line 1644 column 5 - Warning: inserting implicit <a>
line 1645 column 13 - Warning: inserting implicit <a>
line 1645 column 13 - Warning: missing </a> before <pre>
line 1666 column 6 - Warning: inserting implicit <p>
line 1711 column 1 - Warning: missing </a> before <a>
line 1712 column 1 - Warning: missing </a> before <h2>
line 1713 column 5 - Warning: inserting implicit <a>
line 1714 column 13 - Warning: inserting implicit <a>
line 1714 column 13 - Warning: missing </a> before <pre>
line 1746 column 1 - Warning: missing </a> before <a>
line 1747 column 1 - Warning: missing </a> before <a>
line 1748 column 1 - Warning: missing </a> before <a>
line 1749 column 1 - Warning: missing </a> before <a>
line 1750 column 1 - Warning: missing </a> before <a>
line 1751 column 1 - Warning: missing </a> before <a>
line 1752 column 1 - Warning: missing </a> before <a>
line 1753 column 1 - Warning: missing </a> before <a>
line 1754 column 1 - Warning: missing </a> before <a>
line 1755 column 1 - Warning: missing </a> before <h2>
line 1756 column 5 - Warning: inserting implicit <a>
line 1757 column 13 - Warning: inserting implicit <a>
line 1757 column 13 - Warning: missing </a> before <pre>
line 1805 column 49 - Warning: inserting implicit <p>
line 1822 column 14 - Warning: inserting implicit <p>
line 1833 column 41 - Warning: discarding unexpected </p>
line 1833 column 45 - Warning: missing <li>
line 1835 column 20 - Warning: discarding unexpected </p>
line 1835 column 24 - Warning: missing <li>
line 1838 column 6 - Warning: inserting implicit <p>
line 1847 column 6 - Warning: inserting implicit <p>
line 1855 column 1 - Warning: missing </a> before <a>
line 1856 column 1 - Warning: missing </a> before <a>
line 1857 column 1 - Warning: missing </a> before <a>
line 1858 column 1 - Warning: missing </a> before <a>
line 1859 column 1 - Warning: missing </a> before <a>
line 1860 column 1 - Warning: missing </a> before <h2>
line 1861 column 5 - Warning: inserting implicit <a>
line 1862 column 13 - Warning: inserting implicit <a>
line 1862 column 13 - Warning: missing </a> before <pre>
line 1890 column 1 - Warning: missing </a> before <a>
line 1891 column 1 - Warning: missing </a> before <h2>
line 1892 column 5 - Warning: inserting implicit <a>
line 1893 column 13 - Warning: inserting implicit <a>
line 1893 column 13 - Warning: missing </a> before <pre>
line 1916 column 1 - Warning: missing </a> before <a>
line 1917 column 1 - Warning: missing </a> before <h2>
line 1918 column 5 - Warning: inserting implicit <a>
line 1919 column 13 - Warning: inserting implicit <a>
line 1919 column 13 - Warning: missing </a> before <pre>
line 1937 column 1 - Warning: missing </a> before <a>
line 1938 column 1 - Warning: missing </a> before <h2>
line 1939 column 5 - Warning: inserting implicit <a>
line 1940 column 13 - Warning: inserting implicit <a>
line 1940 column 13 - Warning: missing </a> before <pre>
line 1958 column 1 - Warning: missing </a> before <a>
line 1959 column 1 - Warning: missing </a> before <h2>
line 1960 column 5 - Warning: inserting implicit <a>
line 1961 column 13 - Warning: inserting implicit <a>
line 1961 column 13 - Warning: missing </a> before <pre>
line 1981 column 1 - Warning: missing </a> before <a>
line 1982 column 1 - Warning: missing </a> before <a>
line 1983 column 1 - Warning: missing </a> before <h2>
line 1984 column 5 - Warning: inserting implicit <a>
line 1985 column 13 - Warning: inserting implicit <a>
line 1985 column 13 - Warning: missing </a> before <pre>
line 2039 column 1 - Warning: missing </a> before <a>
line 2040 column 1 - Warning: missing </a> before <h2>
line 2041 column 5 - Warning: inserting implicit <a>
line 2042 column 13 - Warning: inserting implicit <a>
line 2042 column 13 - Warning: missing </a> before <pre>
line 2108 column 1 - Warning: missing </a> before <a>
line 2109 column 1 - Warning: missing </a> before <a>
line 2110 column 1 - Warning: missing </a> before <h2>
line 2111 column 5 - Warning: inserting implicit <a>
line 2112 column 13 - Warning: inserting implicit <a>
line 2112 column 13 - Warning: missing </a> before <pre>
line 2139 column 1 - Warning: missing </a> before <a>
line 2140 column 1 - Warning: missing </a> before <a>
line 2141 column 1 - Warning: missing </a> before <h2>
line 2142 column 5 - Warning: inserting implicit <a>
line 2143 column 13 - Warning: inserting implicit <a>
line 2143 column 13 - Warning: missing </a> before <pre>
line 2157 column 1 - Warning: missing </a> before <a>
line 2158 column 1 - Warning: missing </a> before <h2>
line 2159 column 5 - Warning: inserting implicit <a>
line 2160 column 13 - Warning: inserting implicit <a>
line 2160 column 13 - Warning: missing </a> before <pre>
line 2183 column 7 - Warning: inserting implicit <p>
line 2183 column 39 - Warning: unescaped & or unknown entity "&azResult"
line 2193 column 7 - Warning: inserting implicit <p>
line 2204 column 1 - Warning: missing </a> before <a>
line 2205 column 1 - Warning: missing </a> before <h2>
line 2206 column 5 - Warning: inserting implicit <a>
line 2207 column 13 - Warning: inserting implicit <a>
line 2207 column 13 - Warning: missing </a> before <pre>
line 2235 column 1 - Warning: missing </a> before <a>
line 2236 column 1 - Warning: missing </a> before <h2>
line 2237 column 5 - Warning: inserting implicit <a>
line 2238 column 13 - Warning: inserting implicit <a>
line 2238 column 13 - Warning: missing </a> before <pre>
line 2257 column 1 - Warning: missing </a> before <a>
line 2258 column 1 - Warning: missing </a> before <a>
line 2259 column 1 - Warning: missing </a> before <h2>
line 2260 column 5 - Warning: inserting implicit <a>
line 2261 column 13 - Warning: inserting implicit <a>
line 2261 column 13 - Warning: missing </a> before <pre>
line 2298 column 20 - Warning: inserting implicit <p>
line 2302 column 20 - Warning: inserting implicit <p>
line 2305 column 20 - Warning: inserting implicit <p>
line 2308 column 20 - Warning: inserting implicit <p>
line 2317 column 20 - Warning: inserting implicit <p>
line 2321 column 1 - Warning: missing </a> before <a>
line 2322 column 1 - Warning: missing </a> before <h2>
line 2323 column 5 - Warning: inserting implicit <a>
line 2324 column 13 - Warning: inserting implicit <a>
line 2324 column 13 - Warning: missing </a> before <pre>
line 2352 column 1 - Warning: missing </a> before <a>
line 2353 column 1 - Warning: missing </a> before <a>
line 2354 column 1 - Warning: missing </a> before <a>
line 2355 column 1 - Warning: missing </a> before <h2>
line 2356 column 5 - Warning: inserting implicit <a>
line 2357 column 13 - Warning: inserting implicit <a>
line 2357 column 13 - Warning: missing </a> before <pre>
line 2423 column 6 - Warning: discarding unexpected </p>
line 2423 column 10 - Warning: missing <li>
line 2435 column 1 - Warning: inserting implicit <p>
line 2437 column 1 - Warning: missing </a> before <a>
line 2438 column 1 - Warning: missing </a> before <h2>
line 2439 column 5 - Warning: inserting implicit <a>
line 2440 column 13 - Warning: inserting implicit <a>
line 2440 column 13 - Warning: missing </a> before <pre>
line 2457 column 1 - Warning: missing </a> before <a>
line 2458 column 1 - Warning: missing </a> before <a>
line 2459 column 1 - Warning: missing </a> before <a>
line 2460 column 1 - Warning: missing </a> before <a>
line 2461 column 1 - Warning: missing </a> before <a>
line 2462 column 1 - Warning: missing </a> before <a>
line 2463 column 1 - Warning: missing </a> before <a>
line 2464 column 1 - Warning: missing </a> before <a>
line 2465 column 1 - Warning: missing </a> before <a>
line 2466 column 1 - Warning: missing </a> before <a>
line 2467 column 1 - Warning: missing </a> before <a>
line 2468 column 1 - Warning: missing </a> before <a>
line 2469 column 1 - Warning: missing </a> before <a>
line 2470 column 1 - Warning: missing </a> before <h2>
line 2471 column 5 - Warning: inserting implicit <a>
line 2472 column 13 - Warning: inserting implicit <a>
line 2472 column 13 - Warning: missing </a> before <pre>
line 2506 column 1 - Warning: missing </a> before <a>
line 2507 column 1 - Warning: missing </a> before <a>
line 2508 column 1 - Warning: missing </a> before <a>
line 2509 column 1 - Warning: missing </a> before <a>
line 2510 column 1 - Warning: missing </a> before <a>
line 2511 column 1 - Warning: missing </a> before <a>
line 2512 column 1 - Warning: missing </a> before <a>
line 2513 column 1 - Warning: missing </a> before <a>
line 2514 column 1 - Warning: missing </a> before <a>
line 2515 column 1 - Warning: missing </a> before <a>
line 2516 column 1 - Warning: missing </a> before <a>
line 2517 column 1 - Warning: missing </a> before <h2>
line 2518 column 5 - Warning: inserting implicit <a>
line 2519 column 13 - Warning: inserting implicit <a>
line 2519 column 13 - Warning: missing </a> before <pre>
line 4 column 1 - Warning: <table> lacks "summary" attribute
line 6 column 22 - Warning: <img> lacks "alt" attribute
line 38 column 1 - Warning: <table> lacks "summary" attribute
line 46 column 1 - Warning: <table> lacks "summary" attribute
line 61 column 1 - Warning: <table> lacks "summary" attribute
line 159 column 1 - Warning: <table> lacks "summary" attribute
line 338 column 13 - Warning: <a> anchor "sqlite3" already defined
line 354 column 13 - Warning: <a> anchor "sqlite3_blob" already defined
line 370 column 13 - Warning: <a> anchor "sqlite3_context" already defined
line 382 column 13 - Warning: <a> anchor "sqlite3_stmt" already defined
line 404 column 13 - Warning: <a> anchor "sqlite3_value" already defined
line 417 column 13 - Warning: <a> anchor "sqlite3_aggregate_context" already defined
line 436 column 13 - Warning: <a> anchor "sqlite3_auto_extension" already defined
line 456 column 13 - Warning: <a> anchor "sqlite3_bind_parameter_count" already defined
line 475 column 13 - Warning: <a> anchor "sqlite3_bind_parameter_index" already defined
line 487 column 13 - Warning: <a> anchor "sqlite3_bind_parameter_name" already defined
line 506 column 13 - Warning: <a> anchor "sqlite3_blob_bytes" already defined
line 517 column 13 - Warning: <a> anchor "sqlite3_blob_close" already defined
line 527 column 13 - Warning: <a> anchor "sqlite3_blob_open" already defined
line 556 column 13 - Warning: <a> anchor "sqlite3_blob_read" already defined
line 571 column 13 - Warning: <a> anchor "sqlite3_blob_write" already defined
line 591 column 13 - Warning: <a> anchor "sqlite3_busy_handler" already defined
line 650 column 13 - Warning: <a> anchor "sqlite3_busy_timeout" already defined
line 668 column 13 - Warning: <a> anchor "sqlite3_changes" already defined
line 696 column 13 - Warning: <a> anchor "sqlite3_clear_bindings" already defined
line 709 column 13 - Warning: <a> anchor "sqlite3_close" already defined
line 724 column 13 - Warning: <a> anchor "sqlite3_column_count" already defined
line 737 column 13 - Warning: <a> anchor "sqlite3_db_handle" already defined
line 751 column 13 - Warning: <a> anchor "sqlite3_enable_load_extension" already defined
line 766 column 13 - Warning: <a> anchor "sqlite3_enable_shared_cache" already defined
line 798 column 13 - Warning: <a> anchor "sqlite3_exec" already defined
line 839 column 13 - Warning: <a> anchor "sqlite3_extended_result_codes" already defined
line 857 column 13 - Warning: <a> anchor "sqlite3_finalize" already defined
line 878 column 13 - Warning: <a> anchor "sqlite3_get_autocommit" already defined
line 891 column 13 - Warning: <a> anchor "sqlite3_interrupt" already defined
line 909 column 13 - Warning: <a> anchor "sqlite3_last_insert_rowid" already defined
line 930 column 13 - Warning: <a> anchor "sqlite3_load_extension" already defined
line 950 column 13 - Warning: <a> anchor "sqlite3_progress_handler" already defined
line 978 column 13 - Warning: <a> anchor "sqlite3_release_memory" already defined
line 991 column 13 - Warning: <a> anchor "sqlite3_reset" already defined
line 1006 column 13 - Warning: <a> anchor "sqlite3_reset_auto_extension" already defined
line 1019 column 13 - Warning: <a> anchor "sqlite3_set_authorizer" already defined
line 1071 column 13 - Warning: <a> anchor "sqlite3_sleep" already defined
line 1085 column 13 - Warning: <a> anchor "sqlite3_soft_heap_limit" already defined
line 1109 column 13 - Warning: <a> anchor "sqlite3_step" already defined
line 1168 column 13 - Warning: <a> anchor "sqlite3_table_column_metadata" already defined
line 1224 column 13 - Warning: <a> anchor "sqlite3_thread_cleanup" already defined
line 1240 column 13 - Warning: <a> anchor "sqlite3_total_changes" already defined
line 1261 column 13 - Warning: <a> anchor "sqlite3_update_hook" already defined
line 1288 column 13 - Warning: <a> anchor "sqlite3_user_data" already defined
line 1328 column 5 - Warning: <a> anchor "SQLITE_ABORT" already defined
line 1329 column 13 - Warning: <a> anchor "SQLITE_ABORT" already defined
line 1402 column 5 - Warning: <a> anchor "SQLITE_ALTER_TABLE" already defined
line 1403 column 13 - Warning: <a> anchor "SQLITE_ALTER_TABLE" already defined
line 1461 column 5 - Warning: <a> anchor "SQLITE_ANY" already defined
line 1462 column 13 - Warning: <a> anchor "SQLITE_ANY" already defined
line 1480 column 5 - Warning: <a> anchor "SQLITE_BLOB" already defined
line 1481 column 13 - Warning: <a> anchor "SQLITE_BLOB" already defined
line 1509 column 5 - Warning: <a> anchor "SQLITE_DENY" already defined
line 1510 column 13 - Warning: <a> anchor "SQLITE_DENY" already defined
line 1534 column 5 - Warning: <a> anchor "SQLITE_IOERR_BLOCKED" already defined
line 1535 column 13 - Warning: <a> anchor "SQLITE_IOERR_BLOCKED" already defined
line 1571 column 5 - Warning: <a> anchor "SQLITE_STATIC" already defined
line 1572 column 13 - Warning: <a> anchor "SQLITE_STATIC" already defined
line 1591 column 5 - Warning: <a> anchor "SQLITE_VERSION" already defined
line 1592 column 13 - Warning: <a> anchor "SQLITE_VERSION" already defined
line 1619 column 5 - Warning: <a> anchor "sqlite3_aggregate_count" already defined
line 1620 column 13 - Warning: <a> anchor "sqlite3_aggregate_count" already defined
line 1644 column 5 - Warning: <a> anchor "sqlite3_bind_blob" already defined
line 1645 column 13 - Warning: <a> anchor "sqlite3_bind_blob" already defined
line 1713 column 5 - Warning: <a> anchor "sqlite3_collation_needed" already defined
line 1714 column 13 - Warning: <a> anchor "sqlite3_collation_needed" already defined
line 1756 column 5 - Warning: <a> anchor "sqlite3_column_blob" already defined
line 1757 column 13 - Warning: <a> anchor "sqlite3_column_blob" already defined
line 1803 column 1 - Warning: <table> lacks "summary" attribute
line 1861 column 5 - Warning: <a> anchor "sqlite3_column_database_name" already defined
line 1862 column 13 - Warning: <a> anchor "sqlite3_column_database_name" already defined
line 1892 column 5 - Warning: <a> anchor "sqlite3_column_decltype" already defined
line 1893 column 13 - Warning: <a> anchor "sqlite3_column_decltype" already defined
line 1918 column 5 - Warning: <a> anchor "sqlite3_column_name" already defined
line 1919 column 13 - Warning: <a> anchor "sqlite3_column_name" already defined
line 1939 column 5 - Warning: <a> anchor "sqlite3_commit_hook" already defined
line 1940 column 13 - Warning: <a> anchor "sqlite3_commit_hook" already defined
line 1960 column 5 - Warning: <a> anchor "sqlite3_complete" already defined
line 1961 column 13 - Warning: <a> anchor "sqlite3_complete" already defined
line 1984 column 5 - Warning: <a> anchor "sqlite3_create_collation" already defined
line 1985 column 13 - Warning: <a> anchor "sqlite3_create_collation" already defined
line 2041 column 5 - Warning: <a> anchor "sqlite3_create_function" already defined
line 2042 column 13 - Warning: <a> anchor "sqlite3_create_function" already defined
line 2111 column 5 - Warning: <a> anchor "sqlite3_errcode" already defined
line 2112 column 13 - Warning: <a> anchor "sqlite3_errcode" already defined
line 2142 column 5 - Warning: <a> anchor "sqlite3_free" already defined
line 2143 column 13 - Warning: <a> anchor "sqlite3_free" already defined
line 2159 column 5 - Warning: <a> anchor "sqlite3_free_table" already defined
line 2160 column 13 - Warning: <a> anchor "sqlite3_free_table" already defined
line 2206 column 5 - Warning: <a> anchor "sqlite3_get_auxdata" already defined
line 2207 column 13 - Warning: <a> anchor "sqlite3_get_auxdata" already defined
line 2237 column 5 - Warning: <a> anchor "sqlite3_libversion" already defined
line 2238 column 13 - Warning: <a> anchor "sqlite3_libversion" already defined
line 2260 column 5 - Warning: <a> anchor "sqlite3_mprintf" already defined
line 2261 column 13 - Warning: <a> anchor "sqlite3_mprintf" already defined
line 2323 column 5 - Warning: <a> anchor "sqlite3_open" already defined
line 2324 column 13 - Warning: <a> anchor "sqlite3_open" already defined
line 2356 column 5 - Warning: <a> anchor "sqlite3_prepare" already defined
line 2357 column 13 - Warning: <a> anchor "sqlite3_prepare" already defined
line 2439 column 5 - Warning: <a> anchor "sqlite3_profile" already defined
line 2440 column 13 - Warning: <a> anchor "sqlite3_profile" already defined
line 2471 column 5 - Warning: <a> anchor "sqlite3_result_blob" already defined
line 2472 column 13 - Warning: <a> anchor "sqlite3_result_blob" already defined
line 2518 column 5 - Warning: <a> anchor "sqlite3_value_blob" already defined
line 2519 column 13 - Warning: <a> anchor "sqlite3_value_blob" already defined
line 389 column 120 - Warning: trimming empty <p>
line 398 column 6 - Warning: trimming empty <p>
line 542 column 20 - Warning: trimming empty <p>
line 544 column 7 - Warning: trimming empty <p>
line 835 column 62 - Warning: trimming empty <p>
line 1196 column 29 - Warning: trimming empty <p>
line 1203 column 7 - Warning: trimming empty <p>
line 1209 column 13 - Warning: trimming empty <p>
line 1215 column 7 - Warning: trimming empty <p>
line 1368 column 89 - Warning: trimming empty <p>
line 1495 column 65 - Warning: trimming empty <p>
line 1501 column 6 - Warning: trimming empty <p>
line 1660 column 11 - Warning: trimming empty <p>
line 1666 column 6 - Warning: trimming empty <p>
line 1802 column 17 - Warning: trimming empty <p>
line 1805 column 49 - Warning: trimming empty <p>
line 1805 column 53 - Warning: trimming empty <p>
line 1822 column 14 - Warning: trimming empty <p>
line 1830 column 28 - Warning: trimming empty <p>
line 1833 column 45 - Warning: trimming empty <p>
line 1833 column 45 - Warning: trimming empty <li>
line 1835 column 24 - Warning: trimming empty <p>
line 1835 column 24 - Warning: trimming empty <li>
line 1838 column 6 - Warning: trimming empty <p>
line 1843 column 34 - Warning: trimming empty <p>
line 1847 column 6 - Warning: trimming empty <p>
line 2177 column 88 - Warning: trimming empty <p>
line 2183 column 7 - Warning: trimming empty <p>
line 2184 column 46 - Warning: trimming empty <p>
line 2193 column 7 - Warning: trimming empty <p>
line 2296 column 85 - Warning: trimming empty <p>
line 2298 column 20 - Warning: trimming empty <p>
line 2298 column 84 - Warning: trimming empty <p>
line 2302 column 20 - Warning: trimming empty <p>
line 2303 column 52 - Warning: trimming empty <p>
line 2305 column 20 - Warning: trimming empty <p>
line 2306 column 33 - Warning: trimming empty <p>
line 2308 column 20 - Warning: trimming empty <p>
line 2313 column 72 - Warning: trimming empty <p>
line 2317 column 20 - Warning: trimming empty <p>
line 2413 column 38 - Warning: trimming empty <p>
line 2423 column 10 - Warning: trimming empty <p>
line 2423 column 10 - Warning: trimming empty <li>
line 2435 column 1 - Warning: trimming empty <p>
|
|
2419 |
build
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
2
|
'CP_UTF8' : undeclared identifier when trying to build the dll
|
edit |
I am using Microsoft Visual C++ Development System (an old version - 4.0) on Windows XP, and trying to build the dll and associated lib file. The compiler chokes on line 15146 (and following) with an undeclared identifier 'CP_UTF8'.
I'm a newbie, so please be gentle if this is a stupid question. Thanks! |
|
2417 |
new
|
active
|
2007 Jun
|
anonymous
|
|
2007 Nov
|
drh
|
3
|
3
|
Idea for read write concurrency.
|
edit |
This is not a problem, but rather an idea on how to resolve the reader/writer concurrency issues encountered in sqlite.
The idea is to allow a reader and writer to work concurrently not blocking each other. Dual writers would of course block.
When a write occurs:
1. block level changes are made to the database file.
2. Pre-image of that change is written to the journal.
Readers:
1. File I/O on the main file would occur normally.
2. If the block encountered is "new" ie one that was written out by the writer. Then get the original block from the Journal file.
In order to determine "NEW" a change number could be put on each block.
When a READ (select) begins it would first determine the starting global change number. (maybe on the master block?)
When a write occurs it would read the Master blocks change number. (increment this in memory) and use write new blocks with the new value. At commit. The Master block would be updated and the txn journal marked for purge if there are pending reads.
-- Drawbacks: Reading becomes dependent upon the txn journal.
-- Implementation of BLOCK level versioning may ultimately be a simpler approach. Idea would be for a seperate file conaining versioned blocks. This file could be accessed instead of the txn journal. |
2007-Nov-08 15:12:00 by anonymous:
DRH:
Also unaddressed in the proposal is how to locate a particular page
within the journal file without having to do (performance killing)
sequential scan of the possible very large file.
Resolution of page access to avoid sequential scans of Txn Journal.
When a writer is making the modification to a page first it writes the original page to the journal. At this point the journal file offset location is known. Save this offset in the "NEW" page being written into the database file. This implements a backwards chaining of pages into the txn journal.
The reader upon reading the db file page would recognize (see above) that the page is dirty. Acquire the txn journal offset from the dirty page, Read the page from the journal until the starting page is found. This would eliminate any sequential scanning, but may require more than one read request. |
|
2414 |
code
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
1
|
Unable t
|
edit |
I designed a tool in C# using the Sqlite.Net.dll and sqlite3.dll v 3.2.5. The call to sqlite3_step after the sqlite3_prepare function, causes a huge delay to return (~7MINS), sometimes it doesn't return at all. This happens when I'm using v3.2.5 but when I replace it with v 3.3.7, everything works normal. I have tried so many combination of things to get it to work on v3.2.5 (this is the version of the libraries the hardware uses), which includes setting the PRAGMA legacy_file_format to 1, but after every save it reverts back to 0. i will appreciate if I can get a response with any suggestions. Thanks in advance. |
2007-Jun-13 15:58:00 by anonymous:
Please post the schema and the SELECT command that is slow under 3.2.5 and is fast under 3.3.7 so it can be reproduced using the sqlite3 commandline shell. |
|
2413 |
code
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
drh
|
1
|
1
|
1 bug and 2 suggestions in lemon
|
edit |
Hello, ...
Sorry for my english :-) and if i post this with Severity/Priority error.
I found some not serious bug and have some suggetions.
=============================================================================
BUG FIX:
lemon.c for Win32. It not found lempar.c - backslash-bug.
function:
PRIVATE char *pathsearch(argv0,name,modemask);
PATCH:
---- CUT --------------------------------------------------------------------
--- C:/lemon.c Wed Jun 13 15:02:37 2007
+++ D:/Den/Lemon/lemon.c Wed Jun 13 16:25:22 2007
@@ -2911,7 +2911,11 @@
c = *cp;
*cp = 0;
path = (char *)malloc( strlen(argv0) + strlen(name) + 2 );
- if( path ) sprintf(path,"%s/%s",argv0,name);
+ #ifdef __WIN32__
+ if( path ) sprintf(path,"%s\\%s",argv0,name);
+ #else
+ if( path ) sprintf(path,"%s/%s",argv0,name);
+ #endif
*cp = c;
}else{
extern char *getenv();
@@ -2920,11 +2924,19 @@
path = (char *)malloc( strlen(pathlist)+strlen(name)+2 );
if( path!=0 ){
while( *pathlist ){
- cp = strchr(pathlist,':');
+ #ifdef __WIN32__
+ cp = strchr(pathlist,';');
+ #else
+ cp = strchr(pathlist,':');
+ #endif
if( cp==0 ) cp = &pathlist[strlen(pathlist)];
c = *cp;
*cp = 0;
- sprintf(path,"%s/%s",pathlist,name);
+ #ifdef __WIN32__
+ sprintf(path,"%s\\%s",pathlist,name);
+ #else
+ sprintf(path,"%s/%s",pathlist,name);
+ #endif
*cp = c;
if( c==0 ) pathlist = "";
else pathlist = &cp[1];
---- CUT --------------------------------------------------------------------
=============================================================================
SUGGESTION 1:
Why we allocate parser with mallocProc parameter of ParseAlloc function
and free with freeProc of ParseFree function?
We do this because we want what parser is user-allocatable
with USER-DEFINED-MEMORY-ALOCATION-WAY but not with "malloc"/"free" from stdlib... am i right?
If so... why we still allocate memory for parser stack with "realloc" function?
It's bad for solutions where is no stdlib.
My suggestion is
FIRST WAY:
To add to yyParser struct 3 variables like
void *mem_alloc_fn;
void *mem_realloc_fn;
void *mem_free_fn;
and add 3 directives like
%memory_alloc
%memory_realloc
%memory_free
and if it declared - use it for allocating/free/reallocating memory in parser.
and
- void ParseAlloc(void *(*mallocProc)(size_t));
will now as void *ParseAlloc();
- void ParseFree(void *pParser, void (*freeProc)(void));
will now as void ParseFree(void *pParser);
OR SECOND WAY (very simple):
To add to yyParser struct 1 variable like
void *mem_realloc_fn;
- void *ParseAlloc(void *(*mallocProc)(size_t));
will now as void *ParseAlloc(void *(*mallocProc)(size_t), void *(*reallocProc)(void *, size_t));
store reallocProc in mem_realloc_fn in yyParser
and in yyGrowStack something like this:
... yyGrowStack (...)
{
....
if(pParser->mem_realloc_fn != NULL)
{
pNew = pParser->mem_realloc_fn(p->yystack, newSize*sizeof(pNew[0]));
}
else
{
pNew = realloc(p->yystack, newSize*sizeof(pNew[0]));
}
....
}
and use it for reallocating memory in parser.
In this ways - memory allocating in parser is under FULL user control.
=============================================================================
SUGGESTION 2:
I build lemon with VC 8.0 with option /Wp64 (Detect 64-Bit Portability Issues)
and have warnings. Type int, size_t, pointer and unsigned long have diferent size on x32 and x64 platforms.
Can you fix type difference, please?
Only you can choice better way for this - type conversion OR change type of 'warning' variables.
WARNINGS:
d:\den\lemon\lemon.c(1331) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
d:\den\lemon\lemon.c(1337) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
d:\den\lemon\lemon.c(1455) : warning C4113: 'int (__cdecl )()' differs in parameter lists from 'int (__cdecl *)(const void *,const void *)'
d:\den\lemon\lemon.c(1578) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'unsigned long'
d:\den\lemon\lemon.c(1578) : warning C4312: 'type cast' : conversion from 'unsigned long' to 'char **' of greater size
d:\den\lemon\lemon.c(1581) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'unsigned long'
d:\den\lemon\lemon.c(1581) : warning C4312: 'type cast' : conversion from 'unsigned long' to 'char **' of greater size
d:\den\lemon\lemon.c(1586) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'unsigned long'
d:\den\lemon\lemon.c(1586) : warning C4312: 'type cast' : conversion from 'unsigned long' to 'char **' of greater size
d:\den\lemon\lemon.c(1588) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'unsigned long'
d:\den\lemon\lemon.c(1588) : warning C4312: 'type cast' : conversion from 'unsigned long' to 'char **' of greater size
d:\den\lemon\lemon.c(1590) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'unsigned long'
d:\den\lemon\lemon.c(1590) : warning C4312: 'type cast' : conversion from 'unsigned long' to 'char **' of greater size
d:\den\lemon\lemon.c(1592) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'unsigned long'
d:\den\lemon\lemon.c(1592) : warning C4312: 'type cast' : conversion from 'unsigned long' to 'char **' of greater size
d:\den\lemon\lemon.c(1595) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'unsigned long'
d:\den\lemon\lemon.c(1595) : warning C4312: 'type cast' : conversion from 'unsigned long' to 'char **' of greater size
d:\den\lemon\lemon.c(1596) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'unsigned long'
d:\den\lemon\lemon.c(1596) : warning C4312: 'type cast' : conversion from 'unsigned long' to 'char **' of greater size
d:\den\lemon\lemon.c(1624) : warning C4311: 'type cast' : pointer truncation from 'char **' to 'unsigned long'
d:\den\lemon\lemon.c(1624) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'unsigned long'
d:\den\lemon\lemon.c(1628) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'unsigned long'
d:\den\lemon\lemon.c(1628) : warning C4312: 'type cast' : conversion from 'unsigned long' to 'char **' of greater size
d:\den\lemon\lemon.c(1629) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'unsigned long'
d:\den\lemon\lemon.c(1629) : warning C4312: 'type cast' : conversion from 'unsigned long' to 'char **' of greater size
d:\den\lemon\lemon.c(1658) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
d:\den\lemon\lemon.c(1661) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data
d:\den\lemon\lemon.c(1774) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'unsigned long'
d:\den\lemon\lemon.c(1774) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'unsigned long'
d:\den\lemon\lemon.c(1785) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'unsigned long'
d:\den\lemon\lemon.c(1785) : warning C4311: 'type cast' : pointer truncation from 'char *' to 'unsigned long'
d:\den\lemon\lemon.c(1883) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
d:\den\lemon\lemon.c(2722) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
d:\den\lemon\lemon.c(3171) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
d:\den\lemon\lemon.c(3173) : warning C4018: '>=' : signed/unsigned mismatch
d:\den\lemon\lemon.c(3184) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data
d:\den\lemon\lemon.c(3340) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
d:\den\lemon\lemon.c(3346) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
d:\den\lemon\lemon.c(3542) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
|
Ups ... drh, sorry - title change. |
|
2411 |
new
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
5
|
3
|
fts2 RFE - Separate index and storage
|
edit |
It is my understanding of the current implementations of the fts modules that you save your text into the chosen table.column and in the background an index is generated for use by a special search operator. IMHO this puts two distinct concepts together, namely the storage of the text to be indexed, and its actual indexing for full-text-search.
What I am asking for here is the ability to create an fts-index without having the system store the text itself. I.e. putting the text into the table.column extends the index, but will not save the text.
This allows several things not possible with the current implementations:
- Storage of the text outside of the database (fts-index joined to path names).
- Compressed storage of text in the database (fts-index joined to separate blob table).
While I currently have no real idea yet about usecases for the first item I do see the following possible applications for the last item:
- SCM systems which wish to allow fts over all versions of a file, without giving up delta-compression between revisions.
- Help files which allow fts despite being space-efficient due to compressed storage of the help pages (zlib).
In both cases the current implementations of fts would force the applications to choose between either space efficiency, or searchability. |
2007-Jun-13 07:23:58 by anonymous:
This mailing list thread lists additional usage scenarios and arguments in favor of separating FTS index from text storage. It also gives some DB size savings statistics: |
|
2409 |
code
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
drh
|
1
|
1
|
Database malformed with SQLite3.3.17 on WindowsXP
|
edit |
I encountered a problem with SQLite3.3.17 on Windows XP. Under certain situation,
database file got seriously corrupted.
SQLite version: 3.3.17 Windows Binary
Platform:Windows XP SP2(Japanese)
Code wrtten in: Visual C++ 6.0
Here are the procedures to reproduce the problem:
1) Run a program SQLiteCrush.exe.
This program updates 'test.db' repeatedly. Insert data
to work table, copy them into items table, then delete
records from work.
2) Open 'test.db' from sqlite3.exe.
3) Do '.read check.sql' repeatedly.
check.sql is made from many lines of 'pragma integrity_check;'.
4) Keep doing 1 -3 for several minuites, and 'pragma integrity_check'
starts to report something like
"rowid 91667 missing from index sqlite_autoindex_link_1".
So far, I didn't see the database corrupted with SQLite 3.3.7.
Also, without 3), the database was not corrupted. Instead of
'pragma integrity_check', issueing many select statements also
make it currupted. |
2007-Jun-12 02:51:26 by anonymous:
I did more tests to make it clear from which version it happens.
With 3.3.8, I couldn't reproduce the problem.
With 3.3.9, I can reproduce the problem.
It seems there's some change between these two that causes the problem...
2007-Jun-12 03:06:47 by anonymous:
Can you try it against the latest version in CVS, or 3.3.17?
A lot of code has changed since 3.3.9.
2007-Jun-12 05:00:50 by anonymous:
I Already tried 3.3.17. It happenes.
Where can I get the latest CVS precompiled binary for windows platform ?
tamagawa
2007-Jun-13 14:25:47 by drh:
The problem was introduced in SQLite version 3.3.0, specifically
check-in [2848]
. There are related problems that go back even
further in time, we believe. The root of the problem is a logic
error in my design of the pager layer. We are working on a fix
now, as well as a set of test cases that will ensure that
similar errors do not reappear in the future. I will also
soon publish instructions on how to work around the problem
in effected versions of SQLite.
The problem can be easily reproduced by running the script below
using the "testfixture" program that we use for testing SQLite.
# Prepare the database:
#
file delete -force test.db test.db-journal
sqlite3 db test.db
db eval {
CREATE TABLE t1 (
x TEXT UNIQUE NOT NULL,
y BLOB
);
}
# Open a second connection to the database that will be
# used to lock the database file.
#
set DB2 [sqlite3 db2 test.db]
if {$DB2==""} {
set DB2 [sqlite3_connection_pointer db2]
}
# A small cache will cause an early cache spill.
#
db eval {PRAGMA cache_size=10}
# Acquire read lock on the database file using the second connection.
#
set STMT [sqlite3_prepare $DB2 {SELECT rowid FROM sqlite_master} -1 TAIL]
sqlite3_step $STMT
# Insert a short record into the index (10 bytes) and a large record
# into the table (15K). The index record goes in Ok, but during the
# insert into the table, SQLite attempts to upgrade to an EXCLUSIVE
# lock to do a cache flush. When this happens, the cache is left in
# an inconsistent state.
#
set zShort [string repeat 0123456789 1]
set zLong [string repeat 0123456789 1500]
db eval {BEGIN}
set rc [catch { db eval {INSERT INTO t1 VALUES($zShort, $zLong)} } msg]
puts "rc=$rc msg=$msg"
sqlite3_finalize $STMT
db eval {COMMIT}
db close
sqlite3 db test.db
puts [db eval {PRAGMA integrity_check}]
|
|
2408 |
code
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
2
|
1
|
BLOBs not output correctly in .mode insert (shell.c - isnumber)
|
edit |
The method
static int isNumber(const char *z, int *realnum)
from shell.c is wrong.
Steps to reproduce:
1. Get the file www.smatei.3x.ro/project1.zip
2. extract project1.db from the zip file
3. execute
sqlite3 project1.db
sqlite>.mode insert
sqlite> select ID, Name, Color, Active, Priority, PrioritySource, IndexOrder, Language, 0 from Keywords;
INSERT INTO Keywords VALUES(42,#####,0,1,0,0,42,'',0);
INSERT INTO Keywords VALUES(41,'######',0,1,0,0,43,'',0);
If you look at the 42 item, the string next to 42 is not enclosed by the string delimiter '.
This is because the method isnumber returns that the string is number. It is not a number, it is a string in Hebrew (I inserted ### instead of the real strings).
A fix for this might be to set the first parameter unsigned char
static int isNumber(unsigned const char *z, int *realnum)
but I am not sure, because I haven't written C code for a long time.
If you have any more questions, please ask.
Best Regards,
Stefan |
2007-Jun-11 14:46:03 by drh:
Please show me what you get from the following query:
SELECT ID, quote(cast(Name AS BLOB)) FROM Keywords
WHERE ID IN (41,42);
I need this information in order to track down the problem.
2007-Jun-11 14:50:33 by anonymous:
The output is
41|X'D791D7A8D799D799D7A7D793D790D7A0D7A1'
42|X'D7A1D798D7A4D7A1'
2007-Jun-11 16:29:46 by drh:
When I do this:
CREATE TABLE t1(x);
INSERT INTO t1 VALUES(cast(X'D791D7A8D799D799D7A7D793D790D7A0D7A1' as text));
INSERT INTO t1 VALUES(cast(X'D7A1D798D7A4D7A1' AS text));
.mode insert xyz
SELECT * FROM t1;
I see the Hebrew characters, properly quoted.
Can you suggest another way to reproduce the problem?
2007-Jun-11 16:34:55 by anonymous:
SQLite version 3.3.17
Enter ".help" for instructions
sqlite> create table t1(b blob);
sqlite> insert into t1 values(X'0102030405060708090a0dABCD');
sqlite> .dump
BEGIN TRANSACTION;
CREATE TABLE t1(b blob);
INSERT INTO "t1" VALUES(X'0102030405060708090A0DABCD');
COMMIT;
sqlite> .mode insert
sqlite> select * from t1;
INSERT INTO table VALUES('
«Í');
sqlite>
2007-Jun-11 20:07:09 by anonymous:
If I recall correctly, sqlite3.exe assumes all I/O to and from the console is UTF-8. Windows consoles are either MBCS or UNICODE depending on the build settings. Sqlite3.exe was not compiled as UNICODE so anything inserted into a sqlite3 database will be inserted as MBCS.
So if you insert into a database using a 3rd party application that does proper UTF-8, and then query it from the command-line, it will look wrong. Likewise, anything you insert from the command-line will look wrong when queried from an application that uses UTF-8.
2007-Jun-11 20:42:18 by anonymous:
.mode insert treats BLOBs as strings, which is a problem since it stops outputting at the first nil character.
CREATE TABLE t1(a blob);
INSERT INTO t1 VALUES(X'00000008090A0D0D0A00');
.mode insert whatever
select * from t1;
2007-Jun-12 07:39:12 by anonymous:
Hi,
My problem is not the way the string is displayed in the console. The application that reads the database reads it correctly. The problem is when I try to dump a certain table in a file using the following sequence:
.output "file.txt"
.mode insert whatever
select f1, f2, f3 from t1;
The result is a file that some Hebrew strings are not enclosed in ' (apostrophe). After debugging the code, I saw that the method isnumber does not return 0 for that string. It considers all the characters digits.
This problem occurs only on Windows. We tried this on Mac and Linux, and it worked fine.
Best Regards,
Stefan
|
|
2401 |
warn
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
1
|
I can't send anything to the contrib page
|
edit |
I am trying to send a .zip file that is almost 3 meg in size to the contrib page.
I have a login and password.
When I try to upload the file I get a server error.
Is my file too large?
Thanks
Tony Scarpelli
Computer Systems Specialist
Maine Medical Center
Portland Maine
207-662-4987 |
|
2398 |
code
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
2
|
3
|
systemcalls should be restarted when they return EINTR
|
edit |
Introduction: I'm a developer for Alcatel-Lucent, where I program softswitches. I'm a bit of a code-correctness nazi, because I've programmed several systems that have to be very reliable (5 figures), or I've corrected them if they didn't. I was browsing thru the source code of SQLite, to become familiar with it, and to see how reliable it was. Not that we currently use it in a product, but you may never known.
The very first thing I noticed was that none of the systemcalls in os_unix.c was checked for EINTR. From experience, I know that a systemcall can be interrupted while inside the kernel, and return EINTR in errno. The correct reaction is to repeat the system call, just as if nothing happened. This is not an error, just a temporary situation which will be fixed the next time you call it again. One reason is that you call was interrupted by a higher priority interrupt (incoming IO for instance), or to avoid a deadlock in the kernel (returning your syscall will release any locks you might have). It's pretty rare in most usage, but I've seen it lots of times when testing a server under load.
Example of the solution for seekAndWrite (this only shows write, but pwrite is similar) :
got = write(id->h, pBuf, cnt);
should be :
do {
got = write(id->h, pBuf, cnt);
} while ( (got < 0) && (errno == EINTR) );
This has to be done for every systemcall that mentions it on its manpage (but please note, not every OS is the same). This includes many calls where everyone assumes that the call is safe to use, for instance close(). Almost nobody seems to realize that a close can fail, and often there's not even a check for the return code. But I can assure you, it can fail. |
2007-Jun-05 13:39:08 by anonymous:
I prefer the current SQLite behavior NOT to retry in the event of EINTR. I've seen too many UNIX OSes with bugs related to EINTR for system calls within threads over the years, including the most popular ones. Most of these OS bugs have since been fixed, but it's still not worth the trouble in case you come across an unpatched platform. Getting an infinite loop of EINTR errnos in a tight loop due to an OS bug is no fun in a production application.
Technically, POSIX requires that you only read errno if -1 is returned by the system call. QNX is picky about this sort of thing.
2007-Jun-05 17:02:55 by anonymous:
Read my introduction again : I help make systems reliable in my daytime job. Ignoring a read- or write-error is not how you achieve 99.999% availability, especially not when it's easily correctable (a disk-full message or a I/O error due to a corrupt harddisk is another matter ofcourse).
>Technically, POSIX requires that you only read errno if -1 is returned by the system call. QNX is picky about this sort of thing.
well yes, that's what I mean.
2007-Jun-05 17:20:07 by anonymous:
All of SQLite's operations can also be retried if they fail.
SQLite has an extensive test suite for disk failures, malloc failures and many other types of failures that you've likely never considered.
I tend to trust the judgement of the authors of SQLite more than an anonymous guy puffing his chest out in this ticket tracking system.
2007-Jun-05 22:24:09 by anonymous:
hi.
instead of blaming in this ticket, the ticket author could place a patch like:
got = write(id->h, pBuf, cnt);
to do things like:
#ifdef SQLITE3_RETRY_EINTR_SYSCALLS
do {
#endif // SQLITE3_RETRY_EINTR_SYSCALLS
got = write(id->h, pBuf, cnt);
#ifdef SQLITE3_RETRY_EINTR_SYSCALLS
} while ( (got < 0) && (errno == EINTR) );
#endif // SQLITE3_RETRY_EINTR_SYSCALLS
by leaving SQLITE3_RETRY_EINTR_SYSCALLS undefined, this should not affect the current code behaviour and should address the issues ticket author says and he can compile with those 'paranoic' checks.
[]'s
2007-Jun-05 22:25:06 by anonymous:
I did pass my name (visible for the developers), but I'm not logged in. That why it's shown as anonymous (just as you are).
Note that my co-workers have already decided it would be seen up as a negative point for this DBMS. At least for us, because it's a requirement for us to survive these errors. So if we ever are going to use SQLite, we're definitely going to use those changes.
Hey, I'm a code-review nazi, don't blame me. It's just my job :-)
2007-Jun-06 00:58:16 by anonymous:
I think that the retrying would destroy the function expected of sqlite3_interrupt .
Is there a problem in the following methods?
- Re-execute the SQLite API.
- Mask the signals while calling the API of SQLite.
- Mask the signals in the threads that call the API of SQLite.
2007-Jun-06 01:04:47 by anonymous:
As long as #ifdef SQLITE3_RETRY_EINTR_SYSCALLS is not enabled by default, knock yourselves out.
2007-Jun-06 06:38:51 by anonymous:
sqlite3_interrupt() knows nothing about UNIX signals. It just sets a flag that sqlite's VDBE checks from time to time to see if it should gracefully abort an SQL operation.
shell.c happens to install an SIGINT signal handler that happens to call sqlite3_interrupt(), but that's unrelated. sqlite3_interrupt() could be called via any other means.
2007-Jun-06 10:47:27 by anonymous:
See also the SA_RESTART flag for sigaction(), which automatically will restart the systemcall instead of returning EINTR.
Unfortunately not available everywhere, and not very consistent either : see Linus reply at http://lkml.org/lkml/2005/7/23/119 . Applications should still be able to handle EINTR returns gracefully. They're not errors per se (that would be EIO or similar), you can safely restart the system call. I haven't seen endless loops yet, but it's true that on some OS you might want this solution. But you still have to deal with the error (which might cause a rollback in SQLite).
2007-Jun-06 14:51:14 by anonymous:
I would be in favor of optionally compiling SQLite with a #define SQLITE_USE_SA_RESTART or #define SQLITE_RETRY_ON_EINTR, where they are mutually exclusive and disabled by default. SQLITE_RETRY_ON_EINTR should have a maximum retry limit on buggy OSes, though. |
|
2397 |
build
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
2
|
4
|
make install failed on Cygwin
|
edit |
On WinXP Cygwin platform, `make install' failed.
There are at least two problems. I could not resolve them.
(1) Makefile defect.
(2) Tcl on Cygwin is not compatible with other platforms.
(1) can be fixed as follows:
-install: sqlite3$ libsqlite3.la sqlite3.h ${HAVE_TCL:1=tcl_install}
+install: sqlite3$(TEXE) libsqlite3.la sqlite3.h ${HAVE_TCL:1=tcl_install}
(2) can not be fixed. There are at least two Tcl problems.
(a) On Cygwin, an empty string can not be set to the
environment variable. So tclinstaller.tcl line 9:
set env(DESTDIR) ""
this statement has no effect, and Tcl failed at line 10.
(b) On Cygwin, [info sharedlibextension] returns ".dll".
But `make all' generates static library only, libsqlite.dll
does not exist.
As a workaround, commenting out HAVE_TCL in Makefile did the trick.
|
|
2396 |
code
|
active
|
2007 Jun
|
anonymous
|
|
2007 Jun
|
|
1
|
3
|
-column output truncates characters from varchar field.
|
edit |
CREATE TABLE unix (unix_id integer primary key, ip_address varchar(16) unique, status enum, updated timestamp);
INSERT INTO unix VALUES (NULL,'172.26.242.92','in use',timestamp('now'));
INSERT INTO unix VALUES (NULL,'172.26.242.129','in use',timestamp('now'));
INSERT INTO unix VALUES (NULL,'172.26.242.131','in use',timestamp('now'));
INSERT INTO unix VALUES (NULL,'172.26.242.132','in use',timestamp('now'));
INSERT INTO unix VALUES (NULL,'172.26.242.136','in use',timestamp('now'));
INSERT INTO unix VALUES (NULL,'172.26.242.213','in use',timestamp('now'));
INSERT INTO unix VALUES (NULL,'10.193.33.7','in use',timestamp('now'));
INSERT INTO unix VALUES (NULL,'10.193.32.239','in use',timestamp('now'));
Now:
sqlite3 -column test.db "SELECT ip_address, status, updated FROM unix";
172.26.242.92 in use 2007-05-31 22:11:39
172.26.242.12 in use 2007-05-31 22:11:47
172.26.242.13 in use 2007-05-31 22:11:51
172.26.242.13 in use 2007-05-31 22:11:59
172.26.242.13 in use 2007-05-31 22:12:04
172.26.242.21 in use 2007-05-31 22:12:11
10.193.33.7 in use 2007-05-31 23:27:09
10.193.32.239 in use 2007-05-31 23:27:17
The output of the varchar column is always truncated regardless of which column it is placed in. Even if it's the only column.
sqlite3 -column test.db "SELECT ip_address FROM unix";
172.26.242.92
172.26.242.12
172.26.242.13
172.26.242.13
172.26.242.13
172.26.242.21
10.193.33.7
10.193.32.239
|
2007-Jun-01 18:54:42 by anonymous:
Smaller test case:
sqlite> CREATE TABLE t9(a);
sqlite> INSERT INTO "t9" VALUES('a234567890');
sqlite> INSERT INTO "t9" VALUES('a23456789012345');
sqlite> select * from t9;
a234567890
a23456789012345
sqlite> .mode column
sqlite> select * from t9;
a234567890
a234567890
sqlite> select * from t9 order by a desc;
a23456789012345
a234567890
.mode column seems to be remembering the first row's column lengths and using them as the maximum column lengths for subsequent rows.
2007-Jun-01 19:11:11 by anonymous:
.mode column could only work correctly if the outputting of the rows took place only after the maximum column width of each column for each row was determined in advance. This would require buffering alls rows in memory before any data rows would be output.
I recommend to remove MODE_Column functionality from shell.c completely, as it never worked correctly.
2007-Jun-05 14:54:30 by anonymous:
Column mode works fine for most applications. It bases it column widths on the width of the title or a minimum width of 10. If this is not suitable, you can set the column widths manually using the .width command in the shell. If you set your IP address column width to 16 or more everything will be fine. |
|
2393 |
code
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
4
|
4
|
pragma cache_size not accurate when set to less than 10
|
edit |
It seems that the smallest the cache_size can be is 10 pages, despite what can be set and is reported by the cache_size and default_cache_size pragmas:
/*
** Change the maximum number of in-memory pages that are allowed.
*/
void sqlite3PagerSetCachesize(Pager *pPager, int mxPage){
if( mxPage>10 ){
pPager->mxPage = mxPage;
}else{
pPager->mxPage = 10;
}
}
...
static int sqlite3BtreeSetCacheSize(Btree *p, int mxPage){
BtShared *pBt = p->pBt;
sqlite3PagerSetCachesize(pBt->pPager, mxPage);
return SQLITE_OK;
}
...
if( sqlite3StrICmp(zLeft,"cache_size")==0 ){
if( sqlite3ReadSchema(pParse) ) goto pragma_out;
if( !zRight ){
returnSingleInt(pParse, "cache_size", pDb->pSchema->cache_size);
}else{
int size = atoi(zRight);
if( size<0 ) size = -size;
pDb->pSchema->cache_size = size;
sqlite3BtreeSetCacheSize(pDb->pBt, pDb->pSchema->cache_size);
...
if( sqlite3StrICmp(zLeft,"default_cache_size")==0 ){
static const VdbeOpList getCacheSize[] = {
{ OP_ReadCookie, 0, 2, 0}, /* 0 */
{ OP_AbsValue, 0, 0, 0},
{ OP_Dup, 0, 0, 0},
{ OP_Integer, 0, 0, 0},
{ OP_Ne, 0, 6, 0},
{ OP_Integer, 0, 0, 0}, /* 5 */
{ OP_Callback, 1, 0, 0},
};
int addr;
if( sqlite3ReadSchema(pParse) ) goto pragma_out;
if( !zRight ){
sqlite3VdbeSetNumCols(v, 1);
sqlite3VdbeSetColName(v, 0, COLNAME_NAME, "cache_size", P3_STATIC);
addr = sqlite3VdbeAddOpList(v, ArraySize(getCacheSize), getCacheSize);
sqlite3VdbeChangeP1(v, addr, iDb);
sqlite3VdbeChangeP1(v, addr+5, SQLITE_DEFAULT_CACHE_SIZE);
}else{
int size = atoi(zRight);
if( size<0 ) size = -size;
sqlite3BeginWriteOperation(pParse, 0, iDb);
sqlite3VdbeAddOp(v, OP_Integer, size, 0);
sqlite3VdbeAddOp(v, OP_ReadCookie, iDb, 2);
addr = sqlite3VdbeAddOp(v, OP_Integer, 0, 0);
sqlite3VdbeAddOp(v, OP_Ge, 0, addr+3);
sqlite3VdbeAddOp(v, OP_Negative, 0, 0);
sqlite3VdbeAddOp(v, OP_SetCookie, iDb, 2);
pDb->pSchema->cache_size = size;
sqlite3BtreeSetCacheSize(pDb->pBt, pDb->pSchema->cache_size);
The information reported is not accurate:
SQLite version 3.3.17
Enter ".help" for instructions
sqlite> pragma cache_size;
2000
sqlite> pragma default_cache_size;
2000
sqlite> pragma default_cache_size=3;
sqlite> pragma cache_size=7;
sqlite> pragma default_cache_size;
3 (should be 10)
sqlite> pragma cache_size;
7 (should be 10)
|
|
2392 |
code
|
active
|
2007 May
|
anonymous
|
|
2007 Oct
|
|
4
|
4
|
Reduce MemPage and PgHdr struct sizes. Better page memory utilization.
|
edit |
Patch to reduce sizeof(MemPage) below. It saves 8 bytes per cached page or in-memory page on Linux.
sizeof(MemPage) on Linux:
original: 84
patched: 76
Patched "make test" runs without regressions on Linux and Windows.
Timings for "make test" (elapsed):
original: 1:20.74
patched: 1:20.22
Size of sqlite3.o when compiled from almalogmation with all
sqlite features enabled with gcc flags -O3 -fomit-frame-pointer:
original: 586976 bytes
patched: 587880 bytes
Patched sqlite3.o is 904 bytes larger.
Index: src/btreeInt.h
===================================================================
RCS file: /sqlite/sqlite/src/btreeInt.h,v
retrieving revision 1.4
diff -u -3 -p -r1.4 btreeInt.h
--- src/btreeInt.h 16 May 2007 17:28:43 -0000 1.4
+++ src/btreeInt.h 30 May 2007 16:26:03 -0000
@@ -269,15 +269,15 @@ typedef struct BtLock BtLock;
*/
struct MemPage {
u8 isInit; /* True if previously initialized. MUST BE FIRST! */
- u8 idxShift; /* True if Cell indices have changed */
u8 nOverflow; /* Number of overflow cell bodies in aCell[] */
- u8 intKey; /* True if intkey flag is set */
- u8 leaf; /* True if leaf flag is set */
- u8 zeroData; /* True if table stores keys only */
- u8 leafData; /* True if tables stores data on leaves only */
- u8 hasData; /* True if this page stores data */
- u8 hdrOffset; /* 100 for page 1. 0 otherwise */
- u8 childPtrSize; /* 0 if leaf==1. 4 if leaf==0 */
+ u8 hdrOffset:7; /* 100 for page 1. 0 otherwise */
+ u8 zeroData:1; /* True if table stores keys only */
+ u8 childPtrSize:3; /* 0 if leaf==1. 4 if leaf==0 */
+ u8 leaf:1; /* True if leaf flag is set */
+ u8 idxShift:1; /* True if Cell indices have changed */
+ u8 intKey:1; /* True if intkey flag is set */
+ u8 leafData:1; /* True if tables stores data on leaves only */
+ u8 hasData:1; /* True if this page stores data */
u16 maxLocal; /* Copy of Btree.maxLocal or Btree.maxLeaf */
u16 minLocal; /* Copy of Btree.minLocal or Btree.minLeaf */
u16 cellOffset; /* Index in aData of first cell pointer */
|
2007-Sep-07 05:58:45 by anonymous:
Any word on applying this patch?
It saves 8 bytes per MemPage. For the default 2000 page cache it would save 16000 bytes. Larger page caches would save considerably more memory.
2007-Oct-26 21:08:03 by anonymous:
With this patch sizeof(PgHdr) is reduced by 4 bytes (from 48 bytes to 44 bytes) for gcc. No regressions. "make test" runs in the same amount of time.
Index: src/pager.c
===================================================================
RCS file: /sqlite/sqlite/src/pager.c,v
retrieving revision 1.393
diff -u -3 -p -r1.393 pager.c
--- src/pager.c 20 Oct 2007 13:17:55 -0000 1.393
+++ src/pager.c 26 Oct 2007 21:00:33 -0000
@@ -261,11 +261,11 @@ struct PgHdr {
PgHdr *pNextHash, *pPrevHash; /* Hash collision chain for PgHdr.pgno */
PagerLruLink free; /* Next and previous free pages */
PgHdr *pNextAll; /* A list of all pages */
- u8 inJournal; /* TRUE if has been written to journal */
- u8 dirty; /* TRUE if we need to write back changes */
- u8 needSync; /* Sync journal before writing this page */
- u8 alwaysRollback; /* Disable DontRollback() for this page */
- u8 needRead; /* Read content if PagerWrite() is called */
+ u8 inJournal:1; /* TRUE if has been written to journal */
+ u8 dirty:1; /* TRUE if we need to write back changes */
+ u8 needSync:1; /* Sync journal before writing this page */
+ u8 alwaysRollback:1; /* Disable DontRollback() for this page */
+ u8 needRead:1; /* Read content if PagerWrite() is called */
short int nRef; /* Number of users of this page */
PgHdr *pDirty, *pPrevDirty; /* Dirty pages */
#ifdef SQLITE_ENABLE_MEMORY_MANAGEMENT
2007-Oct-26 21:20:09 by anonymous:
How about a compromise. What about some optional setting like?
#ifndef OMIT_SQLITE_BITFIELDS
# define SQLITE_BITFIELD(X) : X
#else
# define SQLITE_BITFIELD(X)
#endif
...
u8 inJournal SQLITE_BITFIELD(1); /* TRUE if has been written to journal */
|
|
2388 |
code
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
1
|
3
|
ORDER BY fails on compound select
|
edit |
The query below was known to be working as late as 3.3.14, but in 3.3.17 it errors with "ORDER BY term number 1 does not match any result column".
Debugging with GDB shows that sqlite3NameFromToken(&pE->token) doesn't return anything, and pE->token looks pretty empty, so possibly this could be a parsing issue?
The query is:
SELECT docs.guid, docs.info, conversations.subject, conversations.date
FROM conversations
JOIN docs ON docs.guid = conversations.guid
WHERE conversations.guid IN (
SELECT docs.guid
FROM conversations
JOIN docs ON docs.guid = conversations.guid
WHERE conversations.date >= (SELECT date FROM conversations WHERE guid = ?6)
AND docs.collection = ?1
AND ((?2 == 0) OR (conversations.sources & ?2) != 0)
AND ((conversations.sources & ?3) == 0)
AND test_info_flags(docs.info, ?7, ?8)
LIMIT (?5 + 1)
)
UNION
SELECT docs.guid, docs.info, conversations.subject, conversations.date
FROM conversations
JOIN docs ON docs.guid = conversations.guid
WHERE conversations.guid IN (
SELECT docs.guid
FROM conversations
JOIN docs ON docs.guid = conversations.guid
WHERE conversations.date < (SELECT date FROM conversations WHERE guid = ?6)
AND docs.collection = ?1
AND ((?2 == 0) OR (conversations.sources & ?2) != 0)
AND ((conversations.sources & ?3) == 0)
AND test_info_flags(docs.info, ?7, ?8)
LIMIT ?4
)
ORDER BY conversations.date DESC, docs.guid DESC;
|
2007-May-27 16:27:23 by anonymous:
2 workarounds:
ORDER BY 4 DESC, 1 DESC;
or
SELECT docs.guid as "guid",
docs.info as "info",
conversations.subject as "subject",
conversations.date as "date"
...
ORDER BY date DESC, guid DESC;
Smaller test case:
create table x1(a);
select x1.a from x1 union select x1.a from x1 order by x1.a;
-- SQL error: ORDER BY term number 1 does not match any result column
-- error in latest 3.3.17+ CVS, but works in SQLite 3.2.2, 3.3.13
select x1.a from x1 union select x1.a from x1 order by a;
-- SQL error: ORDER BY term number 1 does not match any result column
-- has never worked in previous versions
select x1.a from x1 union select x1.a from x1 order by 1;
-- ok in all versions
select x1.a as a from x1 union select x1.a from x1 order by a;
-- ok in all versions
2007-May-27 16:46:19 by anonymous:
Does this query work on other popular databases?
create table x1(a integer);
select x1.a from x1 union select x1.a from x1 order by x1.a;
I'd expect "order by a" to work on most databases, but not "order by x1.a" because the table name would have been lost by the UNION. |
|
2383 |
code
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
3
|
3
|
Inconsistent conversion of BLOB revisited
|
edit |
BLOBs of function results are converted as UTF-8 even if the encoding is UTF-16.
$ ./sqlite3
SQLite version 3.3.17
Enter ".help" for instructions
sqlite> pragma encoding = 'UTF-16BE';
sqlite> select quote(cast(cast('ab' as blob) as text)); -- OK
'ab'
sqlite> select quote(cast(a as text)) from (select X'00610062' a); -- OK
'ab'
sqlite> select quote(cast(X'00610062' as text)); -- fixed by [3975]
'ab'
sqlite> select quote(cast(substr(X'110061006222', 2, 4) as text)); -- NG
''
sqlite> select quote(cast(substr(X'11616222', 2, 2) as text));
'ab'
sqlite> select quote(upper(substr(X'11616222', 2, 2)));
'AB'
|
|
2381 |
doc
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
3
|
3
|
'VACUUM' aborts an active transaction.
|
edit |
VACUUM aborts an active transaction. I'm not sure if this is the intended behavior. I didn't see any documentation to this effect.
sqlite> .sc
CREATE TABLE bar ( c1 integer primary key not null );
sqlite> select max(oid) from bar;
count(oid)
----------
240
sqlite> begin;
sqlite> delete from bar;
sqlite> select max(oid) from bar;
mcount(oid)
----------
0
sqlite> vacuum;
SQL error: cannot VACUUM from within a transaction
sqlite> select max(oid) from bar;
count(oid)
----------
240
|
|
2378 |
code
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
2
|
2
|
Quoted fields come back corrupted, using GROUP BY
|
edit |
Description:
When executing a query, where field names are quoted, and using GROUP
BY, the field names are returned with quotes around.
SQLite version:
SQLite support => enabled
PECL Module version => 2.0-dev $Id: sqlite.c,v 1.166.2.13.2.7 2007/03/06 02:17:13 stas Exp $
SQLite Library => 2.8.17
SQLite Encoding => iso8859
Reproduce code
<?php
$db = sqlite_open(":memory:");
sqlite_query($db, '
CREATE TABLE test (
id INTEGER PRIMARY KEY
)
');
sqlite_query($db, "INSERT INTO test (id) VALUES (1)");
$result = sqlite_query($db, 'SELECT "id" FROM "test" GROUP BY "id"');
var_dump(sqlite_fetch_array($result, SQLITE_ASSOC));
Expected result
array(1) {
["id"]=>
string(1) "1"
}
Actual result
array(1) {
[""id""]=>
string(1) "1"
}
|
2007-May-21 18:14:27 by anonymous:
Corrupted is probably not the right term, but the fields are returned with quotes around them in sqlite3 as well when group by is used on a quoted column:
SQLite version 3.3.17
Enter ".help" for instructions
sqlite> .header on
sqlite> create table t1(a);
sqlite> insert into t1 values(1);
sqlite> select "a" from t1;
a
1
sqlite> select "a" from t1 order by 1;
a
1
sqlite> select "a" from t1 group by 1;
"a"
1
sqlite> select "a" from t1 group by 1 order by 1;
"a"
1
sqlite> select "a" from t1 group by a;
"a"
1
|
|
2377 |
build
|
active
|
2007 May
|
pweilbacher
|
|
2007 Jul
|
|
4
|
3
|
Allow easy DLL build on OS/2
|
edit |
Makefile.in contains a target to build a DLL on Windows but unfortunately it doesn't work for OS/2. Current GCC versions use a calling convention that prepends underscores and these need to go into the .def file. To make a nice DLL header some extra lines in the .def file would be nice, too, that are probably incompatible with Windows linkers. Finally, to make the DLL usable we need to create an import library .lib .
As a nice-to-have feature I would like the DLL to be named after the VERSION but without the dot, as I expect DLLs from version 3.0.x to be imcompatible with 3.3.x or other future 3.x versions... I don't know a clever way to do that other than introducing a new variable into configure.ac and Makefile.in. |
2007-Jul-03 23:42:20 by pweilbacher:
SQLite releases for OS/2 are now built from the amalgamation, so this is only useful for checks of the CVS code between releases.
Not sure if it still makes sense to check this in, but at least the patch can stay attached to the ticket for possible future reference. |
|
2376 |
code
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
3
|
3
|
-batch doesn't work soon enough
|
edit |
on Microsoft XP,
given any.db
and a batch file bug.bat
containing
sqlite3 -batch -init bug.rc any.db "select 1;"
and bug.rc containing
.mode column
Running bug.bat gives the message "Loading resources from bug.rc"
I put in "-batch" so that the "Loading..." message would be suppressed, but it printed anyway. |
|
2374 |
code
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
5
|
5
|
"ALTER TABLE foo RENAME TO bar" will quote bar (ie. 'bar')
|
edit |
Cosmetic issue.
When a table is renamed, its representation in the schema ends up being quoted. Whilst this is harmless it also seems to be unnecessary?
sqlite> create table foo ( c1 integer );
sqlite> .sc
CREATE TABLE foo ( c1 integer );
sqlite> alter table foo rename to bar;
sqlite> .sc
CREATE TABLE 'bar' ( c1 integer );
sqlite> select oid,sql from sqlite_master;
rowid sql
---------- ---------------------------------
1 CREATE TABLE 'bar' ( c1 integer )
|
|
2373 |
new
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
4
|
4
|
"create table as explain <expr>" doesn't work
|
edit |
When using EXPLAIN to try to figure out why/when indices are being used on some tables and not all sometimes I get a lot of data returned.
It would be useful to be able to store this in a table so I can actually use SQL itself to examine the differences in the results I get. |
|
2372 |
code
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
4
|
4
|
sqlite3TestLockingStyle not used if SQLITE_FIXED_LOCKING_STYLE defined
|
edit |
static function sqlite3TestLockingStyle() is not used if SQLITE_FIXED_LOCKING_STYLE is defined. It should probably be wrapped in:
#ifndef SQLITE_FIXED_LOCKING_STYLE |
|
2371 |
code
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
2
|
2
|
sqlite3_errcode() and sqlite3_errmsg() return unexpected results
|
edit |
The manual says that sqlite3_step() directly returns explicit error code if the query has been prepared with the new API sqlite3_prepare_v2().
Subsequently, the functions sqlite3_errcode() and sqlite3_errmsg() should return the correct appropriate error values as well, which they don't - instead something not matching the error is returned. One has to call sqlite3_reset() to get the correct values which should be unnecessary.
See the example output below :
sqlite3_step: result rc = 19, errcode = 1, errmsg = SQL logic error or missing database
sqlite3_reset: result rc = 19, errcode = 19, errmsg = PRIMARY KEY must be unique
Code for this example:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sqlite3.h>
int
main(int argc, char **argv)
{
sqlite3 *db;
int rc, errcode;
sqlite3_stmt *stmt;
const char *pztail;
char *query;
const char *errmsg;
rc = sqlite3_open("test.db", &db);
rc = sqlite3_exec(db, "create table t (x integer not null primary key)", NULL, NULL, NULL);
rc = sqlite3_exec(db, "insert into t values(1)", NULL, NULL, NULL);
query = "insert into t values(?)";
rc = sqlite3_prepare_v2(db, query, strlen(query), &stmt, &pztail);
if( rc!=SQLITE_OK ){
fprintf(stderr, "SQL error: %d\n", rc);
exit(1);
}
rc = sqlite3_bind_int(stmt, 1, 1);
if( rc!=SQLITE_OK ){
fprintf(stderr, "SQL error: %d\n", rc);
exit(1);
}
rc = sqlite3_step(stmt);
errcode = sqlite3_errcode(db);
errmsg = sqlite3_errmsg(db);
printf("sqlite3_step: result rc = %d, errcode = %d, errmsg = %s\n",
rc, errcode, errmsg);
rc = sqlite3_reset(stmt);
errcode = sqlite3_errcode(db);
errmsg = sqlite3_errmsg(db);
printf("sqlite3_reset: result rc = %d, errcode = %d, errmsg = %s\n",
rc, errcode, errmsg);
}
|
|
2363 |
code
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
3
|
3
|
Couldn't build 3.3.17 on Cygwin/Vista
|
edit |
I didn't see anything quite resembling this on a cursory scan thru the buglist; pardon my goof if it's a duplicate.
When I tried to build on Cygwin on Vista, things got to the install phase, and then the Makefile tried to execute
cc sqlite3.c -o sqlite3
which didn't appear to be a defined rule in the Makefile. This then failed because of a lack of a main program, and the install failed.
After a quick scan through the Makefile, I decided to change the target for the install rule to
install: sqlite3$(TEXE) libsqlite3.la sqlite3.h ${HAVE_TCL:1=tcl_install}
which seemed to remedy the problem.
Suggested fix: modify Makefile as shown above. |
2007-May-23 14:29:20 by anonymous:
Another vote for this |
|
2352 |
code
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
5
|
3
|
timeout just 500 msec to soon
|
edit |
After upgrading from 3.3.12 to 3.3.17, the setting of a timeout behaves differently. It occurs exactly 500 msecs sooner. Of course assuming the database is locked and the timeout is set to a value larger than 500 msecs. |
|
2351 |
secure
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
2
|
2
|
UTF-16 convertor accepts malformed UTF-8 sequence
|
edit |
UTF encoding convertor accepts some invalid sequences of UTF-8.
$ ./sqlite3 -version
3.3.17
$ cat test.sql
select hex(a), hex(b), a == b from (select '<CE><B1>' a, '<D0><31>' b);
pragma encoding = 'UTF-16';
select hex(a), hex(b), a == b from (select '<CE><B1>' a, '<D0><31>' b);
$ ./sqlite3 < test.sql
CEB1|D031|0
CEB1|CEB1|1
It's necessary to validate subsequent bytes. |
|
2350 |
code
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
1
|
1
|
Temp files not deleted on WinCE
|
edit |
When using SQLite 3.3.17 on WinCE device temp files end up being accumulated in Temp directory, eventually filling up device's open file quota (999?) and making further operation that requires creation of files impossible.
I have noticed that after a while all queries start failing on the device although if I copied the database to PC and tried the same query I had no problems with it. Started tracing through the code and noticed that sqlite3WinOpenExclusive() is consistently failing to create a file (CreateFileW() would always fail). It turned out that Temp directory was full of 0 length temp files -- after deleting all of them device started working again for a while.
Then started looking for the cause -- winceDestroyLock() never gets to execute DeleteFileW() and delete the file even though pFile->zDeleteOnClose is set because check on the top of the winceDestroyLock() function (if (pFile->hMutex) ) always fails thanks to pFile->hMutex being 0. |
sqlite3WinOpenReadWrite() calls winceCreateLock() on temporary file (zFilename ) but sqlite3WinOpenExclusive() doesn't hence winceDestroyLock() cannot delete temporary file.
sqlite3PagerClose() contains this piece of commented out code:
/* Temp files are automatically deleted by the OS
** if( pPager->tempFile ){
** sqlite3OsDelete(pPager->zFilename);
** }
*/
Comment is not true for WinCE as WinCE doesn't support FILE_ATTRIBUTE_TEMPORARY and FILE_FLAG_DELETE_ON_CLOSE flags. Perhaps it should be surrounded with #if OS_WINCE/#endif instead of being commented out?
2007-May-14 00:09:20 by anonymous:
Tried re-enabling that piece of code in sqlite3PagerClose() and it doesn't help.
Looks like even file handles for temporary files never get closed on WinCE so not only number of temporary file in Temp directory just keeps growing but also filed descriptor for each of them remains open, draining system resources (consistent with observed behavior of rapid and nasty system performance deterioration).
It appears that sqlite3VdbeFreeCursor() always exits immediately because pCx is always NULL and thus sqlite3BtreeClose() never gets called:
void sqlite3VdbeFreeCursor(Vdbe *p, Cursor *pCx){
if( pCx==0 ){
return;
}
if( pCx->pCursor ){
sqlite3BtreeCloseCursor(pCx->pCursor);
}
if( pCx->pBt ){
sqlite3BtreeClose(pCx->pBt);
}
sqlite3BtreeClose() then calls sqlite3PagerClose() which probably explains why re-enabling that code doesn't help -- sqlite3PagerClose() itself never gets called.
2007-May-14 05:16:59 by anonymous:
Did some comparison between operation of the SQLite on WinXP and WinCE.
Comment in previous remark about sqlite3VdbeFreeCursor() always exiting immediately because pCx is always NULL is not correct. pCX is NULL most of the time but this is true for both WinXP and WinCE. WinXP has no problems getting rid of its temp files thanks to its support for FILE_ATTRIBUTE_TEMPORARY and FILE_FLAG_DELETE_ON_CLOSE flags. WinCE also does get its temp file descriptors closed (previous statement incorrect on that account too), it's just that its temp files do not get cleaned up automatically. Initial statement that this was caused because of winceDestroyLock() actually is correct.
Temp files are opened with sqlite3WinOpenExclusive() which DOESN'T use mutex (instead of with sqlite3WinOpenReadWrite() which DOES use mutex) so part of winClose() that was supposed to take care of deleting files after handle is closed (i.e. calling winceDestroyLock() ) doesn't work:
static int winClose(OsFile **pId){
winFile *pFile;
int rc = 1;
if( pId && (pFile = (winFile*)*pId)!=0 ){
int rc, cnt = 0;
OSTRACE2("CLOSE %d\n", pFile->h);
do{
rc = CloseHandle(pFile->h);
}while( rc==0 && cnt++ < MX_CLOSE_ATTEMPT && (Sleep(100), 1) );
#if OS_WINCE
winceDestroyLock(pFile);
#endif
OS_WINCE part should go something like this (although probably not exactly like this as this feels like an ugly hack):
#if OS_WINCE
if (pFile->hMutex){
winceDestroyLock(pFile);
}else{
if( pFile->zDeleteOnClose ){
DeleteFileW(pFile->zDeleteOnClose);
sqliteFree(pFile->zDeleteOnClose);
pFile->zDeleteOnClose = 0;
}
}
#endif
2007-May-14 05:20:33 by anonymous:
Tried the code from the previous remark and it does clean up Temp directory!
I also tried uncommenting that piece of code in sqlite3PagerClose() mentioned in the first remark and it looks like that temp files it tries to delete are never there. I'm guessing that that piece of code can remain commented out. Will keep an eye on it -- in case temp files still eventually start accumulating again even after the fix from previous remark is applied I'll reconsider. |
|
2342 |
doc
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
1
|
1
|
Document that prepared incremental vacuum needs multiple sqlite3_step
|
edit |
Unlike other PRAGMA commands, an sqlite3_prepare()ed PRAGMA incremental_vacuum(x); requires x calls to sqlite3_step to vacuum all x pages, or until sqlite3_step no longer returns SQLITE_ROW .
Maybe it is worth explicitly pointing this out in the documentation in order to avoid confusion? |
|
2340 |
code
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
3
|
3
|
"./configure && make testfixture" link problem
|
edit |
Until the (extremely welcome) sqlite3 blob I/O functionality was checked in, it was possible to run this command on a clean source tree:
./configure && make testfixture
But it now produces these unresolved externals:
./src/tclsqlite.c:297: warning: excess elements in struct initializer
./src/tclsqlite.c:297: warning: (near initialization for `IncrblobChannelType')
/tmp/ccmyzR97.o: In function `test_blob_read':
/sqlite/cvs/sqlite/./src/test1.c:1545: undefined reference to `_sqlite3_blob_read'
/tmp/ccmyzR97.o: In function `test_blob_write':
/sqlite/cvs/sqlite/./src/test1.c:1592: undefined reference to `_sqlite3_blob_write'
/tmp/ccb5dcDK.o: In function `incrblobClose':
/sqlite/cvs/sqlite/./src/tclsqlite.c:156: undefined reference to `_sqlite3_blob_close'
/tmp/ccb5dcDK.o: In function `incrblobInput':
/sqlite/cvs/sqlite/./src/tclsqlite.c:194: undefined reference to `_sqlite3_blob_bytes'
/sqlite/cvs/sqlite/./src/tclsqlite.c:202: undefined reference to `_sqlite3_blob_read'
/tmp/ccb5dcDK.o: In function `incrblobOutput':
/sqlite/cvs/sqlite/./src/tclsqlite.c:226: undefined reference to `_sqlite3_blob_bytes'
/sqlite/cvs/sqlite/./src/tclsqlite.c:235: undefined reference to `_sqlite3_blob_write'
/tmp/ccb5dcDK.o: In function `incrblobSeek':
/sqlite/cvs/sqlite/./src/tclsqlite.c:264: undefined reference to `_sqlite3_blob_bytes'
/tmp/ccb5dcDK.o: In function `DbObjCmd':
/sqlite/cvs/sqlite/./src/tclsqlite.c:322: undefined reference to `_sqlite3_blob_open'
collect2: ld returned 1 exit status
make: *** [testfixture.exe] Error 1
The 2 warnings related to src/tclsqlite.c:297 also seem to indicate a problem.
I'm using Tcl 8.4. |
2007-May-06 21:16:01 by anonymous:
Workaround - hack the generated Makefile to use:
# Compiler options needed for programs that use the TCL library.
#
TCC += -I/usr/local/include -DSQLITE_OMIT_INCRBLOB=1
|
|
2336 |
warn
|
active
|
2007 May
|
anonymous
|
|
2008 Jan
|
|
4
|
4
|
Compiler warnings on strcpy(), sprintf(), et al.
|
edit |
OpenBSD's gcc compiler reports link warnings concerning potential insecure use of certain functions that have a history of abuse, such as strcpy, strcat, sprintf. It would be nice if SQLite could use the more secure version when possible.
/home/achowe/Projects/org/sqlite/lib/libsqlite3.a(util.o)(.text+0x184): In function `sqlite3StrDup':
: warning: strcpy() is almost always misused, please use strlcpy()
/home/achowe/Projects/org/sqlite/lib/libsqlite3.a(os_unix.o)(.text+0x822): In function `sqlite3UnixTempFileName':
: warning: sprintf() is often misused, please use snprintf() |
There was no misuse of these functions. But we'll get rid of them
to avoid the library dependency.
For those that think that the use of strcpy() is a security problem:
if you will check the diffs for this check-in you will see that by
avoiding the use of strcpy() we have made the code more obtuse and
more likely to contain a security bug, not the other way around. But
at least now the compiler will not give warnings about strcpy()...
2007-May-04 15:43:08 by anonymous:
Some are still left in fts1.c and fts2.c.
2008-Jan-07 10:54:43 by anonymous:
SQLite 3.5.4 now generates new warnings on OpenBSD concerning unsafe functions.
gcc -g -O2 -o lemon ./tool/lemon.c
/tmp//cco18706.o(.text+0x14df): In function `ErrorMsg':
tool/lemon.c:1327: warning: vsprintf() is often misused, please use vsnprintf()
/tmp//cco18706.o(.text+0x1655): In function `handle_D_option':
tool/lemon.c:1378: warning: strcpy() is almost always misused, please use strlcpy()
/tmp//cco18706.o(.text+0x14a2): In function `ErrorMsg':
tool/lemon.c:1319: warning: sprintf() is often misused, please use snprintf()
/tmp//cco18706.o(.text+0x3918): In function `file_makename':
tool/lemon.c:2678: warning: strcat() is almost always misused, please use strlcat() |
|
2333 |
new
|
active
|
2007 May
|
anonymous
|
|
2007 May
|
|
5
|
4
|
support memory mapped files
|
edit |
Both Unix and Windows support memory mapped files, i.e. you can load file into memory and then operate on the memory while system reads and writes data from/to a file.
It would be useful if Sqlite could support this -- the user would load file to memory (map file) and then open a database with not a filename but handle to this memory-map.
Reason of this wish: I have read-only database which takes too much time for the first load. Any next load (not long from the first one) is quite fast. So I would like to map the entire database into memory and keep it resident (i.e. database would be in memory even my app quits). This way any load (except the first) would be fast.
In other words it would be a permanent database (the whole database) cache. |
2007-May-03 11:27:36 by drh:
The size of memory mapped files is limited by the address space
of the underlying CPU. So on a 32-bit machine, databases larger
than 4GiB are not accessible using memory mapped files. |
|
2329 |
new
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
5
|
4
|
add a feature to .dump : partial dumps
|
edit |
Hi,
I would like to request a feature related to the .dump command
introduction: ;-)
I have a large database (few GB) and I only remove rows from it.
since I forgot to use the pragma auto_vacuum, I am creating using .dump another database that has the triggers and pragmas I needed.
okay. so, this is slow. probably mainly because of the millions of inserts it needs to perform.
the feature request:
partial .dumps - that is, you specify how many rows or how many megabytes to dump. this should add a begin transaction and a commit at the end of each dumpfile, and enumerate them as well.
for example:
sqlite3 mylarge.db .partialdump --rows=40000 > dumpfile.sql<enter>
dumping.. please wait
- dumping first 40000 rows to file dumpfile.001.sql ....done
- dumping second 40000 rows to file dumpfile.002.sql ....done
etc..
hope this is obvious enough. if you need more info contact me.
I know sqlite tries to be minimal and to the point, but this is a good feature and very handy. (dumping to text and then splitting can take too much space and then impractical)
Thanks, Kobi |
|
2328 |
code
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
1
|
1
|
Makefile sqlite3.c target breakage for C++
|
edit |
This is generated by "make sqlite3.c":
#if 0
extern "C" {
#endif
|
2007-Apr-29 06:02:20 by anonymous:
If the entire sqlite3.c almalgomation is wrapped with:
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif
then it could be compiled with a C++ compiler.
Please close this ticket if you did not intend to have this capability. |
|
2327 |
new
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
anonymous
|
2
|
1
|
"DELETE" operation makes memory rise
|
edit |
First declare a standard SQL script: delete from TableName where ....;
Then calling repeatedly the sqlite3_exec() to process this "DELETE" operation.
Surprisely the memory was rising fast, and couldn't be freed even the program exitted. |
|
2326 |
doc
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
a.rottmann
|
5
|
2
|
miss one word 'list'
|
edit |
in documentation sqlite3: A command-line access program for SQLite
The sqlite3 program is able to show the results of a query in eight different formats: "csv", "column", "html", "insert", "line", "tabs", and "tcl".
missed one format: "list"
it should be:
The sqlite3 program is able to show the results of a query in eight different formats: "csv", "column", "html", "insert", "line", "list", "tabs", and "tcl". |
|
2322 |
code
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
1
|
1
|
Windows error: datetime('2000-10-29 06:00:00','localtime')
|
edit |
NY time zone.
Windows (from http://sqlite.org/sqlite-3_3_17.zip)
SELECT coalesce(datetime('2000-10-29 06:00:00','localtime'),'NULL');
2000-10-29 02:00:00
Linux (from latest CVS, same TZ)
SELECT coalesce(datetime('2000-10-29 06:00:00','localtime'),'NULL');
2000-10-29 01:00:00
make test errors on Windows only:
date-6.2...
Expected: [{2000-10-29 01:00:00}]
Got: [{2000-10-29 02:00:00}]
date-6.3...
Expected: [{2000-04-02 01:59:00}]
Got: [{2000-04-02 02:59:00}]
date-6.6...
Expected: [{2000-10-29 07:00:00}]
Got: [{2000-10-29 06:00:00}]
date-6.7...
Expected: [{2000-04-02 06:59:00}]
Got: [{2000-04-02 05:59:00}]
|
2007-Apr-26 23:09:12 by anonymous:
Confirmed Windows bug on Windows 2000 in NY time zone with Y2K7DST OS patch.
2007-Apr-27 22:03:25 by drh:
Do I correctly understand the previous remark to say that this
is confirmed to be a bug in Windows, not a bug in SQLite? It is
identical code in SQLite for both operating systems, so I would
certainly suspect that the problem is in windows and not in SQLite.
But it would be nice to have confirmation of this before closing
the ticket.
2007-Apr-28 03:19:06 by anonymous:
I meant to write "This erroneous SQLite datetime() output can also be seen on my Windows 2000 machine."
Does it work correctly for you under Windows XP or 2000 with the DST patch?
OS bug or not, it would be strange to not have the datetime() function correctly on a primary platform. If that were the case, it would be better to #ifdef it out of the Windows compile altogether.
2007-Apr-28 03:59:27 by anonymous:
This is a bigger mess than I thought.
http://groups.google.com/group/perl.perl5.porters/msg/e632557614474014?hl=en&
Key phrase:
"This API only provides the transition times according to the current
DST rules. There is no database of historical transition times. That
means that localtime() applied to previous years will use the new
transition times even for old timestamps."
Please don't close this bug. Perhaps some industrious Windows programmer will have a correct solution for it one day. But in the meantime, Windows SQLite users should be aware of it. |
|
2320 |
code
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
drh
|
1
|
1
|
sqlite3_open(sFN_with_umlaut)
|
edit |
Do it in a standard MS Visual Studio Project:
0. CString sFnWithUmlaut = "c:\\long path\\path with umlauts äÄ\\db";
1. call sqlite3_open(sFnWithUmlaut);
2. db cannot be opened, because the transformation functions
utf8ToUnicode/unicodeToUtf8
work incorrect
Is there a way to correct this error on win32?
Is there a workaround?
For a solution thanks in advance...
|
2007-Apr-25 20:21:24 by anonymous:
The functions work correctly, but you are not using them in the correct way. The parameter to sqlite3_open function should be UTF8 string, but you are passing one that is specific to your code page. |
|
2313 |
build
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
3
|
3
|
readline.h is not properly detected
|
edit |
This is actually an old issue i also had with 2.8.15.
configure says "checking for readline.h... no", but it really needs to look for readline/readline.h (or both?)
this is easily fixed with "--with-readline-inc=-I/path/to/include" although the actual syntax for this is a bit unusual/unintuitive) but such "fix" should not be needed as i had these in my environment:
CPPFLAGS="-I/path/to/include"
CFLAGS="-I/path/to/include"
(The library was found by configure, thanks to my LDFLAGS environment setting which is similar to the above.) |
|
2310 |
code
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
anonymous
|
4
|
4
|
Problem installing on AIX 5.3, ML5 after successful compile with xlc
|
edit |
After performing the suggested edits to the Makefile (from Tom Poindexter 2003-12-17):
edit Makefile, change the TCC macro:
TCC = xlc -q32 -qlonglong -D_LARGE_FILE=1 -D_LARGE_FILES=1 -DUSE_TCL_STUBS=1 -O2 -DOS_UNIX=1 -DOS_WIN=0 -DHAVE_USLEEP=1 -I. -I${TOP}/src
Version 3.3.15 compiled perfectly. However, a make install gave me this:
<root@tailinn 14:41:21>: /data/bld
--> make install
tclsh ../sqlite-3.3.15/tclinstaller.tcl 3.3
couldn't open ".libs/libtclsqlite3.so": no such file or directory
while executing
"open $LIBFILE"
invoked from within
"set in [open $LIBFILE]"
(file "../sqlite-3.3.15/tclinstaller.tcl" line 23)
make: 1254-004 The error code from the last command is 1.
I had to edit line 8 of ../sqlite-3-3-15/tclinstaller.tcl by adding a ".0" to the end. Then it installed perfectly. |
2007-Apr-19 20:47:24 by anonymous:
Haven't used AIX or xLC for 15 years - does IBM still make UNIX machines? |
|
2308 |
build
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
4
|
3
|
make sqlite3.c recreates sqlite3.c even though nothing changed
|
edit |
When building the amalgamized sqlite3.c source file, make will recreate the sqlite3.c source file each time it's run. When using this as part of a larger build process, this is annoying, since it will result in unnecessary compilations.
The fix is to rename the makefile target target_source to tsrc to make sure make will be able to properly detect the dependencies. Below is a patch for Makefile.in that fixes this:
--- Makefile.in 19 Apr 2007 10:20:59 -0000 1.167
+++ Makefile.in 19 Apr 2007 11:08:50 -0000
@@ -296,14 +296,14 @@
# files are automatically generated. This target takes care of
# all that automatic generation.
#
-target_source: $(SRC) parse.c opcodes.c keywordhash.h $(VDBEHDR)
+tsrc: $(SRC) parse.c opcodes.c keywordhash.h $(VDBEHDR)
rm -rf tsrc
mkdir -p tsrc
cp $(SRC) $(VDBEHDR) tsrc
rm tsrc/sqlite.h.in tsrc/parse.y
cp parse.c opcodes.c keywordhash.h tsrc
-sqlite3.c: target_source $(TOP)/tool/mksqlite3c.tcl
+sqlite3.c: tsrc $(TOP)/tool/mksqlite3c.tcl
tclsh $(TOP)/tool/mksqlite3c.tcl
# Rules to build the LEMON compiler generator
|
2007-Apr-20 06:01:23 by anonymous:
Make does not deal well with directories as dependencies (because their last modification time doesn't mean what Make thinks it means). It would be much better to use a stamp file. |
|
2304 |
new
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
1
|
1
|
resolve "databas is locked" problem under DEFERRED transaction
|
edit |
under DEFERRED transaction,
if there are multiple thread immediate execute writing operation after BEGIN statement,
sqlite will direct kick in "database is locked" exception,
but if you execute some reading operation before writing operation,
it works well,
could BEGIN statement acquire a shared lock and solve this problem?
{quote:
relative mail archive
http://www.mail-archive.com/sqlite-users@sqlite.org/msg21768.html
} |
|
2303 |
code
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
1
|
1
|
Encrypted databases: No page cache due to problem in pagerSharedLock
|
edit |
With codec encryption enabled, pagerSharedLock always invalidates the page cache, even if no changes have occured since the cache was last valid and it would be safe to retain the cached pages. This in fact disables the newly improved page cache for encrypted databases and slows down performance.
The problem occurs because pagerSharedLock reads the change counter directly from the database file without codec decryption. Since the codec always encrypts full pages, the 4 bytes at offset 24 are read as encrypted data and do not match Pager->iChangeCount .
To solve, codecs would be required to store the 4 bytes at offset 24 of page 1 unencrypted. This would, however, render those 4 bytes vulnerable to attacks. It would therefore be more secure if pagerSharedLock could decrypt page one prior to extracting the change counter. |
Check-in [3844]
does not fix the problem to reset the cache if the codec is changed but the database file is not. The following procedure for opening an encrypted database no longer works with the improved page cache:
- Open an encrypted database. Do not set a key yet as we (pretend to) believe that the database is not encrypted.
- Access the DB for reading. This returns
SQLITE_NOTADB , so we conclude that the DB is encrypted.
- Attach the proper codec using
sqlite3CodecAttach .
- Access the DB again. Problem: This still returns
SQLITE_NOTADB because the old page cache is still in use and is not reloaded.
The codec change is not detected because the pager checks the unencrypted DB file instead of the decrypted page. The file of course did not change, but the decrypted page did because of the new codec. The cache should therefore be cleared.
A workaround would be possible if sqlite3CodecAttach could reset the page cache. Unfortunately, the method to do so (pager_reset ) is static to pager.c. It seems that there once was an external function sqlite3PagerReset (it is still defined in pager.h), but its implementation is unfortunately no longer available.
Could this be fixed in a way that pagerSharedLock checks the decrypted page 1 to see if the database has been modified or, alternatively, by reverting the static pager_reset back to the external sqlite3PagerReset ? |
|
2302 |
build
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
anonymous
|
4
|
4
|
sqlite3 does not honor configure --disable-threads anymore
|
edit |
In a non-threaded TCL build, the TEA configuration option --disable-threads is no longer honored. In version 3.3.12 this used to work:
(test) 49 % packa req sqlite3
couldn't load file "/usr/local/tcl/8.5a5-1/lib/sqlite3.3.15/libsqlite3.3.15.so": /usr/local/tcl/8.5a5-1/lib/sqlite3.3.15/libsqlite3.3.15.so: undefined symbol: pthread_create
(test) 50 % packa req -exact sqlite3 3.3.12
3.3.12
In new file tclsqlite3.c, line 11734, threading is hard-coded with
#define THREADSAFE 1
A workaround for non-threaded builds is to set this manually to
#define THREADSAFE 0
|
2007-Apr-15 17:03:07 by anonymous:
I encountered the same problem and I agree that this change is problematic and should be reverted.
2007-Apr-15 18:03:05 by drh:
Why is it such a problem that the library is threadsafe? Just because it is threadsafe
does not mean you are required to use threads, or anything like that. Everything continues
to work normally in a single threaded application. There is no measurable performance
impact. Why is it so important to you that the threading mutexes not be enabled?
2007-Apr-15 19:34:11 by anonymous:
In a shared library setting it's not such a big deal, but in a purely static binary it can pull in a fair bit of unwanted thread library code. Also, some embedded UNIX-like targets lack a pthreads implementation.
The autoconf default can be threadsafe instead of non-threadsafe. It would be nice if it respected the autoconf flag as it did before. |
|
2301 |
build
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
1
|
1
|
Latest cvs 3.3.15 fails lock4-1.3 test
|
edit |
export CFLAGS=-O3
./configure --prefix=/usr/local
make
make test
produces a single failure...
lock4-1.2... Ok
lock4-1.3...
Error: database is locked
lock4-999.1... Ok
|
2007-Apr-15 02:47:15 by anonymous:
which OS?
2007-Apr-15 11:31:46 by drh:
To amplify the previous comment, I observe that the test works fine for me on both
Linux (SuSE 10.1) and Mac OS-X x86. |
|
2299 |
build
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
1
|
1
|
Cannot compile sqlite-3.3.15 on linux rhel
|
edit |
My platform:
Linux 2.6.9-42.0.3.ELsmp #1 SMP Mon Sep 25 17:28:02 EDT 2006 i686 i686 i386 GNU/Linux
My gcc version:
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
My problem: I'm (ultimately) trying to get svntrac built and installed on this machine, but cannot compile the sqlite dependency.
If I follow the documented build procedure, namely:
1) Create sibling directory to source directory
2) Run ../sqlite-3.3.15/configure from build directory
3) Run make from build directory
I get build errors, mostly:
undefined reference to `__getreent' |
2007-Apr-13 17:20:23 by anonymous:
gcc -g -O2 -o lemon ../sqlite-3.3.15/tool/lemon.c
/tmp/ccOClNK1.o(.text+0x7c): In function `Action_new':
../sqlite-3.3.15/tool/lemon.c:344: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x153): In function `acttab_alloc':
../sqlite-3.3.15/tool/lemon.c:440: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x1ed): In function `acttab_action':
../sqlite-3.3.15/tool/lemon.c:455: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x223): In function `myassert':
../sqlite-3.3.15/tool/lemon.c:567: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x4e4): In function `acttab_insert':
../sqlite-3.3.15/tool/lemon.c:497: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x68f):../sqlite-3.3.15/tool/lemon.c:1362: more undefined references to `__getreent' follow
/tmp/ccOClNK1.o(.text+0x280f): In function `tplt_xfer':
../sqlite-3.3.15/tool/lemon.c:2980: undefined reference to `__ctype_ptr'
/tmp/ccOClNK1.o(.text+0x299a): In function `tplt_open':
../sqlite-3.3.15/tool/lemon.c:3026: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x2a54): In function `tplt_linedir':
../sqlite-3.3.15/tool/lemon.c:3042: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x2a5d):../sqlite-3.3.15/tool/lemon.c:3042: undefined reference to `__swbuf_r'
/tmp/ccOClNK1.o(.text+0x2a8b):../sqlite-3.3.15/tool/lemon.c:3041: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x2a93):../sqlite-3.3.15/tool/lemon.c:3041: undefined reference to `__swbuf_r'
/tmp/ccOClNK1.o(.text+0x2b68): In function `tplt_print':
../sqlite-3.3.15/tool/lemon.c:3061: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x2b71):../sqlite-3.3.15/tool/lemon.c:3061: undefined reference to `__swbuf_r'
/tmp/ccOClNK1.o(.text+0x2ba6):../sqlite-3.3.15/tool/lemon.c:3065: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x2bae):../sqlite-3.3.15/tool/lemon.c:3065: undefined reference to `__swbuf_r'
/tmp/ccOClNK1.o(.text+0x3196): In function `print_stack_union':
../sqlite-3.3.15/tool/lemon.c:3366: undefined reference to `__ctype_ptr'
/tmp/ccOClNK1.o(.text+0x3319):../sqlite-3.3.15/tool/lemon.c:3387: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x3ae0): In function `translate_code':
../sqlite-3.3.15/tool/lemon.c:3207: undefined reference to `__ctype_ptr'
/tmp/ccOClNK1.o(.text+0x447c): In function `ReportTable':
../sqlite-3.3.15/tool/lemon.c:3534: undefined reference to `__ctype_ptr'
/tmp/ccOClNK1.o(.text+0x44a3):../sqlite-3.3.15/tool/lemon.c:3535: undefined reference to `__ctype_ptr'
/tmp/ccOClNK1.o(.text+0x55d4):../sqlite-3.3.15/tool/lemon.c:3575: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x5800): In function `Symbol_new':
../sqlite-3.3.15/tool/lemon.c:4259: undefined reference to `__ctype_ptr'
/tmp/ccOClNK1.o(.text+0x5ba3): In function `Parse':
../sqlite-3.3.15/tool/lemon.c:2500: undefined reference to `__ctype_ptr'
/tmp/ccOClNK1.o(.text+0x5c2c):../sqlite-3.3.15/tool/lemon.c:2407: undefined reference to `__ctype_ptr'
/tmp/ccOClNK1.o(.text+0x619b):../sqlite-3.3.15/tool/lemon.c:1997: undefined reference to `__ctype_ptr'
/tmp/ccOClNK1.o(.text+0x61eb):../sqlite-3.3.15/tool/lemon.c:2201: undefined reference to `__ctype_ptr'
/tmp/ccOClNK1.o(.text+0x628e):../sqlite-3.3.15/tool/lemon.c:2027: more undefined references to `__ctype_ptr' follow
/tmp/ccOClNK1.o(.text+0x65b8): In function `Parse':
../sqlite-3.3.15/tool/lemon.c:2439: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x6603):../sqlite-3.3.15/tool/lemon.c:2415: undefined reference to `__ctype_ptr'
/tmp/ccOClNK1.o(.text+0x6628):../sqlite-3.3.15/tool/lemon.c:2415: undefined reference to `__ctype_ptr'
/tmp/ccOClNK1.o(.text+0x6baa):../sqlite-3.3.15/tool/lemon.c:2164: undefined reference to `__ctype_ptr'
/tmp/ccOClNK1.o(.text+0x7bad): In function `main':
../sqlite-3.3.15/tool/lemon.c:1419: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x7c65):../sqlite-3.3.15/tool/lemon.c:1445: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x7ca0):../sqlite-3.3.15/tool/lemon.c:1425: undefined reference to `__getreent'
/tmp/ccOClNK1.o(.text+0x7d4c):../sqlite-3.3.15/tool/lemon.c:1457: undefined reference to `__ctype_ptr'
/tmp/ccOClNK1.o(.text+0x7e4b):../sqlite-3.3.15/tool/lemon.c:1514: undefined reference to `__getreent'
collect2: ld returned 1 exit status
make: *** [lemon] Error 1
2007-Apr-15 13:51:08 by anonymous:
I am not real familiar with Red Hat, but that looks to me like a case of your C library headers being out of sync with the library proper. There are several different ways that could happen; I would guess that the most probable is that you installed a version of GCC by hand, it copied some of the C library headers to a private directory (GCC tends to do this when you build it from source, unfortunately) and then you installed a new version of the C library from packages.
2007-Apr-15 13:54:33 by anonymous:
To be clearer, I think this is a local installation problem, not a bug in SQLite. |
|
2297 |
code
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
drh
|
3
|
3
|
uninitialized var (with patch)
|
edit |
Warnings with amalgamation and NDEBUG. |
2007-Apr-12 21:21:29 by drh:
I looked at the suggested changes and I didn't find any
cases where it really was possible to use an uninitialized
variable, at least not in a harmful way. Did I overlook
something, or is this ticket just a request to silence
compiler warnings?
2007-Apr-13 00:08:36 by anonymous:
vdbe.c with n, n64, payloadSize and payloadSize64
sqlite3BtreeKeySize,sqlite3BtreeLast return are not checked. You can not be sure the pointer passed as second argument will be init depending on the return of restoreOrClearCursorPosition (btree.c).
page.c with ro
Compiled with -DNDEBUG, the return of sqlite3OsOpenReadWrite is not checked before making a move with 'ro'.
For sContext.zAuthContext in delete.c/update.c, you're the one.
gcc (compiler in general) warnings are quite usefull, i don't think it's a good idea to ignore them and accumulate danger. Perhaps one day, one line in a subroutine will modify some tricky behavior and (re)raise a previous checked warning, making it completely normal and 'under control'. |
|
2294 |
code
|
active
|
2007 Apr
|
anonymous
|
|
2007 Sep
|
|
2
|
1
|
segfault when destroying lock on WinCE with threads
|
edit |
DestroyLock emulation on WinCE platform releases the zDeleteOnClose file outside the mutex acquire section. This lead to frequent segfault when working with several databases concurrently.
Patch simply consists in moving code:
if( pFile->zDeleteOnClose ){
DeleteFileW(pFile->zDeleteOnClose);
sqliteFree(pFile->zDeleteOnClose);
pFile->zDeleteOnClose=NULL;
}
from winClose() (os_win.c:980) to winceDestroyLock(), inside scope of winceMutexAcquire(pFile->hMutex):
/* De-reference and close our copy of the shared memory handle */
UnmapViewOfFile(pFile->shared);
CloseHandle(pFile->hShared);
+ if( pFile->zDeleteOnClose ){
+ DeleteFileW(pFile->zDeleteOnClose);
+ sqliteFree(pFile->zDeleteOnClose);
+ pFile->zDeleteOnClose=NULL;
+ }
/* Done with the mutex */
winceMutexRelease(pFile->hMutex);
CloseHandle(pFile->hMutex);
pFile->hMutex = NULL;
|
2007-Apr-13 00:21:33 by anonymous:
Check in [3836]
fixes it for me. eTcl regression tests, related to running several sqlite database concurrently in several threads, are now passed while they were frequently segfaulting without it.
To help being confident with this blind commit, let's mention that exactly same patch has been introduced in eTcl built since a couple of monthes, to fix issue reported by WM2003 users, and all reported a correct fix. However, I did suggest the patch, so testing and feedback from others may help :-)
Also, note that [3836]
has a typo, requesting feedback in ticket #2249 instead of #2294
2007-Sep-25 03:24:09 by anonymous:
The fix doesn't work and should be reverted. Temporary files do not create locks, so when they are closed and hMutex is null, the winceDestroyLock() file is never called and the temporary files are not cleaned up properly. |
|
2288 |
code
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
4
|
2
|
FTS does not support REPLACE
|
edit |
Simple to replicate:
CREATE VIRTUAL TABLE fts_table USING fts2(text);
INSERT OR REPLACE INTO fts_table (rowid, text) VALUES (1, 'text1');
INSERT OR REPLACE INTO fts_table (rowid, text) VALUES (1, 'text2');
The first insert succeeds, the second fails. Also occurs with fts1. |
2007-Apr-10 15:27:10 by anonymous:
http://www.mail-archive.com/sqlite-users%40sqlite.org/msg23865.html |
|
2283 |
warn
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
1
|
1
|
Compile warning by VCToolkit2003
|
edit |
sqlite3.c
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5494) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5495) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5600) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5601) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5604) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5605) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5606) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5607) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5622) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5623) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5625) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5668) : warning C4244: 'initializing' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5674) : warning C4244: '=' : conversion from 'double' to 'time_t', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5785) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5791) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5883) : warning C4244: '+=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5889) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(5895) : warning C4244: '+=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(6104) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(9622) : warning C4244: '=' : conversion from 'u64' to 'unsigned char', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(9625) : warning C4244: '=' : conversion from 'u64' to 'unsigned char', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(9632) : warning C4244: '=' : conversion from 'u64' to 'u8', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(16030) : warning C4244: 'initializing' : conversion from 'i64' to 'LONG', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(16031) : warning C4244: 'initializing' : conversion from 'i64' to 'LONG', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(16071) : warning C4244: 'initializing' : conversion from 'i64' to 'LONG', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(16075) : warning C4244: 'function' : conversion from 'i64' to 'LONG', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(17312) : warning C4018: '<' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(17903) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(17908) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(18120) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(18128) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(18146) : warning C4018: '<' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(18264) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(18280) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(18668) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(18674) : warning C4244: 'return' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(18771) : warning C4018: '<=' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(19202) : warning C4018: '<=' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(20253) : warning C4018: '>' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(20470) : warning C4018: '<=' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(21671) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(21673) : warning C4244: 'function' : conversion from 'i64' to 'u32', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(23335) : warning C4018: '>' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(23335) : warning C4018: '<=' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(23977) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(23983) : warning C4018: '>' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(24117) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(24124) : warning C4018: '>' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(24437) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(24437) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(24439) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(24441) : warning C4244: 'function' : conversion from 'i64' to 'u32', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(24442) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(24442) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(24815) : warning C4018: '>' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(24976) : warning C4018: '>' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(25046) : warning C4244: '+=' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(25048) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(26605) : warning C4018: '>' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(27294) : warning C4244: '+=' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(27821) : warning C4101: 'rc' : unreferenced local variable
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(28087) : warning C4244: '=' : conversion from 'double' to 'i64', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(28325) : warning C4244: '=' : conversion from 'const i64' to 'double', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(28330) : warning C4244: '=' : conversion from 'const i64' to 'double', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(30422) : warning C4244: 'return' : conversion from 'i64' to 'u32', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(30479) : warning C4244: '=' : conversion from 'u64' to 'unsigned char', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(30644) : warning C4018: '>=' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(30646) : warning C4018: '>=' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(30671) : warning C4018: '<' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(30673) : warning C4018: '<' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(30717) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(30756) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(30860) : warning C4244: 'return' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(31019) : warning C4244: '=' : conversion from 'double' to 'i64', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(31056) : warning C4244: '=' : conversion from 'double' to 'u64', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(33652) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(33718) : warning C4018: '>=' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(33736) : warning C4018: '<' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(33751) : warning C4018: '<' : signed/unsigned mismatch
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(34173) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(34177) : warning C4244: '=' : conversion from 'i64' to 'u8', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(34279) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(34297) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(35189) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(35869) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(35875) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(36389) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(36403) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(46396) : warning C4244: 'initializing' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(46397) : warning C4244: 'initializing' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(46398) : warning C4244: 'initializing' : conversion from 'i64' to 'int', possible loss of data
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(56943) : warning C4005: 'ARRAYSIZE' : macro redefinition
D:\Ulti\SDK\Include\WinNT.h(950) : see previous definition of 'ARRAYSIZE'
D:\Ulti\MyApps\USQLite3\SQLite\sqlite3.c(58192) : warning C4244: '=' : conversion from 'u16' to 'unsigned char', possible loss of data
USQLite3: 2 file(s) built in (0:04.04), 2022 msecs / file, duration = 4586 msecs |
|
2282 |
code
|
active
|
2007 Apr
|
anonymous
|
|
2007 Apr
|
|
3
|
4
|
Update on view with no matching trigger does not raise error
|
edit |
Attempting to update a view with no triggers properly fails with the error
sqlite> update foo set key=key+1;
SQL error: cannot modify foo because it is a view
However, if a single trigger is added that contains a WHEN clause, then UPDATE statements that do not satisfy that WHEN clause silently succeed without raising any error.
sqlite> select 'Before:'; select * from foo; update foo set key=key+1; select 'After:'; select * from foo;
Before:
1|42|forty-two|42.0
2|69|sixty-nine|69.0
After:
1|42|forty-two|42.0
2|69|sixty-nine|69.0
|
2007-Apr-18 21:50:00 by anonymous:
Your desired behavior can be accomplished by changing your trigger to:
create trigger foo_update instead of update on foo
begin
select raise(ABORT, 'invalid key')
where old.key <> new.key;
update foo_backing set num=new.num, str=new.str, float=new.float, dirty=1
where key=new.key;
end;
2007-Apr-24 20:26:46 by anonymous:
I have come up with a sample patch that partially fixes this problem -- specifically, it raises an error if any rows affected by an update/delete against a view are not caught by any triggers. It does not handle uncaught inserts, however, because I couldn't quite figure out how to make that work (much of the logic for updates and deletes is almost identical, whereas the code for inserts is quite different.)
This patch adds/updates 76 lines across 4 files. I disclaim all copyright to these 76 lines. |
|
2280 |
new
|
active
|
2007 Mar
|
anonymous
|
|
2007 Mar
|
|
4
|
3
|
Check constraint failure message should include field name
|
edit |
When an insert or update fails due to a check constraint the error message only says that the insert/update failed. It would be nice if the error message included the field name related to the failed check constraint.
Thanks,
Sam |
2007-Mar-31 00:53:55 by drh:
Duplicate of ticket #2258 |
|
2274 |
todo
|
active
|
2007 Mar
|
anonymous
|
|
2007 Mar
|
drh
|
5
|
3
|
Sqlite segfaults consistently in FTS2
|
edit |
Sqlite segfaults consistently in FTS2
sqlite> delete from mail where subject_='backup failed';
bt
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00025726 in deleteTerms (v=0x404e20, pTerms=0xbfffe95c, iRowid=10503) at ./ext/fts2/fts2.c:1418
1418 return string_dup_n(s, strlen(s));
(gdb) bt
#0 0x00025726 in deleteTerms (v=0x404e20, pTerms=0xbfffe95c, iRowid=10503) at ./ext/fts2/fts2.c:1418
#1 0x00028c49 in fulltextUpdate (pVtab=0x404e20, nArg=1, ppArg=0x180e440, pRowid=0xbfffebf8) at ./ext/fts2/fts2.c:3678
#2 0x000541df in sqlite3VdbeExec (p=0x180de00) at ./src/vdbe.c:4877
#3 0x00012b46 in sqlite3_step (pStmt=0x180de00) at ./src/vdbeapi.c:236
#4 0x0001c392 in sqlite3_exec (db=0x400180, zSql=0x404850 "delete from mail where subject_='backup failed';", xCallback=0x3902 <callback>, pArg=0xbfffee94, pzErrMsg=0xbfffeddc) at ./src/legacy.c:78
#5 0x00006c86 in process_input (p=0xbfffee94, in=0x0) at ./src/shell.c:1649
#6 0x0000746f in main (argc=2, argv=0xbffff81c) at ./src/shell.c:1979
(gdb)
|
|
2270 |
build
|
active
|
2007 Mar
|
anonymous
|
|
2007 Mar
|
|
3
|
4
|
Build on Solaris 8 does not include other libs in .so build
|
edit |
Straightforward build on solaris:
# uname -a
SunOS ganga 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Blade-1000
# ../sqlite-3.3.13/configure --enable-gcc
# ../../tcl/8.4.14/bin/tclsh8.4
% load ./.libs/libtclsqlite3.so.0.8.6
couldn't load file "./.libs/libtclsqlite3.so.0.8.6": ld.so.1: ../../tcl/8.4.14/bin/tclsh8.4: fatal: relocation error: file ./.libs/libtclsqlite3.so.0.8.6: symbol fdatasync: referenced symbol not found
Just rerun gcc for the libtclsqlite with the same options as what libtool printed and add the fdatasync library that configure found (which was -lrt):
% exec gcc all-like-libtool -lrt
% load ./.libs/libtclsqlite3.so.0.8.6
%
I don't know why the build calls the library .0.8.6 - but that's not
holding me up - I just rename it to 3.so.3.13 |
2007-Mar-30 05:36:59 by anonymous:
#1802, #2041 and #2270 are the same basic issue: librt should get linked into libsqlite3.so |
|
2266 |
new
|
active
|
2007 Mar
|
anonymous
|
|
2007 Mar
|
anonymous
|
3
|
3
|
Add support for Row_Number() Over
|
edit |
Row_Number() Over is a windowing function included in the SQL:2003 standard. I need it to be able to rank order several groups by size, using a single query. I know SQLite does not support SQL:2003, but it would be nice to have at least this one function supported. |
2007-Mar-10 10:06:33 by anonymous:
You can easily write your own UDF using SQLite API. Here's an example if you need it right now:
typedef unsigned long long int rowNumberContext;
// aggregate step callback
void rowNumberStep(sqlite3_context *context, int argc, sqlite3_value **argv) {
// initialize or get aggregate function context
rowNumberContext *agg_context = (rowNumberContext*)sqlite3_aggregate_context(context, sizeof(rowNumberContext));
(*agg_context)++;
}
// aggregate final callback
void rowNumberFinal(sqlite3_context *context) {
sqlite3_result_int64(context, *((rowNumberContext *)sqlite3_aggregate_context(context, sizeof(rowNumberContext))));
}
// then just create function:
sqlite3_create_function(db_handle, "row_number", 0, SQLITE_ANY, null, null, rowNumberStep, rowNumberFinal);
I hope I get it right.
This piece of sample code has NOT been tested! Use it at your own risk.
The code above is a good implementation of count(*), but not row_number().
I think Row_Number() is one of the SQL2003 windowing functions. Implementing these would require modifications to the parser, compiler and vdbe layers of sqlite. Not possible using current APIs.
At the current time queries that use Row_Number() will have to be rewritten to use temp tables as intermediate steps. |
|
2258 |
new
|
active
|
2007 Feb
|
anonymous
|
|
2007 Mar
|
|
4
|
3
|
Include field name in check constraint failure message
|
edit |
When a check constraint on a column fails SQLite just responds with "constraint failed". It'd be nice if it included the column name for which constraint failed and possibly the value that failed to pass the constraint.
Thanks,
Sam |
|
2256 |
new
|
active
|
2007 Feb
|
anonymous
|
|
2007 Apr
|
drh
|
5
|
1
|
Add POSITION() function (SQL-92 standard)
|
edit |
Hi!
Just voting for POSITION() function.
It's mighty useful when you need to modify a field in real time with SUBSTR() function (for instance, when 'start' parameter of SUBSTR() function needs to be variable according to POSITION() function).
Many thanks!
Regards. |
2007-Mar-23 14:10:14 by anonymous:
Yes, this is a function which I often suffered from not being available. |
|
2254 |
new
|
active
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
5
|
4
|
ATTACH support IF NOT ATTACHED statement
|
edit |
It'd be nice if ATTACH supported an IF NOT ATTACHED option as in
ATTACH IF NOT ATTACHED 'C:\db\log.dat' AS Logs
so there'd be no harm in issuing an attach statement multiple times (and no need to query the database list to see if a database is already attached). |
|
2247 |
doc
|
active
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
3
|
3
|
documentation of DEFUALT cluase in CREATE TABLE should be fixed
|
edit |
The documentation for the CREATE TABLE statement at
http://www.sqlite.org/lang_createtable.html shows the syntax of the DEFAULT clause as
DEFAULT value
and the description says that value can be NULL, a string constant, a number, or one of three keyword values; CURRENT_DATE, CURRENT_TIME, or CURRENT_TIMESTAMP.
This is incorrect since the DEFAULT clause also allows value to be an expression in brackets. The syntax should be changed to something like
DEFAULT default_value
default_value := value | ( expression )
and the description should say that some expressions are allowed. In particular functions can be used as the expression. It should also be clarified when the DEFAULT clause functions are evaluated, at the time the create statement executes, or at the time a record is added to the table.
Note that not all expressions are allowed. In particular the ( select_statement ) form produces an error saying the default value is not constant, even though the apparently non-constant function random() is accepted.
sqlite> create table t2(id, b default ((select avg(a) from t1)));
SQL error: default value of column [b] is not constant
sqlite> create table t2(id, b default (random()));
sqlite>
Tests using a default function julianday('now') as a default show that the function is evaluated at the time the record is inserted. If that is the case, why can the select expression above not be evaluated each time a record is inserted to generate a default value? |
|
2246 |
doc
|
active
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
5
|
4
|
SQL docs for CREATE TABLE should include FOREIGN KEY syntax
|
edit |
The documentation on supported SQL for CREATE TABLE should include syntax for foreign keys since foreign keys are parsed. Of course it should say that the foreign keys are not enforced, but since they are parsed having the syntax in the documentation would be appropriate.
http://sqlite.org/lang_createtable.html
Thanks,
Sam |
|
2241 |
code
|
active
|
2007 Feb
|
scouten
|
|
2007 Mar
|
|
3
|
3
|
pragma integrity_check no longer affects command-line tool's exit code
|
edit |
With the 3.3.5 build, if you did the following:
sqlite3 /path/to/db "PRAGMA integrity_check;"
You seemed get a 1 result back on the command line if the check failed in any way (and 0 if it was "ok").
With 3.3.13, this doesn't seem to be the case, even if you specify the -bail command line parameter. (I also tried "PRAGMA integrity_check=1;", which is all I care about in this case.) I have a database with errors that returns 0 to the calling process (that is, the sqlite command line's main function returns 0).
We would like to see the 3.3.5 behavior return. |
2007-Mar-29 18:32:54 by drh:
I pulled versions of SQLite going back to 2006-01-01 and I could
not find one where the shell returned a non-zero exit code when
PRAGMA integrity_check failed. Are you sure that you do not
have a customized version of the 3.3.5 shell? |
|
2238 |
new
|
active
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
2
|
3
|
Streams as datbase
|
edit |
Would it be possible to allow the use of streams as a database source? |
2007-Feb-18 03:56:46 by anonymous:
You'll have to be more precise in what you mean by that.
SQLite needs to be able to do random access to the database data (ie seek all over the place according to how it is laid out).
It also needs the ability to have a journal file alongside the database which is used when writing to do a rollback, or even for readers to know that a rollback needs to be done.
I am not aware of any 'streams' that meet those criteria. |
|
2237 |
code
|
active
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
4
|
4
|
Test suite regressions using Tcl 8.5
|
edit |
Tcl 8.5, SQLite 3.3.13 CVS
printf-1.7.6...
Expected: [Three integers: (1000000) ( f4240) (3641100)]
Got: [Three integers: ( 1000000) ( f4240) (3641100)]
printf-1.8.6...
Expected: [Three integers: (999999999) (3b9ac9ff) (7346544777)]
Got: [Three integers: ( 999999999) (3b9ac9ff) (7346544777)]
printf-1.9.7...
Expected: [Three integers: ( 0) ( 0x0) ( 0)]
Got: [Three integers: ( 0) ( 0) ( 0)]
tcl-1.6...
Expected: [1 {syntax error in expression "x*"}]
Got: [1 {invalid bareword "x"
in expression "x*";
should be "$x" or "{x}" or "x(...)" or ...}]
|
|
2235 |
new
|
active
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
4
|
3
|
Missing xml support in FTS2 for the snippet function
|
edit |
The snippet function may output invalid characters when used for an xml stream (like xhtml).
Characters &, < and > need to be escaped (&, < >) in this context.
The modification proposed is to add a boolean parameter to the snippet function to disable/enable the XML processing mode ; for example, given :
insert into poem (name, text) values ('test', 'Xml string with special < > & entities') ;
select snippet(poem, '<strong>', '</strong>', '...', 1) from poem where text match 'xml' ;
output should be:
<strong>Xml</strong> string with special < > & entities
This modification does not affect the default behaviour of the snippet function.
Patch included. |
|
2233 |
new
|
active
|
2007 Feb
|
anonymous
|
|
2007 Mar
|
|
4
|
3
|
extend xBestIndex in vtables to carry the values for each contraint
|
edit |
It would be helpful if the xBestIndex method in virtual table carried the actual values for each constraint. This would allow clients of this call to more accurately set the estimatedCost of the query. The values are available in xFilter but the estimated cost has already been set and encoded by then.
Thanks... |
At the time xBestIndex is called, the values are likely
runtime variables or unbound host parameters and are thus
unknown. |
|
2231 |
new
|
active
|
2007 Feb
|
anonymous
|
|
2007 Mar
|
|
4
|
4
|
shell should ignore leading whitespace for meta commands
|
edit |
The current shell.c doesn't ignore whitespace before meta commands. This is annoying since it ignores whitespace for sql and other commands and thus prevents indenting from being used. If a script is sent to someone like...
sqlite3 data.db3
.header on
create table ...
.q
They can't just cut and paste the script into sqlite3 because of the whitespace.
Patch is ...
--- ..\sqlite-source-3_3_13\shell.c 2007-02-13 08:08:34.000000000 -0300
+++ shell.c 2007-02-15 04:18:05.726995200 -0300
@@ -934,22 +934,35 @@
}
return val;
}
/*
+** Determine if an input line begins with "." ignoring whitespace.
+*/
+static int is_meta_command(const char *z){
+ while( isspace((unsigned char)*z) ){ z++; }
+ return *z == '.';
+}
+
+/*
** If an input line begins with "." then invoke this routine to
** process that line.
**
** Return 1 on error, 2 to exit, and 0 otherwise.
*/
static int do_meta_command(char *zLine, struct callback_data *p){
- int i = 1;
+ int i = 0;
int nArg = 0;
int n, c;
int rc = 0;
char *azArg[50];
+ /* Skip the "." prefix.
+ */
+ while(zLine[i] != '.'){ i++; }
+ ++i;
+
/* Parse the input line into tokens.
*/
while( zLine[i] && nArg<ArraySize(azArg) ){
while( isspace((unsigned char)zLine[i]) ){ i++; }
if( zLine[i]==0 ) break;
@@ -1560,11 +1573,11 @@
seenInterrupt = 0;
}
lineno++;
if( p->echoOn ) printf("%s\n", zLine);
if( (zSql==0 || zSql[0]==0) && _all_whitespace(zLine) ) continue;
- if( zLine && zLine[0]=='.' && nSql==0 ){
+ if( zLine && is_meta_command(zLine) && nSql==0 ){
rc = do_meta_command(zLine, p);
free(zLine);
if( rc==2 ){
break;
}else if( rc ){
|
2007-Mar-01 21:53:33 by anonymous:
Any possibility of this going in? A simple change. Full patch. Brings meta command whitespace processing to the same functionality as SQL (i.e. ignore leading whitespace). Submitting patches to opensource projects is so frustrating when there is no feedback. |
|
2228 |
new
|
active
|
2007 Feb
|
anonymous
|
|
2008 Feb
|
|
3
|
4
|
horizontal partitioning
|
edit |
I would love to see a feature in the next version of sqlite that includes horizontal table partitioning. I see it currently in MySQL Version 5.1 beta. It would be awesome to see it in SQLite |
2008-Feb-01 02:46:29 by anonymous:
Well it would be great for us - won't need to emulate it.
Any thoughts about that?
That's not only about large data sets - you can also make it for some sort of horizontal ATTACH of small separate pieces. |
|
2226 |
code
|
active
|
2007 Feb
|
scouten
|
|
2007 Feb
|
|
5
|
4
|
Report on unused indices (and tables?)
|
edit |
After exercising a particular database heavily, it would be nice to know which indices (and possibly tables) have not been used at all. |
|
2225 |
code
|
active
|
2007 Feb
|
scouten
|
|
2007 Feb
|
|
5
|
4
|
Request count of number of inserts and deletes from the free page list
|
edit |
As a rough indication of potential fragmentation in the database, we'd like to know how many pages have been added and removed from the free page list. |
2007-Feb-10 19:24:13 by drh:
The issue of database fragmentation is also addressed
by ticket #2075 (a ticket which I had overlooked prior to today.) |
|
2224 |
new
|
active
|
2007 Feb
|
scouten
|
|
2007 Feb
|
|
4
|
4
|
Option to have one-bit "journal should exist" flag
|
edit |
Per discussion with DRH: Would it be possible to have a one-bit flag in the header page of the DB file that signals that there should be a journal file present. If you attempt to open a database with that flag set, but the journal file is not present, SQLite should fail to open the DB. |
2007-Feb-09 13:47:44 by drh:
Here is the issue: An application that uses SQLite for persistence
is receiving database corruption reports from the field. The
developers believe that the corruption occurs after a power
failure or other crash leaves a hot journal file and then the
users manually deletes the hot journal thinking that it is some
garbage file left over from the crash. If there is a "journal
should exist" flag in the database file and no journal is seen,
that would indicate that the journal has been deleted or renamed
and that the database has been corrupted. If the application
can detect this, it might be able to locate the deleted journal
in the trashcan and recover from the user error.
Other ideas for addressing this problem:
- Change the "-journal" extension on the journal files to
something like "-do-not-delete".
- Make the journal a hidden file. (The problem here is that
if somebody goes to move the databaes file and the database
has a hot journal, they would likely not know to move the
journal too since it is not visible.)
- Change permissions on the journal file so that it is
read-only. This doesn't prevent the journal from being
deleted by a determined user, but it might at least give
them a clue that this is not a file to be deleted without
at least due consideration.
|
|
2223 |
code
|
active
|
2007 Feb
|
scouten
|
|
2007 Nov
|
|
3
|
3
|
pragma auto_vacuum doesn't survive .dump & reconstitute
|
edit |
When you run sqlite3 path/to/database .dump, it does not contain pragma auto_vacuum even if that option was chosen when creating the source database. |
2007-Feb-08 18:13:27 by scouten:
We wonder if other pragmas are also not being propogated.
2007-Feb-08 18:53:42 by anonymous:
No pragmas are output from .dump. SQLite should have a .dump_with_pragmas command or equivalent.
2007-Nov-27 02:11:05 by anonymous:
auto_vacuum is especially important since you need to specify it before loading the tables in the dump; if you notice that it's missing after loading a dump, it's too late.
I'd also appreciate user_version surviving.
Would patches be welcome for these? I would be happy to contribute one: mail glasser@davidglasser.net. |
|
2222 |
build
|
active
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
4
|
4
|
Type mismatch in fts2.c [5091] when compile as fastcall or stdcall
|
edit |
I noticed a problem when compiling with Borland TurboC using either the -pr or -ps switches and I have a fix. The error is in reference to termDataCmp being passed to qsort. By changing the declaration of termDataCmp from:
static int termDataCmp(const void *av, const void *bv){
to:
static int __cdecl termDataCmp(const void *av, const void *bv){
the problem was resolved. I'm not sure this is a bug, but I thought I should report it just in case someone else runs into it.
Kind Regards,
Tom Olson |
|
2221 |
new
|
active
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
drh
|
3
|
4
|
Store blobs using inode-like lookup of pages rather than linked list
|
edit |
In a recent conversation, the matter of how BLOBs are stored came up. Currently, each page of BLOB data is in a linked list. By default each page is 1K so a very large BLOB may have many many pages.
The linked list becomes inefficient to find and update BLOBs.
DRH mentioned a thought to move to an inode style of page management for BLOBs. This would require updating the file format. |
|
2220 |
new
|
active
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
drh
|
2
|
4
|
fsck for database files
|
edit |
The existing recovery strategies for dealing with a corrupted database are entirely manual and could be improved with a reasonable amount of effort. One possible way to mitigate the issue would be the creation of an fsck recovery mechanism. This would be an improved recovery from the current .dump support. |
|
2219 |
code
|
active
|
2007 Feb
|
shess
|
|
2007 Feb
|
shess
|
2
|
2
|
Creating an fts table in an attached database works wrong.
|
edit |
ATTACH DATABASE 'test2.db' AS two;
CREATE VIRTUAL TABLE two.t2 USING fts2(content);
will put t2_content, t2_segments, and t2_segdir in database 'main' rather than database 'two'. In some cases everything will appear to work, because the tables will be defaults for that name. |
|
2218 |
code
|
active
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
3
|
4
|
select columns from views with table prefix
|
edit |
I have a table and a view on the table, defined like this:
create table mytable (mycolumn varchar);
create view myview as select mytable.mycolumn from mytable;
Now
select "mycolumn" from myview;
does work, but
select mycolumn from myview;
gives "unknown column"! |
|
2215 |
code
|
active
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
1
|
2
|
error messages in virtual table are not propagated
|
edit |
I'm trying to return a customized error message in xBestIndex in my virtual table implementation. Rather than copying my implementation here the problem can be reproduced by changing the fulltextBestIndex method from fts1.
For example:
/* Decide how to handle an SQL query. */
static int fulltextBestIndex(sqlite3_vtab *pVTab, sqlite3_index_info *pInfo){
int i;
TRACE(("FTS1 BestIndex\n"));
pVTab->zErrMsg = sqlite3_mprintf ("THIS IS AN ERROR MESSAGE");
return SQLITE_ERROR;
for(i=0; i<pInfo->nConstraint; ++i){
const struct sqlite3_index_constraint *pConstraint;
If I run the following I do not see the error message reported when using the shell.
$ ./sqlite3
SQLite version 3.3.12
Enter ".help" for instructions
sqlite> create virtual table foo using fts1(name, address);
sqlite> insert into foo (name, address) values ('amanda', '43 elm avenue');
sqlite> select * from foo;
SQL error: SQL logic error or missing database
|
|
2214 |
code
|
active
|
2007 Feb
|
anonymous
|
|
2007 Feb
|
|
5
|
4
|
lemon generates bad error messages for %destructor
|
edit |
When using incorrect syntax for %destructor, lemon generates a bad error message. When I wanted to use %default_destructor, but used %destructor instead:
%destructor { ... }
I got this error message:
Symbol name missing after 134583560estructor keyword
This is trivially fixed by replacing "Symbol name missing after %destructor keyword" with "Symbol name missing after %%destructor keyword" twice in lemon.c |
|
2207 |
new
|
active
|
2007 Jan
|
anonymous
|
|
2007 May
|
|
3
|
4
|
"CREATE TABLE foo AS SELECT * FROM bar" doesn't copy constraints
|
edit |
(cut & paste from an email I sent to the list, though afaict it never appeared)
When creating a table using AS SELECT ... I noticed it didn't copy the
constraints:
SQLite version 3.3.8
Enter ".help" for instructions
sqlite> .schema
CREATE TABLE bar (
t INTEGER NOT NULL PRIMARY KEY,
d INTEGER NOT NULL
);
sqlite> CREATE TABLE foo AS SELECT * FROM bar;
sqlite> .schema
CREATE TABLE foo(timestamp INTEGER,download INTEGER);
CREATE TABLE bar (
t INTEGER NOT NULL PRIMARY KEY,
d INTEGER NOT NULL
);
Is this expected behavior?
I find myself in a sitation where ideally I would like this to create
a table copying contraints (so I can do some processing in dynamically
created temporary tables).
I had a quick look over the documentation and it doesn't mention this
either way. |
2007-Jan-30 18:52:49 by drh:
I have a lot of code that depends "CREATE TABLE ... AS SELECT"
not copying the constraints. Changing this so that constraints
are copied would break my code - which is something I am
disinclined to do.
2007-Jan-30 19:06:34 by anonymous:
Can we perhaps just document this then as the intended behavior then then close this bug out please?
2007-Jan-30 21:57:10 by anonymous:
How about a new feature:
CREATE TABLE foo WITH CONSTRAINTS AS SELECT * FROM bar |
|
2206 |
new
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
5
|
4
|
Support for foreign key constraints in virtual tables
|
edit |
Please consider supporting parsing of foreign key constraints in the CREATE TABLE SQL text passed to sqlite3_declare_vtab().
Rationale: when a virtual table is used to implement something like a JOIN or VIEW on table(s) of the master SQLite database, PRAGMA foreign_key_list() on the virtual table(s) can provide information about key relationship between the virtual table(s) and the table(s) in the master SQLite database.
I've attached a patch which implements this feature, however I'm unsure about possible side effects. |
|
2205 |
build
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
anonymous
|
1
|
1
|
Problem while using with tcl on ARM
|
edit |
I am using the sqlite-3.3.12. I have compiled this version for ARM and mandrake linux. On PC it is working fine. But on the Hand Held device with tcl, it produce error after creating the database file that "database disk image is malformed" while executing query for creating table. Another problem is that on executing sqlite3 executable on PC it shows version 3.3.11 But on executing sqlite3 executable on hand held it shows version 3.3.12 though these both executables were compiled from same source that is sqlite 3.3.12. |
|
2204 |
new
|
active
|
2007 Jan
|
anonymous
|
|
2007 Feb
|
|
5
|
3
|
Stable, documented metadata interface
|
edit |
In response to #2203, I'd like to suggest that a documented, stable means be added to SQLite3 by which consumers of the API may reliably query column metadata for a table, including the names of the columns, whether they are nullable or not, their types, and what their default values are. Given that, currently, the only way to get this data is via the undocumented table_info pragma, clients who want this data are at your mercy every time that pragma changes.
Thanks! |
2007-Jan-30 00:07:28 by anonymous:
How about implementing the sql-standard information_schema?
I see something similar at http://www.sqlite.org/cvstrac/wiki?p=InformationSchema
The PostgreSQL equivalent: http://www.postgresql.org/docs/current/static/information-schema.html
2007-Jan-31 19:14:48 by anonymous:
Pragma table_info is documented at http://www.sqlite.org/pragma.html#schema
2007-Jan-31 19:31:48 by anonymous:
PRAGMAs are deficient because they cannot be used within SELECT statements or as sub-selects. This severely limits their usefulness in an SQL-only context. You have to use SQLite's API to make use of them.
2007-Feb-03 15:10:36 by anonymous:
Note that I was told by Richard himself that the table_info pragma is not considered a documented interface, and as such is fair game for incompatible changes in point releases (as we saw in 3.3.8). What I'm asking for in this ticket is an interface that is officially sanctioned and documented, and which (barring the occassional bug) can be guaranteed to remain stable (between point releases at the very least). |
|
2203 |
code
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
2
|
3
|
table_info pragma "default" column format changed?
|
edit |
Beginning with SQLite3 3.3.8, it looks like the format of the 'default' value returned by the table_info pragma has changed. Before, it used to be a bare string:
dev:~> sqlite3
SQLite version 3.3.7
Enter ".help" for instructions
sqlite> create table testings (a integer primary key, b string default 'Tester', c string default NULL);
sqlite> pragma table_info(testings);
0|a|integer|0||1
1|b|string|0|Tester|0
2|c|string|0||0
After 3.3.8, the 'defaults' column is now a SQL-quoted string:
dev:~> sqlite3
SQLite version 3.3.11
Enter ".help" for instructions
sqlite> create table testings (a integer primary key, b string default 'Tester', c string default NULL);
sqlite> pragma table_info(testings);
0|a|integer|0||1
1|b|string|0|'Tester'|0
2|c|string|0|NULL|0
Now, I think I do prefer the latter, where the default is a SQL-quoted string. However, this seems a rather significant change to make mid-stream, in a minor point release. It broke all Ruby on Rails applications that use sqlite3, for instance, because Rails reads that default value to determine how to default the value of each new record.
Was this intentional? Or is this a bug? I'd love to see this behavior reverted and saved for a release with a more significant release number. |
2007-Jan-29 22:01:54 by anonymous:
One of your fellow Railers requested this change: Ticket #2078
2007-Jan-29 22:10:55 by drh:
See also ticket #1919 which might also be an issue here.
2007-Jan-29 22:33:19 by anonymous:
Anonymous, you make it sound as if anyone associated with Rails can make a request of the sqlite3 team and have it be automatically assumed to be sanctioned by the Rails core team. Whoever did the original request did not do so under the umbrella of Rails core. If that change was the one that resulted in this behavior, it most definitely should not have been recommended, and would not have been blessed by any of the core team.
At this point, though, I'm not interested in blame. I just want to see what can be done to make sqlite3 work with Rails again, preferably in a way that is backwards compatible with previous sqlite3 releases.
2007-Jan-30 05:20:56 by anonymous:
I agree the feature should be fixed due to backwards compatability, but Rails should try to accomodate both pragma variants since they are both "in the wild". You could base your decision on the sqlite version string, for instance.
2007-Jan-30 18:39:44 by anonymous:
Just FYI, there's another related ticket at the Rails trac at http://dev.rubyonrails.org/ticket/6523, and a Debian bug report with a patch at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397531. |
|
2202 |
new
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
5
|
4
|
function request: sqlite3_attach()
|
edit |
Hello! A request for a new function, if i may:
int sqlite3_attach( sqlite3 * host, sqlite3 * parasite, char const * dbname );
In case it's not obvious, this would be functionally identical to calling:
ATTACH parasite as dbname;
from the host database.
Alternately, but probably less useful:
int sqlite3_attach( sqlite3 * host, char const * parasite, char const * dbname );
to directly attach databases. This second option isn't so useful because we already have this feature via the ATTACH SQL command. |
|
2200 |
new
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
5
|
4
|
threadsafe status not reported in .pc file
|
edit |
Some application based on sqlite (for exampe Tracker indexing and searching tool) could need the threadsafe.
Currently there in no way to know the status of threadsafe of installed sqlite.
It could be good add a "threadsafe" variable in sqlite3.pc like
libdir=${exec_prefix}/lib
includedir=${prefix}/include
threadsafe=yes
that developers could query using:
$ pkg-config --variable=threadsafe sqlite3
yes
|
|
2199 |
build
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
1
|
1
|
configure doesn't find libreadline if its in uncommon place
|
edit |
configure doesn't find libreadline if its in uncommon place.
I suggest to change configure to be able to deal with
something like this: --with-readline=/path |
|
2198 |
new
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
5
|
4
|
API: opening only existing databases
|
edit |
It would be useful to enhance the sqlite3_open function so it would take 3 parameters -- the third would control whether the database should exist for function success.
In other words (the 3rd argument):
create_or_access_existing -- works in both cases
do_not_create_new_db -- fails if there is no such database file
It is extremely useful if the user wants only read from the db. In current API she/he gets an delayed error while trying to read the table in database. |
|
2188 |
doc
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
5
|
4
|
Doc bug in src/vdbe.c, should s/P1/P2/ in NotFound
|
edit |
# diff
--- src/vdbe.c 2007-01-10 01:01:14.000000000 +1100
+++ src/vdbe_new.c 2007-01-24 16:34:38.139376872 +1100
@@ -2923,7 +2923,7 @@
**
** The top of the stack holds a blob constructed by MakeRecord. P1 is
** an index. If no entry exists in P1 that matches the blob then jump
-** to P1. If an entry does existing, fall through. The cursor is left
+** to P2. If an entry does existing, fall through. The cursor is left
** pointing to the entry that matches. The blob is popped from the stack.
**
** The difference between this operation and Distinct is that
|
|
2187 |
todo
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
3
|
4
|
RAISE in trigger not being caught by CONFLICT clause in calling SQL
|
edit |
When an exception is raised within a trigger, the on conflict clause on the calling SQL statement is not being invoked.
Note: The CASE statement in example is to demonstrate the error, a CHECK Constraint would have been more appropriate if this were a real world senario.
Sample SQL Below:
CREATE TABLE abc (a);
CREATE TRIGGER abc_insert BEFORE INSERT ON abc BEGIN
SELECT CASE WHEN (new.a > 2) THEN
RAISE(ABORT, 'error here')
END;
END;
BEGIN;
INSERT INTO abc VALUES (1);
-- This should raise error but not rollback
INSERT INTO abc VALUES (4);
-- This should raise error and rollback
INSERT OR ROLLBACK INTO abc VALUES (4);
-- Check to see if ROLLBACK performed (which it hasn't)
SELECT * FROM abc;
|
|
2185 |
new
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
5
|
3
|
API access to opened database pathname - helpful for virtual tables
|
edit |
It would be helpful if there was an api to retrieve the pathname (or :memory:) to the opened database. I am implementing a virtual table and would like to open subsequent virtual table (flat files in the filesystem) in the same location that the DB was opened. |
|
2183 |
code
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
drh
|
1
|
1
|
OMIT_SHARED_CACHE: AV and crash with FTS2 INSERT
|
edit |
Given that SQLite is compiled with
-DSQLITE_ENABLE_FTS2=1
-DSQLITE_OMIT_SHARED_CACHE=1
the following code crashes after about 273 insertions with
Access violation: Read of address 0x00000014
at
btree.c, line 3451: if( pCur->idx>=pPage->nCell ){
Here is the code to reproduce:
int main(int argc, char* argv[])
{
sqlite3_stmt *pStmt;
int i;
check( sqlite3_open( "test_fts2.db3", &db) );
check( sqlite3_exec( db, "CREATE VIRTUAL TABLE FTS USING FTS2 (Content);", 0, 0, 0));
check( sqlite3_exec( db, "BEGIN TRANSACTION;", 0, 0, 0));
check( sqlite3_prepare( db, "INSERT INTO FTS (Content) VALUES ('Far out in the uncharted backwaters of the unfashionable end of the Western Spiral arm of the Galaxy lies a small unregarded yellow sun.');", -1, &pStmt, NULL));
for( i = 1; i < 1000; i++) {
printf( "%d\n", i);
check( sqlite3_step( pStmt) );
check( sqlite3_reset( pStmt) );
}
check( sqlite3_exec( db, "COMMIT;", 0, 0, 0));
check( sqlite3_finalize( pStmt ));
check( sqlite3_close( db ));
printf ("Done");
scanf ("*%s");
return 0;
}
Could this be related to ticket #2032? |
|
2182 |
code
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
4
|
4
|
sqlite3BtreeGetMeta does not check the file format
|
edit |
sqlite3BtreeGetMeta reads database page 1 directly from the pager layer, skipping all of the format checks in lockBtree . Thus, if the very first query you do against a database is "PRAGMA user_version " and the database isn't valid (in particular, if it is an sqlite 2 database) you will get a garbage result rather than an SQLITE_NOTADB or SQLITE_CORRUPT error.
Demonstration:
$ touch bug1.db # empty file
$ dd if=/dev/zero of=bug2.db bs=100 count=1 # file header all zeroes
$ sqlite2 bug3.db 'create table a(b);' # old-format database
$ sqlite3 bug1.db 'pragma user_version' ; echo $?
0
0
$ sqlite3 bug2.db 'pragma user_version' ; echo $?
0
0
$ sqlite3 bug3.db 'pragma user_version' ; echo $?
1795162112
0
Contrast the sensible behavior if you do a SELECT :
$ sqlite3 bug1.db 'select * from a'; echo $?
SQL error: no such table: a
1
$ sqlite3 bug2.db 'select * from a'; echo $?
SQL error: file is encrypted or is not a database
1
$ sqlite3 bug3.db 'select * from a'; echo $?
SQL error: file is encrypted or is not a database
1
|
2007-Jan-21 22:05:14 by anonymous:
(Submitter:) Is there a reason why the file format check doesn't happen in sqlite3_open? |
|
2181 |
new
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
5
|
4
|
Generalize ON CONFLICT to failure trapping for all SQL statements
|
edit |
(This is a more general alternative to the feature request in #2180.)
It would be nice if clauses similar to ON CONFLICT were available for all supported statements, to specify error recovery behavior in all cases. For instance, one would like to be able to write things like
SELECT ... FROM foo ON ABSENT IGNORE;
with the effect that if there is no table 'foo', the SELECT simply returns zero rows. I am not sure what the complete set of conditions to recover from would be, but I think that ABSENT (table or column missing), EXISTS (something you're trying to create already exists), and NONEMPTY (to avoid deleting data unintentionally, per #2180) should cover most cases. |
|
2180 |
new
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
5
|
4
|
feature request: DROP TABLE IF [EXISTS AND] EMPTY
|
edit |
It would be useful to have a straightforward way to drop a table only if it contains no rows. Currently it is necessary to do this in application logic, by doing a dummy SELECT to find out if there's any data in the table (e.g. "SELECT 1 FROM table LIMIT 1" - this is the most efficient such query I can find). And of course one has to take care to handle errors in that SELECT (e.g. if the table doesn't exist).
I suggest DROP TABLE IF EMPTY, by analogy with the existing DROP TABLE IF EXISTS. Naturally, one would like to be able to combine the two, to drop an empty table but do nothing if the table exists or isn't empty. |
2007-Jan-26 22:59:50 by anonymous:
To comment on that last statement:
"I suggest DROP TABLE IF EMPTY, by analogy with the existing DROP TABLE IF EXISTS. Naturally, one would like to be able to combine the two, to drop an empty table but do nothing if the table exists or isn't empty."
That sounds redundant: DROP TABLE IF EMPTY will not drop a table if it has any data, nor if the table does not exist. The question comes to mind, "when is there an error?" Is DROP TABLE IF EMPTY an error if the table is not empty? Or would we need DROP TABLE IF EXISTS AND IF EMPTY to ensure that we have clear success/failure paths in the case that we do DROP TABLE IF EMPTY for a table which we're not sure is there or not. If sounds like "IF EMPTY" should automatically imply "AND IF EXISTS", because a prerequisite of being empty is that the table has to exist.
IMO, a statement like DROP TABLE IF EMPTY is 100% sugar and should not produce any error code, similarly to DROP TABLE IF EXISTS (which does not produce an error if the table DOES exist, though we could rightfully argue that it should raise an error because its condition is not met).
----- sgb |
|
2167 |
new
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
1
|
3
|
add sqlite3_copy_bindings (parallel to sqlite3_transfer_bindings)
|
edit |
sqlite3_transfer_bindings( from, to ) does not leave the 'from' stmt in a usable mode. If I want to create a separate, independent copy of an sqlite3_stmt, I have to replicate the bindings.
I have created a modified version of sqlite3_transfer_bindings() which simply replaced sqlite3VdbeMemMove() with sqlite3VdbeMemCopy(), and named the function sqlite3_copy_bindings. I'm not an expert in Sqlite internals so I can't tell if there any issues with this. |
|
2165 |
code
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
drh
|
4
|
3
|
pager performance and checksum
|
edit |
pager.c
Embedd the 2 byte pager_pagehash() result into the page, near the beginning of the page. Use the intire page to calculate the pager_pagehash exclusive of the two byte page_hash data embedded in the page. That way a simple xor as in CHECK_PAGE of the entire page including the 2 byte pager_pagehash is all that is needed to validate a page. Also you could include the "4 byte" random at the beginning and at the end... But that would be a bit of overkill. The sampling of only every 200 bytes is interesting.
Review change the SQLITE_CHECK_PAGES ifdef to a SQLITE_OMIT_PAGE_CHECK.. As on disk page validity is very important.
Could this be integrated into a pragma setting? |
2007-Jan-12 18:08:49 by anonymous:
uint16_t
pg_chkval(Dpage *pg, uint32_t pg_size) {
register int i;
register uint16_t val = 0;
register uint16_t *bw = (uint16_t *) pg;
for(i= 0; i < pg_size;i=i+2 )
val= val^ *bw++ ;
return val;
}
uint16_t
pg_calcval(Dpage *pg, uint32_t page_size) {
int i;
register uint16_t val = 0;
register uint16_t *bw = (uint16_t *) pg;
/* Scan up to location where chk val is stored */
for(i= 0; i < 8;i=i+2 )
val= val^ *bw++ ;
val = val^ 0;
bw ++ ;
/* Now scan the tail of the block */
for(i=10; i < page_size;i=i+2 )
val= val^ *bw++ ;
return val;
}
|
|
2148 |
doc
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
5
|
5
|
3.3.9 changes.html addition
|
edit |
- Fixed the ".dump" command in the command-line shell to show triggers and views again.
+ Fixed the ".dump" command in the command-line shell to show indexes, triggers and views again.
|
|
2140 |
code
|
active
|
2007 Jan
|
anonymous
|
|
2007 Jan
|
|
3
|
1
|
sqlite doesn't link to readline
|
edit |
sqlite relies on another library to link to libreadline, causing this error with LDFLAGS=-Wl,--as-needed:
gcc -O2 -march=i686 -pipe -DOS_UNIX=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -I. -I./src -DNDEBUG -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_CURSOR -DHAVE_READLINE=1 -I/usr/include/readline -o .libs/sqlite3 ./src/shell.c ./.libs/libsqlite3.so -lpthread -lncurses
/tmp/cclOD1M7.o: In function `process_input':
shell.c:(.text+0x37a5): undefined reference to `readline'
shell.c:(.text+0x37c0): undefined reference to `add_history'
/tmp/cclOD1M7.o: In function `main':
shell.c:(.text+0x3f01): undefined reference to `read_history'
shell.c:(.text+0x3f1a): undefined reference to `stifle_history'
shell.c:(.text+0x3f22): undefined reference to `write_history'
collect2: ld returned 1 exit status |
|
2136 |
new
|
active
|
2007 Jan
|
anonymous
|
|
2007 Mar
|
|
1
|
3
|
sqlite locking does not handle afs; patch included
|
edit |
Please see
http://www.mail-archive.com/sqlite-users%40sqlite.org/msg20672.html |
2007-Jan-02 03:37:59 by anonymous:
According to this checkin, that code has already been added to SQLite:
http://www.sqlite.org/cvstrac/chngview?cn=3459
2007-Jan-16 00:08:58 by anonymous:
Nope, that's something different.
2007-Mar-30 00:39:05 by anonymous:
You're right. I should have looked at the link more closely. |
|
2133 |
build
|
active
|
2006 Dec
|
anonymous
|
|
2007 Mar
|
|
4
|
4
|
meta ticket for outstanding autoconf issues
|
edit |
Please add any outstanding autoconf issues to this ticket.
Ticket #2082: UNIX: configure script doesn't enable loading of extensions
Ticket #1906: HAVE_GMTIME_R and HAVE_LOCALTIME_R
Ticket #1814: Autoconf support for MacOSX univeral binaries
Ticket #2124: -ldl link issue
Ticket #1966: Add a --disable-readline option to configure
Ticket #2053: fdatasync unresolved symbol on solaris 10
Check-in [3709]
: Add a new compile-time macro USE_PREAD64 |
|
2132 |
code
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
3
|
4
|
table_info, index_list, index_info & friends should be virtual tables
|
edit |
The following meta data should be accessible via read-only virtual tables in some sort of sqlite_meta_info table:
PRAGMA database_list;
PRAGMA foreign_key_list(table-name);
PRAGMA index_info(index-name);
PRAGMA index_list(table-name);
PRAGMA table_info(table-name);
This would allow complex querying and joins of the meta data of the database. (Pragmas cannot be used as a subquery).
The underlying introspection mechanism can actually be PRAGMA-based for backwards compatability. |
|
2131 |
code
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
2
|
3
|
Add substring() function (Part of SQL 99)
|
edit |
sqlite> SELECT substring('foobar.class',-6,6) = '.class';
SQL error: no such function: substring
sqlite> SELECT SUBSTRING('foobar.class',-6,6) = '.class';
SQL error: no such function: SUBSTRING
sqlite> SELECT SUBSTR('foobar.class',-6,6) = '.class';
1
sqlite> SELECT substring('foobar.class' FROM -6 FOR 6) = '.class';
SQL error: near "FROM": syntax error
Looking at:
http://www.oreilly.com/catalog/sqlnut/chapter/ch04.html
SQL99 Syntax
SUBSTRING(extraction_string FROM starting_position [FOR length]
[COLLATE collation_name])
It would be useful for sqlite to support this syntax too to make the SQL more portable. |
2006-Dec-28 16:03:03 by anonymous:
sqlite has the substr() routine (func.c code):
{ "substr", 3, 0, SQLITE_UTF8, 0, substrFunc },
#ifndef SQLITE_OMIT_UTF16
{ "substr", 3, 0, SQLITE_UTF16LE, 0, sqlite3utf16Substr },
#endif
this could be 'aliased' to help you using the substring() SQL99 std just doing:
{ "substr", 3, 0, SQLITE_UTF8, 0, substrFunc },
{ "substring", 3, 0, SQLITE_UTF8, 0, substrFunc },
#ifndef SQLITE_OMIT_UTF16
{ "substr", 3, 0, SQLITE_UTF16LE, 0, sqlite3utf16Substr },
{ "substring", 3, 0, SQLITE_UTF16LE, 0, sqlite3utf16Substr },
#endif
|
|
2130 |
code
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
4
|
4
|
replace "long long int" type with "sqlite_int64" defined in sqlite3.h
|
edit |
As the typedef "typedef long long int sqlite_int64" is available in sqlite3.h. Please ensure that remaining references to "long long" use this typedef (for 32bit compilers):
Searching for 'long long int'...
sqlite3.h(89): typedef long long int sqlite_int64;
sqlite3.h(90): typedef unsigned long long int sqlite_uint64;
os_common.h(67):__inline__ unsigned long long int hwtime(void){
os_common.h(68): unsigned long long int x;
os_common.h(74):static unsigned long long int g_start;
sqliteInt.h(185):** cc '-DUINTPTR_TYPE=long long int'
vdbe.c(365):__inline__ unsigned long long int hwtime(void){
vdbe.c(366): unsigned long long int x;
8 occurrence(s) have been found.
thanks |
|
2128 |
code
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
4
|
3
|
virtual table code doesn't verify type of rowid (calling xUpdate)
|
edit |
The virtual tables code doesn't verify the type of rowid when calling update. For example I used the following query:
UPDATE foo SET rowid='a string' WHERE 1
This results in a call to xUpdate with argv[0] equal the current rowid but argv[1] is 'a string'. While I'd be quite happy for rowids to be any SQLite type, the xRowid call only allows 64 bit integers. I believe SQLite should check the new rowid in a case like this is an integer and reject it, rather than calling xUpdate with the bad value. (I also just checked with rowid=3.4 and rowid=NULL and they get passed through as is as well)
A workaround is to document that the xUpdate method must check the new rowid is an integer type. |
|
2127 |
code
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
2
|
3
|
Virtual tables do not always free zErrmsg
|
edit |
The documentation for virtual tables and in particular the sqlite3_vtab structure says "The SQLite core will free and zero the content of zErrMsg when it delivers the error message text to the client application or when it destroys the virtual table."
The latter part does not appear to be true ("when it destroys the virtual table"). I can't find any code that does actually that. (eg vtab.c:496 definitely doesn't, nor does vtab.c:76)
Usually the former case happens. However some operations have their error codes ignored (eg xClose). This can result in the zErrMsg pointing to a message but no error code returned upstream (which would clear the message). Finally as far as I can tell the responsibility for freeing sqlite3_vtab is with the xDisconnect/xDestroy callbacks since the corresponding xCreate/xConnect callbacks allocated it. Consequently there is no way for SQLite to even access zErrmsg since it would be a member of a freed structure after xDisconnect/xDestroy returned. |
|
2126 |
code
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
3
|
1
|
Update hook not invoked when deleteing all rows from table
|
edit |
I was testing the update hook feature of SQLite and incidentally I noticed that hook is not invoked for "DELETE FROM" statement with no WHERE clause. Hook works well for "DELETE FROM ... WHERE ..." statement.
Steps to reproduce:
- Open database, setup update hook
- Execute:
CREATE TABLE Test(Test INTEGER);
- Insert some data:
INSERT INTO TEST (Test) VALUES (1); -- update hook invoked for INSERT
INSERT INTO TEST (Test) VALUES (2); -- update hook invoked for INSERT
INSERT INTO TEST (Test) VALUES (3); -- update hook invoked for INSERT
- Execute:
DELETE FROM TEST; -- update hook IS NOT INVOKED(!) for each row.
|
2006-Dec-22 15:38:44 by drh:
Triggers don't work either. This is a feature not a bug.
When you do "DELETE FROM table" with no WHERE clause, SQLite
drops and recreates the table. Doing it this way have a huge
speed boost.
If you really need the update hook to work add a "WHERE 1" to the
end of the query.
2006-Dec-22 16:11:11 by anonymous:
I don't really need it, maybe other users.
You should update the documentation of sqlite3_update_hook() and triggers mentioning this behaviour.
Another solution is to perform "DELETE FROM" as if it was with WHERE clause, if there is an update hook regitered. |
|
2120 |
new
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
5
|
4
|
Date Column support
|
edit |
1) date column declared as 'date' or 'datestr' or similar.
2) date real type is text, stored like 'yyyy-mm-dd'.
3) sqlite3_column_type() return SQLITE_DATE
4) min, max function return type SQLITE_DATE
5) (optional) new function: sqlite3_column_date() is same as
sqlite3_column_text();
6) modify return type of sqlite3_value_type() (add SQLITE_DATE)
7) (optional) new function sqlite3_value_date() same as sqlite3_value_text(). |
|
2112 |
code
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
5
|
4
|
code compatibility with C++
|
edit |
I need to compile SQLite with C++ compiler (GCC 3.4.5 from MingW). I also compiled the code as single translation unit, by including all relevant source files into single *.cpp file. To make it working I needed to make several dozens of small fixes.
Problems I found:
- 1. <vdbeInt.h> does not have guarding macros
- 2. <os_common.h> does not have guarding macros
- 3. parser.y used symbol"not" which is reserved in C++ and transformed to "!"
- 4. pager.c redefines macros TRACE1 ... TRACE5 which are already defined elsewhere. With several files in one TU this clashes.
- 5. Inner structures and name lookup. With structures like
struct SrcList {
...
struct SrcList_item {
...
C++ requires full qualification, e.g.
struct SrcList::SrcList_item* p = ... // OK
struct SrcList_item* p = ... // ERROR
- 6. Code like
char* p = sqlite3Malloc(...)
fails to compile without cast.
- 7. There are few dozens of places where a signed value is compared with unsigned one and compiler emits a warning.
If some of the points above get eliminated than the porting should be much easier - it was few boring hours of change-try compile-fix cycle for me. |
2006-Dec-19 16:42:35 by anonymous:
this software is written in C with a lemon grammar parser (parser.y), and it´s compiled with GCC compiler suite (GCC, not G++). Also, the source code is not C++ compliant, and isn't structured for a single source file, so avoid reporting tickets like this in the trac, use mailing list to ask things, only report errors here.
2006-Dec-19 17:21:15 by anonymous:
It's fine to ask for reasonable features like making the code C++ clean. Just use a lower priority (4 or 5), as the original ticket poster did. |
|
2110 |
build
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
4
|
3
|
Non-optional linking with readline makes sqlite3 binary GPL
|
edit |
Currently, the sqlite3 binary is linked with libreadline support if it happens to be available at compile time. This may not always be desirable, because readline is licensed under GPL, and therefore the sqlite3 binary becomes GPL.
Solution: There ought to be a configure script parameter --disable-readline (or something similar) to allow creating non-GPL binaries. |
2006-Dec-17 16:11:21 by anonymous:
Another solution would be to use editline instead, which is BSD licensed, from NetBSD project. Here is an autotool- and libtoolized port of it:
<http://www.thrysoee.dk/editline/>.
It seems to even have a readline.h wrapper.
Check the links there for upstream sources and related projects.
2006-Dec-17 16:34:45 by anonymous:
This might work:
env CFLAGS="-UHAVE_READLINE" ./configure
2006-Dec-17 16:55:55 by anonymous:
The -UHAVE_READLINE thing does not work because it is hardcoded into Makefile.in:
# Compiler options needed for programs that use the readline() library.
#
READLINE_FLAGS = -DHAVE_READLINE=@TARGET_HAVE_READLINE@ @TARGET_READLINE_INC@
# The library that programs using readline() must link against.
#
LIBREADLINE = @TARGET_READLINE_LIBS@
...
sqlite3$(TEXE): $(TOP)/src/shell.c libsqlite3.la sqlite3.h
$(LTLINK) $(READLINE_FLAGS) $(LIBPTHREAD) \
-o $@ $(TOP)/src/shell.c libsqlite3.la \
$(LIBREADLINE) $(TLIBS)
You have to manually edit the generated Makefile to remove READLINE_FLAGS and LIBREADLINE. |
|
2106 |
doc
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
4
|
4
|
FtsOne wiki page neglects to mention Porter stemming
|
edit |
http://www.sqlite.org/cvstrac/wiki?p=FtsOne claims that "the module does not perform stemming of any sort" when, in fact, FTS1 (in the 3.3.8 tarball and onwards) appears to fully support Porter stemming, using the same "tokenizer porter" syntax as FTS2. |
|
2105 |
new
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
5
|
5
|
sqlite3_exec does not return modified rows
|
edit |
SQLite does not provide a way to determine wether a statement has succeeded unless it is a select statement.
For instance using the following sample database
create table urls (url text unique)
insert into urls(url) values('http://www.sqlite.org')
insert into urls(url) values('http://www.google.com')
The following statement will execute the callback from sqlite3_exec which can be used to count the rows (becuase its deemed a query)
select * from urls
But the following statement will not execute the callback and so there is no way of knowing wether the statement was succesful or not.
delete from urls where url='http://news.com'
In fact, it is indistinguisable from the following statement...
delete from urls where url='http://www.google.com'
Even using prepared statements and the sqlite3_step function does not allow the user to determine the success of a statement or count affected rows.
There needs to be some way to determine the number of affected rows as a result of a particular statement, not just queries.
One solution would be for sqlite3_exec to call the callback once for each affected row, and that the fields and values parameters be left blank for non queries.
Of course, a better solution may be to add a new API call which can be used when SQLITE_DONE is returned to check for affected rows.
This would allow the API to actually signal success or failure, and more importantly provide a way of counting the affected rows from a particular statement.
Most other database API's provide a way to do this. |
After submitting this bug, i saw other bug reports that were similar with the suggestion that sqlite3_changes can be used to determine the number of affected rows.
So i would like to change this bug report to simply be a documentation request. Please add a link to sqlite3_changes and a description in the documentation for sqlite3_exec so that it is easier to find.
2006-Dec-11 01:06:07 by anonymous:
There is still one case which i cannot resolve even using the sqlite3_changes api call.
That is the following statement.
select * from urls where url='';
Since this select statement returns no results, the callback is not called, and when i call the sqlite3_changes routine it simply supplies the previous change (since select is not considdered a change).
So how then would i determine wether a statement returned no results without knowing in advance wether it was a select?
I suggest sqlite3_changes be modified to return 0 when the statement was a select statement (since this also makes sense, there were no changes). This would allow the detection of select statements which return no results.
2006-Dec-11 01:23:07 by anonymous:
A workaround for this problem is to always manually reset the change count before calling sqlite3_exec
db->nChange = 0;
Unfortunately this is not available to the user, since the sqlite3 structure is not defined in the header.
Perhaps executing a statement which is known to always have 0 changes may achieve the same effect until this can be added/fixed.
2006-Dec-11 19:36:38 by anonymous:
You should look at the empty_result_callbacks pragma documentation at http://www.sqlite.org/pragma.html You can use set this to 1 to get a callback even when your query returns no results.
The other pragma you may be interested in is the count_changes pragma. It can cause insert, delete, and update statements to return a single row with the number of changes when using the sqlite3_exec API. |
|
2104 |
build
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
2
|
3
|
manual link on Mac OS X fails due to common symbol
|
edit |
Attempting a manual link on OS X with fts1:
gcc -O -fPIC -dynamiclib -o mylib sqlite-3.3.8/*.o
Results in the error:
ld: common symbols not allowed with MH_DYLIB output format with the
-multi_module option
fts1.o definition of common _sqlite3_api (size 16)
/usr/bin/libtool: internal link edit command failed
This error is described:
http://gcc.gnu.org/ml/gcc/2005-06/msg00199.html
And a fix:
--- /tmp/sqlite-3.3.8/src/sqlite3ext.h 2006-09-23 21:28:30.000000000 +1000
+++ sqlite3ext.h 2006-10-09 19:20:09.000000000 +1000
@@ -276,7 +276,7 @@
#define sqlite3_overload_function sqlite3_api->overload_function
#endif /* SQLITE_CORE */
-#define SQLITE_EXTENSION_INIT1 const sqlite3_api_routines *sqlite3_api;
+#define SQLITE_EXTENSION_INIT1 const sqlite3_api_routines *sqlite3_api = 0;
#define SQLITE_EXTENSION_INIT2(v) sqlite3_api = v;
#endif /* _SQLITE3EXT_H_ */
|
|
2100 |
code
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
1
|
1
|
Fixes for SQL lower() and upper()
|
edit |
As acknowledged in the documentation, the SQL lower() and upper() functions might not work correctly on UTF-8 characters. This bug might show if a country specific locale is used instead of the standard C locale. Under certain circumstances, SQL lower() or upper() can even corrupt the UTF-8 string into invalid UTF-8 if the tolower() and toupper() C functions convert character values starting from 0x80.
Below I propose implementations of lowerFunc() and upperFunc() which work correctly with UTF-8 characters, regardless of the implementation of the C library tolower() and toupper() functions. If these C functions are implemented to support high ASCII or even Unicode case conversion, the new SQL lower() and upper() will support them as well.
The proposed C implementation applies a technique also found in sqlite3VdbeMemTranslate() in utf.c and makes use of some macros contained in that unit. To avoid duplicating existing code, it could make sense to move lowerFunc() and lowerFunc() to utf.c, just as it has been done with sqlite3utf16Substr().
Finally, here is the code:
/*
** Implementation of the upper() and lower() SQL functions.
*/
static void upperFunc(sqlite3_context *context, int argc, sqlite3_value **argv){
const unsigned char *zIn, *zInTerm;
unsigned char *z, *zOut;
int c, l;
if( argc<1 || SQLITE_NULL==sqlite3_value_type(argv[0]) ) return;
zIn = sqlite3_value_text(argv[0]);
if( zIn==0 ) return;
l = sqlite3_value_bytes(argv[0]);
zInTerm = &zIn[l];
/* When converting case, the maximum growth results from
** translating a 1-byte UTF-8 character to a 4-byte UTF-8 character.
*/
zOut = sqliteMalloc( l * 4 );
z = zOut;
while( zIn<zInTerm ){
READ_UTF8(zIn, c);
c = toupper(c);
WRITE_UTF8(z, c);
}
sqlite3_result_text(context, zOut, z-zOut, sqlite3FreeX);
}
static void lowerFunc(sqlite3_context *context, int argc, sqlite3_value **argv){
const unsigned char *zIn, *zInTerm;
unsigned char *z, *zOut;
int c, l;
if( argc<1 || SQLITE_NULL==sqlite3_value_type(argv[0]) ) return;
zIn = sqlite3_value_text(argv[0]);
if( zIn==0 ) return;
l = sqlite3_value_bytes(argv[0]);
zInTerm = &zIn[l];
/* When converting case, the maximum growth results from
** translating a 1-byte UTF-8 character to a 4-byte UTF-8 character.
*/
zOut = sqliteMalloc( l * 4 );
z = zOut;
while( zIn<zInTerm ){
READ_UTF8(zIn, c);
c = tolower(c);
WRITE_UTF8(z, c);
}
sqlite3_result_text(context, zOut, z-zOut, sqlite3FreeX);
}
|
2006-Dec-05 19:07:32 by anonymous:
I'm not sure this is an improvement. The argument to the ctype.h functions tolower(int C) and toupper(int C) is only defined when C is an integer in the range `EOF' to `255'. The compiler implementation may return garbage for values outside this range.
2006-Dec-06 16:17:23 by anonymous:
The integer in the range 'EOF' to '255' is exactly the problem with the existing implementation: This range will (and does, in some cases) modify UTF-8 bytes (not a character) starting from 128, which can lead to invalid UTF-8 sequences.
If the result of tolower() is indeed undefined for values greater than 255 in some C-implementations then I agree that adding this check to the new code will probably be a good thing:
if( c < 256 ){
c = tolower(c);
}
If, on the other hand, tolower() just returns the character unchanged for values greater than 255, then this check is not necessary.
I want to emphasize once more that the proposed new SQL lower() and upper() implementations never return invalid UTF-8, whereas the current implementation sometimes does. This is, by itself, already a great improvement.
2006-Dec-07 15:29:07 by anonymous:
This modified patch does better than previous if
SQLITE_UNICODE_UPPERLOWERFUNCS is defined at compile time,
because it uses libc _wcsupr / _wcslwr routines.
#ifdef SQLITE_UNICODE_UPPERLOWERFUNCS
#define WCHAR_T_SIZE sizeof(wchar_t)
#if (WCHAR_T_SIZE == 2)
#define MAXUPPERLOWERCHAR_AVAIL 0x0000ffff
#else // (WCHAR_T_SIZE == 4)
#define MAXUPPERLOWERCHAR_AVAIL 0x7fffffff
#endif // (WCHAR_T_SIZE == 2)
#define TOLOWERSQLFUNC(c) unicode_tolower
#define TOUPPERSQLFUNC(c) unicode_toupper
int unicode_tolower(const int c) {
wchar_t buff [2];
if (c > MAXUPPERLOWERCHAR_AVAIL)
return c;
buff[0] = (wchar_t) c;
buff[1] = 0;
_wcslwr(buff);
return (int) buff[0];
}
int unicode_toupper(const int c) {
wchar_t buff [2];
if (c > MAXUPPERLOWERCHAR_AVAIL)
return c;
buff[0] = (wchar_t) c;
buff[1] = 0;
_wcsupr(buff);
return (int) buff[0];
}
#else // SQLITE_UNICODE_UPPERLOWERFUNCS
#define TOLOWERSQLFUNC(c) (c > 255 ? c : tolower(c))
#define TOUPPERSQLFUNC(c) (c > 255 ? c : toupper(c))
#endif // SQLITE_UNICODE_UPPERLOWERFUNCS
/*
** Implementation of the upper() and lower() SQL functions.
*/
static void upperFunc(sqlite3_context *context, int argc, sqlite3_value **argv){
const unsigned char *zIn, *zInTerm;
unsigned char *z, *zOut;
int c, l;
if( argc<1 || SQLITE_NULL==sqlite3_value_type(argv[0]) ) return;
zIn = sqlite3_value_text(argv[0]);
if( zIn==0 ) return;
l = sqlite3_value_bytes(argv[0]);
zInTerm = &zIn[l];
/* When converting case, the maximum growth results from
** translating a 1-byte UTF-8 character to a 4-byte UTF-8 character.
*/
zOut = sqliteMalloc( l * 4 );
z = zOut;
while( zIn<zInTerm ){
READ_UTF8(zIn, c);
c = TOUPPERSQLFUNC(c);
WRITE_UTF8(z, c);
}
sqlite3_result_text(context, zOut, z-zOut, sqlite3FreeX);
}
static void lowerFunc(sqlite3_context *context, int argc, sqlite3_value **argv){
const unsigned char *zIn, *zInTerm;
unsigned char *z, *zOut;
int c, l;
if( argc<1 || SQLITE_NULL==sqlite3_value_type(argv[0]) ) return;
zIn = sqlite3_value_text(argv[0]);
if( zIn==0 ) return;
l = sqlite3_value_bytes(argv[0]);
zInTerm = &zIn[l];
/* When converting case, the maximum growth results from
** translating a 1-byte UTF-8 character to a 4-byte UTF-8 character.
*/
zOut = sqliteMalloc( l * 4 );
z = zOut;
while( zIn<zInTerm ){
READ_UTF8(zIn, c);
c = TOLOWERSQLFUNC(c);
WRITE_UTF8(z, c);
}
sqlite3_result_text(context, zOut, z-zOut, sqlite3FreeX);
}
|
|
2099 |
doc
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
3
|
3
|
virtual table xDestroy/xDisconnect and cleanups
|
edit |
It isn't clear what happens if xDisconnect or xDestroy return an error. From the code for sqlite3VtabCallDestroy pTab->pVtab is not set to zero. Does that mean that Destroy/Disconnect can be called again (the table has been dropped so I don't see how)? If not, then the memory is table is memory leaked.
In my Python wrapper I have to decide what to do when the Python code returns an error. Should I free the Python objects when returning the error code, or leave them allocated. If they are left allocated, then will they be leaked or will there be another opportunity to free them? |
2006-Dec-24 11:16:56 by anonymous:
From the code, the return code from xDisconnect is completely ignored (vtab.c:62)
xDisconnect is also unconditionally called whereas xDestroy is optionally called (vtab.c:496). If anything I would expect xDisconnect to be optional and xDestroy to be mandatory.
I still can't answer the original question in this ticket. Currently xDisconnect ignores the return value and therefore results in unconditional disconnection. xDestroy is ultimately called in OP_VDestroy in the vdbe but I can't tell what happens if an error is returned. |
|
2098 |
warn
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
1
|
1
|
php sqlite problem after commit transaction
|
edit |
please see php bugs
http://bugs.php.net/bug.php?id=39735&thanks=2
the error:
COMMIT TRANSACTION;
begin transaction;
PRAGMA default_synchronous=NORMAL;
PRAGMA auto_vacuum=1;
PRAGMA synchronous=NORMAL;
PRAGMA default_temp_store=MEMORY;
PRAGMA temp_store=MEMORY;
PRAGMA case_sensitive_like=0;
PRAGMA encoding=\"UTF-8\";
COMMIT TRANSACTION; <-- here php(sqlite) crash
error message:
php: ./src/pager.c:1237: syncJournal: Assertion `pPg->needSync==0'
failed.
Aborted
php 5.1.6 |
2006-Dec-04 23:41:22 by drh:
The code in question has been essentially unchanged for
three years. This is the first report of this bug. Meanwhile,
most of the rest of the world has moved on to use SQLite version 3.x.
Your work-around is to issued the pragmas separately, not inside a
transaction.
We will keep this bug on file and work on
it as time permits. But because
the problem appears to be in 3-year-old code, does not lead to
data loss or database corruption, does not impact any paid
support customers, and because nobody has ever
run into it before, this bug will be fixed at a very low priority.
Please do not expect it to be fixed anytime soon. |
|
2096 |
code
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
3
|
3
|
ATTACH DATABASE returns SQLITE_ERROR when database is locked
|
edit |
From an email sent to DRH:
I am working on a problem surrounding the inability to ATTACH to a
database file. The error text being returned is "database is locked",
which should be SQLITE_BUSY, however, the error code being returned by
sqlite3_exec is SQLITE_ERROR. Is sqlite3_exec wrong in returning
SQLITE_ERROR rather than SQLITE_BUSY? I have some nagging feeling that
I determined or read that the attachFunc function does not return a
truly-relevant status code, but I can't see why offhand nor can I find
any evidence to support that theory. If sqlite3_exec is doing the right
thing, however, then the question becomes one of identifying when to
retry the ATTACH statement; we're currently keying off SQLITE_BUSY or
SQLITE_LOCKED, as appropriate, and I'd rather not be trying to trap
errors based on error text. |
|
2095 |
doc
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
1
|
3
|
xFindFunction documentation incomplete
|
edit |
The documentation doesn't say when xFindFunction is called. It is obviously called the first time a function is needed, but is it called every time?
My underlying issue is that the ppArg return value is going to be dynamically allocated and I need to know when it can be freed (I have to free it since it will be a pointer to a reference counted object) |
|
2093 |
code
|
active
|
2006 Dec
|
anonymous
|
|
2006 Dec
|
|
2
|
3
|
sqlite3_vtab_cursor doesn't have errMsg
|
edit |
The sqlite3_vtab_cursor structure doesn't have a zErrMsg pointer. Only the containing vtable does. This means that operations on cursor objects that have an error have to set the error on the vtable not the cursor. Unfortunately this means that there are race conditions since two different cursors on the same vtable could have errors at the same time. If the cursors are in different threads then a crash or worse can happen. |
|
2090 |
build
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
4
|
3
|
Test corrupt2.test fails: Solaris
|
edit |
While running 'make test', I had come across the following errors:
...
corrupt2-1.1... Ok
corrupt2-1.2...
Expected: [1 {file is encrypted or is not a database}]
Got: [0 {table abc abc 2 {CREATE TABLE abc(a, b, c)}}]
corrupt2-1.3...
Expected: [1 {file is encrypted or is not a database}]
Got: [0 {table abc abc 2 {CREATE TABLE abc(a, b, c)}}]
corrupt2-1.4...
Expected: [1 {database disk image is malformed}]
Got: [0 {table abc abc 2 {CREATE TABLE abc(a, b, c)}}]
corrupt2-1.5...
Expected: [1 {database disk image is malformed}]
Got: [0 {table abc abc 2 {CREATE TABLE abc(a, b, c)}}]
...
Turns out that SQLite was working fine, but TCL was not corrupting the database correctly (who would ever have thought I would want to?). Apparently the 'a' mode for opening a file in Solaris was resetting the position of a write to the end of a file before actually writing (this appears to be a point of contention on the TCL bug tracker). From the way the test is written, it appears that portions of the file were to be overwritten, instead of appending to the end of the file.
I will attach a patch to corrupt2.test after posting this message which, instead of attempting an overwrite, writes individual portions of the database file at a time, with requested strings inserted (technically, replacing) into the file at the requested offsets. |
2006-Nov-29 23:37:05 by anonymous:
I should mention that this is SunOS 5.8, and TCL version 8.4.14.
2006-Dec-05 10:22:08 by anonymous:
I also get these errors (same tcl version but not SunOS). Have you tried a simpler patch by replacing the 'a' in the open calls by a 'r+'? This solved the problem for me.
2007-Jan-23 19:55:08 by anonymous:
That worked! Thank you so much! |
|
2089 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
3
|
3
|
Decouple sqlite_int64 from other 64bit datatypes
|
edit |
Currently sqlite3 makes the (valid) assumption that sqlite_int64 (or i64, u64) is 64 bit wide, matches with Tcl_WideInt and has the same datasize (and byte order) than double. The following patch fixes this and allows sqlite_int64 to be any integral type, e.g. a 32bit int (with the limitations of the reduced datatype size).
The use case for this is for systems that do not support 64bit integers (e.g. lack of compiler feature, embedded system), db's of small data size, and systems without large file support. The patch allows compiling with -DSQLITE_INT64_TYPE=int -DSQLITE_32BIT_ROWID for such a system. |
2006-Nov-29 01:13:07 by anonymous:
Hm, now I wanted to add the patch file but I don't get the formatting right without editing the file and removing empty lines. How am I supposed to add a patch file (created with diff -ru)? |
|
2087 |
new
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
3
|
3
|
Ability to add a check constraint via the alter table command
|
edit |
This is an improvement request.
Add the possibility to add a check constraint to an existing table via the alter table statement.
Example :
CREATE TABLE a(x INTEGER, y INTEGER);
INSERT INTO a VALUES (1,2);
ALTER TABLE a ADD CHECK (y>0);
Actual result :
SQL error: near "CHECK": syntax error
|
|
2086 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
5
|
4
|
Alias in update
|
edit |
Aliases at UPDATE clause doesn't work, i.e.:
UPDATE table1 t1 SET uid=(SELECT rowid FROM table2 WHERE uid=t1.uid AND data=t1.data);
Code whithout aliases work fine. |
|
2084 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
4
|
3
|
Add API function mapping column decl string to SQLite type
|
edit |
This is an API feature request.
It would be nice to be able to obtain the SQLite type (e.g. SQLITE_INTEGER) from the declared column type string as returned by sqlite3_column_decltype.
This was discussed briefly on the mailing list here:
http://marc.10east.com/?l=sqlite-users&m=116422872301957&w=2
The function I have in mind is:
int sqlite3_decltype_to_type(const char *decl)
{
Token decl_token;
char aff_type;
int col_type;
decl_token.z = decl;
if( decl_token.z ){
decl_token.n = strlen(decl_token.z);
aff_type = sqlite3AffinityType(&decl_token);
switch( aff_type ){
case SQLITE_AFF_INTEGER:
col_type = SQLITE_INTEGER;
break;
case SQLITE_AFF_NUMERIC: /* falls through */
case SQLITE_AFF_REAL:
col_type = SQLITE_FLOAT;
break;
case SQLITE_AFF_TEXT:
col_type = SQLITE_TEXT;
break;
case SQLITE_AFF_NONE:
col_type = SQLITE_BLOB;
break;
default:
col_type = 0; /* unknown */
break;
}
}
return col_type;
}
If this seems agreeable, I would be willing to put together a real patch. However, I would need some guidance on where it should go. I'm not sure what should happen when no type can be determined. |
2006-Nov-26 22:32:45 by anonymous:
According to the comment above the function sqlite3AffinityType: "If none of the substrings in the above table are found, SQLITE_AFF_NUMERIC is returned". The default condition in sqlite3_decltype_to_type will not be reached.
2006-Nov-26 23:04:23 by anonymous:
Thanks for pointing to that comment. Looks like SQLITE_AFF_NUMERIC is, for these purposes, unknown. So the case statement could be:
switch( aff_type ){
case SQLITE_AFF_INTEGER:
col_type = SQLITE_INTEGER;
break;
case SQLITE_AFF_REAL:
col_type = SQLITE_FLOAT;
break;
case SQLITE_AFF_TEXT:
col_type = SQLITE_TEXT;
break;
case SQLITE_AFF_NONE:
col_type = SQLITE_BLOB;
break;
case SQLITE_AFF_NUMERIC: /* falls through */
default:
col_type = 0; /* unknown */
break;
}
2006-Nov-27 02:43:06 by anonymous:
Your first function was correct, it just had some unreachable code. There's no unknown affinity, in the absence of a match the affinity is assumed to be numeric:
int sqlite3_decltype_to_type(const char *decl) {
int type = SQLITE_FLOAT;
if( decl ){
Token token;
token.z = decl;
token.n = strlen(token.z);
switch( sqlite3AffinityType(&token) ){
case SQLITE_AFF_INTEGER:
type = SQLITE_INTEGER;
break;
case SQLITE_AFF_TEXT:
type = SQLITE_TEXT;
break;
case SQLITE_AFF_NONE:
type = SQLITE_BLOB;
break;
default:
break;
}
}
return type;
}
|
|
2083 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
4
|
4
|
Give more detailed extension loading error information with dlerror
|
edit |
When using loadable extensions. if dlopen returns an error then SQLite just gives a generic "unable to open shared library" message back. This makes it quite hard to diagnose problems.
I suggest that on Unix platforms you append %s/dlerror() to the message and on Windows append %d/GetLastError() |
|
2082 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
3
|
4
|
UNIX: configure script doesn't enable loading of extensions
|
edit |
The code in loadext.c:234 looks for HAVE_DLOPEN being #defined in order to enable library loading on Linux. However as best I can tell, the configure script never looks for dlopen. It does look for dlfcn.h. (Based on examining the output of configure and config.log)
Consequently extension loading isn't available on Unixen that do support it if you build using ./configure
Work around is to use this commmand:
env CFLAGS="-DHAVE_DLOPEN" ./configure
|
2006-Nov-26 20:53:59 by drh:
The "autoconf" command is busted in SuSE 10.2, which is the OS
I am currently running. So I am unable to rebuild configure after
editing configure.ac. Until the autoconf problem
is resolved, I am unable to address the request in this ticket.
Sorry.
2006-Nov-26 22:36:48 by anonymous:
What happens when you upgrade to the latest version of autoconf for SuSE? I'm sure someone on the list could help you resolve this issue.
2006-Nov-27 07:05:27 by anonymous:
I am actually using Gentoo.
There is a trivial workaround as I noted so there is no need for a solution for 3.3.8. It would be nice to have it fixed for whatever version comes next so that I don't need to document the workaround.
2006-Nov-27 18:32:11 by anonymous:
Another open autoconf ticket:
Check-in [3397]
: Add HAVE_GMTIME_R and HAVE_LOCALTIME_R flags and use them if defined. Unable to modify the configure script to test for gmtime_r and localtime_r, however, because on my SuSE 10.2 system, autoconf generates a configure script that does not work. Bummer. Ticket #1906 |
|
2081 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
doughenry
|
1
|
1
|
sqlite3_column_decltype throws exception, if selection is grouped
|
edit |
If I "group by" a selection over several columns I can't find out the orgin type of these columns using sqlite3_column_decltype(..). An exception is thrown. |
2006-Nov-23 18:37:47 by anonymous:
You also get no decl type from a subselect. This goes to the typeless nature of SQLite - I don't think a type can even be derived in this case. |
|
2080 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
4
|
4
|
Tranfering large BLOB data not efficient
|
edit |
The current approach for tranfering BLOB data (sqlite3_bind_blob, sqlite3_column_blob) is not efficent for large BLOBs, since the whole BLOB data needs to be kept (multiple times?) in memory.
It would be nice to have (additional) methods for streaming the (large) BLOB data to/from the database. Alternatively we could have methods for
transfering the BLOB data in chunks.
Same holds to some extend for large text fields. |
2006-Dec-03 09:53:02 by anonymous:
What is your definition of large? (1MB, 100MB, 1GB?)
Note also that SQLite has an upper limit of 2GB on a field due to the use of signed int in the apis which is 32 bit even on 64 bit platforms. That will limit you to 2GB for blobs, 1GB for UTF-16 strings and somewhere inbetween for UTF-8 strings |
|
2077 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
2
|
1
|
Problems with using ASCII symbols 0x80 - 0xFF in database path
|
edit |
Platform: Windows.
The SQLite library and executable doesn't see database files that are placed into folders named using ASCII symbols with codes 0x80-0xFF. That symbols are used to represent language-specific symbols (for example, Russian). In result, database cannot be placed into folder with name in Russian language.
This bug is "unstable": it doesn't appear in all cases. Below are logs from my experiments with this problem. In all cases the path I requested exists, and database file is placed there.
I have noticed that problem depends on filename path and name lengths.
=========================================================
// creating test database
E:\!DISTRIB\sqlite-3_3_7>sqlite3.exe test.sqb
SQLite version 3.3.7
Enter ".help" for instructions
sqlite> create table a(id int);
sqlite> insert into a values (1);
sqlite> ^C
E:\!DISTRIB\sqlite-3_3_7>copy test.sqb e:\test.sqb
'3'\'`'a'Z'b'`'S'Q'_'` 'f'Q'[']'`'S: 1. //This means that 1 file was copied
E:\!DISTRIB\sqlite-3_3_7>sqlite3 e:\test.sqb
SQLite version 3.3.7
Enter ".help" for instructions
sqlite> select * from a;
1
sqlite> ^C
// Works!
E:\!DISTRIB\sqlite-3_3_7>mkdir e:\'/
//Using ASCII symbol "'/" (0x8D) to represent cyrillic letter which can be entered in the command line by using Alt+(141) combination
E:\!DISTRIB\sqlite-3_3_7>copy test.sqb E:\'/\test.sqb
'3'\'`'a'Z'b'`'S'Q'_'` 'f'Q'[']'`'S: 1.
E:\!DISTRIB\sqlite-3_3_7>sqlite3 e:\'/\test.sqb
SQLite version 3.3.7
Enter ".help" for instructions
sqlite> select * from a;
1
sqlite> ^C
// That is works too!
E:\!DISTRIB\sqlite-3_3_7>mkdir E:\'/\1
E:\!DISTRIB\sqlite-3_3_7>copy test.sqb E:\'/\1\test.sqb
'3'\'`'a'Z'b'`'S'Q'_'` 'f'Q'[']'`'S: 1.
E:\!DISTRIB\sqlite-3_3_7>sqlite3 E:\'/\1\test.sqb
Unable to open database "E:\(T\1\test.sqb": unable to open database file
// Doesn't work, and writes the wrong symbol "(T" in place of "'/"! I've noticed that if we convert symbol "'/" from DOS encoding to Windows encoding and then write it in DOS encoding, then we'll get "(T".
E:\!DISTRIB\sqlite-3_3_7>copy test.sqb E:\'/\tst.sqb
'3'\'`'a'Z'b'`'S'Q'_'` 'f'Q'[']'`'S: 1.
E:\!DISTRIB\sqlite-3_3_7>sqlite3 E:\'/\tst.sqb
SQLite version 3.3.7
Enter ".help" for instructions
sqlite> select * from a;
SQL error: no such table: a
sqlite> ^C
// It seems to work, i don't get an error, but doesn't see the tables! =(
=================================
|
|
2076 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
a.rottmann
|
1
|
1
|
% exists as value in varchar
|
edit |
abnormal abend of client application (C++) when sqlite returns stream of data containing "%" value.
Is % a special character? |
2006-Nov-21 14:14:25 by anonymous:
% is not a special character. Can you post a small C program demonstrating the problem? |
|
2075 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2007 Feb
|
|
3
|
3
|
Improve VACUUM speed and INDEX page locality
|
edit |
In testing several 100 Meg - 1 Gig databases (including the Monotone OpenEmbedded database) I found that changing the order of the SQL commands executed by VACUUM to create indexes after table inserts results in 15% faster VACUUM times, and up to 25% faster cold-file-cache queries when indexes are used. This patch effectively makes the pages of each index contiguous in the database file after a VACUUM, as opposed to being scattered throughout the pages of the table related to the index. Your results may vary, but I think this is a very safe change that can potentially boost average database performance.
Index: src/vacuum.c
===================================================================
RCS file: /sqlite/sqlite/src/vacuum.c,v
retrieving revision 1.65
diff -u -3 -p -r1.65 vacuum.c
--- src/vacuum.c 18 Nov 2006 20:20:22 -0000 1.65
+++ src/vacuum.c 20 Nov 2006 21:09:27 -0000
@@ -143,14 +143,6 @@ int sqlite3RunVacuum(char **pzErrMsg, sq
" AND rootpage>0"
);
if( rc!=SQLITE_OK ) goto end_of_vacuum;
- rc = execExecSql(db,
- "SELECT 'CREATE INDEX vacuum_db.' || substr(sql,14,100000000)"
- " FROM sqlite_master WHERE sql LIKE 'CREATE INDEX %' ");
- if( rc!=SQLITE_OK ) goto end_of_vacuum;
- rc = execExecSql(db,
- "SELECT 'CREATE UNIQUE INDEX vacuum_db.' || substr(sql,21,100000000) "
- " FROM sqlite_master WHERE sql LIKE 'CREATE UNIQUE INDEX %'");
- if( rc!=SQLITE_OK ) goto end_of_vacuum;
/* Loop through the tables in the main database. For each, do
** an "INSERT INTO vacuum_db.xxx SELECT * FROM xxx;" to copy
@@ -162,10 +154,22 @@ int sqlite3RunVacuum(char **pzErrMsg, sq
"FROM sqlite_master "
"WHERE type = 'table' AND name!='sqlite_sequence' "
" AND rootpage>0"
-
);
if( rc!=SQLITE_OK ) goto end_of_vacuum;
+ /* Create indexes after the table inserts so that their pages
+ ** will be contiguous resulting in (hopefully) fewer disk seeks.
+ */
+ rc = execExecSql(db,
+ "SELECT 'CREATE UNIQUE INDEX vacuum_db.' || substr(sql,21,100000000) "
+ " FROM sqlite_master WHERE sql LIKE 'CREATE UNIQUE INDEX %'");
+ if( rc!=SQLITE_OK ) goto end_of_vacuum;
+
+ rc = execExecSql(db,
+ "SELECT 'CREATE INDEX vacuum_db.' || substr(sql,14,100000000)"
+ " FROM sqlite_master WHERE sql LIKE 'CREATE INDEX %' ");
+ if( rc!=SQLITE_OK ) goto end_of_vacuum;
+
/* Copy over the sequence table
*/
rc = execExecSql(db,
|
2007-Feb-11 00:49:50 by drh:
My alternative plan is to modify insert.c so that it recognizes
the special case of
INSERT INTO table1 SELECT * FROM table2;
when table1 and table2 have identical schemas, including all the
same indices. When this special case is recognized, the generated
bytecode will first transfer all table entries from table2 to table1,
using a row by row transfer without decoding each row into its
constituient columns. Then it will do the same for each index.
There will be two benefits here. First, when the above construct
occurs during the course of a VACUUM, the table and each index,
including intrisic indices associated with UNIQUE and PRIMARY KEY
constraints, will be transferred separately so that all of there
pages will be adjacent in the database file. The second benefit
will occur when trying to load large quantities of data into an
indexed table. Loading indexed data into a very large table is
currently slow because the index entries are scattered haphazardly
around in the file. But if data is first loaded into a smaller
temporary table with the same schema, it can then be transferred
to the main table using an INSERT statement such as the above in
what amounts to a merge operation.
2007-Feb-11 06:58:36 by anonymous:
There's no question that your proposal will greatly improve VACUUM speed which relies on the "INSERT INTO table1 SELECT * from table2" construct. But would it be possible for you to relax the restriction on having identical indexes for table1 and table2? For that matter it would be nice if table2 could be any subselect or view. Then "REPLACE INTO table1 SELECT ...anything..." could also be optimized. Since you can detect that SQLite is doing a bulk insert anyway, it could generate code to make a temporary staging table with automatically generated identical indexes to table1 which could be periodically merged into table1 and truncated every X rows. X could be either set via pragma or be a function of the size of the page cache. The temporary staging table would be dropped after the bulk INSERT INTO ... SELECT. Every user inserting large volumes of data would have to perform this procedure anyway. Manually recreating all the indexes for a given temporary table to match the original table and performing the looping logic is cumbersome and error-prone. It would be very conveniant if SQLite were to do it on the user's behalf. This scheme could only work if there are no triggers on table1, of course.
2007-Feb-11 09:16:25 by drh:
My initial enhancement does nothing to preclude the more agressive
enhancement described by anonymous. In order to avoid subtle bugs,
and in view of my limited time available to work on this, I think it
best to take the more conservative approach first and defer the more
elaborate optimization suggested by anonymous until later.
2007-Feb-11 13:54:34 by anonymous:
It should be possible to identify contiguous blocks of individual "INSERT INTO table1 VALUES(...)" statements to the same table within a large transaction and perform the same proposed optimization as with "INSERT INTO table1 SELECT ...". This would require higher level coordination by the parser. Anytime a read operation (SELECT, UPDATE) occurs on such a table marked for bulk INSERT within the large transaction, its temp staging table could be merged into the INSERT destination table and the staging table truncated. The process could be repeated for the remainder of the transaction.
Such an optimization would be a huge benefit to SQLite users since they would need not know the idiosynchracies of the implementation of "INSERT INTO table1 SELECT ..." in order to have efficient table and index population.
Alternatively, if you wish to avoid the complexity of re-assembling and staging individual INSERT statements, it might be a good opportunity for SQLite to support the multi-row variant of the INSERT command:
INSERT INTO table1 (a,b,c) VALUES(1,2,3), (4,5,6), (7,8,9);
Which is essentially a transform of:
CREATE TEMP TABLE table1_staging (a,b,c);
INSERT INTO table1_staging VALUES(1,2,3);
INSERT INTO table1_staging VALUES(4,5,6);
INSERT INTO table1_staging VALUES(7,8,9);
INSERT INTO table1 SELECT * FROM table1_staging;
-- TRUNCATE OR DROP table1_staging as necessary
which could use the same bulk staging optimization.
2007-Feb-13 02:42:41 by anonymous:
Any harm in checking in the simple patch above for the 3.3.13 release?
2007-Feb-13 12:51:47 by drh:
I have a much better fix standing by that I intend to check-in as
soon as I get 3.3.13 out the door. I don't want this in 3.3.13
for stability reasons.
2007-Feb-18 23:07:08 by anonymous:
Some related analysis and an .import patch using a :memory: staging table with the "INSERT INTO table1 SELECT FROM table2" construct can be found here:
http://www.mail-archive.com/sqlite-users%40sqlite.org/msg22143.html |
|
2074 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
4
|
4
|
feature request: .dump with page_size
|
edit |
It would be useful for sqlite shell users to have a .dump command variant that would cause .dump to output the current database setting of "PRAGMA page_size;". Something similar to:
sqlite> .dump2
PRAGMA page_size=16364;
...rest of dump...
This way they can trivially preserve the page size when exporting/importing data from/to SQLite:
sqlite3 old.db .dump2 | sqlite3 new.db
without resorting to non-portable shell gymnastics:
(echo -n "PRAGMA page_size=" ; sqlite3 old.db "PRAGMA page_size;" ; echo ";" ; ./sqlite3.exe old.db .dump) | sqlite3 new.db
Perhaps other PRAGMA settings could also optionally be exported (legacy_file_format, cache size, etc). |
|
2070 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
4
|
4
|
No error for ambiguous result alias in WHERE clause
|
edit |
This SELECT should result in an error since 'x' is ambiguous:
select a x, 2*a x from (select 3 a union select 4 a) where x>3;
4|8
The current heuristic seems to be the first matching result set expression alias from left-to-right "wins". |
2006-Nov-17 19:38:15 by anonymous:
In this test case, the right-most ambiguous expression wins:
CREATE TABLE t1(a);
INSERT INTO t1 VALUES(3);
INSERT INTO t1 VALUES(4);
INSERT INTO t1 VALUES(5);
select a*2 a, a from t1 where a>4;
10|5
It appears that table values take precedence over result set aliases in where clauses. |
|
2068 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
4
|
4
|
pkgIndex.tcl contains incomplete version number
|
edit |
The pkgIndex.tcl file generated by sqlite 3.3.8 contains the line:
package ifneeded sqlite3 3.3 ...
Whereas the library actually provides version 3.3.8. In a 8.5 Tcl interpreter, this results in an error message when package require'd:
attempt to provide package sqlite3 3.3 failed: package sqlite3 3.3.8 provided instead
The solution seems to be to adjust the Makefile.in tcl_install target to pass $(RELEASE) rather than $(VERSION) to the tclinstaller.tcl script. |
|
2066 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
2
|
2
|
Incorrect error message in the case of ENOLCK
|
edit |
If you're trying to open a sqlite database that is stored on a filesystem that doesn't support locking, then you'll get the error when you try to execute any commands on it:
Error: file is encrypted or is not a database
If you run sqlite under strace, you see:
read(0, ".schema\n.quit\n", 4096) = 14
fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, len=1}, 0xafa5cd70) = 0
fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=1073741826, len=510}, 0xafa5cd70) = 0
fcntl64(3, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=1073741824, len=1}, 0xafa5cd70) = 0
access("/mnt/www/zzz_old_sites/trac.db-journal", F_OK) = -1 ENOENT (No such file or directory)
fstat64(3, {st_mode=S_IFREG|0644, st_size=584704, ...}) = 0
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, "** This file contains an SQLite "..., 1024) = 1024
fcntl64(3, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}, 0xafa5cdd0) = -1 ENOLCK (No locks available)
write(2, "Error: file is encrypted or is n"..., 46Error: file is encrypted or is not a database
Sqlite should really check the exact error code, and give a more helpful error (eg "Locking not available on this filesystem. Databases may only be stored on filesystems that support locking") |
|
2063 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
4
|
4
|
vtab_err.test fails if sqlite is compiled without -DSQLITE_MEMDEBUG
|
edit |
I noticed that when running `make fulltest', vtab_err.test
fails with an error message like this one (repeated over and
over) if sqlite has been compiled without the option
-DSQLITE_MEMDEBUG
vtab_err-2.1...
Error: invalid command name "sqlite_malloc_fail"
altermalloc.test also has the same "sqlite_malloc_fail"
command in it, but it doesn't cause an error because it
skips the test if it detects that -DSQLITE_MEMDEBUG
isn't available. I'll attach a patch that should fix it.
The code is pretty much copied directly from altermalloc.test. |
|
2062 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
4
|
4
|
document 'pk' column of PRAGMA table_info()
|
edit |
Comment in pragma.c and sqlite.org/pragma.html does not mention the sixth column of PRAGMA table_info(). |
|
2061 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
anonymous
|
5
|
5
|
cleanup for quickstart.html
|
edit |
just compiled the C example from quickstart.html (gcc/glibc Debian SID)
a small hint (a bit pea-counting):
to avoid warnings either #include<stdlib.h> for the exit() function or (maybe better) use return instead of calling exit(). |
|
2060 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2007 Feb
|
|
1
|
1
|
Table references enclosed in parenthesis become "invisible"
|
edit |
Hi,
I'm developing an RDF-based system, which translates queries from SPARQL into SQL. While trying to add support for SQLite (MySQL is already supported) I came across the following problem: when table references in a FROM clause are enclosed in parenthesis, they cannot be referenced from outside the parenthesized expression. For example, given the table definitions
CREATE TABLE IF NOT EXISTS t1 (a, b);
CREATE TABLE IF NOT EXISTS t2 (c, d);
CREATE TABLE IF NOT EXISTS t3 (e, f);
The following queries all fail with "no such column" errors:
SELECT t1.a, t3.f
FROM (t1 CROSS JOIN t2 ON t1.b = t2.c) LEFT JOIN t3 ON t2.d = t3.e;
SELECT t1.a, t3.f
FROM t1 CROSS JOIN (t2 LEFT JOIN t3 ON t2.d = t3.e) ON t1.b = t2.c;
SELECT t1.a, t2.d
FROM (t1), (t2)
WHERE t1.b = t2.c;
I'm not sure if it is always possible to reformulate the queries in such a way that the extra parenthesis aren't necessary, but I suspect that complex expressions involving joins may require them to achieve the intended semantics. In any case, my system would require large changes to be able to get rid of the parenthesized subjoins, so it would be nice if this problem could be fixed. :-) |
2006-Nov-10 03:56:46 by anonymous:
For what it's worth, here's the parse trees of two similar queries ("SELECT t1.a, t2.d FROM t1, t2 WHERE t1.b = t2.c" and "SELECT t1.a, t2.d FROM (t1), (t2) WHERE t1.b = t2.c"), as well as one of the other more complicated join queries previously listed.
SELECT t1.a, t2.d FROM t1, t2 WHERE t1.b = t2.c;
Select {
op: TK_SELECT
isResolved: 1
pSrc: {
a[0]: {
zName: t1
iCursor: 0
colUsed: 0x00000003
pTab: t1
jointype: JT_INNER
}
a[1]: {
zName: t2
iCursor: 1
colUsed: 0x00000003
pTab: t2
}
}
pEList: {
a[0]: {
pExpr: {
op: TK_COLUMN
span: {t1.a}
affinity: SQLITE_AFF_NONE
iTable: 0
iColumn: 0
pTab: t1
}
}
a[1]: {
pExpr: {
op: TK_COLUMN
span: {t2.d}
affinity: SQLITE_AFF_NONE
iTable: 1
iColumn: 1
pTab: t2
}
}
}
pWhere: {
op: TK_EQ
span: {t1.b = t2.c}
pLeft: {
op: TK_COLUMN
span: {t1.b}
affinity: SQLITE_AFF_NONE
iTable: 0
iColumn: 1
pTab: t1
}
pRight: {
op: TK_COLUMN
span: {t2.c}
affinity: SQLITE_AFF_NONE
iTable: 1
iColumn: 0
pTab: t2
}
}
}
SELECT t1.a, t2.d FROM (t1), (t2) WHERE t1.b = t2.c;
Select {
op: TK_SELECT
isResolved: 1
pSrc: {
a[0]: {
zAlias: sqlite_subquery_5C0A10_
iCursor: 0
pTab: sqlite_subquery_5C0A10_
pSelect: {
op: TK_SELECT
isResolved: 1
pSrc: {
a[0]: {
zName: t1
iCursor: 1
colUsed: 0x00000003
pTab: t1
}
}
pEList: {
a[0]: {
zName: a
pExpr: {
op: TK_COLUMN
token: {a}
span: {a}
affinity: SQLITE_AFF_NONE
iTable: 1
iColumn: 0
pTab: t1
}
}
a[1]: {
zName: b
pExpr: {
op: TK_COLUMN
token: {b}
span: {b}
affinity: SQLITE_AFF_NONE
iTable: 1
iColumn: 1
pTab: t1
}
}
}
}
jointype: JT_INNER
}
a[1]: {
zAlias: sqlite_subquery_5BE4F0_
iCursor: 2
pTab: sqlite_subquery_5BE4F0_
pSelect: {
op: TK_SELECT
isResolved: 1
pSrc: {
a[0]: {
zName: t2
iCursor: 3
colUsed: 0x00000003
pTab: t2
}
}
pEList: {
a[0]: {
zName: c
pExpr: {
op: TK_COLUMN
token: {c}
span: {c}
affinity: SQLITE_AFF_NONE
iTable: 3
iColumn: 0
pTab: t2
}
}
a[1]: {
zName: d
pExpr: {
op: TK_COLUMN
token: {d}
span: {d}
affinity: SQLITE_AFF_NONE
iTable: 3
iColumn: 1
pTab: t2
}
}
}
}
}
}
pEList: {
a[0]: {
pExpr: {
op: TK_COLUMN
span: {t1.a}
flags: EP_Resolved EP_Error
iTable: -1
iColumn: 0
}
}
a[1]: {
pExpr: {
op: TK_DOT
span: {t2.d}
pLeft: {
op: TK_ID
token: {t2}
span: {t2}
}
pRight: {
op: TK_ID
token: {d}
span: {d}
}
}
}
}
pWhere: {
op: TK_EQ
span: {t1.b = t2.c}
pLeft: {
op: TK_DOT
span: {t1.b}
pLeft: {
op: TK_ID
token: {t1}
span: {t1}
}
pRight: {
op: TK_ID
token: {b}
span: {b}
}
}
pRight: {
op: TK_DOT
span: {t2.c}
pLeft: {
op: TK_ID
token: {t2}
span: {t2}
}
pRight: {
op: TK_ID
token: {c}
span: {c}
}
}
}
}
SQL error: no such column: t1.a
SELECT t1.a, t3.f FROM (t1 CROSS JOIN t2 ON t1.b = t2.c) LEFT JOIN t3 ON t2.d = t3.e;
Select {
op: TK_SELECT
isResolved: 1
pSrc: {
a[0]: {
zAlias: sqlite_subquery_5BFA30_
iCursor: 0
pTab: sqlite_subquery_5BFA30_
pSelect: {
op: TK_SELECT
isResolved: 1
pSrc: {
a[0]: {
zName: t1
iCursor: 1
colUsed: 0x00000003
pTab: t1
jointype: JT_INNER JT_CROSS
}
a[1]: {
zName: t2
iCursor: 2
colUsed: 0x00000003
pTab: t2
}
}
pEList: {
a[0]: {
zName: a
pExpr: {
op: TK_COLUMN
span: {t1.a}
affinity: SQLITE_AFF_NONE
iTable: 1
iColumn: 0
pTab: t1
}
}
a[1]: {
zName: b
pExpr: {
op: TK_COLUMN
span: {t1.b}
affinity: SQLITE_AFF_NONE
iTable: 1
iColumn: 1
pTab: t1
}
}
a[2]: {
zName: c
pExpr: {
op: TK_COLUMN
span: {t2.c}
affinity: SQLITE_AFF_NONE
iTable: 2
iColumn: 0
pTab: t2
}
}
a[3]: {
zName: d
pExpr: {
op: TK_COLUMN
span: {t2.d}
affinity: SQLITE_AFF_NONE
iTable: 2
iColumn: 1
pTab: t2
}
}
}
pWhere: {
op: TK_EQ
span: {t1.b = t2.c}
flags: EP_FromJoin EP_Resolved
iRightJoinTable: 2
pLeft: {
op: TK_COLUMN
span: {t1.b}
affinity: SQLITE_AFF_NONE
flags: EP_FromJoin EP_Resolved
iTable: 1
iColumn: 1
iRightJoinTable: 2
pTab: t1
}
pRight: {
op: TK_COLUMN
span: {t2.c}
affinity: SQLITE_AFF_NONE
flags: EP_FromJoin EP_Resolved
iTable: 2
iColumn: 0
iRightJoinTable: 2
pTab: t2
}
}
}
jointype: JT_LEFT JT_OUTER
}
a[1]: {
zName: t3
iCursor: 3
pTab: t3
}
}
pEList: {
a[0]: {
pExpr: {
op: TK_COLUMN
span: {t1.a}
flags: EP_Resolved EP_Error
iTable: -1
iColumn: 0
}
}
a[1]: {
pExpr: {
op: TK_DOT
span: {t3.f}
pLeft: {
op: TK_ID
token: {t3}
span: {t3}
}
pRight: {
op: TK_ID
token: {f}
span: {f}
}
}
}
}
pWhere: {
op: TK_EQ
span: {t2.d = t3.e}
flags: EP_FromJoin
iRightJoinTable: 3
pLeft: {
op: TK_DOT
span: {t2.d}
flags: EP_FromJoin
iRightJoinTable: 3
pLeft: {
op: TK_ID
token: {t2}
span: {t2}
flags: EP_FromJoin
iRightJoinTable: 3
}
pRight: {
op: TK_ID
token: {d}
span: {d}
flags: EP_FromJoin
iRightJoinTable: 3
}
}
pRight: {
op: TK_DOT
span: {t3.e}
flags: EP_FromJoin
iRightJoinTable: 3
pLeft: {
op: TK_ID
token: {t3}
span: {t3}
flags: EP_FromJoin
iRightJoinTable: 3
}
pRight: {
op: TK_ID
token: {e}
span: {e}
flags: EP_FromJoin
iRightJoinTable: 3
}
}
}
}
SQL error: no such column: t1.a
2006-Nov-11 18:29:33 by anonymous:
The resolving bug appears to be that unique column names or column aliases are searched across all subqueries, but table names and table aliases are only searched at their current SELECT level only.
With this in mind, here are mechanical workarounds without using column aliases (assumes the column names in all joined tables are unique):
SELECT a, f FROM (t1 CROSS JOIN t2 ON t1.b = t2.c) LEFT JOIN t3 ON d = e;
SELECT t1.a, f FROM t1 CROSS JOIN (t2 LEFT JOIN t3 ON t2.d = t3.e) ON t1.b = c;
SELECT a, d FROM (t1), (t2) WHERE b = c;
And here are mechanical workarounds using column aliases (assumes the column names are not unique between tables):
SELECT t1.a, t3f FROM t1 CROSS JOIN (select t3.f t3f, t2.c t2c from t2 LEFT JOIN t3 ON t2.d = t3.e) ON t1.b = t2c;
SELECT t1a, t3.f FROM (select t1.a t1a, t2.d t2d from t1 CROSS JOIN t2 ON t1.b = t2.c) LEFT JOIN t3 ON t2d = t3.e;
SELECT t1a, t2d FROM (select t1.a t1a, t1.b t1b from t1), (select t2.c t2c, t2.d t2d from t2) WHERE t1b = t2c;
Notice that t3.f in the second query did not require an alias because the table "t3" was part of its immediate SELECT. You could make an alias for every column just in case, I just wanted to highlight the difference.
2007-Feb-13 15:40:31 by anonymous:
Fixing this issue would slow down SELECT parsing and column resolution for all queries (more specifically all prepared statements) due to the recursion required for column resolution. It would be easier to change your SQL code generator to accomodate SQLite. Just make aliases for every table at every subselect level and have the SELECT at any given level only work with the table aliases at that level. |
|
2059 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
1
|
1
|
Still missing .DEF file from Windows 3.3.8 source code distribution
|
edit |
The file sqlite3.def is missing from the zip archive of sources used to build sqlite3 on Windows. Ticket number 2031 was closed with a remark that this file is generated during the build process. That is true if one is building on Linux with MinGW32 configured as a cross-compiler. If one were building using that method then I assume one would not be downloading the src.zip archive anyway.
My impression is that the src.zip archive is prepared once the build has been performed on Linux so Windows developers can directly build sqlite (and the generated files) without need of the other tools that the build process depends on. If this is accurate, then it would be very helpful if the src.zip archive could also include the sqlite3.def file. Without this file it is not possible for Windows developers to create a DLL from the src.zip archive.
Thanks |
2006-Nov-09 20:05:23 by anonymous:
Works fine as is with MinGW ./configure && make sqlite3.exe |
|
2057 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
3
|
1
|
full_column_names when 2 or more tables are joined is not working
|
edit |
Version 2.8 has the behavior described in the documentation in respect to full_column_names when 2 or more tables are present with (table/alias).*, but 3.3.8 doesn't, mixing the pragmas "full_column_names" and "short_column_names" can only force to have full_column_names allways or never, some programs expect the behavior described in the documentation to remain working. |
2006-Nov-08 20:10:13 by anonymous:
Version 3.3.3 as well has the same problem.
2006-Nov-09 09:34:52 by anonymous:
Changing the line 977 of select.c (3.3.8) from:
if( pEList->a[i].zName){
to:
if( pEList->a[i].zName && pTabList->nSrc==1){
with pragma short_column_names = 0 behaves like 2.8 series. |
|
2051 |
code
|
active
|
2006 Nov
|
anonymous
|
|
2006 Nov
|
|
5
|
5
|
minor documentation bug
|
edit |
On the page http://www.sqlite.org/lang_attach.html you wrote:
If an attached table doesn't have a duplicate table name in the main database, it doesn't require a database name prefix. When a database is attached, all of its tables which don't have duplicate names become the default table of that name. Any tables of that name attached afterwards require the table prefix. If the default table of a given name is detached, then the last table of that name attached becomes the new default.
I think the right form should be: Any tables of that name attached afterwards require the database prefix.
Am I right?
Thank you,
Dim Zegebart |
|
2048 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
drh
|
1
|
1
|
table_info on columns with no default value are returned as string
|
edit |
On line 486, noDflt is declared as
static const Token noDflt = { (unsigned char*)"", 0, 0 };
And on line 493:
if( pDflt->z ){
sqlite3VdbeOp3(v, OP_String8, 0, 0, (char*)pDflt->z, pDflt->n);
}else{
sqlite3VdbeAddOp(v, OP_Null, 0, 0);
So columns with no default value aren't being set to null because the (pDflt->z) condition is non-null. |
|
2046 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Nov
|
shess
|
1
|
1
|
FTS1 - Error closing database due to unfinished statements
|
edit |
The following script causes an error in SQLite3.exe with FTS1. The error will surface only AFTER the script has finished AND you have typed .exit at the sqlite> prompt to quit SQLite3.
The problem seems that the SELECT statement is not properly finalized due to an internal error.
-- The next line is for Windows only, please adopt it
-- if running Linux or use a FTS1-enabled SQLite3 binary.
select load_extension ('fts1.dll');
CREATE TABLE Snippets(
SnippetID INTEGER PRIMARY KEY,
SnippetTitle TEXT,
FtsID INTEGER);
CREATE VIRTUAL TABLE SnippetsFts USING FTS1 (SnippetTitle, SnippetText);
INSERT INTO Snippets (SnippetTitle) VALUES ('one');
INSERT INTO Snippets (SnippetTitle) VALUES ('two');
SELECT SnippetID FROM Snippets JOIN SnippetsFts ON FtsID = +SnippetsFts.RowID
WHERE SnippetsFts MATCH 'one';
-- After the script is done, type .exit at the prompt to close the database.
--
-- SQLite3 will close, but report the following error before doing so:
--
-- "error closing database: Unable to close due to unfinalised statements"
--
-- Does this qualify for a bug?
The script is also attached to this ticket. |
2006-Nov-27 22:58:49 by shess:
Attached tighter version of the replication script, generated in isolating what mattered to the bug. |
|
2043 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
1
|
1
|
Spaces in view statement
|
edit |
If you have a table defined with fields that contain spaces.
create table table1 ("field one", "field two", "field three");
Then you do a select
select "field one" from table1;
That works fine. However if you save it as a view
create view view_one as select "field one" from table1;
Then if you run a select on the view it fails.
select * from view_one; |
|
2041 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2007 Mar
|
|
4
|
4
|
sqlite3.pc on Solaris needs -lrt in "Libs:" entry
|
edit |
On Solaris, to get fdatasync(), it's necessary to link with -lrt (the realtime library). I reported that issue a while back, and sqlite's configure has since become smart enough to look for fdatasync() in -lrt, and some of the sqlite Makefile targets know to at $(TLIBS) to the link line, to pick up any addtional libraries (like -lrt) that may be needed.
The problem is that -lrt isn't added to the sqlite3.pc file that's generated, so other applications that use pkg-config and the sqlite3.pc to determine how to link against libsqlite3 don't know that they need to add -lrt.
One fairly easy fix for the problem is to modify sqlite3.pc.in to also include @TARGET_LIBS@ in the Libs: line. That way, if anything is added to TARGET_LIBS by configure, it's automatically substituted into both the Makefile and sqlite3.pc.
Still, I don't understand why libsqlite3 isn't directly linked against -lrt. It's the libsqlite.3.so.* that has the dependency on librt, not the sqlite3 shell, so I don't understand why $(TLIBS) is mentioned for the sqlite3 target instead of the libsqlite3.la target.
I can provide a patch that adds @TARGET_LIBS@ to the Libs line for sqlite3.pc, or I can provide a patch that adds $(TLIBS) to the link line for libsqlite3.la and removes it from sqlite3. I just need to know which the developers prefer.
Thanks!
Tim |
2006-Nov-22 15:09:25 by anonymous:
I was having similar problems, but my build failures didn't occur until 'make test'. Unfortunately, <code>@TARGET_LIBS@</code> did not work for me... Thankfully, adding <code>$(TLIBS)</code> to the libsqlite3.la rule in the Makefile did.
Thank you for reporting your fix! You've helped me greatly!
-- Brett
2007-Mar-30 05:37:16 by anonymous:
#1802, #2041 and #2270 are the same basic issue: librt should get linked into libsqlite3.so |
|
2037 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
1
|
1
|
Sqlite3 can't use datafile in Chinese path with Win2000 and WindowsXP.
|
edit |
Sqlite3 can't use datafile in Chinese path with Win2000 and WindowsXP.
This is a bug in os_win.c .
My firend modify code to so , it work right.
/*
** Convert a UTF-8 string to UTF-32. Space to hold the returned string
** is obtained from sqliteMalloc.
*/
static WCHAR *utf8ToUnicode(const char *zFilename){
int nChar;
WCHAR *zWideFilename;
if( !isNT() ){
return 0;
}
nChar = MultiByteToWideChar(CP_THREAD_ACP, MB_COMPOSITE, zFilename, -1, NULL, 0);
zWideFilename = sqliteMalloc( nChar*sizeof(zWideFilename[0]) );
if( zWideFilename==0 ){
return 0;
}
nChar = MultiByteToWideChar(CP_THREAD_ACP, MB_COMPOSITE, zFilename, -1, zWideFilename, nChar);
if( nChar==0 ){
sqliteFree(zWideFilename);
zWideFilename = 0;
}
return zWideFilename;
}
/*
** Convert UTF-32 to UTF-8. Space to hold the returned string is
** obtained from sqliteMalloc().
*/
static char *unicodeToUtf8(const WCHAR *zWideFilename){
int nByte;
char *zFilename;
nByte = WideCharToMultiByte(CP_THREAD_ACP, WC_COMPOSITECHECK, zWideFilename, -1, 0, 0, 0, 0);
zFilename = sqliteMalloc( nByte );
if( zFilename==0 ){
return 0;
}
nByte = WideCharToMultiByte(CP_THREAD_ACP, WC_COMPOSITECHECK, zWideFilename, -1, zFilename, nByte,
0, 0);
if( nByte == 0 ){
sqliteFree(zFilename);
zFilename = 0;
}
return zFilename;
}
|
2006-Oct-20 10:26:46 by anonymous:
The proposed fix is completely wrong, but the bug exists nonetheless. The problem is that SQLite expects file names in UTF-8 encoding (and there is probably bug in your application too guessing from the proposed fix). While this works fine on NT systems where the UTF-8 encoding is converted to UTF-16 and passed to system wide-character APIs, the code path for non-NT systems (Win 9x) with ANSI-only APIs doesn't convert the UTF-8 file names into the ANSI code page which is expected by the system APIs. |
|
2032 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
1
|
1
|
AV in btree.c running FTS2 compiled with SQLITE_OMIT_SHARED_CACHE
|
edit |
If compiled with FTS2 support as well as SQLITE_OMIT_SHARED_CACHE=1, the sqlite console application causes an
Access Violation: btree.c, line 3538: Read of address x00000014
if( pCur->idx>=pPage->nCell ){
if the SQL (attatched) is executed.
I believe that this is a bug in btree.c, for the following reasons:
- The AV does not show if the #ifndef SQLITE_OMIT_SHARED_CACHE (lines 3514 and 3525) are commentet out.
- From my reading, all virtual tables use the extension API only and do not access the btree directly.
|
2006-Oct-25 06:30:43 by shess:
Note that the attached SQL has exactly 273 INSERT statements. 273==256+16+1, so this is kicking in at a merge point. Don't know how that's relevant, but it seems suspicious.
2006-Oct-25 16:31:34 by anonymous:
Many thanks for looking into this - it was driving me mad until I came up with the rather simple SQL to reproduce it.
I am not sure if the number of INSERTS is 100% the number needed to cause the problem, but the crash always happens after the exact same number of inserts. I did not count them but added roughly enough of them to cause the error.
Sidenote: I can also make FTS2 to crash at another point, which I thought was related to the sizeof() bug I also reported. But apprarently it is not. Unfortunately I can not provide a test case for this since I can reproduce it only after adding some 3000 or so copyrighted documents to an empty database. At the time of the crash the DB is about 250 MB in size. However, I will run a test after the next commits to FTS2.
2006-Oct-26 08:57:41 by anonymous:
My previious comments from yesterday seem to be invalidated by the latest checkins [3486]
, [3488]
and [3489]
. Many thanks for those!
However, the problem with SQLITE_OMIT_SHARED_CACHE still persists. |
|
2028 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
4
|
2
|
FTS1: UNIQUE() expression and UPDATE command not working
|
edit |
I'm working with tables, containing around 1,4 million entries (1GB file size). To allow faster fulltext search I tried FTS1 now.
What I saw is:
creating the virtual FTS1 table with one keyword "UNIQUE(code), reference, text, ..." I had the idea to have faster access to "code", because this entry is only one time existing in table.
In my actual SQLITE table "UNIQUE" was good idea, because "UPDATE"ing of entries was much faster as without "UNIQUE" expression.
Unfortunately, in that moemnt I use "UNIQUE" expression in fulltext table, the FTS1 table doesn't accept insertion of entries like "INSERT into receipe (code, reference, text) values ('4711', 'RefnotAvailable', 'Test');"
So I removed the "UNIQUE" keyword, knowing that later "UPDATE" command to modify entries will be slower.
So I built new table with additional FTS1 fulltext table.
Then I tried to "UPDATE" one entry. In that moment the program stopped immediately working (WIN XP system), what means that the application stopped without comment and returned to desktop.
I tried the same in SQLITE3.exe (command line program) but also that program suspended immediately after the UPDATE command (like "UPDATE Volltext SET code = '4710', reference = 'RefChanged', text = 'notext';"
That seems to me to be a bug.
By the way, creating fulltext table to search inside my whole database increased the filesize a lot (4 times). May be that is solved in FTS2?
Last wish: Fulltext search like "foo*" to find "fool" and "foot" would be a really great improvement.
Best regards
Ingo |
2006-Oct-23 13:56:59 by anonymous:
Ooops, as I saw today, also "DELETE" statements are causing SQLITE to stop working (crash). Program returns to Desktop on WIN XP after DELETE command. |
|
2027 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
1
|
1
|
FTS: Phrase searches return Offsets for individual phrase words
|
edit |
With FTS (one as well as two), phrase searches return offsets for all individual words instead of the phrase as a whole, like in
select name, ingredients from recipe where ingredients match '"broccoli cheese"';
Offsets() returns at least two matches for both individual words:
|
|
2026 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
4
|
5
|
\n in .output is not allowed even with quote
|
edit |
.output drive:\nabc.txt
.output e:\new0.txt
.output z:\new1.txt
.output "c:\new2.txt"
will result an error
omitting the \ will just put the file in the same folder to the sqlite3.exe (doesnt help)
solve it by replace \ by / |
2006-Oct-15 21:28:55 by anonymous:
How about c:\\new.txt?
2006-Oct-16 11:49:58 by anonymous:
How about "c:/new.txt"? |
|
2025 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
drh
|
5
|
5
|
Add pragama command to return loaded extension list
|
edit |
How about add a new pragama command to return loaded extension list? |
|
2024 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
drh
|
5
|
5
|
Add If not exist syntax to Create Virtual Table
|
edit |
Parser Enhancement request: is it possible to add If not exist syntax to Create Virtual Table? all other create schema support such syntax. |
|
2022 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
1
|
1
|
.import command is not working
|
edit |
I have a windows system running version 3.3.6 and a linux system running 3.3.3
when I run .import catalog.csv TEMPDATA on the windows system, it works fine. On the linux system, no data gets imported. There are no error messages.
Is this a known issue in 3.3.3? |
2006-Oct-14 01:15:07 by anonymous:
A sample SQL schema and a 3 line import file demonstrating the problem would be helpful.
2006-Nov-08 15:48:28 by anonymous:
Schema:
CREATE TABLE Catalog (
UPC text
, SKU text primary key
, DESC text
, PACK text
, PRICE text
, SIZE text );
test.csv contents
00000000103,103,EFFEM CHOCOLATE FUNSIZE 75PPK 1 X1EA,1,$155.94,1 EA
00000000152,414317,CLEARLIGHT SLUSH CUP 16OZ CDL16 1X50EA,1,$5.04,50 EA
00000000152,56880,CLEARLIGHT SLUSH CUP 16OZ CDL16 20X50EA,20,$96.31,50 EA
Command that does nothing:
.import test.csv Catalog
2006-Nov-08 15:52:40 by anonymous:
Sorry, I'll try this again:
Schema:
CREATE TABLE Catalog (
UPC text
, SKU text primary key
, DESC text
, PACK text
, PRICE text
, SIZE text );
test.csv contents
00000000103,103,EFFEM CHOCOLATE FUNSIZE 75PPK 1 X1EA,1,$155.94,1 EA
00000000152,414317,CLEARLIGHT SLUSH CUP 16OZ CDL16 1X50EA,1,$5.04,50 EA
00000000152,56880,CLEARLIGHT SLUSH CUP 16OZ CDL16 20X50EA,20,$96.31,50 EA
Command that does nothing:
.import test.csv Catalog
|
|
2019 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
1
|
1
|
FTS1: Create table in transaction raises Out of Sequence error (21)
|
edit |
This error:
SQL error: library routine called out of sequence
is caused if the following script is executed by the Windows version of the SQLite3 console application with .load fts1.dll extension. If it does not show immediately, it will eventually surface if the script is run multiple times.
The cause of the problem seems to be related to the transaction, the create virtual table as well as the amount of data inserted.
Finally, the script is attached. |
|
2017 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
1
|
1
|
DROP TABLE fails on FTS1 utility tables with certain OMIT_s defined
|
edit |
The following SQL fails when SQLite is compiled with the SQLITE_OMIT_ defines stated below:
create virtual table foo using fts1 (content);
drop table foo;
create virtual table foo using fts1 (content);
Cause: The foo_content and foo_term tables are not deleted.
To verify, please define these SQLITE_OMIT_s:
OPTS += -DSQLITE_OMIT_ALTERTABLE
OPTS += -DSQLITE_OMIT_ANALYZE
OPTS += -DSQLITE_OMIT_AUTHORIZATION
OPTS += -DSQLITE_OMIT_AUTOINCREMENT
OPTS += -DSQLITE_OMIT_AUTOVACUUM
OPTS += -DSQLITE_OMIT_BETWEEN_OPTIMIZATION
OPTS += -DSQLITE_OMIT_BLOB_LITERAL
OPTS += -DSQLITE_OMIT_CAST
OPTS += -DSQLITE_OMIT_CHECK
OPTS += -DSQLITE_OMIT_COMPLETE
OPTS += -DSQLITE_OMIT_COMPOUND_SELECT
OPTS += -DSQLITE_OMIT_EXPLAIN
OPTS += -DSQLITE_OMIT_FLAG_PRAGMAS
OPTS += -DSQLITE_OMIT_FOREIGN_KEY
OPTS += -DSQLITE_OMIT_GET_TABLE
OPTS += -DSQLITE_OMIT_GLOBALRECOVER
OPTS += -DSQLITE_OMIT_INTEGRITY_CHECK
OPTS += -DSQLITE_OMIT_LIKE_OPTIMIZATION
OPTS += -DSQLITE_OMIT_MEMORYDB
OPTS += -DSQLITE_OMIT_OR_OPTIMIZATION
OPTS += -DSQLITE_OMIT_ORIGIN_NAMES
OPTS += -DSQLITE_OMIT_PAGER_PRAGMAS
OPTS += -DSQLITE_OMIT_PROGRESS_CALLBACK
OPTS += -DSQLITE_OMIT_QUICKBALANCE
OPTS += -DSQLITE_OMIT_REINDEX
OPTS += -DSQLITE_OMIT_SCHEMA_VERSION_PRAGMAS
OPTS += -DSQLITE_OMIT_SHARED_CACHE
OPTS += -DSQLITE_OMIT_SUBQUERY
OPTS += -DSQLITE_OMIT_TCL_VARIABLE
OPTS += -DSQLITE_OMIT_TEMPDB
OPTS += -DSQLITE_OMIT_TRACE
OPTS += -DSQLITE_OMIT_TRIGGER
OPTS += -DSQLITE_OMIT_UTF16
OPTS += -DSQLITE_OMIT_VACUUM
OPTS += -DSQLITE_OMIT_VIEW
Without the SQLITE_OMIT_s, everything works just fine. |
|
2015 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
anonymous
|
5
|
4
|
Enhancement Req: "EXPRn" PRAGMA for result set expression column names
|
edit |
I would like to propose a new PRAGMA command that could be set to control how expression column names are represented in result sets.
The current behavior appears to be that the expression that generated the column becomes the column name. For example, "SELECT COLUMN1, COLUMN 2, COLUMN1 + COLUMN2 FROM MYTABLE" yields:
[COLUMN1] | [COLUMN2] | [COLUMN1 + COLUMN2]
I propose a PRAGMA to remove the expression itself and replace it with 'EXPRn', where n is an ordinal based on the number of expression columns in the result set. (First expression is 0, second is 1, and so on):
[COLUMN1] | [COLUMN2] | [EXPR0] |
2006-Oct-12 09:17:25 by anonymous:
Maybe you can just use
SELECT COLUMN1, COLUMN 2, COLUMN1 + COLUMN2 AS EXPR0 FROM MYTABLE
instead. |
|
2014 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
anonymous
|
4
|
3
|
Enhancement Req: CREATE [TEMP | TEMPORARY] VIRTUAL TABLE
|
edit |
Regarding the experimental VIRTUAL TABLE implementation, I believe it would of benefit to provide a "temp", or volatile construct when working with them.
-- From a SQL syntax perspective, adding an optional keyword "TEMP" to the declaration: CREATE [TEMP | TEMPORARY] VIRTUAL TABLE.
-- From a code perspective, I would envision this to invoke xCreate as it does now, but when the database is closed, the table is automatically dropped like any temp table, and xDestroy invoked rather than xDisconnect.
One sticky point I can picture is behavior when multiple opens exist to a single database from the same process space. Since virtual tables are already reference counted (in SQLite 3.3.8), perhaps the reference count could be made to span database handles and be bubbled up to the process level instead. That would allow the table to be CREATEd on one handle, CONNECTed on a second handle, then DISCONNECTed/DESTROYed based on the process-wide reference count.
I feel that there are numerous implementation possibilities for this. Having no option to auto-drop a virtual table can lead to stray module references, creating SQLite database files that cannot be properly utilized if the vtable module is not available.
Of course this can be implemented by the application calling DROP TABLE on it's own, but an embedded solution that takes care of it seems more 'proper' given the thought that goes into SQLite as a whole. |
|
2013 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
drh
|
4
|
3
|
Autoincrement increments on failing INSERT OR IGNORE
|
edit |
% package require sqlite3
3.3.8
% sqlite3 db ""
% db eval "CREATE TABLE test (counter INTEGER PRIMARY KEY AUTOINCREMENT, value text NOT NULL UNIQUE)"
% db eval "INSERT INTO test VALUES(4, 'hallo')"
% db eval "SELECT * FROM sqlite_sequence"
test 4
% db eval "INSERT OR IGNORE INTO test(value) VALUES('hallo')"
% db eval "SELECT * FROM sqlite_sequence"
test 5
---> there has no dataset been inserted but the AUTOINCREMENT-counter is incremented
% db eval "INSERT OR IGNORE INTO test VALUES(4, 'hallo')"
% db eval "SELECT * FROM sqlite_sequence"
test 5
---> right behavior: no inserted dataset and no incrementation
This maybe could be a problem if the "INSERT OR IGNORE" happens very often. |
|
2012 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
4
|
3
|
trigger4.test aborts "make test" on Windows
|
edit |
The failure to remove these files causes "make test" to abort without completing remaining tests:
trigger4-99.9... Ok
./testfixture: error deleting "trigtest.db": permission denied
while executing
"file delete -force trigtest.db trigtest.db-journal"
(file "test/trigger4.test" line 199)
fix:
Index: test/trigger4.test
===================================================================
RCS file: /sqlite/sqlite/test/trigger4.test,v
retrieving revision 1.9
diff -u -3 -p -r1.9 trigger4.test
--- test/trigger4.test 4 Oct 2006 11:55:50 -0000 1.9
+++ test/trigger4.test 9 Oct 2006 14:09:07 -0000
@@ -195,6 +195,6 @@ do_test trigger4-7.2 {
integrity_check trigger4-99.9
-file delete -force trigtest.db trigtest.db-journal
+catch {file delete -force trigtest.db trigtest.db-journal}
finish_test
|
Not sure why this ticket was set to Fixed_in_3.0, but I can reproduce the "make test" abort on Windows.
2006-Oct-11 00:27:16 by drh:
I do not know why the resolution was set to "Fixed_In_3.0" either.
It seems to have been set that why by the original submitter.
I will fix this eventually, but since it does not represent a real
malfunction, it has a lower priority. |
|
2011 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
3
|
2
|
Escaping Porblem with .mode insert (double apostrophe)
|
edit |
select * from messages where message_id="74B23AAF-5FFD6BF2";
74B23AAF-5FFD6BF2|75|0|0|0|0|Europe talks, acts tough on Iran||http://www.ncr-iran.org/index.php?option=com_content&task=view&id=1052&Itemid=71|1140529235.0|By Gareth HardingThe United Press International, BRUSSELS -- Europeans are supposed to prefer soft to hard power, jaw-jaw to war-war and appeasement to confrontation. In short, in the words of neo-conservative scholar Robert Kagan: \'Americans are from Mars; Europeans are from Venus.\'
The ".mode insert / .output" file looks like this.
INSERT INTO messages VALUES('74B23AAF-5FFD6BF2',75,0,0,0,0,'Europe talks, acts tough on Iran','','http://www.ncr-iran.org/index.php?option=com_content&task=view&id=1052&Itemid=71',1140529235.0,'By Gareth HardingThe United Press International, BRUSSELS -- Europeans are supposed to prefer soft to hard power, jaw-jaw to war-war and appeasement to confrontation. In short, in the words of neo-conservative scholar Robert Kagan: \''Americans are from Mars; Europeans are from Venus.\''');
Now there are two apostrophe and the Escaping is broken. |
|
2010 |
code
|
active
|
2006 Oct
|
anonymous
|
|
2006 Oct
|
|
3
|
3
|
Timeout ignored in Shared-Cache locking model
|
edit |
With shared cache enabled, the busy timeout seems to be ignored. SQLITE_BUSY comes immediately. This occurs at least for locking situations within one shared cache.
My server (if i may call the cache sharing thread that way) has its own timeout handling. But I thought that a small timeout in sqlite3 might help to distinguish locks from deadlocks.
This was reproduced with both Python wrappers. These just call sqlite3_enable_shared_cache and sqlite3_busy_timeout and then execute BEGIN IMMEDIATE from two connections. |
2006-Oct-06 13:56:21 by anonymous:
Weird, I thought it's my fault, but I see exactly the same behaviour with the C# ADO.NET 2.0 wrapper w/ the shared cache patch. |
|
2006 |
event
|
active
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
1
|
1
|
Strange data in a table.
|
edit |
When dumping a database file, this is what I found:
CREATE TABLE TopSites (
XID INTEGER REFERENCES X(ID),
YID INTEGER REFERENCES Y(ID),
URLID INTEGER REFERENCES TopSitesURLs(ID));
INSERT INTO "TopSites" VALUES(-761955577, 5, 1322);
INSERT INTO "TopSites" VALUES(-761955577, 5, 1120);
INSERT INTO "TopSites" VALUES(-761955577, 5, 1323);
INSERT INTO "TopSites" VALUES(-761955577, 5, 1324);
.......................................................
INSERT INTO "TopSites" VALUES(-761955577, 5, 1323);
INSERT INTO "TopSites" VALUES(-761955577, 5, 1324);
INSERT INTO "TopSites" VALUES(NULL, 'http://www.bnimanningham.com', NULL);
INSERT INTO "TopSites" VALUES(NULL, 'http://www.wellnesscareoncollins.com.au/Chiropractic-Articles.html', NULL);
INSERT INTO "TopSites" VALUES(NULL, 'http://www.healthyrisepharmacy.com', NULL);
INSERT INTO "TopSites" VALUES(NULL, 'http://www.alextechmelb.com/testimonials.html', NULL);
INSERT INTO "TopSites" VALUES(NULL, 'http://www.ecca.com.au/melbourne-contactus.html', NULL);
INSERT INTO "TopSites" VALUES(NULL, 'http://www.naturopathicwellness.com.au/additionaltherapies.htm', NULL);
INSERT INTO "TopSites" VALUES(NULL, 'http://www.rrr.org.au/sponsors.php', NULL);
INSERT INTO "TopSites" VALUES(NULL, 'http://www.caavic.asn.au/html/s02_article/show_article.asp?id=507&topic_id=-1&category_id=-1', NULL);
INSERT INTO "TopSites" VALUES(NULL, 'http://www.cosmeticchoice.com.au/healing_nutrition.php?PHPSESSID=&PHPSESSID=d85928253b38f1bf88200022e7a93218', NULL);
INSERT INTO "TopSites" VALUES(NULL, 'http://www.coca.com.au/vic.htm', NULL);
INSERT INTO "TopSites" VALUES(NULL, 'http://www.embracechiropractic.com.au', NULL);
INSERT INTO "TopSites" VALUES(NULL, 'http://www.cooperchiro.com', NULL);
The database was created on:
os: Mac OS X 10.4.6
jre: 1.5.0_06-64
sqlite: 3.3.4
The code for inserting into the database is:
public static String GetTopSitesInsert(int aX, int aY, int aURLID)
{
return "INSERT OR ROLLBACK INTO TopSites (XID, YID, URLID) VALUES
(" +
aX + ", " + aY + ", " + aURLID + ");";
}
I think that the last lines are from another table, or from another insert, as the java int could have never been a value like:
http://www.bnimanningham.com
When trying to delete some rows from this table, sqlite threw "malformed database" exception and the java virtual machine crashed. |
2006-Sep-29 12:23:31 by anonymous:
This is duplicate of #2005
2006-Sep-29 14:03:50 by drh:
I'm thinking this and #2005 represent a bug in whatever Java
bindings the reporter is using. |
|
2005 |
event
|
active
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
1
|
1
|
Multiple rows with the same primary key, and null values in "not null"
|
edit |
This is what I have found when dumping a database file:
CREATE TABLE TopSitesURLs (
ID INTEGER PRIMARY KEY,
URLText TEXT NOT NULL
);
INSERT INTO "TopSitesURLs" VALUES(1, 'http://www.backinline.com.au');
INSERT INTO "TopSitesURLs" VALUES(2, 'http://www.wellnesscareoncollins.com.au');
INSERT INTO "TopSitesURLs" VALUES(3, 'http://www.oakleighdental.com.au/chirodontics.php');
INSERT INTO "TopSitesURLs" VALUES(4, 'http://bacinactionchiropractic.com');
INSERT INTO "TopSitesURLs" VALUES(5, 'http://melbourne.zpages.com.au/chiropractors');
INSERT INTO "TopSitesURLs" VALUES(6, 'http://myname.chiropractic.com.au');
INSERT INTO "TopSitesURLs" VALUES(7, 'http://www.melbournechiropractor.com');
INSERT INTO "TopSitesURLs" VALUES(8, 'http://www.chiroweb.net/us/fl_melbourne.html');
INSERT INTO "TopSitesURLs" VALUES(9, 'http://www.chiropractor.net.au/aridiskin.htm');
INSERT INTO "TopSitesURLs" VALUES(10, 'http://www.melbournechiropractic.com.au');
INSERT INTO "TopSitesURLs" VALUES(11, 'http://www.melbournechiropractor.com/index.php?page=privacy.php&pageID=-1');
INSERT INTO "TopSitesURLs" VALUES(12, 'http://www.vitaminstoday.com.au/chiropractor/index.php?page=grid');
INSERT INTO "TopSitesURLs" VALUES(13, 'http://www.goodechiro.com/index.asp');
INSERT INTO "TopSitesURLs" VALUES(14, 'http://www.goodechiro.com/FirstVisit.asp');
INSERT INTO "TopSitesURLs" VALUES(15, 'http://www.usenature.com/chirodirectory.htm');
INSERT INTO "TopSitesURLs" VALUES(16, 'http://www.melbournemeditationcentre.com.au/courses/teacher.htm');
INSERT INTO "TopSitesURLs" VALUES(17, 'http://www.yogatree.com.au/Therapies.htm');
...................................................................................
INSERT INTO "TopSitesURLs" VALUES(6259, 'http://www.yarravillehealth.com.au/osteopath-melbourne.html');
INSERT INTO "TopSitesURLs" VALUES(6260, 'http://www.worldveganday.org.au/forum/viewtopic.php?p=4543&sid=465ea5c2e7452f6fd23470488e277781');
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(14, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
INSERT INTO "TopSitesURLs" VALUES(15, NULL);
The database was created on:
os: Mac OS X 10.4.6
jre: 1.5.0_06-64
sqlite: 3.3.4
The primary key 15 is duplicated, and the "not null" field is null. |
2006-Sep-29 12:03:17 by anonymous:
What tool (and parameters) did you use to dump the database?
2006-Sep-29 13:13:28 by drh:
When I run the SQL, I get lots of errors. And the resulting database
does not contain any duplicate primary keys or NULLs in NOT NULL
columns.
Can you attach the database that contains duplicate primary keys and
NULLs in NOT NULL columns to this ticket so that I can see it?
jre==Java Runtime Engine? Are you using some kind of java binding
to SQLite? If so, which one? Is SQLite in a separate DLL, or is
your Java binding using a statically linked (and possibly modified
and broken) version of SQLite?
2006-Oct-03 15:15:54 by anonymous:
I am using a java wrapper for sqlite:
http://www.ch-werner.de/javasqlite/overview-summary.html
I got the same problem again:
INSERT INTO "TopSitesURLs" VALUES(13023, 'http://costaricaretirementvacationproperties.com/index.php?op=show_listing&ShowOption=Condo Resales&option=cat');
INSERT INTO "TopSitesURLs" VALUES(13024, 'http://www.hot-tropics.com/costa-rica-links.html');
INSERT INTO "TopSitesURLs" VALUES(13025, 'http://southpacificrealestateservices.com/index.php?PHPSESSID=6b7a257fad5cbd886f09526a2cd59ed8');
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(9, NULL);
INSERT INTO "TopSitesURLs" VALUES(13041, 'http://www.livingabroadincostarica.com');
INSERT INTO "TopSitesURLs" VALUES(13042, 'http://limitededitionsre.com/blog.html');
INSERT INTO "TopSitesURLs" VALUES(13043, 'http://www.officecenter.nosaranet.com/property.html');
You can see the index 13025, then up to 13041 you can see only 9.
How do I upload a database?
2006-Oct-03 15:17:33 by anonymous:
I have dumped the database with sqlite3.exe in command line:
sqlite3.exe file.db .dump > file.sql
2006-Oct-03 17:44:00 by anonymous:
How do I upload a database?
Use the Attach link near the top right. Note that attachment size is currently limited to 100KB.
2006-Oct-04 06:38:23 by anonymous:
An integrity check on this database looks like this:
C:\Documents and Settings\stefan matei\Desktop>sqlite3 project.db
SQLite version 3.3.4
Enter ".help" for instructions
sqlite> PRAGMA integrity_check;
*** in database main ***
On tree page 59 cell 10: 2nd reference to page 1077
On tree page 59 cell 10: Child page depth differs
On tree page 59 cell 11: Child page depth differs
On page 871 at right child: 2nd reference to page 1078
sqlite> .quit
When can this happen? Is there a fix for this (integrity fix or something)? I ask this because the database is perfectly readable. I assume that a tool can be done to check the tables and remove all the data that are not complying to the table definition. |
|
2004 |
warn
|
active
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
1
|
4
|
vtab.c:142: warning: pointer targets in initialization differ in signe
|
edit |
const unsigned char *z = pParse->sArg.z;
fix this warning but then this warning appears:
vtab.c:145: warning: pointer targets in passing argument 1 of 'sqlite3StrNDup' differ in signedness
which can be fixed with:
addModuleArgument(pParse->pNewTable, sqliteStrNDup((char *)z, n)); |
|
1998 |
build
|
active
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
2
|
3
|
prefix option to configure ignored in tclinstaller.tcl
|
edit |
schliep@karlin:~/tmp/sqlite-3.3.7> configure --prefix=/some/dir
...
schliep@karlin:~/tmp/sqlite-3.3.7> make install
tclsh ./tclinstaller.tcl 3.3
can't create directory "/usr/lib/tcl8.4/sqlite3": permission denied
After commenting out all the stuff in ./tclinstaller.tcl things work |
|
1996 |
new
|
active
|
2006 Sep
|
anonymous
|
Unknown
|
2006 Sep
|
drh
|
2
|
3
|
Data type CHAR
|
edit |
An interface API for CHAR datatypes would really be helpful.
For example, often sql tables contain CHAR(1) datatypes or CHAR(10) types. There should be some mechanism for handling these types natively. ie: sqlite3_bind_char
sqlite3_column_char
sqlite3_result_char
sqlite3_value_char
This will allow a more native implementation for CHAR datatypes, As it is, a single CHAR(1) must be first converted into a string (char[2]) and copied with a terminator. for CHAR types, not \000 termination is required. It is implied with the lenght.
Thanks... |
|
1994 |
code
|
active
|
2006 Sep
|
anonymous
|
Parser
|
2006 Sep
|
|
1
|
3
|
Columns from nested joins aren't properly propagated
|
edit |
When using this query:
SELECT * FROM ROLE_ATTRIBUTE INNER JOIN (ROLE INNER JOIN PERSON ON ROLE.PERSON_ID=PERSON.ID) ON ROLE_ATTRIBUTE.PERSON_ID=ROLE.PERSON_ID AND ROLE_ATTRIBUTE.PROJECT_ID=ROLE.PROJECT_ID WHERE ((PERSON.FIRSTNAME = "bob"));
the parser fails with an error "no such column: ROLE.PROJECT_ID". It seems that doing an inner join with more than one subexpression doesn't work. |
2006-Sep-25 22:41:52 by anonymous:
Your query will run without the brackets.
SELECT *
FROM PERSON P INNER JOIN ROLE_ATTRIBUTE RA
ON P.ID = RA.PERSON_ID
INNER JOIN ROLE R
ON RA.PROJECT_ID = R.PROJECT_ID AND
P.ID = R.PERSON_ID
WHERE P.FIRSTNAME = 'bob';
2006-Sep-25 23:03:28 by navaraf:
Hm, you're right. So actually the thing SQLite chokes on is the parenthesis syntax as JOIN parameter. I can try to modify the generator to produce the expanded form, but since the same code is used for MSSQL, MySQL and Oracle I still think it would be handy to allow it in SQLite too. Also it's not my code that generates these horrible expressions and I'd rather try to avoid modifying it.
2006-Sep-26 09:59:13 by anonymous:
I changed the title to correctly describe the problem. Also I found another thread on the mailing list that describes exactly the same problem:
http://marc.10east.com/?t=115378699000001
2006-Sep-26 11:42:38 by navaraf:
I believe the "lookupName" function in src/expr.c should do recursion for ephemeral tables found in the pSrcList (at least those that were created as subqueries in the FROM clause of the SELECT statement). |
|
1992 |
code
|
active
|
2006 Sep
|
anonymous
|
|
2006 Nov
|
shess
|
1
|
1
|
FTS1: Problems after dropping utility tables
|
edit |
There are problems if FTS1 utilities tables are dropped from a database. See following SQL for details.
drop table if exists x;
-- Create a FTS1 table.
create virtual table x using fts1 ('content');
-- Drop table x_content: Works fine, but should this be allowed?
-- The same errors below also show if table x_term is dropped.
drop table x_content;
-- All attempts to access table x now result in errors,
-- including dropping table x. There seems to be no way out
-- except of recreating the database. All three commands below
-- cause the same error, regardless if executed in sequence
-- or individually:
insert into x (content) values ('one two three'); -- Error!
delete from x; -- Error!
drop table x; -- Error!
|
Added "not exists" to allow dropping an fts table with corrupted backing. Allowing updates to such tables is unlikely to happen (not even clear what it would mean, in most cases!). |
|
1990 |
code
|
active
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
1
|
1
|
sqlite3_close doesn't release always the file handle
|
edit |
I think that sqlite3_close behave strangly.
I use version 3.3.7 on Linux (Fedora Core 5).
What I do is to open a database, and start a transaction in it. Then, without ending the transaction, open again the database and simply close it.
I found out, that the inner sqlite3_close return 0 (SQLITE_OK), but the file handle is not released. So if I do it too many times, I run out of file handles.
You are free to ask why I open and close that many times the same database while it is already in transaction.
This is my mistake. Actually, it is already fixed.
But I still wonder - shouldn't the sqlite3_close return other thing then just SQLITE_OK? Especially if the file handle is not released? If it did, I would find my mistake much earlier.
Here is my script that demonstrate it (you can use /usr/sbin/lsof in linux to see how many times the file is opened):
#include <sqlite3.h>
int main(int argc, char **argv) {
sqlite3* db;
sqlite3* db_inner;
int rc;
int i;
system("rm -f open_many_test.db");
rc = sqlite3_open("open_many_test.db", &db);
sqlite3_exec(db, "begin", 0, 0, 0);
sqlite3_stmt *pStmt;
rc = sqlite3_prepare(db,
"create table a (id varchar)",
-1,
&pStmt,
0);
rc = sqlite3_step(pStmt);
sqlite3_finalize(pStmt);
rc = sqlite3_prepare(db,
"insert into a values('bla')",
-1,
&pStmt,
0);
rc = sqlite3_step(pStmt);
sqlite3_finalize(pStmt);
for (i = 0; i < 10000; i++) {
rc = sqlite3_open("open_many_test.db", &db_inner);
printf("sqlite3_open gives %d\n", rc);
rc = sqlite3_close(db_inner);
printf("sqlite3_close gives %d\n", rc);
}
sqlite3_exec(db, "commit", 0, 0, 0);
rc = sqlite3_close(db);
}
|
2006-Sep-23 15:29:46 by drh:
This behavior is intentional. It is there to work around bugs
in the design of posix advistory locks. See ticket #561 and
check-in [1171]
.
Under posix, if you have the same file open multiple times
and you close one of the file descriptors, all locks on that
file for all file descriptors are cleared. To prevent this
from occurring, SQLite defers closing file descriptors until
all locks on the file have been released.
One possible work-around would be to reuse file descriptors
that waiting to be closed for the next open, rather than
creating a new file descriptor.
2006-Sep-23 15:35:21 by anonymous:
The inner call should to sqlite3_open() should simply fail in that case, rather than set up a condition where by a file descriptor is leaked (which no one wants). This is unfortunate because sqlite3_open()'s behavior would not be uniform across platforms.
2006-Sep-23 16:43:32 by anonymous:
SQLite should do a lookup via stat()'s st_dev/st_ino fields prior to open() and if found to be the same as an already opened database file, it should use the same (refcounted) file descriptor, eliminating the need for open() in this case.
...upon reflection, having two sqlite connections using the same file descriptor would be a bad thing. stat() could be used to decide if a fd pending close() is recyclable, though.
2006-Sep-23 18:17:34 by drh:
Two points:
- SQLite does not and has never leaked file descriptors. All
file descriptors are eventually closed. The close is merely
deferred until the pending transaction COMMITs.
- I will be taking a very caution and careful approach toward
resolving this issue. The issue itself is minor (it has only just
now been reported but the behavior has been there for 3 years)
but the consequences of getting the fix wrong are severe
(database corruption.) And there are abundant opportunities
for getting the fix wrong.
|
|
1983 |
code
|
active
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
2
|
2
|
I/O Error at a size of 4GB and auto_vacuum=1
|
edit |
when i'm building a database with auto_vacuum=1 and page_size=8192, i get an I/O error at a size of about 4GB. All tables are still readable but then it isn't possible to insert any more data.
The table is filled with a column of BLOBs and some columns with numbers. I use the 3.3.7 binary with Windows 2000 Server. |
|
1980 |
code
|
active
|
2006 Sep
|
drh
|
|
2006 Sep
|
|
1
|
1
|
Initializing FTS1 twice causes it to fail.
|
edit |
If you try to load the shared module twice, it causes the module
to no longer work. |
|
1975 |
new
|
active
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
5
|
4
|
Request for sqlite3_table_column_metadata16
|
edit |
It would be nice to have a sqlite3_table_column_metadata16() function as an UTF-16 version of the existing sqlite3_table_column_metadata(). |
|
1974 |
code
|
active
|
2006 Sep
|
anonymous
|
Unknown
|
2006 Sep
|
|
1
|
1
|
column type not consistent in views
|
edit |
package require sqlite3
sqlite3 db test.db
db eval {
create table one (
size FLOAT
);
create view two as
select size from one;
}
db eval {insert into one values(50.0)}
puts [db eval {select size from one}]
puts [db eval {select size from two}]
outputs:
50.0
50 |
|
1972 |
code
|
active
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
2
|
4
|
segfault on empty query
|
edit |
SQLite 2.8.17 used in latest versions of PHP segfaults with empty query (i.e. " ", 1 whitespace).
PHP reproduce code:
<?php
$dbh = new PDO('sqlite2:pdo_sqlite2');
var_dump($dbh->query(" "));
?>
GDB backrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1077220512 (LWP 3909)]
0x0814d227 in sqlite_step (pVm=0x0, pN=0x40364218, pazValue=0x40364210, pazColName=0x40364214) at /local/dev/php-src_5_2/ext/sqlite/libsqlite/src/vdbe.c:117
117 if( p->magic!=VDBE_MAGIC_RUN ){
(gdb) bt
#0 0x0814d227 in sqlite_step (pVm=0x0, pN=0x40364218, pazValue=0x40364210, pazColName=0x40364214) at /local/dev/php-src_5_2/ext/sqlite/libsqlite/src/vdbe.c:117
#1 0x0812556a in pdo_sqlite2_stmt_execute (stmt=0x40364094) at /local/dev/php-src_5_2/ext/sqlite/pdo_sqlite2.c:102
#2 0x080bf4d5 in zim_PDO_query (ht=1, return_value=0x40363110, return_value_ptr=0x0, this_ptr=0x40363178, return_value_used=1)
at /local/dev/php-src_5_2/ext/pdo/pdo_dbh.c:1033
#3 0x0824c1d6 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffca90) at /local/dev/php-src_5_2/Zend/zend_vm_execute.h:200
#4 0x0824c722 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffca90) at /local/dev/php-src_5_2/Zend/zend_vm_execute.h:322
#5 0x0824bde9 in execute (op_array=0x403637e4) at /local/dev/php-src_5_2/Zend/zend_vm_execute.h:92
#6 0x0822e66a in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /local/dev/php-src_5_2/Zend/zend.c:1095
#7 0x081e7993 in php_execute_script (primary_file=0xbfffef00) at /local/dev/php-src_5_2/main/main.c:1759
#8 0x082933de in main (argc=2, argv=0xbfffefe4) at /local/dev/php-src_5_2/sapi/cli/php_cli.c:1102
(gdb) f 0
#0 0x0814d227 in sqlite_step (pVm=0x0, pN=0x40364218, pazValue=0x40364210, pazColName=0x40364214) at /local/dev/php-src_5_2/ext/sqlite/libsqlite/src/vdbe.c:117
117 if( p->magic!=VDBE_MAGIC_RUN ){
(gdb) p p
$1 = (Vdbe *) 0x0
Proposed patch:
http://cvs.php.net/viewvc.cgi/php-src/ext/sqlite/libsqlite/src/vdbe.c?r1=1.7.4.1&r2=1.7.4.1.2.1 |
2006-Sep-10 11:10:26 by drh:
PHP is calling sqlite_step() with a NULL sqlite_stmt pointer.
This seems more like a bug in PHP than SQLite.
I suggest patching PHP, somewhere in pdo_sqlite2.c I'm guessing,
so that it checks to see if the statement pointer returned by
sqlite_prepare() is NULL and skips the sqlite_step() and
sqlite_finalize() calls if it is. The proposed patch above
seems to confirm this strategy: The proposed patch would cause
PHP to receive an SQLITE_MISUSE error. An SQLITE_MISUSE error
indicates that the API is begin used incorrectly. The right fix,
it seems to me, would be to use the API correctly.
2006-Sep-10 15:40:46 by anonymous:
"An SQLITE_MISUSE error indicates that the API is begin used incorrectly". I agree - and this simple NULL check would be the perfect place for SQLite to issue such a MISUSE error. Having SQLite recover from such a relatively common type of NULL input error would be beneficial to its users. SQLite already goes to great lengths to recover from out of memory situations. I don't see any reason not to add a simple "if NULL" check here to avoid crashing the the user's application.
2006-Sep-10 16:56:12 by drh:
I would quickly add such a change to SQLite version 3. And
in fact I have already done so. See Ticket #870 and
check-in [1906]
. But we are talking about SQLite version 2, here,
which is in maintenance mode and should not be used for new
development.
2006-Sep-10 20:05:41 by anonymous:
>I suggest patching PHP, somewhere in pdo_sqlite2.c
That's possible too, but currently I see no reasons to do it.
>I'm guessing, so that it checks to see if the statement pointer returned by
> sqlite_prepare() is NULL and skips the sqlite_step() and sqlite_finalize() calls if it is.
The statement pointer in this case is (not) returned by sqlite_compile() call.
Here is the piece of code:
...
S->einfo.errcode = sqlite_compile(S->H->db, stmt->active_query_string, &tail, &S->vm, &errmsg);
if (S->einfo.errcode != SQLITE_OK) {
pdo_sqlite2_error_stmt(errmsg, stmt);
return 0;
}
S->done = 0;
S->einfo.errcode = sqlite_step(S->vm, &S->ncols, &S->rowdata, &S->colnames);
...
From what I see, sqlite_compile() considers " " query as valid and doesn't return error, but in the same time the statement pointer remains NULL, which is clearly wrong.
As I've said, it's easy to check if it's NULL or not in PHPs code, but I really think that the problem is in sqlite_compile(). |
|
1961 |
build
|
active
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
3
|
3
|
3.3.7 : wrong readline.h path in Makefile
|
edit |
We have readline.h installed in /usr/local/include/readline. In SQLite it is accessed with :
#include <readline/readline.h>
But unfortunatly in Makefile, READLINE flags contains :
-I /usr/local/include/readline
instead of
-I /usr/local/include |
|
1960 |
code
|
active
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
4
|
2
|
Issues with .import in sqlite.exe
|
edit |
I ran into two possible problems when using the .import operation in sqlite3:
- .import seems to be confused by NULLs; in the file NullTest.dat the null is at the end of the line
- .import chokes on empty field when importing to field of type: integer PRIMARY KEY AUTOINCREMENT
For example line like:
~2~3~4~5~6
Example:
Schema:
--Table with autoincrement
CREATE TABLE test1(
id integer PRIMARY KEY AUTOINCREMENT,
c1 integer NULL ,
c2 integer NULL ,
c3 text NULL,
c4 text NULL,
c5 text NULL
);
-- Table with no autoincrement field
CREATE TABLE test2(
id integer NULL,
c1 integer NULL ,
c2 integer NULL ,
c3 text NULL,
c4 text NULL,
c5 text NULL
);
.separator ~
.import NullTest.dat test1
.import NullTest.dat test2
.import NoNullTest.dat test2
I have short test files that I can email to the person who is looking at this. |
|
1959 |
new
|
active
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
4
|
3
|
Unblockable TEMP TABLES
|
edit |
TEMP TABLES locks the complete database as long as a prepared stmt is running at the main database. Temp Tables are in separate files... so I hope it can be changed without big problems.
The new driver for OpenOffice.org needs temp tables that won't lock the complete database because of cached resultsets.
It only can be emulate it with "attach a database, copy data, detach". But the problem is that the API of OOo needs to change the cached resultset. It isn't possible to add this without temporary tables. So the driver could use sqlite3_update_hook() to know when he needs to reload the resultset.
Thanks |
|
1958 |
code
|
active
|
2006 Sep
|
anonymous
|
|
2006 Sep
|
|
4
|
4
|
some printf tests fail with Tcl 8.5a5, ok with Tcl 8.4
|
edit |
Tcl 8.5a5:
printf-1.7.6...
Expected: [Three integers: (1000000) ( f4240) (3641100)]
Got: [Three integers: ( 1000000) ( f4240) (3641100)]
printf-1.8.6...
Expected: [Three integers: (999999999) (3b9ac9ff) (7346544777)]
Got: [Three integers: ( 999999999) (3b9ac9ff) (7346544777)]
printf-1.9.7...
Expected: [Three integers: ( 0) ( 0x0) ( 0)]
Got: [Three integers: ( 0) ( 0) ( 0)]
Tcl 8.4:
printf-1.7.6... Ok
printf-1.8.6... Ok
printf-1.9.7... Ok
|
2006-Sep-05 02:27:00 by anonymous:
This is not directly related to the ticket, but concerns the same test file... Why are these tests not run on windows? I thought sqlite3_mprintf() is platform independent.
if {$::tcl_platform(platform)!="windows"} {
set m 1
foreach {a b} {1 1 5 5 10 10 10 5} {
set n 1
foreach x {0.001 1.0e-20 1.0 0.0 100.0 9.99999 -0.00543 -1.0 -99.99999} {
do_test printf-2.$m.$n.1 [subst {
sqlite3_mprintf_double {A double: %*.*f} $a $b $x
}] [format {A double: %*.*f} $a $b $x]
do_test printf-2.$m.$n.2 [subst {
sqlite3_mprintf_double {A double: %*.*e} $a $b $x
}] [format {A double: %*.*e} $a $b $x]
do_test printf-2.$m.$n.3 [subst {
sqlite3_mprintf_double {A double: %*.*g} $a $b $x
}] [format {A double: %*.*g} $a $b $x]
do_test printf-2.$m.$n.4 [subst {
sqlite3_mprintf_double {A double: %d %d %g} $a $b $x
}] [format {A double: %d %d %g} $a $b $x]
do_test printf-2.$m.$n.5 [subst {
sqlite3_mprintf_double {A double: %d %d %#g} $a $b $x
}] [format {A double: %d %d %#g} $a $b $x]
do_test printf-2.$m.$n.6 [subst {
sqlite3_mprintf_double {A double: %d %d %010g} $a $b $x
}] [format {A double: %d %d %010g} $a $b $x]
incr n
}
incr m
}
} ;# endif not windows
|
|
1954 |
code
|
active
|
2006 Sep
|
anonymous
|
Unknown
|
2006 Sep
|
|
1
|
1
|
Dual Core Processor Lockup
|
edit |
I seem to be seeing a problem with dual core processors in the the Open call is locking and does not release or throw an exception. It does not occur every time, but occurs around 50% of the time. I have not seen the problem on non dual core processors. |
2006-Sep-02 21:06:38 by anonymous:
This ticket is way too vague to be actionable. What operating system? AMD or Intel? What specific version of SQLite? Was the library precompiled or did you compile it yourself?
Personally, I can report no errors or problems with dual-core CPU's on Windows XP using an AMD X2 4400+ dual-core CPU. Tested with both a 32-bit build and a 64-bit build of SQLite on x64 Windows. |
|
1953 |
code
|
active
|
2006 Sep
|
anonymous
|
TclLib
|
2006 Sep
|
|
4
|
3
|
Fix for false 64-bit comparisons "make test" failures on Cygwin
|
edit |
The trivial patch below allows Cygwin to correctly pass all (two dozen or so) 64-bit integer-related tests in "make test". It does so by treating all 64-bit integer SQL results as strings. (Note: SQLite has always produced correct 64-bit integer results, it's just that the test harness on Cygwin produces false failures without this patch.)
There is no impact to other platforms, and allows us unfortunate Windows users to be useful members of society.
RCS file: /sqlite/sqlite/src/tclsqlite.c,v
retrieving revision 1.172
diff -u -r1.172 tclsqlite.c
--- src/tclsqlite.c 31 Aug 2006 15:07:15 -0000 1.172
+++ src/tclsqlite.c 1 Sep 2006 17:27:44 -0000
@@ -432,7 +432,12 @@
if( v>=-2147483647 && v<=2147483647 ){
pVal = Tcl_NewIntObj(v);
}else{
+#ifndef __CYGWIN__
pVal = Tcl_NewWideIntObj(v);
+#else
+ int bytes = sqlite3_value_bytes(pIn);
+ pVal = Tcl_NewStringObj((char *)sqlite3_value_text(pIn), bytes);
+#endif
}
break;
}
@@ -1420,7 +1425,11 @@
if( v>=-2147483647 && v<=2147483647 ){
pVal = Tcl_NewIntObj(v);
}else{
+#ifndef __CYGWIN__
pVal = Tcl_NewWideIntObj(v);
+#else
+ pVal = dbTextToObj((char *)sqlite3_column_text(pStmt, i));
+#endif
}
break;
}
Example test failures before patch:
$ ./testfixture.exe test/misc2.testmisc2-1.1... Ok
misc2-1.2... Ok
misc2-2.1... Ok
misc2-2.2... Ok
misc2-2.3... Ok
misc2-3.1... Ok
misc2-4.1...
Expected: [4000000000]
Got: [-294967296]
misc2-4.2...
Expected: [4000000000 2147483648]
Got: [-294967296 -2147483648]
misc2-4.3... Ok
misc2-4.4...
Expected: [1 2147483648 2147483647]
Got: [1 -2147483648 2147483647]
misc2-4.5...
Expected: [1 4000000000 2147483648 2147483647]
Got: [1 -294967296 -2147483648 2147483647]
misc2-4.6...
Expected: [1 2147483647 2147483648 4000000000]
Got: [1 2147483647 -2147483648 -294967296]
misc2-5.1... Ok
misc2-6.1... Ok
misc2-7.1... Ok
misc2-7.2... Ok
misc2-7.3... Ok
misc2-7.4... Ok
misc2-7.5... Ok
misc2-7.6... Ok
misc2-7.7... Ok
misc2-7.8... Ok
misc2-8.1... Ok
misc2-9.1... Ok
misc2-9.2... Ok
misc2-9.3... Ok
misc2-10.1... Ok
Thread-specific data deallocated properly
5 errors out of 28 tests
Failures on these tests: misc2-4.1 misc2-4.2 misc2-4.4 misc2-4.5 misc2-4.6
After patch applied:
$ ./testfixture.exe test/misc2.testmisc2-1.1... Ok
misc2-1.2... Ok
misc2-2.1... Ok
misc2-2.2... Ok
misc2-2.3... Ok
misc2-3.1... Ok
misc2-4.1... Ok
misc2-4.2... Ok
misc2-4.3... Ok
misc2-4.4... Ok
misc2-4.5... Ok
misc2-4.6... Ok
misc2-5.1... Ok
misc2-6.1... Ok
misc2-7.1... Ok
misc2-7.2... Ok
misc2-7.3... Ok
misc2-7.4... Ok
misc2-7.5... Ok
misc2-7.6... Ok
misc2-7.7... Ok
misc2-7.8... Ok
misc2-8.1... Ok
misc2-9.1... Ok
misc2-9.2... Ok
misc2-9.3... Ok
misc2-10.1... Ok
Thread-specific data deallocated properly
0 errors out of 28 tests
Failures on these tests:
The only new regression on Cygwin is this test, which is expected:
types3-2.3...
Expected: [wideInt]
Got: []
|
2006-Sep-01 18:55:25 by drh:
The TCL interface is more than just part of the test harness.
A lot of people use the TCL interface as part of their applications.
I believe what this patch does is mask a real problem.
I would prefer to fix the underlying problem, not just treat the
symptom.
2006-Sep-02 02:48:57 by anonymous:
I have no interest in fixing bugs in Tcl itself on Cygwin. I just want to reliably build and test SQLite. The proposed fix is purely pragmatic and is intended only for the test harness. Indeed, when dealing with testing only, the fix is not Cygwin-specific and would work on any platform. The test harness under stock Cygwin as it stands simply does not work for 64 bit values. When you see such a failure you assume that SQLite is in error. Perhaps a compromise can be made and the code fix in question can be wrapped in #ifdef SQLITE_TESTFIXTURE or equivalent instead of #ifdef __CYGWIN__. I would hate to see someone else waste any time on this trivially fixable issue.
2006-Sep-02 13:27:08 by drh:
Perhaps you could put an "if" statement in the test scripts
that skipped over the tests that do not work if running under
cygwin. You can probably figure out if you are running under
cygwin by looking at elements of the tcl_platform array.
2006-Sep-02 13:48:56 by drh:
I retract my previous suggestion. I do not want such patches in the
SQLite source tree.
I will resist any patches such as shown here because they are really
hacks to work around a faulty Tcl build on Cygwin. The correct way
to fix this is to fix the Tcl build for Cygwin. This is probably as
simple as download a copy of Tcl and recompiling. I'm curious to
know why the default Tcl build for Cygwin only supports 32-bit
integers. Is there some problem with 64-bit integer support on
Cygwin?
The patch shown in the Description section above
is not good because it presumes that Cygwin
will always be broken. I think a better assumption is that Cygwin
will get fixed. And I do not want to cripple the TCL interface
to work around a bug that is not related to SQLite and which
might not exist on every system. That is so wrong.
I will be willing to put in a test that checks for the cygwin
brokenness and prints a warning to the user. Perhaps something
like this:
if {"*[db eval {SELECT 10000000000}]*"!="*10000000000*"} {
puts "*********** WARNING *************"
puts "Your build of TCL only supports 32-bit integers."
puts "This will cause many test failures. To run these"
puts "tests you must install a version of TCL that supports"
puts "64-bit integers."
exit
}
The question is, does that test correctly detect the broken Cygwin?
Since I have no ready access to a windows machine, I have no way
of testing it.
2006-Sep-02 14:06:28 by anonymous:
Then you would have an on-going maintenance issue with future tests. If'ing out valid tests just masks the problem and defeats the purpose of having a test regression suite. If a test fails legitimately, it should be reported as such. But these particular 64-bit tests work correctly if the simple proposed patch to the test harness is checked in. There is nothing wrong with the tests themselves - just the test harness on certain platforms for which Tcl does support 64-bit integers for whatever reason. Is the purpose of the test suite to test SQLite or Tcl implementations?
I know that Cygwin is a considered a tier "C" platform for SQLite, but appreciate that from a Cygwin environment me and many others have reported at least couple of dozen non-platform-specific SQLite bugs over the past year. You probably have as many or more Cygwin users on the mailing list than Mac OSX users. Why put up artificial ideological roadblocks?
2006-Sep-02 14:10:35 by anonymous:
Please do not check the "Your build of TCL only supports 32-bit integers". It is couter-productive to exit when the great majority of tests will pass. Such a check will basically exclude stock Cygwin installs from testing SQLite. Given the choice between having a broken test harness and this TCL 32-bit check, it is more useful to have a broken test harness.
2006-Sep-04 01:25:00 by anonymous:
Cygwin Tcl 8.5 64-bit integer math bug report
Cygwin Tcl 8.5a5 64-bit integer math fix |
|
1948 |
code
|
active
|
2006 Aug
|
anonymous
|
Shell
|
2006 Aug
|
|
2
|
3
|
Double quotes are not escaped in csv mode
|
edit |
If text is exported using "csv" mode, double quotes in strings are not escaped. Generally double-quotes in a quoted field in CSV should be escaped by repeate. I.e., 'This is a "test".' could be about as "This is a ""test""."
This doesn't appear to be the behavior SQLite uses, so, in the meantime, I'll have to export my data using another method and then transform that data into CSV for my import script. |
|
1947 |
code
|
active
|
2006 Aug
|
anonymous
|
Shell
|
2006 Aug
|
|
3
|
3
|
".mode insert" works bad with BLOBs
|
edit |
.mode insert displays BLOBs as strings, which isn't very good for embedded NULs.
Having output more like the one from .dump would be better, IMO.
sqlite> select * from t;
INSERT INTO table VALUES('');
sqlite> .dump
BEGIN TRANSACTION;
CREATE TABLE t(f BLOB);
INSERT INTO "t" VALUES(X'0041');
COMMIT;
|
|
1942 |
new
|
active
|
2006 Aug
|
anonymous
|
|
2006 Aug
|
|
4
|
4
|
select without left join with the *= operator
|
edit |
Enhancement request for support *=/=* operator in select queries.
It's more easier to write SQL queries without left/right join by using *=/=* operator.
Mentionned on Unsupported Wiki page :
http://www.sqlite.org/cvstrac/wiki?p=UnsupportedSql
* 2006.03.06 : select without left join with the *= operator
SELECT t1.code, t2.code
FROM table1 t1, table2 t2
WHERE t1.t2_ref_id *= t2.id
This is Sybase ASE syntax. Use LEFT JOIN or RIGHT JOIN instead.
|
|
1941 |
code
|
active
|
2006 Aug
|
anonymous
|
|
2006 Aug
|
|
1
|
1
|
Unrevolved _sqlite3ExprCodeAndCache with SQLITE_OMIT_TRIGGER
|
edit |
If SQLITE_OMIT_TRIGGER is set, linker complains about an unresolved _sqlite3ExprCodeAndCache symbol.
sqlite3ExprCodeAndCache is defined in expr.c and wrapped with #ifndef SQLITE_OMIT_TRIGGER .
However, references in
insert.c, line 536
update.c, line 348 and 362
are not wrapped with #ifndef SQLITE_OMIT_TRIGGER .
I followed the suggestion quoted below (posted earlier to this list) without avail.
Is it safe (or even required?) to change sqliteInt.h to
#ifndef SQLITE_OMIT_TRIGGER
void sqlite3ExprCodeAndCache(Parse*, Expr*);
#else
# define sqlite3ExprCodeAndCache(A,B)
#endif
In the mailing list, DRH argued that the above change will probably fail and suggested that a safer fix would be to remove the #ifndef SQLITE_OMIT_TRIGGER from around the sqlite3ExprCodeAndCache function. |
2006-Oct-12 17:35:32 by anonymous:
The problem is still present in 3.3.8. Removing the
#ifndef SQLITE_OMIT_TRIGGER
from around the
sqlite3ExprCodeAndCache
function seems to fix it. Could you commit this? |
|
1939 |
event
|
active
|
2006 Aug
|
anonymous
|
Unknown
|
2006 Aug
|
|
2
|
1
|
SQLite hangs with WHERE condition in an SELECT with joined table
|
edit |
I have an database with 7 Tables. I wanted to make an SELECT in which i join the other Tables with an LEFT OUTER JOIN. That works but when i add an WHERE clause on an Joined Table my Application hangs. The sqlite3.exe hangs at the same query.
My Database:
CREATE TABLE MMBundesland (ID INTEGER, Bezeichnung varchar(255), Kennung INTEGER);
CREATE TABLE MMCoords (ID INTEGER, Laenge DOUBLE, Breite DOUBLE, System varchar(50));
CREATE TABLE MMKFZ (ID INTEGER, Bezeichnung varchar(255));
CREATE TABLE MMKategorie (ID INTEGER,Bezeichnung varchar(255));
CREATE TABLE MMKreis (ID INTEGER, Bezeichnung varchar(255), Kennung INTEGER);
CREATE TABLE MMOrte (ID INTEGER, CoordID INTEGER, Name varchar(255), KategorieID INTEGER, KreisID INTEGER, BundeslandID INTEGER, KfzID INTEGER, DefPLZID INTEGER, Kennung INTEGER);
CREATE TABLE MMPLZ (ID INTEGER, PLZ varchar(10), CoordID INTEGER, OrtID INTEGER);
The Query was:
SELECT o.ID, o.Name,p.PLZ as DefPLZ,k.Bezeichnung,b.Bezeichnung as Bundesland, p.ID AS PLZID
FROM MMOrte o
LEFT OUTER JOIN MMPLZ p ON o.DefPLZID = p.ID OR o.ID = p.OrtID
LEFT OUTER JOIN MMKategorie k ON o.KategorieID = k.ID
LEFT OUTER JOIN MMBundesland b ON o.BundeslandID = b.ID
LEFT OUTER JOIN MMPLZ p2 ON o.ID = p2.OrtID
WHERE (p.PLZ like '72141%')
ORDER BY o.Name
Wenn I use:
SELECT o.ID, o.Name,p.PLZ as DefPLZ,k.Bezeichnung,b.Bezeichnung as Bundesland, p.ID AS PLZID
FROM MMPLZ p
LEFT OUTER JOIN MMOrte o ON o.DefPLZID = p.ID OR o.ID = p.OrtID
LEFT OUTER JOIN MMKategorie k ON o.KategorieID = k.ID
LEFT OUTER JOIN MMBundesland b ON o.BundeslandID = b.ID
LEFT OUTER JOIN MMPLZ p2 ON o.ID = p2.OrtID
WHERE (p.PLZ like '72141%')
ORDER BY o.Name
The Query Works.
It seems to work if i use in WHERE Clause one Column from the Table neer the FROM keyword.
The main Problem is that SQLite hangs... I will generate my Query so that it works... |
2006-Aug-25 13:32:21 by anonymous:
"Hanging" is not very descriptive. Your query is working but now it either makes poor use of indexes or is doing full table scans, or possibly an unintended cross join.
2007-Jan-10 16:31:41 by anonymous:
I am seeing the same problem. It works on a limit of 1 and then fails on a limit of 2.
2007-Jan-10 16:49:09 by drh:
If you would like me to work on this, please send a reproducible
test case. |
|
1938 |
build
|
active
|
2006 Aug
|
anonymous
|
|
2006 Aug
|
|
4
|
5
|
Cygwin compilation of v3 fails
|
edit |
make install leads to this:
[UTEKLIFEBOOK] ~/MyDocuments/dl/sqlite-3.3.7 > make install
tclsh ./tclinstaller.tcl 3.3
can't read "env(DESTDIR)": no such variable |
2006-Aug-25 13:24:19 by anonymous:
Looking at your log file you can see that sqlite3.exe was built successfully. Tcl is an optional component of SQLite. All you need is:
./configure && make sqlite3.exe
Or install TCL via Cygwin setup.exe.
2006-Sep-26 17:02:54 by anonymous:
Why not build with this?
- ./configure --disable-tcl
- make
- make install
It works for me. |
|
1935 |
event
|
active
|
2006 Aug
|
anonymous
|
Parser
|
2006 Aug
|
|
4
|
4
|
GROUP BY and ORDER BY constant expressions valid?
|
edit |
I'm not sure what other databases do in this situation, or whether a constant expression should be deemed a constant in ORDER BY and GROUP BY and result in an error.
CREATE TABLE t1(a,b);
INSERT INTO "t1" VALUES(1, 2);
INSERT INTO "t1" VALUES(1, 3);
INSERT INTO "t1" VALUES(2, 3);
INSERT INTO "t1" VALUES(2, 4);
INSERT INTO "t1" VALUES(2, 5);
-- as expected
select a, b from t1 group by 0;
SQL error: GROUP BY column number 0 out of range - should be between 1 and 2
-- ???
select a, b from t1 group by 0/1;
2|5
select a, b from t1 group by 0.0;
2|5
select a, b from t1 order by 13/2;
1|2
1|3
2|3
2|4
2|5
select a, b from t1 group by 3/9 order by 1/9, 7.0, 0.4-3;
2|5
|
2006-Aug-26 07:26:06 by anonymous:
The integer is the column number. |
|
1934 |
doc
|
active
|
2006 Aug
|
anonymous
|
|
2006 Aug
|
|
5
|
5
|
Documentation about default file format
|
edit |
Default file format has changed from 3.3.7.
This is mentionned here :
http://www.sqlite.org/changes.html
and
http://www.sqlite.org/formatchng.html
but not here :
http://www.sqlite.org/pragma.html (PRAGMA legacy_file_format) |
|
1933 |
new
|
active
|
2006 Aug
|
anonymous
|
|
2006 Aug
|
|
5
|
4
|
Add different date's separators
|
edit |
A time string can be in any of the following formats:
1. YYYY-MM-DD
2. YYYY-MM-DD HH:MM
3. YYYY-MM-DD HH:MM:SS
4. YYYY-MM-DD HH:MM:SS.SSS
5. YYYY-MM-DDTHH:MM
6. YYYY-MM-DDTHH:MM:SS
7. YYYY-MM-DDTHH:MM:SS.SSS
8. HH:MM
9. HH:MM:SS
10. HH:MM:SS.SSS
11. now
12. DDDD.DDDD
Add possibility to have date's separators different of dash
Examples :
YYYY.MM.DD HH:MM:SS
YYYY/MM/DD HH:MM:SS
|
|
1928 |
new
|
active
|
2006 Aug
|
anonymous
|
Parser
|
2006 Aug
|
|
2
|
2
|
NULL rowid in views and subqueries
|
edit |
$ cat rowid_on_views.sql
create table abc(a,b,c);
insert into abc values(4,5,6);
insert into abc values(3,2,1);
create view vv as select * from abc;
select 'select rowid, * from abc;';
select rowid, * from abc;
select 'select rowid, * from (select * from abc);';
select rowid, * from (select * from abc);
select 'select rowid, * from vv;';
select rowid, * from vv;
$ ./sqlite337 < rowid_on_views.sql
select rowid, * from abc;
1|4|5|6
2|3|2|1
select rowid, * from (select * from abc);
|4|5|6
|3|2|1
select rowid, * from vv;
|4|5|6
|3|2|1
|
2006-Aug-21 09:09:15 by anonymous:
The point is simply that a view or subquery does not (meaning "cannot") have a rowid - just contemplate the case where your view takes the max(..) or count(..) of something.
You would get the behaviour that you seem to expect when you declare your original table as
create table abc(rowid integer primary key, a,b,c);
2006-Aug-21 14:35:04 by anonymous:
Not sure what you're talking about. Your example does not work.
Many databases support the concept of "row id's" on views. It is a very useful construct.
-- working Oracle example
create table abc(a integer, b integer ,c integer);
insert into abc values(4,5,6);
insert into abc values(3,2,1);
create view abc_vu as select * from abc;
select rownum, a, b, c from (select * from abc_vu);
ROWNUM A B C
1 4 5 6
2 3 2 1
-- another Oracle example
select rownum, v1.*, v2.* from (select * from abc_vu) v1, (select * from abc_vu) v2;
ROWNUM A B C A B C
1 4 5 6 4 5 6
2 3 2 1 4 5 6
3 4 5 6 3 2 1
4 3 2 1 3 2 1
2006-Aug-22 05:32:26 by anonymous:
Hm, rowid (original ticket) and rownum (3rd remark) are very different things. I've tested the following with Oracle:
create table abc(a integer, b integer ,c integer);
insert into abc values(4,5,6);
insert into abc values(3,2,1);
insert into abc values(4,5,10);
create view abc_vu as select max(a) as amax,b,count(*) as cnt from abc group by b;
Now
SQL> select rownum, amax,b,cnt from (select * from abc_vu);
ROWNUM AMAX B CNT
---------- ---------- ---------- ----------
1 3 2 1
2 4 5 2
whereas
SQL> select rowid, amax,b,cnt from (select * from abc_vu);
select rowid, amax,b,cnt from (select * from abc_vu)
*
ERROR at line 1:
ORA-01446: cannot select ROWID from view with DISTINCT, GROUP BY, etc.
2006-Aug-22 05:36:03 by anonymous:
PS: selecting rowid from views without "group by" is supported by Oracle:
SQL> create view abc_vu2 as select * from abc;
View created.
SQL> select rowid,a,b,c from (select * from abc_vu2);
ROWID A B C
------------------ ---------- ---------- ----------
AAADmaAAFAAAFNzAAA 4 5 6
AAADmaAAFAAAFNzAAB 3 2 1
AAADmaAAFAAAFNzAAC 4 5 10
|
|
1924 |
new
|
active
|
2006 Aug
|
anonymous
|
Parser
|
2007 May
|
|
2
|
3
|
optimize queries on unions, constant folding
|
edit |
Please see the attached patch that optimizes
SELECTs on a compound subquery, or VIEWs containing UNIONS.
pragma temp_store=memory;
CREATE TABLE n1(a integer primary key);
INSERT INTO "n1" VALUES(1);
INSERT INTO "n1" VALUES(2);
INSERT INTO "n1" VALUES(3);
INSERT INTO "n1" VALUES(4);
INSERT INTO "n1" VALUES(5);
INSERT INTO "n1" VALUES(6);
INSERT INTO "n1" VALUES(7);
INSERT INTO "n1" VALUES(8);
INSERT INTO "n1" VALUES(9);
INSERT INTO "n1" VALUES(10);
CREATE VIEW vu as select v3.a a, v5.a-v2.a*v7.a b from n1 v1,n1 v2,n1 v3,n1 v4,n1 v5,n1 v6,n1
v7;
CREATE VIEW v2 as select * from vu union all select 7, 8;
select count(*), avg(b) from v2 where a<3;
The above query takes 58 seconds in sqlite 3.3.7, using 136M of temp_store.
With the patch, it takes just 12 seconds and uses 26M of temp_store.
The patch also performs 32 bit integer constant folding:
sqlite> explain select 1*2+3-4%5/2|128;
0|Goto|0|4|
1|Integer|131|0|
2|Callback|1|0|
3|Halt|0|0|
4|Goto|0|1|
5|Noop|0|0|
|
2006-Aug-17 13:03:31 by anonymous:
TK_REM (the '%' operator) is not handled correctly in the patch.
It should follow the logic of TK_SLASH and check 'right' against zero.
+ case TK_REM: { v = left % right; break; }
...
+ case TK_SLASH: {
+ if (right) {
+ v = left / right;
+ } else {
+ return;
+ }
+ break;
+ }
2006-Aug-17 15:50:20 by anonymous:
These 2 cases can overflow a 32 bit value. The calculation should be done in 64 bit int math, and if the result can fit into 32-bits, then fold it, otherwise return (similar to TK_SLASH).
+ case TK_PLUS: { v = left + right; break; }
+ case TK_STAR: { v = left * right; break; }
Or just handle all cases in 64-bit math.
2006-Aug-18 10:11:53 by anonymous:
Wouldn't TK_MINUS also be able to overflow 32-bit, just in the opposite direction, so to speak ? Example: -2000000000 - 2000000000
2006-Aug-18 13:51:05 by anonymous:
should you make
+ i64 left;
+ i64 right;
+ i64 v;
instead of
+ int left;
+ int right;
+ int v;
to avoid int32 overflows.
2006-Aug-18 16:27:21 by anonymous:
The attachment sqlite337-union-and-constants-opt-v2.diff.txt addresses all reported issues and passes "make test" without any regressions.
2006-Aug-18 19:41:20 by anonymous:
You're not assuming that "right" could be a i64 value in this last patch...
2006-Aug-19 13:41:14 by anonymous:
right is a 32 bit value.
/*
** If the expression p codes a constant integer that is small enough
** to fit in a 32-bit integer, return 1 and put the value of the integer
** in *pValue. If the expression is not an integer or if it is too big
** to fit in a signed 32-bit integer, return 0 and leave *pValue unchanged.
*/
int sqlite3ExprIsInteger(Expr *p, int *pValue){
2007-May-16 20:09:38 by anonymous:
Updated patch as of May 16, 2007 CVS:
http://marc.info/?l=sqlite-users&m=117934558505665&w=2
http://marc.info/?l=sqlite-users&m=117934558505665&q=p3
2007-May-19 15:47:51 by anonymous:
Some improvements, new comments and a new test case.
http://www.mail-archive.com/sqlite-users%40sqlite.org/msg24859.html
http://marc.info/?l=sqlite-users&m=117958960408282&q=p3 |
|
1907 |
new
|
active
|
2006 Aug
|
anonymous
|
|
2006 Aug
|
|
4
|
4
|
date and time types
|
edit |
I would like to have datetime types in sqlite (date, datetime, interval).
as far as I understood of sqlite, the declared type used in the create table statement is just a hint, and the data is stored with its own type description. this makes it impossible to store a date into any field, unless type checking, conversion and validation is performed by the client side.
implementing type checking and conversion on the client side would mean that the dynamic typing in sqlite goes lost for that applications. |
2006-Aug-05 13:49:35 by anonymous:
Also, the way SQLite currently stores datetimes is not space efficient (stored as text) and there is no standard format between different SQLite applications. But I can't see a way to improve this situation without breaking backwards compatability. |
|
1906 |
new
|
active
|
2006 Aug
|
anonymous
|
Unknown
|
2006 Aug
|
|
1
|
2
|
date.c line 417 uses non-thread safe localtime() call
|
edit |
The date.c file uses a call to localtime() that is not threadsafe.
Could it be replaced with localtime_r where supported. |
2006-Aug-04 16:17:22 by anonymous:
Please apply this patch to make SQLite threadsafe:
Index: configure.ac
===================================================================
RCS file: /sqlite/sqlite/configure.ac,v
retrieving revision 1.26
diff -u -r1.26 configure.ac
--- configure.ac 3 Jun 2006 18:02:18 -0000 1.26
+++ configure.ac 4 Aug 2006 16:05:21 -0000
@@ -669,6 +669,11 @@
#
AC_CHECK_FUNC(usleep, [TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_USLEEP=1"])
+#########
+# Figure out whether or not we have a "localtime_r()" function.
+#
+AC_CHECK_FUNC(localtime_r, [TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_LOCALTIME_R=1"])
+
#--------------------------------------------------------------------
# Redefine fdatasync as fsync on systems that lack fdatasync
#--------------------------------------------------------------------
Index: src/date.c
===================================================================
RCS file: /sqlite/sqlite/src/date.c,v
retrieving revision 1.54
diff -u -r1.54 date.c
--- src/date.c 31 Jan 2006 20:49:13 -0000 1.54
+++ src/date.c 4 Aug 2006 16:05:21 -0000
@@ -393,7 +393,7 @@
static double localtimeOffset(DateTime *p){
DateTime x, y;
time_t t;
- struct tm *pTm;
+ struct tm tmLocaltime;
x = *p;
computeYMD_HMS(&x);
if( x.Y<1971 || x.Y>=2038 ){
@@ -411,15 +411,20 @@
x.validJD = 0;
computeJD(&x);
t = (x.rJD-2440587.5)*86400.0 + 0.5;
- sqlite3OsEnterMutex();
- pTm = localtime(&t);
- y.Y = pTm->tm_year + 1900;
- y.M = pTm->tm_mon + 1;
- y.D = pTm->tm_mday;
- y.h = pTm->tm_hour;
- y.m = pTm->tm_min;
- y.s = pTm->tm_sec;
- sqlite3OsLeaveMutex();
+//#define HAVE_LOCALTIME_R
+#ifdef HAVE_LOCALTIME_R
+ localtime_r(&t, &tmLocaltime);
+#else
+ /* sqlite3OsEnterMutex(); not needed due to HAVE_LOCALTIME_R */
+ tmLocaltime = *localtime(&t);
+ /* sqlite3OsLeaveMutex(); not needed due to HAVE_LOCALTIME_R */
+#endif
+ y.Y = tmLocaltime.tm_year + 1900;
+ y.M = tmLocaltime.tm_mon + 1;
+ y.D = tmLocaltime.tm_mday;
+ y.h = tmLocaltime.tm_hour;
+ y.m = tmLocaltime.tm_min;
+ y.s = tmLocaltime.tm_sec;
y.validYMD = 1;
y.validHMS = 1;
y.validJD = 0;
2006-Aug-04 17:48:38 by anonymous:
The same type of autoconfig and src/date.c code changes have to be done for the not-threadsafe gmtime() function. The current implementation (even with the mutex) is not threadsafe in all cases. |
|
1905 |
new
|
active
|
2006 Aug
|
anonymous
|
VDBE
|
2006 Aug
|
|
5
|
4
|
Get bound param as sqlite3_value?
|
edit |
It doesn't seem to be possible to get the values, that have been bound to a prepared statement, after binding them.
What's the use you ask?
In complex scenarios the code might do complex binds (binding a NULL or an int/text depending on application logic is a simple example).
A wrapper around sqlite3_step can use the requested new function to iterate over all parameters and dump them to the debug log on errors.
Looking at the vdbe stuff, this seems to be a straight forward function, that will just return a pointer to vdbe->aVar[i-1] after range checking. |
|
1902 |
new
|
active
|
2006 Jul
|
anonymous
|
Parser
|
2006 Jul
|
|
5
|
3
|
allow alternate INSERT syntax using SET foo=bar
|
edit |
Please support the alternate INSERT statement syntax in your parser that several other database products (and possibly the SQL standard) supports where you can say things like:
INSERT INTO foo SET bar='hello', baz='world';
The main part of the statement, which maps field names to values, then is a lot easier for users to work with, either manually or in SQL generators, and can be reused between INSERT and UPDATE statements.
This should be simple to add, and I strongly suggest having it in before the next release (eg, as part of 3.3.7).
Thank you. -- Darren Duncan |
|
1901 |
code
|
active
|
2006 Jul
|
anonymous
|
Unknown
|
2006 Jul
|
adamd
|
2
|
2
|
problem in select request with a alias table
|
edit |
I have a table with 3 columns : c0, c1 and c2
My request is:
select * from (select *, 'test' as new_col from table) as tmp inner join (select 'test' as new_col) as tmp1 on tmp.new_col = tmp1.new_col;
The column's name as a result of this request (sqlite 3-3.3.6) is:
|tmp.table.c0|tmp.table.c1|tmp.table.c2|tmp.new_col|tmp1.new_col
In sqlite 3-3.2.7, the column's name is:
|c0|c1|c2|collected|new_col|new_col
Before this version, my request ran on mysql, postgresql and sqlite. Now I don't have the possibility of using this request with the new sqlite version. |
2006-Jul-31 10:11:59 by anonymous:
sorry in In sqlite 3-3.2.7, the column's name is:
|c0|c1|c2|new_col|new_col
2007-Jan-08 14:52:43 by anonymous:
I had a similar problem with SQLite in PHP, see my bug report here:
http://bugs.php.net/bug.php?id=40064 |
|
1900 |
code
|
active
|
2006 Jul
|
anonymous
|
Unknown
|
2006 Jul
|
a.rottmann
|
1
|
1
|
CURRENT_TIMESTAMP keyword not inserting UTC date in column
|
edit |
This is the schema for my table.
create table char (player varchar(64) NOT NULL default '~',
name varchar(64) NOT NULL default '~',
date timestamp NOT NULL default current_timestamp)
Whenever an insert is made to the table the column 'date' does get a UTC timestamp, it gets a string value 'current_timestamp'. Is my schema wrong? |
2006-Jul-30 22:31:06 by anonymous:
*doesnt get a UTC timestap
2006-Jul-31 00:38:49 by anonymous:
Works fine for me. What's the exact syntax of your INSERT statement? |
|
1898 |
doc
|
active
|
2006 Jul
|
anonymous
|
|
2006 Jul
|
|
5
|
4
|
sqlite3_progress_handler still marked experimental in documentation
|
edit |
According to DRH's posting on the sqlite-user mailing list, sqlite3_progress_handler is no longer experimental and the note in the documentation should be removed. Here's the ticket to track this issue... |
|
1896 |
new
|
active
|
2006 Jul
|
drh
|
|
2006 Jul
|
|
1
|
1
|
All extensions to be statically linked
|
edit |
The new LoadableExtensions mechanism is great for loading new extensions
out of external files. But we also need the ability to statically
link extensions with an application and load them into database
connections as needed.
One possible solution would be a new API that takes a fake
filename and a function pointer. Any attempt to call
sqlite3_load_extension() on that fake filename by any
SQLite connection invokes the function pointer rather than
actually opening a shared library with that filename. |
2006-Jul-26 11:30:28 by anonymous:
In order to statically link extensions to the application, they'll all need to have unique entry function names. Besides meaning that extensions couldn't be statically linked without possible modification (I somehow suspect "sqlite3_extension_init" will be a popular name), it ensures that the extensions are uniquely identified in the application function namespace.
So I think it should just be necessary to have a function to register these function names and pointers, and sqlite3_load_extension() with a NULL zFile and appropriate zProc would have no trouble finding them in the "registry".
A trivial modification to the SQL load_extension() function to take just the function name would be a bonus.
c.
2006-Jul-26 11:39:59 by anonymous:
Something else which would be handy for statically linking extensions... It might be useful for a developer to directly call the extension entry function instead of formally registering it (i.e. they only want the extension available to a specific DB handle), in which case there should be a way to provide the sqlite3_api_routines structure to the entry function. Just making sure it's mentioned and formally documented in sqlite.h should be sufficient. |
|
1895 |
doc
|
active
|
2006 Jul
|
anonymous
|
|
2006 Jul
|
anonymous
|
4
|
3
|
IS operator not documented
|
edit |
Hello,
I tried to work with varchar fields having NULL values. However, I was not able to find the right operator to catch such values, and none of the operators mentionend in datatype3.html seemed to help. Finally I tried "is null" (or IS NOT NULL) and well, that seems to do what I want. But there are questions:
- is this an intended feature?
- if yes, can I rely on having it in the future versions?
- if this is not an intended feature, what is the right way to match NULL values?
- if that's just a documentation problem, will the documentation be updated?
|
2006-Jul-19 19:02:17 by anonymous:
It's part of the SQL standard. "IS" isn't really an operator; it's an optional token that's part of the NULL and NOT NULL predicates. |
|
1893 |
code
|
active
|
2006 Jul
|
anonymous
|
|
2006 Aug
|
|
3
|
3
|
sqlite doesn't use indexes containing primary key in prim. key selects
|
edit |
I have table:
CREATE TABLE IF NOT EXISTS 'customers' (
'rowid' INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
'fname' CHAR(40) NOT NULL,
'sname' CHAR(40) NOT NULL,
'birthno' CHAR(11) NULL)
And index:
CREATE UNIQUE INDEX IF NOT EXISTS 'idx_customers_sname'
ON 'customers' (
'sname' ASC,
'fname' ASC,
'rowid' ASC
);
Command
SELECT * FROM customers ORDER BY sname ASC, fname ASC, rowid ASC;
doesn't use created index.
Command
SELECT * FROM customers ORDER BY sname ASC, fname ASC;
uses index idx_customers_sname.
I think this is a bug, but maybe (i don't know), it is by desing.
If I don't specify rowid in ORDER BY, is the resultset ordered by rowid anyway? |
2006-Jul-24 16:02:29 by anonymous:
In SQL single quotes are used around string literals, and double quotes are used around identifiers where required to enclose keywords and/or embedded spaces. In your case no quotes are required at all because your table and column identifiers are continuos (i.e. do not contain embedded spaces) non-keyword names. If you are going to include unnecessary quotes then you should at least use the correct ones.
CREATE TABLE IF NOT EXISTS "customers" (
"rowid" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
"fname" CHAR(40) NOT NULL,
"sname" CHAR(40) NOT NULL,
"birthno" CHAR(11) NULL);
CREATE UNIQUE INDEX IF NOT EXISTS "idx_customers_sname" ON "customers" ( "sname" ASC, "fname" ASC, "rowid" ASC );
Aside from that, this does look like a bug. SQLite is doing an unnecessary sort for the first query, and correctly using the index for the second.
I suspected that it might be related to handling of the special column name rowid, but it does the same thing if rowid is replaced with a more generic name like id as shown below.
SQLite version 3.3.6
Enter ".help" for instructions
sqlite> CREATE TABLE IF NOT EXISTS "customers" (
...> "id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
...> "fname" CHAR(40) NOT NULL,
...> "sname" CHAR(40) NOT NULL,
...> "birthno" CHAR(11) NULL);
sqlite>
sqlite> CREATE UNIQUE INDEX IF NOT EXISTS "idx_customers_sname"
...> ON "customers" ( "sname" ASC, "fname" ASC, "id" ASC );
sqlite>
sqlite>
sqlite> explain query plan SELECT * FROM customers ORDER BY sname ASC, fname ASC
, id ASC;
0|0|TABLE customers
sqlite> explain query plan SELECT * FROM customers ORDER BY sname ASC, fname ASC
;
0|0|TABLE customers WITH INDEX idx_customers_sname ORDER BY
sqlite>
sqlite> .explain on
sqlite>
sqlite> explain SELECT * FROM customers ORDER BY sname ASC, fname ASC, id ASC;
addr opcode p1 p2 p3
---- -------------- ---------- ---------- ---------------------------------
0 OpenVirtual 1 5 keyinfo(3,BINARY,BINARY)
1 Goto 0 34
2 Integer 0 0
3 OpenRead 0 2
4 SetNumColumns 0 4
5 Rewind 0 19
6 Rowid 0 0
7 Column 0 1
8 Column 0 2
9 Column 0 3
10 MakeRecord 4 0
11 Column 0 2
12 Column 0 1
13 Rowid 0 0
14 Sequence 1 0
15 Pull 4 0
16 MakeRecord 5 0
17 IdxInsert 1 0
18 Next 0 6
19 Close 0 0
20 OpenPseudo 2 0
21 SetNumColumns 2 4
22 Sort 1 32
23 Integer 1 0
24 Column 1 4
25 Insert 2 0
26 Column 2 0
27 Column 2 1
28 Column 2 2
29 Column 2 3
30 Callback 4 0
31 Next 1 23
32 Close 2 0
33 Halt 0 0
34 Transaction 0 0
35 VerifyCookie 0 2
36 Goto 0 2
37 Noop 0 0
sqlite> explain SELECT * FROM customers ORDER BY sname ASC, fname ASC;
addr opcode p1 p2 p3
---- -------------- ---------- ---------- ---------------------------------
0 Noop 0 0
1 Goto 0 21
2 Integer 0 0
3 OpenRead 0 2
4 SetNumColumns 0 4
5 Integer 0 0
6 OpenRead 2 4 keyinfo(3,BINARY,BINARY)
7 Rewind 2 18
8 RowKey 2 0
9 IdxIsNull 0 17
10 IdxRowid 2 0
11 MoveGe 0 0
12 Rowid 0 0
13 Column 0 1
14 Column 0 2
15 Column 0 3
16 Callback 4 0
17 Next 2 8
18 Close 0 0
19 Close 2 0
20 Halt 0 0
21 Transaction 0 0
22 VerifyCookie 0 2
23 Goto 0 2
24 Noop 0 0
sqlite>
2006-Aug-03 17:33:51 by anonymous:
Thank you for clarification of single and double quotes usage.
I will drop the quotes completely since using double quotes is little bit annoying inside C string literals...
It seems that the problem with index and sorting on primary key is independent of primary key column name. In fact, previously I was using "id" :-) and the result was the same as you mentioned. |
|
1890 |
code
|
active
|
2006 Jul
|
anonymous
|
Unknown
|
2006 Jul
|
|
3
|
4
|
double quotes ("") in a query are ambiguous
|
edit |
sqlite> SELECT "uuid" FROM objects LIMIT 1;
b43c9cdc-0dc8-11db-9475-080020a846a9
sqlite> SELECT "uuidx" FROM objects LIMIT 1;
uuidx
The objects table has a column named uuid; it does not have a column named uuidx. The behaviour of "" depends on whether the contents are a valid column name, and I cannot see when this is desirable behaviour.
(I know that `` and '' are the right quotes to use, by the way - I'm just pointing out that "" can surprise people a lot and should probably be fixed or removed) |
2006-Jul-13 13:39:37 by anonymous:
The current behaviour is an SQL standard thing, so SQLite implements it for the sake of compatibility.
Certainly most people agree with you that it's a bad thing.
2006-Jul-13 16:56:05 by anonymous:
Perhaps what we need then is a big fat warning in the manual :)
- Peter
2006-Jul-17 00:06:41 by drh:
Please suggest a specific location in the documentation where
I should put a warning about the use of " instead of ' and I
will add it.
2006-Jul-27 10:30:12 by anonymous:
lang_expr.html seems like an obvious choice; perhaps also a sidenote on FAQ question 16 - Peter |
|
1885 |
code
|
active
|
2006 Jul
|
anonymous
|
Shell
|
2006 Jul
|
|
2
|
3
|
sqlite3 .mode insert and .dump do not list column names for selects
|
edit |
In sqlite3 .mode insert does not list column names for selects - it should. This makes dumping selected columns from tables when intending to add or delete columns problematic. .dump doesn't list column names either, IMHO it should. Consider
sqlite> .mode tabs
sqlite> select * from users;
ed 2006-07-05 52
sqlite> .mode insert
sqlite> select abs_tgt from users;
INSERT INTO table VALUES(52);
sqlite>
Obviously the workaround is to hand edit the output SQL |
2006-Jul-11 10:20:08 by anonymous:
I've just noticed it doesn't include the table name in the INSERT statements either. |
|
1884 |
code
|
active
|
2006 Jul
|
anonymous
|
|
2006 Jul
|
|
3
|
2
|
pragma table_info caches results from previous query
|
edit |
this problem is observed with pysqlite's latest windows build 2.3.2 and others. it does not occur on unix-based builds, which is why I suspect the issue is in sqlite, since pysqlite's code is platform-neutral.
if you get a result from a "pragma table_info()" call, and do not consume all the results, then a subsequent call to the same statement does not return up-to-date results, i.e. if the table had been dropped in between. it behaves as though the results of "pragma table_info" are globally cached somewhere, ignoring the fact that is was executed again.
this test program illustrates the problem:
from pysqlite2 import dbapi2 as sqlite
connection = sqlite.connect(':memory:')
# check for a nonexistent table
c = connection.execute("pragma table_info(users)")
row = c.fetchone()
assert row is None # its good.
# now create the table
connection.execute("""
create table users (
foo VARCHAR(10),
name VARCHAR(40)
)
""")
# do the table_info pragma. returns two rows
c = connection.execute("pragma table_info(users)")
# get the first row
row = c.fetchone()
print row
# but then dont get the second, close out the cursor instead.
#row2 = c.fetchone() # uncomment to fully consume both rows, then it works
c.close()
c = None
# rollback too.
connection.rollback()
# now drop the table
connection.execute("DROP TABLE users")
print "dropped"
# now it should be gone, right? well it is, but the pragma
# call starts off with the former result set
c = connection.execute("pragma table_info(users)")
row = c.fetchone()
print row
assert row is None # fails.
|
|
1882 |
code
|
active
|
2006 Jul
|
anonymous
|
|
2006 Jul
|
|
1
|
1
|
Wrong algorithm of SQLITE_VERSION_NUMBER calculation
|
edit |
The sqlite3.h comment describing how numeric version number is calculated is as follows:
"The SQLITE_VERSION_NUMBER is an integer with the value
(X*100000 + Y*1000 + Z). For example, for version "3.1.1beta",
SQLITE_VERSION_NUMBER is set to 3001001."
But the value of SQLITE_VERSION_NUMBER is greater than the equation above suggests.
The value X*100000 should be changed to X*1000000 (one milion). |
|
1878 |
code
|
active
|
2006 Jun
|
anonymous
|
CodeGen
|
2006 Jun
|
|
2
|
3
|
No index used when specifying alias name in ORDER BY clause
|
edit |
Using an alias name in the ORDER BY clause prevents indices from being used in the query for sorting purposes:
For this schema:
CREATE TABLE t1 (c1, c2);
CREATE TABLE t2 (c3, c4);
CREATE INDEX t1_idx ON t1(c2);
the following select query:
EXPLAIN QUERY PLAN
SELECT t1.c2 AS col2, t2.c4 AS col4
FROM t1 LEFT JOIN t2 ON t1.c1=t2.c3 ORDER BY t1.c2;
will indeed use index t1_idx:
sqlite> EXPLAIN QUERY PLAN
SELECT t1.c2 AS col2, t2.c4 AS col4
FROM t1 LEFT JOIN t2 ON t1.c1=t2.c3
ORDER BY t1.c2;
0|0|TABLE t1 WITH INDEX t1_idx
1|1|TABLE t2
However, when using the alias name col2 in the ORDER BY clause, the index won't be used:
sqlite> EXPLAIN QUERY PLAN
SELECT t1.c2 AS col2, t2.c4 AS col4
FROM t1 LEFT JOIN t2 ON t1.c1=t2.c3
ORDER BY col2;
0|0|TABLE t1
1|1|TABLE t2
IMHO, the same index should be used in both queries? |
2006-Jun-30 13:54:10 by anonymous:
Not sure whether it's a different issue, but when using a second column in the ORDER BY clause, also no index will be used:
sqlite> EXPLAIN QUERY PLAN
SELECT t1.c2 AS col2, t2.c4 AS col4
FROM t1 LEFT JOIN t2 ON t1.c1=t2.c3 ORDER BY t1.c2, t2.c4;
0|0|TABLE t1
1|1|TABLE t2
Personally, I'd expect sqlite to use the t1_idx index as well to fulfill the primary ordering?
2006-Jun-30 16:04:31 by anonymous:
As a workaround try "ORDER BY 1"
2006-Jul-03 08:41:01 by anonymous:
Sorry, I'm not sure how "ORDER BY 1" would be a workaround, when I really need the results to be sorted by table column data...
(I don't want to start a discussion in the bug tracker, so you're welcome to take any suggestions/answers to the sqlite-user mailing list, which I also monitor.)
2006-Jul-03 15:51:11 by anonymous:
I'm not the poster of previous comment, but ORDER BY (n) order by result column index. In your case, using ORDER BY 1, it will be ordered by the first column.
2006-Jul-04 07:33:30 by anonymous:
Thanks for the clarification. This would be a workaround for the first problem mentioned, but when sorting by two columns, still no index will be used, even if using ORDER BY 1,2
2006-Jul-04 21:34:24 by anonymous:
SQLite really needs a way to explicitly state which index(es) to use. Perhaps something similar to Oracle's comment hints. |
|
1874 |
new
|
active
|
2006 Jun
|
anonymous
|
CodeGen
|
2006 Jun
|
|
2
|
3
|
IN is much slower than making separate queries
|
edit |
I have a 500,000-row table with the following schema:
CREATE TABLE foo(bar INTEGER NOT NULL, baz INTEGER NOT NULL, biz INTEGER NULL, buzz INTEGER NULL);
CREATE INDEX biz ON foo (bar, baz, biz);
CREATE INDEX buzz ON foo (bar, baz, buzz);
I'm performing the query:
SELECT * FROM foo WHERE bar IN (0,1) AND baz IN (0,1) AND (biz IN (0,1) OR buzz IN (0,1));
On both Apple's 3.1.3 and a stock 3.3.6 on Mac OS X 10.4.6 PowerPC, this query consistently takes 3 seconds to execute. However, if I unroll the query:
SELECT * FROM foo WHERE bar=0 AND baz=0 AND biz=0;
SELECT * FROM foo WHERE bar=0 AND baz=0 AND buzz=0;
...and so on for the other values of bar and baz...
it takes 0.2 seconds.
I was able to reproduce this with the attached scripts by doing:
./mkdb > mkdb.sql
sqlite3 testdb < mkdb.sql
time sqlite3 testdb < q1 > /dev/null
time sqlite3 testdb < q2 > /dev/null
The database was recreated between the 3.1.3 and the 3.3.6 testing.
EXPLAIN on the IN query segfaults on both 3.1.3 and 3.3.6, otherwise I'd attach that output. I'll write up a separate bug for that :) |
2006-Jun-27 20:52:35 by anonymous:
[3315]
fixed the EXPLAIN crash, so I've attached EXPLAIN output for the IN query.
2006-Jun-27 22:01:31 by drh:
On SuSE Linux 10.0 running on a Dell Latitude D600 laptop and using the latest
code from CVS, I'm getting times of 1.2s and 0.45s. If I create an additional
index:
CREATE INDEX i2 ON foo(bar,baz,biz,buzz);
then the time for the first query drops to 0.7s. Note, however, the q1 and q2
are very different queries. In particular q2 omits half the rows. The (rough)
equivalent of q2 is this:
SELECT * FROM foo
WHERE bar IN (0,1)
AND baz IN (0,1)
AND (biz=0 or buzz=0);
If I modify q2 so that it includes the biz=1 and buzz=1 cases, its
query time increases to 0.7s, the same as q1 with the added index.
Further note that q1 and q2 are still not exactly the same. Q2 includes
multiple copies of rows where biz IN (0,1) AND buzz IN (0,1) where q1
only includes such lines once. There are only 120 such lines in the
database, but it still a difference.
I will recast this ticket as a request for performance enhancements on
queries using the IN operator on a fixed list of values.
2006-Jun-28 01:52:32 by drh:
Note to self: The expression +x IN (1,2,3,...) appears to be faster
than +x=1 OR +x=2 OR ... when there are 6 or more terms. With 5
terms or fewer, a string of ORs is faster. |
|
1872 |
code
|
active
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
4
|
3
|
sqlite3_open doesn't support RFC1738 format for filename
|
edit |
sqlite3_open only supports UTF-8 encoding as a format for its filename argument (http://www.sqlite.org/capi3ref.html#sqlite3_open).
If your application receives a RFC1738 encoded URL for filename, that has to be UTF-8-encoded for use in SQLite. It would be nice if that could be instead passed directly to sqlite3_open.
Is RFC1738 URL decoding support planned for SQLite?
(RFC1738 link: http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc1738.html) |
|
1871 |
event
|
active
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
2
|
3
|
VACUUM should not change 3.x file format
|
edit |
VACUUM should not "upgrade" the file format as it violates the principle of least astonishment. VACUUM upgrading the file format prevents users working with older versions of SQLite 3.x from sharing a common database file with users of more recent versions of the library. At the very least, if a version of SQLite can not produce the same version of the database file after VACUUM, it should do nothing, or perhaps return a warning. |
2006-Jun-27 13:25:30 by drh:
What if a user wants to upgrade the file format so that they can
take advantage of descending indices, for example? How should they
accomplish that? Should they be forced to dump and restore the
database?
2006-Jun-27 14:10:16 by anonymous:
Manually dumping the old database and restoring it with a more recent version of SQLite is reasonable given the incompatible nature of the change.
2006-Jun-27 15:30:32 by anonymous:
I agree. Can't SQLite do the equivalent of pragma legacy_file_format=1 on the new database created by the VACUUM command if the current file is in the old format?
The dump and restore operation is usable for updating the file format, but does require two installed versions of SQLite, one old and one new. Couldn't you add a new command or pragma that would do the format upgrade. Perhaps an optional upgrade argument to the VACUUM command that defualts to off could be used. If it is off the format of the new database is unchanged, if it is on, the format is upgraded. The VACUUM command doesn't seem like the obvious place tto look for a format upgrade option though. A new UPGRADE command would be more obvious, even if it is actually implemented by the same routines that do the VACUUM. It may be better to use something a little lower profile than a new command, perhaps a "PRAGMA upgrade_file_format" would be better. It would also allow future extension to provide a format version number that the database is to be upgraded to (ie PRAGMA upgrade_file_format=4).
2006-Jun-27 17:55:23 by anonymous:
it's a simple issue. since SQLite know the file format of database that is opened, on VACUUM it should create a file with the same version (such like a internal _sqlite3_open_ex() call that receive the file format that should be created. since SQLite can read/write those formats, there's no reason for doing a 'file format' upgrade. |
|
1869 |
doc
|
active
|
2006 Jun
|
anonymous
|
Unknown
|
2006 Jun
|
anonymous
|
4
|
4
|
Website typo
|
edit |
http://www.sqlite.org/capi3ref.html#sqlite3_exec has this:
"As an example, suppose the query result where this table:"
Instead of "where," "were" should have been used. |
|
1867 |
code
|
active
|
2006 Jun
|
anonymous
|
BTree
|
2006 Jun
|
|
1
|
3
|
Access Violation after set a new page_size
|
edit |
An access violation occured on W2K when I try to create a new table in the empty database.
There was a following sequence of SQL commands
select count(*)==2 as cnt from sqlite_master where type='table' and tbl_name in ('tbl1', 'tbl2');
so if cnt is equal 0 then I execute command
pragma page_size=4096;
and then create a new table.
I gess that some of internal structures by this time have been initialized and so when I try to create new table the page_size is lower then needed.
we overwrite memory in the function zeroPage in instruction:
memset(&data[hdr], 0, pBt->usableSize - hdr);
Size of structure data less then pBt->usableSize
Below result after memset
0:000> dt MemPage 004c3cf0
+0x000 isInit : 0 ''
+0x001 idxShift : 0 ''
+0x002 nOverflow : 0 ''
+0x003 intKey : 0x1 ''
+0x004 leaf : 0x1 ''
+0x005 zeroData : 0 ''
+0x006 leafData : 0x1 ''
+0x007 hasData : 0 ''
+0x008 hdrOffset : 0 ''
+0x009 childPtrSize : 0 ''
+0x00a maxLocal : 0
+0x00c minLocal : 0
+0x00e cellOffset : 0
+0x010 idxParent : 0
+0x012 nFree : 0xf94
+0x014 nCell : 0
+0x018 aOvfl : [5] _OvflCell
+0x040 pBt : (null)
+0x044 aData : (null)
+0x048 pgno : 0
+0x04c pParent : (null)
0012ea50 10006861 004c3cf0 0000000d 00000064 dblited!decodeFlags+0x80 [D:\sqllite\sqlite-3.3.6\btree.c @ 1349]
0012ea70 10006710 004c3cf0 0000000d 004c3cf0 dblited!zeroPage+0xd0 [D:\sqllite\sqlite-3.3.6\btree.c @ 1466]
0012ea8c 10006215 002fd390 002fd390 00000000 dblited!newDatabase+0xf9 [D:\sqllite\sqlite-3.3.6\btree.c @ 2061]
0012eaa0 10052ba0 002f7c30 00000001 0012f0e4 dblited!sqlite3BtreeBeginTrans+0xd6 [D:\sqllite\sqlite-3.3.6\btree.c @ 2141]
0012f0a4 10057cf5 004c3d80 0012f13c 0012f478 dblited!sqlite3VdbeExec+0x2c6d [D:\sqllite\sqlite-3.3.6\vdbe.c @ 2386]
0012f0e4 00412801 004c3d80 0012f1d4 0012f478 dblited!sqlite3_step+0x1db [D:\sqllite\sqlite-3.3.6\vdbeapi.c @ 223]
|
|
1864 |
new
|
active
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
drh
|
3
|
3
|
List availabe SQL functions
|
edit |
Once LoadableExtensions are implemented it would be really nice to be
able to get list of all available SQL functions and number[s] of
arguments.
Mostly I'm thinking about a scenario where you'd load someone else's
library from SQLite shell. Hopefully those will become common once
infrastructure is in place.
I guess SQLite already keeps track of all available functions
internally? |
2006-Jun-21 19:48:07 by drh:
Perhaps this could be done using a
virtual table.
2006-Jun-21 20:15:27 by anonymous:
Yes, this seems to be a really nice fit for virtual tables.
I lurked through the sources briefly, and it seems like all required
info is already there, in struct sqlite3 . Right? |
|
1862 |
code
|
active
|
2006 Jun
|
anonymous
|
TclLib
|
2006 Jun
|
tclguy
|
1
|
1
|
SQLite cannot load/import data from file
|
edit |
I found the problem when I tried to load a data file into a table. To reproduce the problem, I got a mini testcase.
DATA FILE - test.dat
1 0 0
2 90000 0
3 366000 0
---------------------------
Log from SQLite:
khronos-yajun>sqlite3 test
SQLite version 3.3.6
Enter ".help" for instructions
sqlite> create table test (id INT, x1 INT, x2 INT);
sqlite> .import test.dat test
test.dat line 1: expected 3 columns of data but found 1
sqlite> .exit
The problem also exists when I use tcl wrapper (sql copy abort test test.dat).
I looked into the code in src/tclsqlite.c,
In Lines
1045 nByte = strlen(zSql);
1046 rc = sqlite3_prepare(pDb->db, zSql, 0, &pStmt, 0);
1047 sqlite3_free(zSql);
Is the third argument of sqlite3_prepare supposed to be the length of zSql, hence nByte?
Also in lines
1070 zSql[j++] = ')';
1071 zSql[j] = 0;
1072 rc = sqlite3_prepare(pDb->db, zSql, 0, &pStmt, 0);
1073 free(zSql);
If I change these two places to reflect the length of zSql, I seem to succeed.
Yajun |
2006-Sep-27 16:25:47 by anonymous:
This is a duplicate of #1797 |
|
1861 |
code
|
active
|
2006 Jun
|
anonymous
|
Pager
|
2006 Jun
|
|
1
|
1
|
Problem in using Triggers and multithreading
|
edit |
I am using SQLite3 database with triggers . This database is used by my processing engine which is having 10 threads accessing the same database. Trigger is used to updata and insert records in a table and that very table is also updated by threads.
Processing engine crashes whenever a trigger updates or inserts a record in the table.
Can you tell me how to configure my existing engine to avoid crashing?
Is it safe to use trigger? |
|
1860 |
doc
|
active
|
2006 Jun
|
anonymous
|
Pager
|
2006 Jun
|
danielk1977
|
1
|
1
|
Problem in using SQLite3 with trigger and multithreading
|
edit |
I am using SQLite3 database with triggers . This database is used by my processing engine which is having 10 threads accessing the same database. Trigger is used to updata and insert records in a table and that very table is also updated by threads.
Processing engine crashes whenever a trigger updates or inserts a record in the table. |
|
1858 |
doc
|
active
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
5
|
5
|
Typo: Pearl -> Perl
|
edit |
sqlite/www/index.tcl 1.139
s/Pearl/Perl/g
|
|
1857 |
code
|
active
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
3
|
4
|
Can't use ISO 8601 dates with time zone designator 'Z'
|
edit |
Date-times of the format 'YYYY-MM-DDTHH:MM:SS.sssZ' do not return a valid date.
e.g. datetime('2006-06-19T15:44:07.466940Z').
The 'Z' indicates UTC.
This is the format generated by 'svn log --xml'.
More details of the format at http://www.w3.org/TR/NOTE-datetime.
This 'svn diff' fixes the problem:
--- date.c (revision 656)
+++ date.c (working copy)
@@ -136,7 +136,7 @@
**
** If the parse is successful, write the number of minutes
** of change in *pnMin and return 0. If a parser error occurs,
-** return 0.
+** return 1.
**
** A missing specifier is not considered an error.
*/
@@ -200,7 +200,10 @@
p->h = h;
p->m = m;
p->s = s + ms;
- if( parseTimezone(zDate, p) ) return 1;
+ if (*zDate == 'Z')
+ p->tz = 0;
+ else if( parseTimezone(zDate, p) )
+ return 1;
p->validTZ = p->tz!=0;
return 0;
}
PS Should probably add a test case to 'sqlite/test/date.test'. |
|
1856 |
code
|
active
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
2
|
3
|
SQLITE_OMIT_UTF16 breaks 'make test'
|
edit |
When compiling sqlite 3.3.6 with -DSQLITE_OMIT_UTF16 and you say 'make test' it fails:
make test
./libtool --mode=link gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -I. -I./src -DSQLITE_DEBUG=2 -DSQLITE_MEMDEBUG=2 -DSQLITE_OMIT_UTF16 -I/usr/include -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_CURSOR -DTCLSH=1 -DSQLITE_TEST=1 -DSQLITE_CRASH_TEST=1 \
-DTEMP_STORE=1 -o testfixture ./src/btree.c ./src/date.c ./src/func.c ./src/os.c ./src/os_unix.c ./src/os_win.c ./src/os_os2.c ./src/pager.c ./src/pragma.c ./src/printf.c ./src/test1.c ./src/test2.c ./src/test3.c ./src/test4.c ./src/test5.c ./src/test6.c ./src/test7.c ./src/test_async.c ./src/test_md5.c ./src/test_server.c ./src/utf.c ./src/util.c ./src/vdbe.c ./src/where.c ./src/tclsqlite.c \
libsqlite3.la -L/usr/lib -ltcl8.4 -ldl -lpthread -lieee -lm
gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -I. -I./src -DSQLITE_DEBUG=2 -DSQLITE_MEMDEBUG=2 -DSQLITE_OMIT_UTF16 -I/usr/include -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_CURSOR -DTCLSH=1 -DSQLITE_TEST=1 -DSQLITE_CRASH_TEST=1 -DTEMP_STORE=1 -o .libs/testfixture ./src/btree.c ./src/date.c ./src/func.c ./src/os.c ./src/os_unix.c ./src/os_win.c ./src/os_os2.c ./src/pager.c ./src/pragma.c ./src/printf.c ./src/test1.c ./src/test2.c ./src/test3.c ./src/test4.c ./src/test5.c ./src/test6.c ./src/test7.c ./src/test_async.c ./src/test_md5.c ./src/test_server.c ./src/utf.c ./src/util.c ./src/vdbe.c ./src/where.c ./src/tclsqlite.c ./.libs/libsqlite3.so -L/usr/lib -ltcl8.4 -ldl -lpthread -lieee -lm -Wl,--rpath -Wl,/home/cla/proj/caissadb/sqlite/sqlite/lib
./src/test1.c: In function 'Sqlitetest1_Init':
./src/test1.c:3742: error: 'unaligned_string_counter' undeclared (first use in this function)
./src/test1.c:3742: error: (Each undeclared identifier is reported only once
./src/test1.c:3742: error: for each function it appears in.)
make: *** [testfixture] Error 1
Maybe there is a '#ifndef SQLITE_OMIT_UTF16' / '#endif' needed around
Tcl_LinkVar(interp, "unaligned_string_counter",
(char*)&unaligned_string_counter, TCL_LINK_INT);
in Line 3742 in file src/test1.c?
Regards. |
|
1853 |
code
|
active
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
3
|
4
|
sqlite3_analyzer-3.3.4 integer overflows on large database
|
edit |
sqlite3_analyzer-3.3.4 reports senseless values (negative bytes and percents) for some fields of my 28 GB database:
Examples:
Bytes of storage consumed............. 291456000
Bytes of payload...................... -1382746251 -474.4%
Average payload per entry............. -3.80
(I'll attached the full output separatly.)
I'm using the pre-built Linux binary of sqlite3_analyzer-3.3.4 from the sqlite homepage. My system is
cn@jehova:~/misc/jibladze> uname -a
Linux jehova 2.6.13-15.10-smp #1 SMP Fri May 12 16:11:24 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux |
2006-Jun-18 17:28:20 by anonymous:
Here's the full output:
cn@jehova:~> du -ah /playground/cn/yacop-data/gfr/steenrod-5-E-1Rfull
28G /playground/cn/yacop-data/gfr/steenrod-5-E-1Rfull
cn@jehova:~> sqlite-analyzer /playground/cn/yacop-data/gfr/steenrod-5-E-1Rfull
Analyzing table chartinfo...
Analyzing table complog...
Analyzing table fragments...
Analyzing table generators...
Analyzing table header...
Analyzing table sqlite_master...
Analyzing table worklog...
Analyzing index sdegind of table fragments...
Analyzing index sqlite_autoindex_header_1 of table header...
Analyzing index sqlite_autoindex_worklog_1 of table worklog...
/** Disk-Space Utilization Report For /playground/cn/yacop-data/gfr/steenrod-5-E-1Rfull
*** As of 2006-Jun-18 18:55:01
Page size in bytes.................... 1024
Pages in the whole file (measured).... 28439973
Pages in the whole file (calculated).. 28439972
Pages that store data................. 28439972 100.000%
Pages on the freelist (per header).... 0 0.0%
Pages on the freelist (calculated).... 1 0.0%
Pages of auto-vacuum overhead......... 0 0.0%
Number of tables in the database...... 7
Number of indices..................... 3
Number of named indices............... 1
Automatically generated indices....... 2
Size of the file in bytes............. 29122532352
Bytes of user payload stored.......... -1818729787 -6.2%
*** Page counts for all tables with their indices ********************
FRAGMENTS............................. 28409448 99.89%
COMPLOG............................... 13559 0.048%
CHARTINFO............................. 11151 0.039%
GENERATORS............................ 5797 0.020%
WORKLOG............................... 10 0.0%
SQLITE_MASTER......................... 5 0.0%
HEADER................................ 2 0.0%
*** All tables and indices *******************************************
Percentage of total database.......... 100.000%
Number of entries..................... 728140955
Bytes of storage consumed............. -942239744
Bytes of payload...................... 1093495310 -116.1%
Average payload per entry............. 1.50
Average unused bytes per entry........ -2.73
Average fanout........................ 88.00
Maximum payload per entry............. 1157
Entries that use overflow............. 351 0.0%
Index pages used...................... 270372
Primary pages used.................... 28169249
Overflow pages used................... 351
Total pages used...................... 28439972
Unused bytes on index pages........... 32954241 11.9%
Unused bytes on primary pages......... -2022053395 165.815%
Unused bytes on overflow pages........ 37488 10.4%
Unused bytes on all pages............. -1989061666 211.099%
*** All tables *******************************************************
Percentage of total database.......... 84.3%
Number of entries..................... 364670985
Bytes of storage consumed............. -1233700864
Bytes of payload...................... -1818727376 147.420%
Average payload per entry............. -4.99
Average unused bytes per entry........ 4.87
Average fanout........................ 88.00
Maximum payload per entry............. 1157
Entries that use overflow............. 351 0.0%
Index pages used...................... 270372
Primary pages used.................... 23690315
Overflow pages used................... 351
Total pages used...................... 23961038
Unused bytes on index pages........... 32954241 11.9%
Unused bytes on primary pages......... 1742865277 -115.4%
Unused bytes on overflow pages........ 37488 10.4%
Unused bytes on all pages............. 1775857006 -143.9%
*** All indices ******************************************************
Percentage of total database.......... 15.7%
Number of entries..................... 363469970
Bytes of storage consumed............. 291461120
Bytes of payload...................... -1382744610 -474.4%
Average payload per entry............. -3.80
Average unused bytes per entry........ 1.46
Maximum payload per entry............. 17
Entries that use overflow............. 0 0.0%
Primary pages used.................... 4478934
Overflow pages used................... 0
Total pages used...................... 4478934
Unused bytes on primary pages......... 530048624 181.859%
Unused bytes on overflow pages........ 0
Unused bytes on all pages............. 530048624 181.859%
*** Table CHARTINFO **************************************************
Percentage of total database.......... 0.039%
Number of entries..................... 560603
Bytes of storage consumed............. 11418624
Bytes of payload...................... 7708145 67.5%
Average payload per entry............. 13.75
Average unused bytes per entry........ 0.31
Average fanout........................ 99.00
Maximum payload per entry............. 14
Entries that use overflow............. 0 0.0%
Index pages used...................... 112
Primary pages used.................... 11039
Overflow pages used................... 0
Total pages used...................... 11151
Unused bytes on index pages........... 14280 12.5%
Unused bytes on primary pages......... 160371 1.4%
Unused bytes on overflow pages........ 0
Unused bytes on all pages............. 174651 1.5%
*** Table COMPLOG ****************************************************
Percentage of total database.......... 0.048%
Number of entries..................... 322413
Bytes of storage consumed............. 13884416
Bytes of payload...................... 11350473 81.7%
Average payload per entry............. 35.20
Average unused bytes per entry........ 1.20
Average fanout........................ 98.00
Maximum payload per entry............. 45
Entries that use overflow............. 0 0.0%
Index pages used...................... 138
Primary pages used.................... 13421
Overflow pages used................... 0
Total pages used...................... 13559
Unused bytes on index pages........... 19411 13.7%
Unused bytes on primary pages......... 367295 2.7%
Unused bytes on overflow pages........ 0
Unused bytes on all pages............. 386706 2.8%
*** Table FRAGMENTS and all its indices ******************************
Percentage of total database.......... 99.89%
Number of entries..................... 726939530
Bytes of storage consumed............. -973496320
Bytes of payload...................... 1070540938 -110.0%
Average payload per entry............. 1.47
Average unused bytes per entry........ -2.74
Average fanout........................ 88.00
Maximum payload per entry............. 1157
Entries that use overflow............. 351 0.0%
Index pages used...................... 270061
Primary pages used.................... 28139036
Overflow pages used................... 351
Total pages used...................... 28409448
Unused bytes on index pages........... 32910337 11.9%
Unused bytes on primary pages......... -2022636857 161.759%
Unused bytes on overflow pages........ 37488 10.4%
Unused bytes on all pages............. -1989689032 204.386%
*** Table FRAGMENTS w/o any indices **********************************
Percentage of total database.......... 84.1%
Number of entries..................... 363469765
Bytes of storage consumed............. -1264952320
Bytes of payload...................... -1841680107 145.593%
Average payload per entry............. -5.07
Average unused bytes per entry........ 4.88
Average fanout........................ 88.00
Maximum payload per entry............. 1157
Entries that use overflow............. 351 0.0%
Index pages used...................... 270061
Primary pages used.................... 23660107
Overflow pages used................... 351
Total pages used...................... 23930519
Unused bytes on index pages........... 32910337 11.9%
Unused bytes on primary pages......... 1742284627 -113.0%
Unused bytes on overflow pages........ 37488 10.4%
Unused bytes on all pages............. 1775232452 -140.3%
*** Indices of table FRAGMENTS ***************************************
Percentage of total database.......... 15.7%
Number of entries..................... 363469765
Bytes of storage consumed............. 291456000
Bytes of payload...................... -1382746251 -474.4%
Average payload per entry............. -3.80
Average unused bytes per entry........ 1.46
Maximum payload per entry............. 9
Entries that use overflow............. 0 0.0%
Primary pages used.................... 4478929
Overflow pages used................... 0
Total pages used...................... 4478929
Unused bytes on primary pages......... 530045812 181.861%
Unused bytes on overflow pages........ 0
Unused bytes on all pages............. 530045812 181.861%
*** Table GENERATORS *************************************************
Percentage of total database.......... 0.020%
Number of entries..................... 317989
Bytes of storage consumed............. 5936128
Bytes of payload...................... 3889213 65.5%
Average payload per entry............. 12.23
Average unused bytes per entry........ 0.18
Average fanout........................ 98.00
Maximum payload per entry............. 14
Entries that use overflow............. 0 0.0%
Index pages used...................... 59
Primary pages used.................... 5738
Overflow pages used................... 0
Total pages used...................... 5797
Unused bytes on index pages........... 8350 13.8%
Unused bytes on primary pages......... 49171 0.84%
Unused bytes on overflow pages........ 0
Unused bytes on all pages............. 57521 0.97%
*** Table HEADER and all its indices *********************************
Percentage of total database.......... 0.0%
Number of entries..................... 10
Bytes of storage consumed............. 2048
Bytes of payload...................... 187 9.1%
Average payload per entry............. 18.70
Average unused bytes per entry........ 180.70
Maximum payload per entry............. 50
Entries that use overflow............. 0 0.0%
Primary pages used.................... 2
Overflow pages used................... 0
Total pages used...................... 2
Unused bytes on primary pages......... 1807 88.2%
Unused bytes on overflow pages........ 0
Unused bytes on all pages............. 1807 88.2%
*** Table HEADER w/o any indices *************************************
Percentage of total database.......... 0.0%
Number of entries..................... 5
Bytes of storage consumed............. 1024
Bytes of payload...................... 124 12.1%
Average payload per entry............. 24.80
Average unused bytes per entry........ 173.80
Maximum payload per entry............. 50
Entries that use overflow............. 0 0.0%
Primary pages used.................... 1
Overflow pages used................... 0
Total pages used...................... 1
Unused bytes on primary pages......... 869 84.9%
Unused bytes on overflow pages........ 0
Unused bytes on all pages............. 869 84.9%
*** Indices of table HEADER ******************************************
Percentage of total database.......... 0.0%
Number of entries..................... 5
Bytes of storage consumed............. 1024
Bytes of payload...................... 63 6.2%
Average payload per entry............. 12.60
Average unused bytes per entry........ 187.60
Maximum payload per entry............. 17
Entries that use overflow............. 0 0.0%
Primary pages used.................... 1
Overflow pages used................... 0
Total pages used...................... 1
Unused bytes on primary pages......... 938 91.6%
Unused bytes on overflow pages........ 0
Unused bytes on all pages............. 938 91.6%
*** Table SQLITE_MASTER **********************************************
Percentage of total database.......... 0.0%
Number of entries..................... 10
Bytes of storage consumed............. 5120
Bytes of payload...................... 2411 47.1%
Average payload per entry............. 241.10
Average unused bytes per entry........ 249.70
Average fanout........................ 4.00
Maximum payload per entry............. 483
Entries that use overflow............. 0 0.0%
Index pages used...................... 1
Primary pages used.................... 4
Overflow pages used................... 0
Total pages used...................... 5
Unused bytes on index pages........... 891 87.0%
Unused bytes on primary pages......... 1606 39.2%
Unused bytes on overflow pages........ 0
Unused bytes on all pages............. 2497 48.8%
*** Table WORKLOG and all its indices ********************************
Percentage of total database.......... 0.0%
Number of entries..................... 400
Bytes of storage consumed............. 10240
Bytes of payload...................... 3943 38.5%
Average payload per entry............. 9.86
Average unused bytes per entry........ 10.46
Average fanout........................ 5.00
Maximum payload per entry............. 13
Entries that use overflow............. 0 0.0%
Index pages used...................... 1
Primary pages used.................... 9
Overflow pages used................... 0
Total pages used...................... 10
Unused bytes on index pages........... 972 94.9%
Unused bytes on primary pages......... 3212 34.9%
Unused bytes on overflow pages........ 0
Unused bytes on all pages............. 4184 40.9%
*** Table WORKLOG w/o any indices ************************************
Percentage of total database.......... 0.0%
Number of entries..................... 200
Bytes of storage consumed............. 6144
Bytes of payload...................... 2365 38.5%
Average payload per entry............. 11.82
Average unused bytes per entry........ 11.55
Average fanout........................ 5.00
Maximum payload per entry............. 13
Entries that use overflow............. 0 0.0%
Index pages used...................... 1
Primary pages used.................... 5
Overflow pages used................... 0
Total pages used...................... 6
Unused bytes on index pages........... 972 94.9%
Unused bytes on primary pages......... 1338 26.1%
Unused bytes on overflow pages........ 0
Unused bytes on all pages............. 2310 37.6%
*** Indices of table WORKLOG *****************************************
Percentage of total database.......... 0.0%
Number of entries..................... 200
Bytes of storage consumed............. 4096
Bytes of payload...................... 1578 38.5%
Average payload per entry............. 7.89
Average unused bytes per entry........ 9.37
Maximum payload per entry............. 9
Entries that use overflow............. 0 0.0%
Primary pages used.................... 4
Overflow pages used................... 0
Total pages used...................... 4
Unused bytes on primary pages......... 1874 45.8%
Unused bytes on overflow pages........ 0
Unused bytes on all pages............. 1874 45.8%
*** Definitions ******************************************************
Page size in bytes
The number of bytes in a single page of the database file.
Usually 1024.
Number of pages in the whole file
The number of 1024-byte pages that go into forming the complete
database
Pages that store data
The number of pages that store data, either as primary B*Tree pages or
as overflow pages. The number at the right is the data pages divided by
the total number of pages in the file.
Pages on the freelist
The number of pages that are not currently in use but are reserved for
future use. The percentage at the right is the number of freelist pages
divided by the total number of pages in the file.
Pages of auto-vacuum overhead
The number of pages that store data used by the database to facilitate
auto-vacuum. This is zero for databases that do not support auto-vacuum.
Number of tables in the database
The number of tables in the database, including the SQLITE_MASTER table
used to store schema information.
Number of indices
The total number of indices in the database.
Number of named indices
The number of indices created using an explicit CREATE INDEX statement.
Automatically generated indices
The number of indices used to implement PRIMARY KEY or UNIQUE constraints
on tables.
Size of the file in bytes
The total amount of disk space used by the entire database files.
Bytes of user payload stored
The total number of bytes of user payload stored in the database. The
schema information in the SQLITE_MASTER table is not counted when
computing this number. The percentage at the right shows the payload
divided by the total file size.
Percentage of total database
The amount of the complete database file that is devoted to storing
information described by this category.
Number of entries
The total number of B-Tree key/value pairs stored under this category.
Bytes of storage consumed
The total amount of disk space required to store all B-Tree entries
under this category. The is the total number of pages used times
the pages size.
Bytes of payload
The amount of payload stored under this category. Payload is the data
part of table entries and the key part of index entries. The percentage
at the right is the bytes of payload divided by the bytes of storage
consumed.
Average payload per entry
The average amount of payload on each entry. This is just the bytes of
payload divided by the number of entries.
Average unused bytes per entry
The average amount of free space remaining on all pages under this
category on a per-entry basis. This is the number of unused bytes on
all pages divided by the number of entries.
Maximum payload per entry
The largest payload size of any entry.
Entries that use overflow
The number of entries that user one or more overflow pages.
Total pages used
This is the number of pages used to hold all information in the current
category. This is the sum of index, primary, and overflow pages.
Index pages used
This is the number of pages in a table B-tree that hold only key (rowid)
information and no data.
Primary pages used
This is the number of B-tree pages that hold both key and data.
Overflow pages used
The total number of overflow pages used for this category.
Unused bytes on index pages
The total number of bytes of unused space on all index pages. The
percentage at the right is the number of unused bytes divided by the
total number of bytes on index pages.
Unused bytes on primary pages
The total number of bytes of unused space on all primary pages. The
percentage at the right is the number of unused bytes divided by the
total number of bytes on primary pages.
Unused bytes on overflow pages
The total number of bytes of unused space on all overflow pages. The
percentage at the right is the number of unused bytes divided by the
total number of bytes on overflow pages.
Unused bytes on all pages
The total number of bytes of unused space on all primary and overflow
pages. The percentage at the right is the number of unused bytes
divided by the total number of bytes.
**********************************************************************
The entire text of this report can be sourced into any SQL database
engine for further analysis. All of the text above is an SQL comment.
The data used to generate this report follows:
*/
BEGIN;
CREATE TABLE space_used(
name clob, -- Name of a table or index in the database file
tblname clob, -- Name of associated table
is_index boolean, -- TRUE if it is an index, false for a table
nentry int, -- Number of entries in the BTree
leaf_entries int, -- Number of leaf entries
payload int, -- Total amount of data stored in this table or index
ovfl_payload int, -- Total amount of data stored on overflow pages
ovfl_cnt int, -- Number of entries that use overflow
mx_payload int, -- Maximum payload size
int_pages int, -- Number of interior pages used
leaf_pages int, -- Number of leaf pages used
ovfl_pages int, -- Number of overflow pages used
int_unused int, -- Number of unused bytes on interior pages
leaf_unused int, -- Number of unused bytes on primary pages
ovfl_unused int -- Number of unused bytes on overflow pages
);
INSERT INTO space_used VALUES('chartinfo','chartinfo',0,571641,560603,7708145,0,0,14,112,11039,0,14280,160371,0);
INSERT INTO space_used VALUES('complog','complog',0,335833,322413,11350473,0,0,45,138,13421,0,19411,367295,0);
INSERT INTO space_used VALUES('fragments','fragments',0,387129871,363469765,19633156373,320532,351,1157,270061,23660107,351,32910337,1742284627,37488);
INSERT INTO space_used VALUES('generators','generators',0,323726,317989,3889213,0,0,14,59,5738,0,8350,49171,0);
INSERT INTO space_used VALUES('header','header',0,5,5,124,0,0,50,0,1,0,0,869,0);
INSERT INTO space_used VALUES('sqlite_master','sqlite_master',0,13,10,2411,0,0,483,1,4,0,891,1606,0);
INSERT INTO space_used VALUES('worklog','worklog',0,204,200,2365,0,0,13,1,5,0,972,1338,0);
INSERT INTO space_used VALUES('sdegind','fragments',1,363469765,363469765,2912221045,0,0,9,0,4478929,0,0,530045812,0);
INSERT INTO space_used VALUES('sqlite_autoindex_header_1','header',1,5,5,63,0,0,17,0,1,0,0,938,0);
INSERT INTO space_used VALUES('sqlite_autoindex_worklog_1','worklog',1,200,200,1578,0,0,9,0,4,0,0,1874,0);
COMMIT;
|
|
1851 |
code
|
active
|
2006 Jun
|
anonymous
|
Unknown
|
2006 Jun
|
|
2
|
1
|
USE "ORDER BY" error on uClinux
|
edit |
when I use "ORDER BY" function in a "select" on uClinux 2.4.24,
I get a error:"SQL error or missing database" but the same program
run on windows or Linux OK. |
2006-Jun-16 11:20:15 by drh:
This is certainly a strange error. Combined with #1850, it
suggests a problem with your build, not a problem in SQLite.
I have no ability to use or run uCLinux. So if the error cannot
be reproduced on a desktop system, there is not much I can do
to address the problem. I am afraid you are on your own on
this one.
2006-Jun-19 03:12:31 by anonymous:
I'm just wondering that SQLite 3.2.8 runs on this uClinux system OK but SQLite 3.3.5 is error. |
|
1850 |
code
|
active
|
2006 Jun
|
anonymous
|
Unknown
|
2006 Jun
|
|
2
|
1
|
NUMERIC data type ERROE when read on uClinux
|
edit |
I have update some data of a tables's NUMERIC TYPE column on Windows or Linux,but when I use "select *......." to read on uClinux 2.4.24,I get the wrong value,example:the date I've written is 12.5,but readback is 2.3534826093695e -18.5(use the sqlite3_column_text API). I tried to get the value used "sqlite3_column_double" API,but the result is also wrong;
But when I update some data with this column on uClinux,I can read the data right! |
2006-Jun-16 01:53:24 by drh:
What CPU is this happening on?
SQLite assumes that floating point values are stored as
IEEE 64-bit floats in the same byte order as a 64-bit
integer. If your chip does not match this expectation,
then floating point won't work. |
|
1838 |
code
|
active
|
2006 Jun
|
anonymous
|
|
2006 Jun
|
|
5
|
5
|
test types3-1.3 fails on 64-bit Linux
|
edit |
I just compiled 3.3.6 on my 64-bit Linux system (OpenSuse 10, using a self-compiled Tcl 8.4.11) and got one failure from "make test":
types3-1.3...
Expected: [wideInt integer]
Got: [int integer]
This seems to be an error in the test suite itself: Changing
set V [expr {1+123456789012345}]
to
set V [expr {wide(1+123456789012345)}]
gets rid of the failure. |
|
1837 |
new
|
active
|
2006 Jun
|
anonymous
|
Pager
|
2006 Jun
|
|
4
|
4
|
Deadlock detection would be best reported using explicit error code.
|
edit |
As discussed in email (*), an explicit deadlock error code might be beneficial for an application to detect and recover from deadlock. Deadlock is different to SQLITE_BUSY, and should be notified as such (IMHO).
(*) http://www.mail-archive.com/sqlite-users%40sqlite.org/msg15979.html |
2006-Jun-12 11:23:49 by drh:
Changing the integer return code would be not be a backwards
compatible change, so that approach must be rejected. But we
will consider some mechanism to make it easier for programmers
to figure out that they are dealing with deadlock and not a
temporary delay.
2006-Jun-12 15:43:59 by anonymous:
Is there a fatal return code? If so, perhaps it could be overloaded with an additional function to determine if this 'fatal' error is actually a deadlock. Deadlocks are a common return code from almost every database I've ever programmed for. I am not sure how you can work around it otherwise. |
|
1833 |
doc
|
active
|
2006 Jun
|
anonymous
|
Unknown
|
2006 Jun
|
drh
|
4
|
3
|
PRAGMA legacy_file_format not documented
|
edit |
[2922]
introduces the legacy_file_format pragma, but it's not documented anywhere. At the very least, it should be mentioned in /sqlite/www/pragma.tcl, unless there's some better way to have a SQLite 3.3.5 (or so) generate databases usable by older versions of SQLite 3 (Debian stable, for example, ships with 3.2.1). |
|
1822 |
code
|
active
|
2006 May
|
anonymous
|
|
2006 Sep
|
|
3
|
3
|
Table Alias together with Subquery seems not to work proper
|
edit |
SELECT * FROM auth AS a LEFT JOIN (SELECT tm.team FROM teammbs AS tm) AS tr ON a.ateam=tr.team;
Error message: No such colum tr.team
But if I run the sub-query itself, it works fine.
Of course, this example can be expressed different, so no subquery required. But the complete expression looks like this:
SELECT a.auth, a.avalue FROM auth a LEFT JOIN (SELECT tm.member, tm.team FROM teammbs tm, team t WHERE tm.team=t.teamid AND (t._state<64 or (t._state>120 AND t._state<192)) AND (tm._state<64 or (tm._state>120 AND tm._state<192))) AS tr ON a.ateam=tr.team WHERE (a._state<64 or (a._state>120 AND a._state<192)) AND (a.auser='test' OR tr.member='test') ORDER BY a.auth;
It works fine with MySQL 5, and brings the same error on SQLite 3: No such column tr.team.
Any idea? |
|
1820 |
warn
|
active
|
2006 May
|
anonymous
|
TclLib
|
2006 Oct
|
anonymous
|
5
|
1
|
make: *** [tclsqlite.lo] Error 1
|
edit |
unding ReHatlinux9.0
$ make
..............
..............
./libtool --mode=compile gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -I. -I../sqlite-3.3.5/src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_CURSOR -c ../sqlite-3.3.5/src/tclsqlite.c
gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -I. -I../sqlite-3.3.5/src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_CURSOR -c ../sqlite-3.3.5/src/tclsqlite.c -fPIC -DPIC -o .libs/tclsqlite.o
../sqlite-3.3.5/src/tclsqlite.c: In function `DbUpdateHandler':
../sqlite-3.3.5/src/tclsqlite.c:333: warning: passing arg 3 of `Tcl_ListObjAppendElement' makes pointer from integer without a cast
../sqlite-3.3.5/src/tclsqlite.c: In function `tclSqlFunc':
../sqlite-3.3.5/src/tclsqlite.c:419: warning: passing arg 1 of `Tcl_NewByteArrayObj' discards qualifiers from pointer target type
../sqlite-3.3.5/src/tclsqlite.c:427: warning: assignment makes pointer from integer without a cast
../sqlite-3.3.5/src/tclsqlite.c:485: `Tcl_WideInt' undeclared (first use in this function)
../sqlite-3.3.5/src/tclsqlite.c:485: (Each undeclared identifier is reported only once
../sqlite-3.3.5/src/tclsqlite.c:485: for each function it appears in.)
../sqlite-3.3.5/src/tclsqlite.c:485: parse error before "v"
../sqlite-3.3.5/src/tclsqlite.c:486: `v' undeclared (first use in this function)
../sqlite-3.3.5/src/tclsqlite.c: In function `DbObjCmd':
../sqlite-3.3.5/src/tclsqlite.c:685: warning: passing arg 3 of `Tcl_GetIndexFromObj' from incompatible pointer type
../sqlite-3.3.5/src/tclsqlite.c:1309: warning: passing arg 2 of `Tcl_GetVar2Ex' discards qualifiers from pointer target type
../sqlite-3.3.5/src/tclsqlite.c:1331: `Tcl_WideInt' undeclared (first use in this function)
../sqlite-3.3.5/src/tclsqlite.c:1331: parse error before "v"
../sqlite-3.3.5/src/tclsqlite.c:1332: `v' undeclared (first use in this function)
../sqlite-3.3.5/src/tclsqlite.c:1382: warning: passing arg 1 of `Tcl_NewByteArrayObj' discards qualifiers from pointer target type
../sqlite-3.3.5/src/tclsqlite.c:1390: warning: assignment makes pointer from integer without a cast
../sqlite-3.3.5/src/tclsqlite.c:1838: warning: passing arg 3 of `Tcl_GetIndexFromObj' from incompatible pointer type
../sqlite-3.3.5/src/tclsqlite.c: In function `DbMain':
../sqlite-3.3.5/src/tclsqlite.c:2024: warning: passing arg 2 of `Tcl_CreateObjCommand' discards qualifiers from pointer target type
make: *** [tclsqlite.lo] Error 1 |
To solve this error, install ActiveTCL and then:
../sqlite-3.3.8/configure --with-tcl=/usr/local/ActiveTcl/lib
make |
|
1817 |
new
|
active
|
2006 May
|
anonymous
|
|
2006 Jun
|
|
1
|
2
|
Patch to enable SQLite again on OS/2
|
edit |
As we urgently need OS/2 support to be able to build Mozilla applications (Firefox, SeaMonkey, Thunderbird) we have to activate it again in SQLite CVS.
Daniel Lee Kruse ported the two C files with some input from Andy Willis and me (Peter Weilbacher). I hope this is the right way to go about this. |
The OS/2 changes from this and from follow-up ticket #1836 were checked in some time ago, so I am marking this fixed. |
|
1816 |
code
|
active
|
2006 May
|
anonymous
|
VDBE
|
2006 May
|
|
1
|
2
|
Database corruption with pragma auto_vacuum
|
edit |
We had a database created with PRAGMA auto_vacuum=1, that started returning the following message on a DELETE statement.
SQL error: database disk image is malformed
Running the VACUUM command and running the same DELETE statement succeeds.
Running PRAGMA integrity_check on the database (before the VACUUM command is issued) results in the following output:
sqlite> PRAGMA integrity_check;
*** in database main ***
Page 3393 is never used
Page 3398 is never used
Page 3400 is never used
Page 3401 is never used
Page 3402 is never used
Page 3405 is never used
Page 3406 is never used
sqlite> VACUUM;
sqlite> PRAGMA integrity_check;
ok
We tried as a temporary workaround, running PRAGMA integrity_check and, based on the result, deciding whether or not to run VACUUM, but this can consume too much time.
If needed, I can send a small database that exhibits this problem. |
2006-May-22 21:45:47 by drh:
The database is probably not helpful. What I need to know is:
- What sequence of SQL statements do you issue to cause this to occur?
- What operating system you are using.
- Is the application multi-threaded?
- Is the problem reproducible?
- Are you using a precompiled binary or did you compile it yourself?
- Does the problem go away if you turn off autovacuum?
2006-May-22 22:11:09 by anonymous:
- What sequence of SQL statements do you issue to cause this to occur?
It is unknown exactly what all of the the statements are leading up to the corruption. I can send the possible statements via private e-mail.
- What operating system you are using.
Windows XP Professional w/ Service Pack 2.
- Is the application multi-threaded?
Yes.
- Is the problem reproducible?
The corruption happens on occasion -- so far it is not known to be easily reproducable in a finite number of steps.
- Are you using a precompiled binary or did you compile it yourself?
Self-compiled library. When we use the database in our application, it is contained in abstracted classes with concurrency control.
- Does the problem go away if you turn off autovacuum?
We have not seen database corruption if auto_vacuum is off when the database is initially created. Is it possible to turn off auto vacuum after the database tables have been created (no when using pragma auto_vacuum, according to the docs)?
2006-May-22 22:28:46 by anonymous:
Rather than relying on trial and error to reproduce the bug, one technique the bug reporter might try to reproduce the problem is to take a snapshot of the database when it is in a known good state and save it somewhere and then have every process that comes into contact with the database file log every SQLite command (and pragma) complete with millisecond-resolution timestamp and process/thread ID as follows:
SELECT * FROM WHATEVER; -- 2006-05-23 14:44:45.237 PID 345 Thread 0
insert into blah values(3,4,5); -- 2006-05-23 14:50:15.345 PID 345 Thread 0
update foo set v=5 where y>4; -- 2006-05-23 15:05:12.930 PID 239 Thread 0
Should the problem happen again, each command could easily be replayed in an appropriate thread in the same order from the last known "good" state, greatly increasing the chances of repeating the bug. If repeating these commands does not lead to database corruption, it is fairly likely that the bug is in your multithreaded code, and not in SQLite.
Perhaps SQLite already has such a command tracing facility already. I don't know.
2006-May-22 22:42:04 by anonymous:
sqlite3_trace();
It passes all the caller-generated SQL statements to a callback (although it doesn't fill in bindings).
It also outputs a lot of "internal" SQL statements (VACUUM, for example, is a collection of operations on a temp table), but you should be able to recognize that stuff as something your app would never generate. |
|
1815 |
code
|
active
|
2006 May
|
anonymous
|
Parser
|
2006 May
|
|
3
|
3
|
Support of W3C-DTF(ISO8601 subset) is incomplete
|
edit |
"Z" of a time zone is ignored.
Reference: http://www.w3.org/TR/NOTE-datetime
CREATE table test(dt);
INSERT INTO "test" VALUES('2006-05-20T01:10:20+00:00');
INSERT INTO "test" VALUES('2006-05-20T01:10:20Z');
INSERT INTO "test" VALUES('2006-05-20T10:10:20+09:00');
SELECT datetime(dt) from test;
2006-05-20 01:10:20
2006-05-20 01:10:20
|
|
1814 |
new
|
active
|
2006 May
|
anonymous
|
|
2006 May
|
|
3
|
4
|
Autoconf support for MacOSX univeral binaries
|
edit |
SQLite is used widely on OS X. One problem for many OS X developers is preparing SQLite for universal binaries. I think there are a couple ways to solve this.
1. Add a new configure option --enable-macosx-universal to put the right compiler switches
2. Rework the configure makefiles so that you can override with the typical CFLAGS overrides as suggested by Apple in this article:
http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/compiling/chapter_4_section_3.html
I've attached a patch that will enable universal binaries if you chose the --enable-macosx-universal option, are on -*-darwin os, and have disabled shared libraries. This patch may not be exactly how you would want to integrate but it should serve as a good starting point.
I've tested in a PPC powermac, PPC powerbook, and Intel Mac mini.
--- sqlite-3.3.5/configure.ac 2006-04-03 13:16:01.000000000 -0700
+++ sqlite-3.3.x/configure.ac 2006-05-18 16:42:08.000000000 -0700
@@ -661,6 +661,32 @@
AC_CHECK_FUNC(fdatasync, [TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_FDATASYNC=1"])
+##########
+# Mac OS X Universal Binary support
+#
+AC_MSG_CHECKING([whether building for macosx])
+case "${build}" in
+ *-*-darwin* )
+ AC_ARG_ENABLE(macosx-universal,
+ AC_HELP_STRING([--enable-macosx-universal],[Enable macosx universal binaries]),,enable_macosxuniversal=no)
+ AC_MSG_CHECKING([whether building Universal Binaries])
+ if test "$enable_macosxuniversal" = "no"; then
+ AC_MSG_RESULT([no])
+ else
+ AC_MSG_CHECKING([if shared libraries are disabled])
+ if test "$enable_shared" = "no"; then
+ TARGET_CFLAGS="$TARGET_CFLAGS -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk"
+ AC_MSG_RESULT([yes (Universal Binaries enabled)])
+ else
+ AC_MSG_RESULT([no (Universal Binaries disabled)])
+ fi
+ fi
+ ;;
+ *)
+ AC_MSG_RESULT([no])
+esac
+
+
#########
# Put out accumulated miscellaneous LIBRARIES
#
|
|
1812 |
new
|
active
|
2006 May
|
anonymous
|
|
2006 May
|
|
4
|
1
|
alter table add column default current_timestamp
|
edit |
I wish I can alter my schema and add column with non-constant default.
How difficult is this compared with constant default? |
|
1811 |
doc
|
active
|
2006 May
|
anonymous
|
|
2006 May
|
|
5
|
3
|
how many open cursors are allowed for one application?
|
edit |
I would like to know, how many open cursors allowed at the same time. |
|
1810 |
new
|
active
|
2006 May
|
anonymous
|
|
2006 May
|
|
3
|
3
|
localtime() not threadsafe on UNIX
|
edit |
The following SQLite code from src/date.c is only guaranteed to function correctly with multiple threads on UNIX if the SQLite library is the only caller of localtime(). If an application that uses the SQLite library's date functions happens to call localtime() either directly or indirectly via another third party library, then localtime() can return a pointer to inconsistant data. localtime_r() should be use instead.
sqlite3OsEnterMutex();
pTm = localtime(&t);
y.Y = pTm->tm_year + 1900;
y.M = pTm->tm_mon + 1;
y.D = pTm->tm_mday;
y.h = pTm->tm_hour;
y.m = pTm->tm_min;
y.s = pTm->tm_sec;
sqlite3OsLeaveMutex();
Windows and some versions of UNIX may use thread-local storage to make localtime() threadsafe. This is not the case with Linux or any other OS that uses GNU libc:
/* Convert `time_t' to `struct tm' in local time zone.
Copyright (C) 1991,92,93,95,96,97,98,2002 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA. */
#include <time.h>
/* The C Standard says that localtime and gmtime return the same pointer. */
struct tm _tmbuf;
/* Return the `struct tm' representation of *T in local time,
using *TP to store the result. */
struct tm *
__localtime_r (t, tp)
const time_t *t;
struct tm *tp;
{
return __tz_convert (t, 1, tp);
}
weak_alias (__localtime_r, localtime_r)
/* Return the `struct tm' representation of *T in local time. */
struct tm *
localtime (t)
const time_t *t;
{
return __tz_convert (t, 1, &_tmbuf);
}
libc_hidden_def (localtime)
As an added benefit, you get better thread concurrency by getting rid of the sqlite3OsEnterMutex/sqlite3OsLeaveMutex when you use localtime_r. |
2006-May-15 12:53:42 by drh:
All of this is pointed out already in the documentation.
I will therefore change this ticket from a bug to an
enhancement request.
Note that we have considered the use of
localtime_r() in the past and rejected it since it will
lead to a significant complication of the build process. |
|
1809 |
code
|
active
|
2006 May
|
anonymous
|
CodeGen
|
2006 May
|
|
1
|
3
|
Huge slowdown/increased memory use when using GROUP BY on big dataset
|
edit |
This seemingly nonsensical query is a greatly reduced test case taken from several queries I use with SQLite 3.2.1. The real example joins various huge tables and much more complicated views. I'd like to upgrade beyond SQLite 3.2.1, but this is a showstopper.
It takes 13 seconds to run on SQLite 3.2.1 and uses just 1.2M of memory. With 3.3.5+ from CVS it takes 185 seconds and uses 230M of memory.
PRAGMA temp_store=MEMORY;
CREATE TABLE n1(a integer primary key);
INSERT INTO "n1" VALUES(1);
INSERT INTO "n1" VALUES(2);
INSERT INTO "n1" VALUES(3);
INSERT INTO "n1" VALUES(4);
INSERT INTO "n1" VALUES(5);
INSERT INTO "n1" VALUES(6);
INSERT INTO "n1" VALUES(7);
INSERT INTO "n1" VALUES(8);
INSERT INTO "n1" VALUES(9);
INSERT INTO "n1" VALUES(10);
INSERT INTO "n1" VALUES(11);
INSERT INTO "n1" VALUES(12);
INSERT INTO "n1" VALUES(13);
INSERT INTO "n1" VALUES(14);
INSERT INTO "n1" VALUES(15);
CREATE VIEW vu as select v3.a a, v5.a-v2.a*v7.a b
from n1 v1,n1 v2,n1 v3,n1 v4,n1 v5,n1 v6,n1 v7;
select a a, sum(b) T from vu where a=7 group by a;
It seems that SQLite 3.2.1 had a much more efficient GROUP BY algorithm that discarded unnecessary data as the view was traversed. |
2006-May-13 03:01:28 by anonymous:
Seeing as this ticket concerns the GROUP BY statement it would make more sense to have an example like this:
select a a, sum(b) T from vu where a<4 group by a;
But both queries exhibit the same slowdown and memory increase, in any event.
2006-May-13 15:09:39 by anonymous:
This GROUP BY slowdown/memory increase is not specific to VIEWs. I repeated the test against a comparably sized table with the same results. You'll see this effect for any SELECT operating on a large number of rows using GROUP BY.
2006-May-13 16:44:04 by anonymous:
The slowdown first appears in SQLite 3.2.6 in check-in [2662]
.
2006-May-24 13:19:29 by anonymous:
Here's an example to show an actual real-life use of GROUP BY in SQLite <= 3.2.5... Imagine performing mathematical operations on every combination of rows in several large tables for statistical analysis. The GROUP BY algorithm change in 3.2.6 now makes using GROUP BY on huge cross joins not usable for this purpose because it creates an intermediate result set of the product of all cross joins - several times larger than the size of the (already huge) database itself. Indexing is not useful in this case because there is nothing to index by design. All table rows must be traversed.
Older versions of SQLite performed this operation extremely efficiently because grouping took place in the main traversal loop. I would think that the old algorithm could be used, but instead of keeping the intermediate results in memory, an index and a table in temp store could be used. |
|
1804 |
code
|
active
|
2006 May
|
anonymous
|
Unknown
|
2006 May
|
|
4
|
3
|
Inconsistent value type returned by SUM when using a GROUP BY
|
edit |
Using a schema with test table:
CREATE TABLE Tbl1 (Key1 INTEGER, Num1 REAL)
And test data:
INSERT INTO Tbl1 (Key1,Num1) VALUES (1,5.0)
The query:
SELECT SUM(Tbl1.Num1) AS Num1Sum FROM Tbl1
Returns a column with the value type correctly reported as FLOAT (2).
However, the query:
SELECT Tbl1.Key1, SUM(Tbl1.Num1) AS Num1Sum FROM Tbl1 GROUP BY Tbl1.Key1
Returns two columns with value types INT (1) and INT (1).
The SUM function is returning a different value type for these two queries when both should return FLOAT (2).
This problem does not occur when any SUMmed value is not a whole number in which case, both queries return a value type of FLOAT for the SUM column.
I have applied the patch from Check In 3169 (relating to #1726 and #1755) to select.c but this does not resolve the problem. |
2006-May-10 09:34:11 by anonymous:
I should have added that this problem was seen in a Windows CE build running on Pocket PC 2003 and built using eMbedded Visual C++ 4.0.
2006-May-10 11:24:47 by anonymous:
I can confirm that exactly the same behaviour is exhibited when built under Windows XP (32-bit).
2006-May-10 12:40:21 by drh:
The answer you are getting back is exactly correct. Why do
you care what its datatype is? If you don't like the datatype,
cast it.
2006-May-10 13:42:14 by anonymous:
For maximum compatibility with other SQL databases, both
SELECT SUM(field2) FROM table
and
SELECT field1, SUM(field2) FROM table GROUP BY field1
should return the same data type for the SUM column. All other databases I have worked with do this. I understand that SQLite uses manifest typing but believe that it should be consistent.
The problem I have is that in my query function (which takes an SQL string and returns a page of results as a 2D array of objects), I don't know whether to use sqlite3_column_double or sqlite3_column_int because I don't know what the calling function requires this column to be returned as. I am currently using the sqlite3_column_decltype call to switch which sqlite3_column_* function I use (and falling back on sqlite3_column_type when the declared type is not known e.g. for aggregate functions like SUM). If the return type of SUM is unpredictable, my calling functions can't assume returned values will be of the same type as the field that is being SUMmed (as is the case with other SQL databases).
If you don't consider this to be a problem with SQLite, then I think my only option will be for calling functions to pass in an array of return types so that I always return objects of the correct type. |
|
1802 |
build
|
active
|
2006 May
|
anonymous
|
Unknown
|
2007 Mar
|
|
4
|
4
|
sqlite.pc needs -lrt on Solaris for fdatasync()
|
edit |
sqlite 3.3.x correctly checks for fdatasync() in -lrt during its configure, so it will make use of fdatasync() on Solaris.
The problem is that the sqlite.pc doesn't record that -lrt is needed when other packages wish to link with sqlite, so other packages will fail to link using the Libs: entry from sqlite.pc.
I think this could be fixed by just adding
@TARGET_LIBS@
to the end of the Libs: line in sqlite.pc.in, since TARGET_LIBS should only contain any necessary additional libraries. The later call to AC_SUBST(TARGET_LIBS) will then handle getting any libraries listed in TARGET_LIBS substituted in.
I will submit a patch, if you wish, if you think that's the correct fix. |
2007-Mar-30 05:37:44 by anonymous:
#1802, #2041 and #2270 are the same basic issue: librt should get linked into libsqlite3.so |
|
1801 |
new
|
active
|
2006 May
|
anonymous
|
Pager
|
2006 May
|
owensmk
|
5
|
4
|
Include Support for User-defined Lock Synchronization
|
edit |
SQLite uses a busy-wait model for locking. For high concurrency applications this can be become inefficient. I have written a patch for pager.c which introduces two hooks - lock() and unlock() - whereby the application can participate in locking/sychronization of connections. This can in some cases increase overall concurrency by an order of magnitude. The callback implementation is very similar to the busy handler.
All of the synchronization is implemented by the application. SQLite simply calls the hooks at the appropriate times, if they are registered. A full description of the patch is available at http://www.gintana.com/sqlite/. |
|
1799 |
code
|
active
|
2006 May
|
anonymous
|
Pager
|
2006 May
|
|
2
|
3
|
temp_store=MEMORY slower than FILE for large intermediate result sets
|
edit |
(This ticket was split off from #1790 because that ticket was becoming too broad.)
When temp_store=MEMORY it can negatively effect the performance of queries with large intermediate result sets generated from SELECTs of either file-based tables or memory-based tables. This is true when sufficient RAM is available to the SQLite process to completely hold the intermediate results in memory without swapping to disk.
In the example below, "big" is a file-based table in foo.db with 10 million rows. It was created with "create table big(x,y)".
# unmodified stock SQLite built from May 5 2006 CVS (after check-in [3178])
# compiled with default settings for SQLITE_DEFAULT_PAGE_SIZE and N_PG_HASH
$ time ./may5-sqlite/sqlite3 foo.db "PRAGMA temp_store = MEMORY; select x, y from big order by y, x" >/dev/null
real 13m23.828s
user 13m18.452s
sys 0m0.811s
# SQLite built from May 5 2006 CVS, but compiled with proposed change of
# SQLITE_DEFAULT_PAGE_SIZE set to 4096, and N_PG_HASH set to 16384
$ time ./may5-sqlite-hash-opt/sqlite3 foo.db "PRAGMA temp_store = MEMORY; select x, y from big order by y, x" >/dev/null
real 6m16.031s
user 6m13.108s
sys 0m0.811s
Compiling with SQLITE_DEFAULT_PAGE_SIZE = 1024, and N_PG_HASH = 32768 resulted in the same timing as the may5-sqlite-hash-opt test run above.
If temp_store=FILE (with default SQLite values for SQLITE_DEFAULT_PAGE_SIZE and N_PG_HASH), the timings are comparable to temp_store=MEMORY with SQLITE_DEFAULT_PAGE_SIZE=4096, and N_PG_HASH=16384.
Large intermediate results sets can cause SQLite to spend more than half of its CPU time in the function pager_lookup(). By increasing the value of N_PG_HASH and SQLITE_DEFAULT_PAGE_SIZE, the time spent in pager_lookup can be reduced to near zero, thus doubling performance in such cases.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
51.97 118.31 118.31 119658386 0.00 0.00 pager_lookup
4.36 128.25 9.94 4000009 0.00 0.06 sqlite3VdbeExec
3.06 135.21 6.96 315629923 0.00 0.00 parseCellPtr
3.05 142.16 6.95 171797186 0.00 0.00 sqlite3VdbeRecordCompare
2.67 148.22 6.07 12000005 0.00 0.01 sqlite3BtreeMoveto
2.14 153.10 4.88 343594380 0.00 0.00 sqlite3VdbeSerialGet
1.68 156.93 3.83 171797188 0.00 0.00 sqlite3MemCompare
1.63 160.65 3.72 77995781 0.00 0.00 sqlite3pager_get
1.60 164.29 3.65 169734946 0.00 0.00 sqlite3pager_unref
1.58 167.88 3.59 654100795 0.00 0.00 get2byte
|
2006-May-07 18:37:50 by anonymous:
Timings on same Windows machine with check-in [3180]
applied:
# FILE
$ time ./may7-sqlite/sqlite3 foo.db "PRAGMA temp_store = FILE; select x, y from big order by y, x" >/dev/null
real 5m7.157s
user 4m19.905s
sys 0m20.827s
# MEMORY
$ time ./may7-sqlite/sqlite3 foo.db "PRAGMA temp_store = MEMORY; select x, y from big order by y, x" >/dev/null
real 5m12.328s
user 5m9.781s
sys 0m0.984s
Much better.
temp_store=MEMORY is now competitive with FILE, although temp_store=FILE (when the OS is able to cache the file entirely in memory) is marginally faster.
I still think the MEMORY time can be reduced further by another 20 seconds judging by the sys time of 20.827s in the FILE test. The MEMORY subsystem of SQLite ought to have an advantage over the FILE subsystem because it does not incur any system call overhead. I'll see if a profile turns up anything obvious. |
|
1798 |
doc
|
active
|
2006 May
|
anonymous
|
|
2006 May
|
|
5
|
4
|
preprocessed is misspelled on download page
|
edit |
On the download page you'll find the text "proprocessed". |
|
1797 |
code
|
active
|
2006 May
|
anonymous
|
TclLib
|
2006 May
|
drh
|
1
|
1
|
COPY command doesn't work in tclsqlite 3.3.5
|
edit |
The COPY command doesn't seem to work in the tcl sqlite lib. This same script and datafile works in version 3.2.7.
load ./lib/libtclsqlite[info sharedlibextension]
sqlite MEMORY_DB :memory:
MEMORY_DB onecolumn "PRAGMA empty_result_callbacks=1"
puts [MEMORY_DB version]
MEMORY_DB eval "create table xyz (col1,col2)"
MEMORY_DB copy ignore win_pol /home/centadm/win_pol4.csv \t
MEMORY_DB eval "select * from xyz" sqlite_array {
puts "Here in the callback"
foreach sqlite_value $sqlite_array(*) {
puts "$sqlite_value $sqlite_array($sqlite_value)"
}
}
The data file win_pol4.csv consists of two columns, tab seperated.
DATA1 DATA2
And the output:
-bash-3.00$ tclsh test_sqlite.tcl
3.3.5
while executing
"MEMORY_DB copy ignore win_pol /home/centadm/win_pol4.csv \t"
(file "test_sqlite.tcl" line 5)
-bash-3.00$ pwd
/home/centadm
-bash-3.00$ ls -l /home/centadm/win_pol4.csv
-rw-r--r-- 1 centadm centadm 12 May 5 14:21 /home/centadm/win_pol4.csv
-bash-3.00$ more /home/centadm/win_pol4.csv
DATA1 DATA2
A TCL Error is returned from the copy command, no message tho. I have used catch to capture the command and verified that there is no data going into the table.
Also, PRAGMA empty_result_callbacks=1 still doesn't seem to work in the tcllib. If you catch the COPY command above, you still never see the "Here in the callback" message. |
2006-May-05 17:57:42 by anonymous:
Clarification:
The line
MEMORY_DB copy ignore win_pol /home/centadm/win_pol4.csv \t
should read
MEMORY_DB copy ignore xyz /home/centadm/win_pol4.csv \t
However the result is the same:
-bash-3.00$ tclsh test_sqlite.tcl
3.3.5
while executing
"MEMORY_DB copy ignore xyz /home/centadm/win_pol4.csv \t"
(file "test_sqlite.tcl" line 7)
-bash-3.00$
2006-May-05 19:46:56 by anonymous:
I have narrowed it down to the code here in tclsqlite.c:
zSql = sqlite3_mprintf("SELECT * FROM '%q'", zTable);
if( zSql==0 ){
Tcl_AppendResult(interp, "Error: no such table: ", zTable, 0);
return TCL_ERROR;
}
nByte = strlen(zSql);
rc = sqlite3_prepare(pDb->db, zSql, 0, &pStmt, 0);
sqlite3_free(zSql);
if( rc ){
Tcl_AppendResult(interp, "Error: ", sqlite3_errmsg(pDb->db), 0);
nCol = 0;
}else{
nCol = sqlite3_column_count(pStmt); <--- RETURNING 0 FOR COLUMN COUNT, HAVE VERIFIED TABLE HAS TWO COLUMNS
}
sqlite3_finalize(pStmt);
if( nCol==0 ) {
return TCL_ERROR; <--- NO ERROR MESSAGE RETURNED
}
2006-May-16 17:51:28 by anonymous:
I found the problem. The first sqlite3_prepare under DB_COPY should have -1 as it's third argument. When this was change from a 0 to -1 the copy command works in tclsqlite.
rc = sqlite3_prepare(pDb->db, zSql,0, &pStmt, 0);
should be
rc = sqlite3_prepare(pDb->db, zSql,-1, &pStmt, 0);
2006-May-16 18:01:11 by anonymous:
There is also another reference (the insert statement) to the prepare statement under DB_COPY that needs to change it's third argument from 0 to -1.
2006-Sep-27 16:24:53 by anonymous:
The same problem is present with version 3.3.7 over here. However, the indicated patch seem to work. |
|
1791 |
code
|
active
|
2006 May
|
anonymous
|
Unknown
|
2006 May
|
|
1
|
1
|
Native threads support for BeOS
|
edit |
BeOS ports lacks native thread support.
BeOS has very powerful but lightweight threading system, being throughout multithreaded, but it differs from posix-thread ideology, thus our pthreads implementation atm looks more like flacky workaround.
Ideally will be to have separate implementation for thread-support, like for Win16/32 versions.
At the moment this problem caused bustage of BeOS Mozilla port,
https://bugzilla.mozilla.org/show_bug.cgi?id=330340
nearest workaround might be pthreads usage, inspite its flackyness, but it also causes mess for Mozilla build/configure system, because for other parts in Mozilla we use nspr-threads, which, for BeOS, use native version |
2006-Oct-27 05:48:51 by anonymous:
BeOS locking extensions (using native bthreads) have been written and are included in the SQLite3 built into Mozilla Firefox. Is there some process wherein these changes might be incorporated into the SQLite tree?
2006-Oct-27 12:48:11 by anonymous:
Follow the example of OS/2 and propose a patch against the latest SQLite CVS that has proper #ifdef's around BeOS code so it won't break other platforms. Since you're probably the only one interested in this patch, you'll have to do the diffing/merging/testing work yourself.
2006-Nov-07 03:55:36 by anonymous:
Thanks for the advice. We've completed updates to code so it works with the sqlite 3.3.8 patches proposed for Firefox. Current implementation has a parallel os-specific file (os_beos.c). However, with the latest round of locking enhancements to os_unix.c, we're now wondering if it makes more sense to simply enhance this file to support BeOS locking. (yes, we. surprisingly, there is more than one BeOS user left on the planet.) :) |
|
1790 |
code
|
active
|
2006 May
|
anonymous
|
Pager
|
2006 May
|
|
3
|
3
|
:memory: performance difference between v2 and v3
|
edit |
Please see the following link for details: http://www.mail-archive.com/sqlite-users%40sqlite.org/msg14937.html
Possible fix?
RCS file: /sqlite/sqlite/src/pager.c,v
retrieving revision 1.266
diff -u -r1.266 pager.c
--- pager.c 7 Apr 2006 13:54:47 -0000 1.266
+++ pager.c 3 May 2006 19:02:17 -0000
@@ -1663,7 +1663,7 @@
pPager->memDb = memDb;
pPager->readOnly = readOnly;
/* pPager->needSync = 0; */
- pPager->noSync = pPager->tempFile || !useJournal;
+ pPager->noSync = pPager->tempFile || !pPager->useJournal;
pPager->fullSync = (pPager->noSync?0:1);
/* pPager->pFirst = 0; */
/* pPager->pFirstSynced = 0; */
|
2006-May-03 19:32:12 by drh:
The suggested change makes no difference in performance when
I try it.
2006-May-03 21:41:24 by anonymous:
If transactions are not used, 85% of the time of this memory database benchmark is spent in pager_get_all_dirty_pages().
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
85.25 31.20 31.20 100002 0.31 0.31 pager_get_all_dirty_pages
1.39 31.71 0.51 100011 0.01 0.20 sqlite3VdbeExec
1.17 32.14 0.43 10487713 0.00 0.00 parseCellPtr
0.63 32.37 0.23 12943618 0.00 0.00 sqlite3VdbeSerialGet
0.61 32.59 0.23 3432951 0.00 0.00 pager_lookup
0.52 32.78 0.19 4849544 0.00 0.00 sqlite3VdbeRecordCompare
0.44 32.95 0.16 400006 0.00 0.00 sqlite3BtreeMoveto
0.41 33.09 0.15 2064924 0.00 0.00 sqlite3pager_get
0.40 33.24 0.14 6471807 0.00 0.00 sqlite3MemCompare
0.06 31.25 100002/100002 sqlite3BtreeCommit [4]
[5] 85.6 0.06 31.25 100002 sqlite3pager_commit [5]
31.20 0.00 100002/100002 pager_get_all_dirty_pages [6]
0.05 0.00 389365/389365 clearHistory [65]
-----------------------------------------------
31.20 0.00 100002/100002 sqlite3pager_commit [5]
[6] 85.2 31.20 0.00 100002 pager_get_all_dirty_pages [6]
2006-May-03 21:51:30 by anonymous:
Stats with BEGIN/COMMIT enabled:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
11.88 0.34 0.34 4849544 0.00 0.00 sqlite3VdbeRecordCompare
8.16 0.56 0.23 10487713 0.00 0.00 parseCellPtr
7.80 0.79 0.22 12943618 0.00 0.00 sqlite3VdbeSerialGet
6.38 0.96 0.18 100013 0.00 0.03 sqlite3VdbeExec
4.26 1.08 0.12 29816 0.00 0.02 balance_nonroot
3.90 1.20 0.11 6471807 0.00 0.00 sqlite3MemCompare
3.19 1.28 0.09 1964925 0.00 0.00 sqlite3pager_get
3.19 1.38 0.09 400006 0.00 0.00 sqlite3BtreeMoveto
2.84 1.46 0.08 19170231 0.00 0.00 get2byte
2.66 1.53 0.07 700015 0.00 0.00 sqlite3VdbeSerialPut
2.13 1.59 0.06 600993 0.00 0.00 sqlite3Malloc
1.77 1.64 0.05 4400155 0.00 0.00 sqlite3pager_unref
1.77 1.69 0.05 3332952 0.00 0.00 pager_lookup
1.77 1.74 0.05 1418379 0.00 0.00 decodeFlags
1.77 1.79 0.05 1332302 0.00 0.00 initPage
1.60 1.83 0.04 5270826 0.00 0.00 findOverflowCell
1.42 1.88 0.04 12181181 0.00 0.00 findCell
1.42 1.92 0.04 4849549 0.00 0.00 fetchPayload
1.42 1.96 0.04 359548 0.00 0.00 insertCell
1.24 1.99 0.04 4896877 0.00 0.00 parseCell
1.06 2.02 0.03 5284245 0.00 0.00 cellSizePtr
1.06 2.05 0.03 3227291 0.00 0.00 binCollFunc
1.06 2.08 0.03 2616113 0.00 0.00 _page_ref
1.06 2.11 0.03 1368027 0.00 0.00 reparentPage
1.06 2.14 0.03 934205 0.00 0.00 sqlite3GenericMalloc
1.06 2.17 0.03 300010 0.00 0.00 sqlite3BtreeCursor
0.89 2.19 0.03 2536689 0.00 0.00 get4byte
0.89 2.22 0.03 1864920 0.00 0.00 getPage
...
0.00 2.82 0.00 3 0.00 0.00 pager_get_all_dirty_pages
0.00 0.00 3/3 sqlite3BtreeCommit [116]
[119] 0.0 0.00 0.00 3 sqlite3pager_commit [119]
0.00 0.00 6551/6551 clearHistory [118]
0.00 0.00 3/3 pager_get_all_dirty_pages [370]
-----------------------------------------------
0.00 0.00 3/3 sqlite3pager_commit [119]
[370] 0.0 0.00 0.00 3 pager_get_all_dirty_pages [370]
2006-May-03 22:27:35 by anonymous:
with the outer BEGIN/COMMIT disabled, the memory database benchmark stats:
static PgHdr *pager_get_all_dirty_pages(Pager *pPager){
// this point is reached 100,002 times
PgHdr *p, *pList;
pList = 0;
for(p=pPager->pAll; p; p=p->pNextAll){
// this point is reached 322,956,271 times
if( p->dirty ){
// this point is reached 389,365 times
p->pDirty = pList;
pList = p;
}
}
return pList;
}
2006-May-04 05:23:08 by anonymous:
This patch makes the test (with transaction) run 7% faster for gcc 3.4.4 with -O2. At -O3, gcc performs the inlining of these functions even without the inline hint, so this patch has no effect.
RCS file: /sqlite/sqlite/src/btree.c,v
retrieving revision 1.324
diff -u -3 -p -r1.324 btree.c
--- btree.c 4 Apr 2006 01:54:55 -0000 1.324
+++ btree.c 4 May 2006 05:12:35 -0000
@@ -439,17 +439,17 @@ static int checkReadLocks(BtShared*,Pgno
/*
** Read or write a two- and four-byte big-endian integer values.
*/
-static u32 get2byte(unsigned char *p){
+inline static u32 get2byte(unsigned char *p){
return (p[0]<<8) | p[1];
}
-static u32 get4byte(unsigned char *p){
+inline static u32 get4byte(unsigned char *p){
return (p[0]<<24) | (p[1]<<16) | (p[2]<<8) | p[3];
}
-static void put2byte(unsigned char *p, u32 v){
+inline static void put2byte(unsigned char *p, u32 v){
p[0] = v>>8;
p[1] = v;
}
-static void put4byte(unsigned char *p, u32 v){
+inline static void put4byte(unsigned char *p, u32 v){
p[0] = v>>24;
p[1] = v>>16;
p[2] = v>>8;
2006-May-04 19:44:57 by anonymous:
I just want to confirm that a file database is faster than a memory database for 3.3.5+. Are these numbers correct?
43,478 inserts/second best case for file for 3.3.5+ and 40,000 inserts/second best case for memory?
Even with the OS caching the entire database file entirely in RAM, this finding is quite surprising.
Test DB IDX TX RC 3.3.5+ 3.3.5 2.8.17
1 mem n y 1000000 40000 33333 76923
2 mem y y 1000000 27027 22727 58824
3 mem n n 1000000 35714 5263 83333
4 mem y n 1000000 24390 2778 62500
5 file n y 1000000 43478 35714 40000
6 file y y 1000000 28571 24390 23256
7 file n n 1000 11 11 13
8 file y n 1000 9 10 13
http://www.sqlite.org/cvstrac/attach_get/256/sqlite_speed.txt
2006-May-04 20:19:18 by anonymous:
I'm seeing slightly different results. The memory database using a transaction is (slightly) faster than the file-based database using a transaction.
Timings on 3.3.5+ on Windows XP, gcc 3.4.4 -O3 -fomit-frame-pointer
IDX TX # inserts wall time inserts/sec
--- --- --------- ---------- -----------
mem no no 100,000 4.8s 20,833
mem no yes 100,000 4.3s 23,255
file no yes 100,000 4.7s 21,276
file no no 1,000 99.8s 10
...things get worse for :memory: as you increase the number of inserts, while the file database numbers remain constant:
IDX TX # inserts wall time inserts/sec
--- --- --------- ---------- -----------
mem no yes 1,000,000 48.5s 20,638
mem no yes 2,000,000 118.6s 16,863
mem no yes 4,000,000 364.7s 10,967
file no yes 1,000,000 46.8s 21,354
file no yes 2,000,000 93.8s 21,321
file no yes 4,000,000 187.5s 21,333
Do Linux users get similar results?
Considering I have 512K CPU L2 cache, I wonder if there's some CPU cache effect going on here with the way the :memory: db is allocated.
2006-May-04 21:35:07 by anonymous:
It seems there is some quadratic behavior in pager_lookup (latest CVS). 52% of the time is spent in that function. Profile data from :memory: db, TX on, no IDX, 4 million inserts:
/*
** Find a page in the hash table given its page number. Return
** a pointer to the page or NULL if not found.
*/
static PgHdr *pager_lookup(Pager *pPager, Pgno pgno){
PgHdr *p = pPager->aHash[pager_hash(pgno)];
while( p && p->pgno!=pgno ){
p = p->pNextHash;
}
return p;
}
% cumulative self self total
time seconds seconds calls ms/call ms/call name
51.97 118.31 118.31 119658386 0.00 0.00 pager_lookup
4.36 128.25 9.94 4000009 0.00 0.06 sqlite3VdbeExec
3.06 135.21 6.96 315629923 0.00 0.00 parseCellPtr
3.05 142.16 6.95 171797186 0.00 0.00 sqlite3VdbeRecordCompare
2.67 148.22 6.07 12000005 0.00 0.01 sqlite3BtreeMoveto
2.14 153.10 4.88 343594380 0.00 0.00 sqlite3VdbeSerialGet
1.68 156.93 3.83 171797188 0.00 0.00 sqlite3MemCompare
1.63 160.65 3.72 77995781 0.00 0.00 sqlite3pager_get
1.60 164.29 3.65 169734946 0.00 0.00 sqlite3pager_unref
1.58 167.88 3.59 654100795 0.00 0.00 get2byte
1.30 170.84 2.95 973877 0.00 0.07 balance_nonroot
1.27 173.74 2.90 56939555 0.00 0.00 initPage
1.24 176.56 2.83 171797188 0.00 0.00 binCollFunc
0.93 178.69 2.12 386371475 0.00 0.00 findCell
0.86 180.65 1.96 96207437 0.00 0.00 pageDestructor
0.83 182.53 1.89 95976540 0.00 0.00 _page_ref
0.80 184.36 1.83 2708031 0.00 0.00 assemblePage
0.80 186.19 1.82 41662605 0.00 0.00 reparentPage
0.74 187.88 1.70 171797188 0.00 0.00 fetchPayload
0.73 189.55 1.67 73995778 0.00 0.00 getPage
0.67 191.07 1.52 59647596 0.00 0.00 decodeFlags
0.63 192.51 1.44 132945443 0.00 0.00 findOverflowCell
0.62 193.93 1.41 40148167 0.00 0.00 sqlite3PutVarint
0.59 195.27 1.34 134687272 0.00 0.00 releasePage
0.59 196.62 1.34 73764879 0.00 0.00 getAndInitPage
0.54 197.84 1.22 8000003 0.00 0.02 sqlite3BtreeInsert
0.52 199.01 1.18 60000030 0.00 0.00 sqlite3VdbeSerialType
0.52 200.19 1.18 24000011 0.00 0.00 moveToRoot
0.49 201.30 1.10 179797130 0.00 0.00 getCellInfo
0.43 202.28 0.98 9882306 0.00 0.00 insertCell
0.42 203.22 0.94 47288132 0.00 0.00 moveToChild
0.40 204.15 0.92 173434760 0.00 0.00 parseCell
0.40 205.06 0.91 95806930 0.00 0.00 get4byte
0.34 205.83 0.78 41662605 0.00 0.00 sqlite3pager_lookup
0.33 206.57 0.74 165099370 0.00 0.00 sqlite3MallocFailed
0.32 207.31 0.73 20000010 0.00 0.00 sqlite3VdbeSerialPut
0.31 208.02 0.71 8000015 0.00 0.00 sqlite3VdbeHalt
0.30 208.70 0.68 27052986 0.00 0.00 sqlite3GetVarint
0.28 209.33 0.63 174637767 0.00 0.00 put2byte
0.27 209.96 0.62 8000006 0.00 0.00 sqlite3BtreeCursor
0.26 210.54 0.59 8148152 0.00 0.00 fillInCell
0.25 211.12 0.57 3385610 0.00 0.01 reparentChildPages
0.25 211.69 0.57 16000006 0.00 0.00 checkReadLocks
0.22 212.19 0.51 48000093 0.00 0.00 sqlite3VdbeFreeCursor
0.22 212.69 0.50 133898861 0.00 0.00 cellSizePtr
0.22 213.19 0.50 24000010 0.00 0.00 popStack
0.20 213.65 0.46 50076560 0.00 0.00 sqlite3pager_ref
0.20 214.10 0.45 pager_reset
0.19 214.54 0.44 8000024 0.00 0.00 closeAllCursors
0.19 214.97 0.42 12000024 0.00 0.00 sqlite3VdbeMemMakeWriteable
0.18 215.38 0.41 32000052 0.00 0.00 sqlite3VdbeMemSetStr
0.18 215.78 0.40 11616158 0.00 0.00 allocateSpace
0.17 216.16 0.39 8000000 0.00 0.00 bindText
0.16 216.51 0.35 25098767 0.00 0.00 sqlite3MallocRaw
0.16 216.87 0.35 8000005 0.00 0.00 sqlite3BtreeCloseCursor
0.15 217.22 0.34 45560699 0.00 0.00 sqlite3FreeX
0.15 217.56 0.34 36000014 0.00 0.00 sqlite3VarintLen
0.15 217.90 0.34 36000009 0.00 0.00 sqlite3VdbeMemShallowCopy
0.14 218.22 0.33 47999969 0.00 0.00 sqlite3VdbeSerialTypeLen
0.14 218.54 0.33 4000008 0.00 0.00 sqlite3VdbeMakeReady
-----------------------------------------------
41.19 0.00 41662605/119658386 sqlite3pager_lookup [15]
77.12 0.00 77995781/119658386 sqlite3pager_get [8]
[5] 52.0 118.31 0.00 119658386 pager_lookup [5]
-----------------------------------------------
0.19 4.02 4000003/77995781 sqlite3BtreeGetMeta [28]
3.53 74.30 73995778/77995781 getPage [9]
[8] 36.0 3.72 78.31 77995781 sqlite3pager_get [8]
77.12 0.00 77995781/119658386 pager_lookup [5]
1.12 0.00 56939550/95976540 _page_ref [40]
0.03 0.00 230897/230897 page_remove_from_stmt_list [139]
0.03 0.00 230897/230897 makeClean [138]
0.01 0.00 230897/461804 sqlite3pager_pagecount [150]
0.00 0.00 230897/25098767 sqlite3MallocRaw [58]
-----------------------------------------------
1.82 44.94 41662605/41662605 reparentChildPages [13]
[14] 20.5 1.82 44.94 41662605 reparentPage [14]
0.78 41.96 41662605/41662605 sqlite3pager_lookup [15]
2.21 0.00 41672966/131189801 sqlite3pager_unref <cycle 2> [31]
0.00 0.00 93099/50076560 sqlite3pager_ref [75]
-----------------------------------------------
0.78 41.96 41662605/41662605 reparentPage [14]
[15] 18.8 0.78 41.96 41662605 sqlite3pager_lookup [15]
41.19 0.00 41662605/119658386 pager_lookup [5]
0.77 0.00 39036990/95976540 _page_ref [40]
-----------------------------------------------
0.77 0.00 39036990/95976540 sqlite3pager_lookup [15]
1.12 0.00 56939550/95976540 sqlite3pager_get [8]
[40] 0.8 1.89 0.00 95976540 _page_ref [40]
2006-May-04 21:41:37 by anonymous:
I guess increasing this array size is in order:
PgHdr *aHash[N_PG_HASH]; /* Hash table to map page number to PgHdr */
Too many hash collisions leading to growing linked lists in buckets.
Or perhaps pager_hash has to be replaced with a better hash function.
2006-May-04 22:04:47 by anonymous:
Increasing the size of N_PG_HASH to 8192 seems to help the "4 million insert in a transaction into a memory database" benchmark. It now runs in 203.5 seconds (19656 inserts/sec), as opposed to 364.7 seconds (10967 inserts/sec) previously. This is closer to the 187.5 seconds for the file-based database timing.
2006-May-04 22:13:16 by anonymous:
Increasing N_PG_HASH to 16384 yields 21,052 inserts/second for a 4 million insert single-transaction :memory: database no-index run. This is very close to the file database figure of 21,333 inserts/second.
2006-May-04 22:23:19 by anonymous:
Setting N_PG_HASH to 32768 yields 21,621 inserts/second in the 4M insert s in a single-transaction in a memory db test. This is marginally faster than the file based database timing. Increasing N_PG_HASH has diminishing returns after 16384.
2006-May-05 15:33:31 by anonymous:
You should get the same effect if you increase the page size instead of increasing the size of the hash table. With a larger page size there will be fewer pages to be managed by the hash table. This might be a better solution for many applications. A hash table with 32K entries occupies 128K of RAM, whether it is used or not.
2006-May-05 19:37:51 by anonymous:
128K of RAM when dealing with a 230M :memory: database is not terribly significant.
Here's the timings for various N_PG_HASH and SQLITE_DEFAULT_PAGE_SIZE values for 4 million inserts into a :memory: database in a single transaction:
N_PG_HASH SQLITE_DEFAULT_PAGE_SIZE inserts/sec
--------- ------------------------ -----------
16384 4096 21,622
32768 1024 21,621
8192 8192 20,513
4096 4096 20,101
4096 8192 19,417
2048 4096 16,878
2048 8192 16,598
2048 16384 15,038
2048 32768 13,937
2048 1024 10,782
So it seems the default values of N_PG_HASH and SQLITE_DEFAULT_PAGE_SIZE should be raised.
2006-May-05 21:34:01 by anonymous:
My point was that most users do not have 230 MB memory databases, so having a large hash table which is fixed at that size may be a burden. 128K for the hash table is a lot if you only have 128K in your memmory database.
I agree that increasing these values would seem to provide a substantial performance increase at little cost. I would suggest using the 4K hash table and the 4K page size. These values are close to the current values. Many users have reported a general speed improvement using a page size of 4K which matches the value used by WinXP (and think many other Os's as well) for disk I/O blocks. These values nearly double the insert rate over the current default values. The fixed size hash table only takes twice the space.
2006-May-06 14:54:32 by anonymous:
Memory page speed should be as fast as possible as it effects the general performance of SQLite. Perhaps a static hash table is not the best data structure here. Don't temp tables and intermediate select results on file-based tables use memory-based pages? Making memory page speed as fast as possible will improve overall SQLite performance whether you are using a file or memory based database. For example, when ordering result sets from a file-based database select this routine is used to generate the code:
static void pushOntoSorter(
Parse *pParse, /* Parser context */
ExprList *pOrderBy, /* The ORDER BY clause */
Select *pSelect /* The whole SELECT statement */
){
Vdbe *v = pParse->pVdbe;
sqlite3ExprCodeExprList(pParse, pOrderBy);
sqlite3VdbeAddOp(v, OP_Sequence, pOrderBy->iECursor, 0);
sqlite3VdbeAddOp(v, OP_Pull, pOrderBy->nExpr + 1, 0);
sqlite3VdbeAddOp(v, OP_MakeRecord, pOrderBy->nExpr + 2, 0);
sqlite3VdbeAddOp(v, OP_IdxInsert, pOrderBy->iECursor, 0);
For those of us who have very complicated nested sub-selects of file-based tables in many queries or even ORDER BYs on huge result sets, speeding up the memory page performance should be a performance win for SQLite in general.
2006-May-06 17:37:32 by anonymous:
The following test demonstrates that this memory page issue can greatly effect
the performance of queries against file-based tables if temp_store is set to MEMORY.
"big" is a file-based table in foo.db with 10 million rows. It was created with "create table big(x,y)".
# unmodified stock SQLite built from May 5 2006 CVS (after check-in [3178])
# compiled with default settings for SQLITE_DEFAULT_PAGE_SIZE and N_PG_HASH
$ time ./may5-sqlite/sqlite3 foo.db "PRAGMA temp_store = MEMORY; select x, y from big order by y, x" >/dev/null
real 13m23.828s
user 13m18.452s
sys 0m0.811s
# SQLite built from May 5 2006 CVS, but compiled with proposed change of
# SQLITE_DEFAULT_PAGE_SIZE set to 4096, and N_PG_HASH set to 16384
$ time ./may5-sqlite-hash-opt/sqlite3 foo.db "PRAGMA temp_store = MEMORY; select x, y from big order by y, x" >/dev/null
real 6m16.031s
user 6m13.108s
sys 0m0.811s
This is not even what I would consider to be a big table.
I should mention that compiling with SQLITE_DEFAULT_PAGE_SIZE = 1024, and N_PG_HASH = 32768 resulted in same timing as the may5-sqlite-hash-opt test run above. A pretty good return for an extra 126K.
2006-May-08 04:07:25 by anonymous:
You now get 20,725 inserts/second as of the latest check-in [3180]
for 4 million inserts into a :memory: database in a single transaction (using the default SQLITE_DEFAULT_PAGE_SIZE of 1K). This is nearly twice as fast as SQLite prior to the check-in [3180]
(10,782 inserts/second). However, it is 4% slower than the best timing prior to [3180]
when compiled with N_PG_HASH=32768 and SQLITE_DEFAULT_PAGE_SIZE=1024 which got 21,622 inserts/second (see table above). Increasing the size of SQLITE_DEFAULT_PAGE_SIZE with the latest CVS either has no effect or makes the memory insert benchmark timings slightly worse. |
|
1789 |
doc
|
active
|
2006 May
|
anonymous
|
Unknown
|
2006 May
|
drh
|
4
|
4
|
sqlite3_result_error() not adequately documented
|
edit |
Documentation for sqlite3_result_error() and friends says "operation of these routines is very similar to the operation of sqlite3_bind_blob() and its cousins", but none of the bind routines are really that similar. So it's not obvious from existing documentation whether the int argument is a string length or, say, a SQLITE_ error code, or a static/transient flag. A glance at /sqlite/src/func.c suggests that it's a static/transient flag, but it's not entirely clear (and if it is, why isn't the signature similar to sqlite3_result_text() ?)
sqlite3.h and capi3.html should probably have a little more discussion about returning error situations from user-defined functions.
c. |
|
1788 |
new
|
active
|
2006 Apr
|
anonymous
|
|
2006 Apr
|
|
5
|
5
|
memory allocator able to return with several allocated bloks at once
|
edit |
dlmalloc from Doug Lea (http://g.oswego.edu/dl/html/malloc.html) is public domain memory allocator written in C, replacing the malloc/free family. It is very fast (my microbenchmark had shown amortized allocation or deallocation time around 100 CPU cycles (Athlone XP), while default RTLs for VC++ or Borland were around 500x (really) slower, all three allocators were MT safe). dlmalloc is also used in Linux, I think, as a default allocator in libc.
dlmalloc has one more feature - it is able to allocate several blocks at once. This should be faster than chanin of malloc()s, has better cache locality and possible causes less of fragmentation.
Perhaps SQLite may employ such feature in some CPU bound place. |
2006-Apr-29 21:50:53 by anonymous:
Developers are free to link with whatever malloc lib they want. The coding of SQLite itself does not require a change if you happen to use Lea's malloc or Hoard or whatever.
2006-May-01 23:56:15 by anonymous:
That's not my point (I do use dlmalloc). The library may take advantage of ability to allocate several independent memory block during single call to the allocator, expecting it to be faster, having better cache locality and less fragmentation than sequence of calls. Hypothetical effect depend on how much and where SQLite is allocator-bound. |
|
1786 |
warn
|
active
|
2006 Apr
|
anonymous
|
|
2006 Apr
|
|
4
|
4
|
Yet another list of compiler warnings.
|
edit |
I compiled sqlite 3.3.5 from sqlite-source-3_3_5.zip using msvc 2005. Similar warnings show up with both gcc4 on mac (and I assume other platforms) and using sun studio on both solaris and linux. On msvc I set to the higest warning level, then disabled the following warnings which are in my opinion not real issues (4311;4312;4100;4210;4127). Most of the warnings follow the general form of int to smaller size int truncation without explicit cast, float or double sized type to int without explicit cast, or comparison of a signed to unsigned type. The following is my build log showing the warnings:
------ Rebuild All started: Project: sqlite, Configuration: Debug Win32 ------
Deleting intermediate and output files for project 'sqlite', configuration 'Debug|Win32'
Compiling...
alter.c
analyze.c
attach.c
c:\src\sqlite-source-3_3_5\attach.c(314) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
auth.c
btree.c
c:\src\sqlite-source-3_3_5\btree.c(449) : warning C4244: '=' : conversion from 'u32' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(450) : warning C4244: '=' : conversion from 'u32' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(453) : warning C4244: '=' : conversion from 'u32' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(454) : warning C4244: '=' : conversion from 'u32' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(455) : warning C4244: '=' : conversion from 'u32' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(456) : warning C4244: '=' : conversion from 'u32' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(538) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(540) : warning C4244: 'function' : conversion from 'i64' to 'u32', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(831) : warning C4389: '==' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(898) : warning C4018: '<' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(955) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(961) : warning C4244: '=' : conversion from 'u32' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(967) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(986) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(988) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(990) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1174) : warning C4389: '==' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(1226) : warning C4244: '-=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1239) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1303) : warning C4244: '+=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1316) : warning C4244: '-=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1342) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1343) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1344) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1349) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1350) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1353) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1354) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1356) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1405) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1407) : warning C4244: '=' : conversion from 'u32' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1435) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1460) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1465) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1467) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1468) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1661) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1663) : warning C4244: '=' : conversion from 'u32' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1692) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1865) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1867) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1949) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(1950) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(2056) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(2206) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(2267) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(2374) : warning C4389: '==' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(2397) : warning C4389: '==' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(2402) : warning C4018: '>' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(2402) : warning C4018: '<=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(2405) : warning C4389: '==' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(2418) : warning C4389: '==' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(2475) : warning C4389: '!=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(2814) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(2990) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(2996) : warning C4018: '>' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(3129) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(3136) : warning C4018: '>' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(3184) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(3448) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(3448) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(3450) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(3452) : warning C4244: 'function' : conversion from 'i64' to 'u32', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(3453) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(3453) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(3817) : warning C4018: '>' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(3854) : warning C4389: '!=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(3859) : warning C4389: '!=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(3869) : warning C4389: '!=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(3970) : warning C4018: '>' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(4029) : warning C4389: '==' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(4038) : warning C4244: '+=' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(4040) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(4117) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(4242) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(4259) : warning C4018: '<=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(4322) : warning C4244: '-=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(4331) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(4611) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(4695) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(5070) : warning C4018: '<=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(5499) : warning C4389: '==' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(5591) : warning C4018: '>' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(5725) : warning C4389: '==' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(5768) : warning C4389: '==' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(5774) : warning C4389: '!=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(5895) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(5896) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(5897) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(5898) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(5899) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(5905) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(5924) : warning C4244: '+=' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(5941) : warning C4244: '=' : conversion from 'u32' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(5948) : warning C4244: '=' : conversion from 'u32' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(5958) : warning C4244: '=' : conversion from 'u32' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(5962) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(6281) : warning C4244: '+=' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\btree.c(6444) : warning C4389: '!=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\btree.c(6448) : warning C4389: '==' : signed/unsigned mismatch
build.c
c:\src\sqlite-source-3_3_5\build.c(35) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(183) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(262) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(320) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(347) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(363) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(522) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(552) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(556) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(620) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(622) : warning C4389: '==' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\build.c(955) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(1127) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(1128) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(1216) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(1302) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(1319) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(1324) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(1330) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(1481) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(1531) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(1538) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(1555) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(1624) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(2036) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(2073) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(2081) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(2082) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(2083) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(2109) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(2342) : warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(2345) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(2354) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(2361) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(2382) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(2383) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(2429) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(2490) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\build.c(2873) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data
callback.c
c:\src\sqlite-source-3_3_5\callback.c(28) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\callback.c(59) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\callback.c(160) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\callback.c(301) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data
complete.c
date.c
c:\src\sqlite-source-3_3_5\date.c(204) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(233) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(234) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(339) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(340) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(343) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(344) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(345) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(346) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(360) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(361) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(363) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(407) : warning C4244: 'initializing' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(413) : warning C4244: '=' : conversion from 'double' to 'time_t', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(459) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(508) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(514) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(590) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(606) : warning C4244: '+=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(612) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(618) : warning C4244: '+=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(812) : warning C4244: 'initializing' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(813) : warning C4244: 'initializing' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(815) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(827) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(839) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(844) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(848) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\date.c(849) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data
delete.c
c:\src\sqlite-source-3_3_5\delete.c(71) : warning C4244: 'function' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\delete.c(165) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data
expr.c
c:\src\sqlite-source-3_3_5\expr.c(201) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\expr.c(346) : warning C4389: '==' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\expr.c(1158) : warning C4244: 'function' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\expr.c(1160) : warning C4244: 'function' : conversion from 'int' to 'u8', possible loss of data
func.c
c:\src\sqlite-source-3_3_5\func.c(221) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\func.c(234) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\func.c(866) : warning C4244: 'initializing' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\func.c(867) : warning C4244: 'initializing' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\func.c(868) : warning C4244: 'initializing' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\func.c(869) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\func.c(1052) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\func.c(1074) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\func.c(1096) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\func.c(1098) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
hash.c
c:\src\sqlite-source-3_3_5\hash.c(35) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\hash.c(39) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\hash.c(105) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
insert.c
c:\src\sqlite-source-3_3_5\insert.c(993) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\insert.c(996) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
legacy.c
main.c
c:\src\sqlite-source-3_3_5\main.c(413) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\main.c(446) : warning C4244: 'function' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\main.c(458) : warning C4244: 'function' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\main.c(773) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\main.c(783) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\main.c(787) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\main.c(1102) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
opcodes.c
os.c
os_unix.c
os_win.c
c:\src\sqlite-source-3_3_5\os_win.c(781) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\os_win.c(785) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\os_win.c(873) : warning C4244: 'initializing' : conversion from 'i64' to 'LONG', possible loss of data
c:\src\sqlite-source-3_3_5\os_win.c(874) : warning C4244: 'initializing' : conversion from 'i64' to 'LONG', possible loss of data
c:\src\sqlite-source-3_3_5\os_win.c(880) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\os_win.c(915) : warning C4244: 'initializing' : conversion from 'i64' to 'LONG', possible loss of data
c:\src\sqlite-source-3_3_5\os_win.c(919) : warning C4244: 'function' : conversion from 'i64' to 'LONG', possible loss of data
c:\src\sqlite-source-3_3_5\os_win.c(959) : warning C4244: '=' : conversion from 'int' to 'short', possible loss of data
c:\src\sqlite-source-3_3_5\os_win.c(1135) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\os_win.c(1199) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
Generating Code...
c:\src\sqlite-source-3_3_5\os_win.c(856) : warning C4701: potentially uninitialized local variable 'wrote' used
c:\src\sqlite-source-3_3_5\btree.c(5424) : warning C4701: potentially uninitialized local variable 'pNext' used
c:\src\sqlite-source-3_3_5\btree.c(5424) : warning C4701: potentially uninitialized local variable 'szNext' used
Compiling...
pager.c
c:\src\sqlite-source-3_3_5\pager.c(424) : warning C4244: '=' : conversion from 'u32' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(425) : warning C4244: '=' : conversion from 'u32' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(426) : warning C4244: '=' : conversion from 'u32' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(427) : warning C4244: '=' : conversion from 'u32' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(469) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(554) : warning C4018: '<' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\pager.c(750) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(972) : warning C4389: '==' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\pager.c(1075) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1080) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1289) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1297) : warning C4389: '==' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\pager.c(1307) : warning C4018: '<' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\pager.c(1423) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1440) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1498) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1499) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1500) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1617) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1647) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1648) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1662) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1663) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1664) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1666) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1799) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1805) : warning C4244: 'return' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(1890) : warning C4018: '<=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\pager.c(1927) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(2268) : warning C4018: '<=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\pager.c(2520) : warning C4389: '==' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\pager.c(2637) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\pager.c(3009) : warning C4389: '!=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\pager.c(3628) : warning C4018: '<=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\pager.c(3629) : warning C4389: '!=' : signed/unsigned mismatch
parse.c
parse.c(1309) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
parse.y(154) : warning C4244: '=' : conversion from '__w64 unsigned int' to 'unsigned int', possible loss of data
parse.y(229) : warning C4244: '=' : conversion from '__w64 int' to 'unsigned int', possible loss of data
parse.y(233) : warning C4244: '=' : conversion from '__w64 int' to 'unsigned int', possible loss of data
parse.y(379) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
parse.y(451) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
parse.y(532) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
parse.y(536) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
parse.y(871) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
parse.y(880) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
parse.y(919) : warning C4244: '=' : conversion from '__w64 unsigned int' to 'unsigned int', possible loss of data
parse.c(3271) : warning C4244: 'function' : conversion from 'int' to 'unsigned char', possible loss of data
parse.c(3282) : warning C4244: 'function' : conversion from 'int' to 'unsigned char', possible loss of data
pragma.c
c:\src\sqlite-source-3_3_5\pragma.c(49) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\pragma.c(118) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\pragma.c(443) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
prepare.c
c:\src\sqlite-source-3_3_5\prepare.c(274) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\prepare.c(577) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data
printf.c
c:\src\sqlite-source-3_3_5\printf.c(413) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\printf.c(426) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\printf.c(493) : warning C4244: '=' : conversion from 'int' to 'etByte', possible loss of data
c:\src\sqlite-source-3_3_5\printf.c(503) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\printf.c(517) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\printf.c(540) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\printf.c(543) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\printf.c(544) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\printf.c(551) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\printf.c(579) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\printf.c(581) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\printf.c(596) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\printf.c(620) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\printf.c(621) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\printf.c(644) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\printf.c(647) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
random.c
c:\src\sqlite-source-3_3_5\random.c(68) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\random.c(83) : warning C4244: '+=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\random.c(86) : warning C4244: '+=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\random.c(97) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
select.c
c:\src\sqlite-source-3_3_5\select.c(69) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\select.c(183) : warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data
c:\src\sqlite-source-3_3_5\select.c(557) : warning C4244: 'initializing' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\select.c(976) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\select.c(1004) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\select.c(1744) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\select.c(2231) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
shell.c
c:\src\sqlite-source-3_3_5\shell.c(387) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(407) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(409) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(586) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(587) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(738) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(838) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(880) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(941) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(961) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(1005) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(1035) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(1042) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(1056) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(1148) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(1236) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(1353) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(1472) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(1477) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\shell.c(1698) : warning C4013: 'access' undefined; assuming extern returning int
table.c
tokenize.c
trigger.c
c:\src\sqlite-source-3_3_5\trigger.c(113) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\trigger.c(172) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\trigger.c(260) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\trigger.c(265) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\trigger.c(454) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\trigger.c(476) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\trigger.c(540) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\trigger.c(631) : warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data
update.c
c:\src\sqlite-source-3_3_5\update.c(155) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data
utf.c
c:\src\sqlite-source-3_3_5\utf.c(326) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(326) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(326) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(326) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(326) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(326) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(333) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(333) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(333) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(333) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(333) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(333) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(336) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(353) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(501) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\utf.c(549) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data
util.c
c:\src\sqlite-source-3_3_5\util.c(724) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\util.c(756) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\util.c(870) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\util.c(1040) : warning C4244: '=' : conversion from 'long double' to 'double', possible loss of data
c:\src\sqlite-source-3_3_5\util.c(1041) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\util.c(1226) : warning C4244: '=' : conversion from 'u64' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\util.c(1229) : warning C4244: '=' : conversion from 'u64' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\util.c(1236) : warning C4244: '=' : conversion from 'u64' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\util.c(1355) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\util.c(1360) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
vacuum.c
c:\src\sqlite-source-3_3_5\vacuum.c(131) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
vdbe.c
c:\src\sqlite-source-3_3_5\vdbe.c(662) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(677) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(693) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(752) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(1601) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(1931) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(1957) : warning C4018: '<' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\vdbe.c(1997) : warning C4018: '>=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\vdbe.c(2004) : warning C4018: '>=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\vdbe.c(2013) : warning C4018: '<' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\vdbe.c(2028) : warning C4018: '<' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\vdbe.c(2312) : warning C4244: 'initializing' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(2313) : warning C4244: 'initializing' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(2450) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(2454) : warning C4244: '=' : conversion from 'i64' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(2554) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(2572) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(2614) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(2615) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(2628) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(2788) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(2805) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(3064) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(3445) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(3546) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(3595) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(3601) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(3641) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(3809) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(4118) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(4131) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbe.c(4514) : warning C4244: 'initializing' : conversion from 'int' to 'u8', possible loss of data
vdbeapi.c
c:\src\sqlite-source-3_3_5\vdbeapi.c(55) : warning C4244: 'return' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbeapi.c(201) : warning C4244: '=' : conversion from 'double' to 'i64', possible loss of data
c:\src\sqlite-source-3_3_5\vdbeapi.c(238) : warning C4244: '=' : conversion from 'double' to 'u64', possible loss of data
c:\src\sqlite-source-3_3_5\vdbeapi.c(650) : warning C4244: 'function' : conversion from 'int' to 'u8', possible loss of data
vdbeaux.c
c:\src\sqlite-source-3_3_5\vdbeaux.c(117) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\vdbeaux.c(482) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbeaux.c(527) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbeaux.c(531) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbeaux.c(564) : warning C4018: '<=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\vdbeaux.c(659) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbeaux.c(676) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbeaux.c(862) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbeaux.c(1034) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbeaux.c(1526) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data
c:\src\sqlite-source-3_3_5\vdbeaux.c(1595) : warning C4244: 'return' : conversion from 'i64' to 'u32', possible loss of data
c:\src\sqlite-source-3_3_5\vdbeaux.c(1651) : warning C4244: '=' : conversion from 'u64' to 'unsigned char', possible loss of data
c:\src\sqlite-source-3_3_5\vdbeaux.c(1813) : warning C4018: '>=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\vdbeaux.c(1815) : warning C4018: '>=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\vdbeaux.c(1841) : warning C4018: '<' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\vdbeaux.c(1843) : warning C4018: '<' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\vdbeaux.c(1887) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbeaux.c(1926) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data
vdbefifo.c
vdbemem.c
c:\src\sqlite-source-3_3_5\vdbemem.c(49) : warning C4244: 'function' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\vdbemem.c(194) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbemem.c(319) : warning C4244: '=' : conversion from 'double' to 'i64', possible loss of data
c:\src\sqlite-source-3_3_5\vdbemem.c(491) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
c:\src\sqlite-source-3_3_5\vdbemem.c(557) : warning C4244: '=' : conversion from 'const i64' to 'double', possible loss of data
c:\src\sqlite-source-3_3_5\vdbemem.c(562) : warning C4244: '=' : conversion from 'const i64' to 'double', possible loss of data
c:\src\sqlite-source-3_3_5\vdbemem.c(740) : warning C4018: '<=' : signed/unsigned mismatch
c:\src\sqlite-source-3_3_5\vdbemem.c(859) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
Generating Code...
c:\src\sqlite-source-3_3_5\select.c(3290) : warning C4701: potentially uninitialized local variable 'pTabList' used
c:\src\sqlite-source-3_3_5\select.c(3290) : warning C4701: potentially uninitialized local variable 'pEList' used
c:\src\sqlite-source-3_3_5\select.c(764) : warning C4701: potentially uninitialized local variable 'pseudoTab' used
c:\src\sqlite-source-3_3_5\printf.c(372) : warning C4701: potentially uninitialized local variable 'xtype' used
c:\src\sqlite-source-3_3_5\pager.c(1635) : warning C4701: potentially uninitialized local variable 'nameLen' used
Compiling...
where.c
c:\src\sqlite-source-3_3_5\where.c(227) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data
c:\src\sqlite-source-3_3_5\where.c(581) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data
c:\src\sqlite-source-3_3_5\where.c(582) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data
c:\src\sqlite-source-3_3_5\where.c(583) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\where.c(594) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data
c:\src\sqlite-source-3_3_5\where.c(604) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data
c:\src\sqlite-source-3_3_5\where.c(605) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data
c:\src\sqlite-source-3_3_5\where.c(608) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\where.c(630) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data
c:\src\sqlite-source-3_3_5\where.c(702) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data
c:\src\sqlite-source-3_3_5\where.c(743) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data
c:\src\sqlite-source-3_3_5\where.c(744) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data
c:\src\sqlite-source-3_3_5\where.c(1798) : warning C4244: 'function' : conversion from 'int' to 'u16', possible loss of data
c:\src\sqlite-source-3_3_5\where.c(1836) : warning C4244: 'function' : conversion from 'int' to 'u16', possible loss of data
Generating Code...
Creating library...
Build log was saved at "file://c:\src\sqlite-source-3_3_5\Debug\BuildLog.htm"
sqlite - 0 error(s), 451 warning(s)
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ========== |
|
1785 |
new
|
active
|
2006 Apr
|
anonymous
|
Shell
|
2006 Apr
|
|
4
|
3
|
rl_readline_name not set
|
edit |
Hi,
I have a conditionnal construct into my .inputrc:
$if sqlite
"S ": "select "
"L ": "like "
"II ": "insert into "
"U ": "update "
"V ": "view "
"(V ": "values (( "
"C ": "create "
"DR ": "drop "
"DI ": "distinct "
"F ": "from "
"W ": "where "
$endif
http://tiswww.tis.case.edu/~chet/readline/readline.html#SEC11
but it doesn't work with sqlite because rl_readline_name is not set in the source. I don't know about readline so i can't submit a patch.
regards |
|
1783 |
code
|
active
|
2006 Apr
|
anonymous
|
Unknown
|
2006 Apr
|
|
3
|
2
|
insert times increase with growing table size (when indexed)
|
edit |
The time needed to insert (or update) entries in a table with an index on one of the fields increases with the size of the table. For large databases inserts become very slow (which I suppose is likely the problem in ticket #1547). sqlite2 does not have this scaling problem on inserts. (Some of our queries do not scale on sqlite2 however, making its use also impossible.)
----- example code -----
package require dbi
package require dbi_sqlite3
dbi_sqlite3 db
db create /tmp/test.db
db open /tmp/test.db
db exec {create table "region" (
"id" integer not null primary key,
"start" integer,
"end" integer
)}
db exec {create index "region_index" on "region"("start")}
set num 1
for {set j 1} {$j < 20} {incr j} {
puts [lindex [time {
db begin
for {set i 1} {$i < 100000} {incr i} {
set s [expr {round(rand()*1000000)}]
set e [expr {round(rand()*1000000)}]
db exec {
insert into "region"("id","start","end")
values(?,?,?)
} $num $s $e
incr num
}
db commit
}] 0]
}
----- timings -----
5712186
6621934
9492997
13234978
14881322
19119044
25296162
26670866
35378986
35877042
44383517
54576510
53317621
63516664
76587973
73791188
88460462
101650099 |
|
1782 |
code
|
active
|
2006 Apr
|
anonymous
|
Unknown
|
2006 Apr
|
|
1
|
1
|
journal file exclusion
|
edit |
I have a long running process which opens a connection to a sqlite3 database, let's called it a.rdb. The connection is never closed during the life time of the process, and it's set to auto commit mode.
Now, if I delete a.rdb, and re-create it again(the long running process is still holding a fd to the deleted file at this point), the long running process is still creating a.rdb-journal from time to time. To make it worse, if at that time, I use the sqlite3 command line to modify the database when the file a.rdb-journal exists, the file in a.rdb-journal is also played back into the new a.rdb file, which doesn't seem to be the correct behavior.
Is it the intended design?
Thanks,
John |
|
1781 |
new
|
active
|
2006 Apr
|
anonymous
|
|
2006 Apr
|
|
3
|
5
|
Interleaved sqlite_step behaves inconsistently
|
edit |
I am not sure if 'interleaved' is the correct term to use, but I will explain what I am doing. I have listed this ticket type as "code defect", maybe "documentation" or "incident" would have been just as good.
The issue here is that the sqlite3_step may fail or succeed depending on an 'irrelevant' ORDER BY clause - atleast irrelevant to my results.
I have a loop that performs a query using sqlite3_step(q), inside the loop the data from the resuling row is used to update a table using sqlite3_step(u). I know that I do not have to do it this way, I could cache the query results in an array thus avoiding the interleaving, but I am not doing that here for the purpose of illustrating this issue.
If what I am doing is illegal, it should not return success by just adding an ORDER BY clause, I think it should fail and be documented as such. When it succeeds, the results are 100% perfect everytime, so I know SQLite can do this.
If what I am doing is legal, why does it fail without the ORDER BY clause.
Contrived code that would reproduce the issue:
sqlite3* db;
sqlite3_stmt* stmtquery;
sqlite3_stmt* stmtupdate;
const char queryok[] = "SELECT c1, c2 FROM t1 WHERE c2='row' ORDER BY c1;"; // ** ORDER BY c1
const char query[] = "SELECT c1, c2 FROM t1 WHERE c2='row';";
const char update[] = "UPDATE t1 SET c2='foo' WHERE c1=1;";
int ret = sqlite3_open( ":memory:", &db );
ret = sqlite3_exec( db, "create table t1 (c1, c2);", NULL, NULL, NULL );
ret = sqlite3_exec( db, "insert into t1 (c2) values ('row');", NULL, NULL, NULL );
ret = sqlite3_exec( db, "insert into t1 (c2) values ('row');", NULL, NULL, NULL );
// success using queryok (ORDER BY)
ret = sqlite3_prepare( db, queryok, -1, &stmtquery, NULL ); // SQLITE_OK
ret = sqlite3_step( stmtquery ); // SQLITE_ROW
ret = sqlite3_prepare( db, update, -1, &stmtupdate, NULL ); // SQLITE_OK
ret = sqlite3_step( stmtupdate ); // SQLITE_DONE
ret = sqlite3_finalize( stmtquery ); // SQLITE_OK
ret = sqlite3_finalize( stmtupdate ); // SQLITE_OK
// same code fails using query (no ORDER BY)
ret = sqlite3_prepare( db, query, -1, &stmtquery, NULL ); // SQLITE_OK
ret = sqlite3_step( stmtquery ); // SQLITE_ROW
ret = sqlite3_prepare( db, update, -1, &stmtupdate, NULL ); // SQLITE_OK
ret = sqlite3_step( stmtupdate ); // ** SQLITE_ERROR
ret = sqlite3_finalize( stmtquery ); // SQLITE_OK
ret = sqlite3_finalize( stmtupdate ); // ** SQLITE_LOCKED
// is this the only supported way?
ret = sqlite3_prepare( db, query, -1, &stmtquery, NULL ); // SQLITE_OK
ret = sqlite3_step( stmtquery ); // SQLITE_ROW
ret = sqlite3_finalize( stmtquery ); // SQLITE_OK
ret = sqlite3_prepare( db, update, -1, &stmtupdate, NULL ); // SQLITE_OK
ret = sqlite3_step( stmtupdate ); // SQLITE_DONE
ret = sqlite3_finalize( stmtquery ); // SQLITE_OK
ret = sqlite3_close( db );
|
2006-Apr-24 14:52:51 by anonymous:
While the order by clause may be superfluous to you, it isn't to sqlite. To implement order by, sqlite must have an index on the column used for ordering, in which case it can scan the table in the expected order, or it must scan the table entire table copying records to a temporary table which it then sorts into the required order. In the first case the table is still being read while it is being scanned, so it is open when the first result is retuned. In the second case, the table is read during the table scan, then closed. Only the temporary table is open for reading when the first result is returned.
A query without an order by clause always scans the table in the same manner as the first case. I.e. the table is open for reading when the first result is returned.
Sqlite does not allow a table to be updated while it is open for reading, hence you will get an error in the first case, or with a query that does not have an order by clause.
The fact that it works with the order by clause in your case is a side effect of the fact that sqlite had to create a temporary table to sort the results. The main table is closed, and it is returning results from the temporary table when you try to do the update. This would break if you were to add an index on the column that you are ordering by. |
|
1778 |
new
|
active
|
2006 Apr
|
anonymous
|
Parser
|
2007 Mar
|
|
1
|
3
|
stdev does not work, workaround not possible due to missing sqrt
|
edit |
It would be so great but it is too hard to use sqlite for any statistical purposes without having either an easy way of calculating standard deviation (stdev) nor any chance to create an ugly workaround because square root (sqrt) is also not working or missing. And even to square (sqr) values are resulting in long terms; but at least this is possible.
Is this because it is a lot of work to calculate the sum of values and sum of values squared at the same time during record traversal? Would this basic and standard function be not SQL conform?
Example:
select count(*), avg(Num), stdev(Num) from Population;
My workaround proposal is to use variance due to missing sqrt function:
select count(*), avg(Num) as mean,
(sum(Num*Num)/(count(*)-1)-sum(Num)*sum(Num)/count(*)/(count(*)-1)) as stdevsquared from Population;
Isn't this looking ugly and error prone? Can you imagine the performance if I have to calculate mean and stdev for 20 or more columns? |
2006-Apr-20 14:27:31 by anonymous:
It's pretty simple to add your own custom functions to SQLite. Edit sqlite/src/func.c and take a search for sumStep and sumFinalize for an example.
2006-Apr-20 18:11:06 by anonymous:
Index: src/func.c
===================================================================
RCS file: /sqlite/sqlite/src/func.c,v
retrieving revision 1.127
diff -u -r1.127 func.c
--- src/func.c 7 Apr 2006 13:26:43 -0000 1.127
+++ src/func.c 20 Apr 2006 18:10:08 -0000
@@ -20,7 +20,7 @@
*/
#include "sqliteInt.h"
#include <ctype.h>
-/* #include <math.h> */
+#include <math.h>
#include <stdlib.h>
#include <assert.h>
#include "vdbeInt.h"
@@ -114,6 +114,20 @@
}
/*
+** Implementation of the sqrt() function
+*/
+static void sqrtFunc(sqlite3_context *context, int argc, sqlite3_value **argv){
+ double rVal;
+ assert( argc==1 );
+ rVal = sqlite3_value_double(argv[0]);
+ if( rVal<0.0 ) {
+ sqlite3_result_error(context, "sqrt of negative", -1);
+ return;
+ }
+ sqlite3_result_double(context, sqrt(rVal));
+}
+
+/*
** Implementation of the abs() function
*/
static void absFunc(sqlite3_context *context, int argc, sqlite3_value **argv){
@@ -995,6 +1009,7 @@
#ifndef SQLITE_OMIT_UTF16
{ "substr", 3, 0, SQLITE_UTF16LE, 0, sqlite3utf16Substr },
#endif
+ { "sqrt", 1, 0, SQLITE_UTF8, 0, sqrtFunc },
{ "abs", 1, 0, SQLITE_UTF8, 0, absFunc },
{ "round", 1, 0, SQLITE_UTF8, 0, roundFunc },
{ "round", 2, 0, SQLITE_UTF8, 0, roundFunc },
2006-Jun-03 22:30:12 by anonymous:
VAR() and STDEV() aggregate functions that match Excel:
sqlite> select var(a), stdev(a) from (select 1 a union select 9 a);
32.0|5.65685424949238
Index: src/func.c
===================================================================
RCS file: /sqlite/sqlite/src/func.c,v
retrieving revision 1.128
diff -u -3 -p -r1.128 func.c
--- src/func.c 11 May 2006 13:25:39 -0000 1.128
+++ src/func.c 3 Jun 2006 22:25:46 -0000
@@ -20,7 +20,7 @@
*/
#include "sqliteInt.h"
#include <ctype.h>
-/* #include <math.h> */
+#include <math.h>
#include <stdlib.h>
#include <assert.h>
#include "vdbeInt.h"
@@ -820,6 +820,42 @@ static void test_error(
}
#endif /* SQLITE_TEST */
+typedef struct VarCtx VarCtx;
+struct VarCtx {
+ i64 n;
+ double sumw;
+ double m;
+ double t;
+};
+static void varStep(sqlite3_context *context, int argc, sqlite3_value **argv){
+ VarCtx *p;
+ double xi, q, temp, r;
+ assert( argc==1 );
+ p = sqlite3_aggregate_context(context, sizeof(*p));
+ xi = sqlite3_value_double(argv[0]);
+ q = xi - p->m;
+ temp = p->sumw + 1;
+ r = q / temp;
+ p->m += r;
+ p->t += r * p->sumw * q;
+ p->sumw = temp;
+ ++p->n;
+}
+static void varFinalize(sqlite3_context *context){
+ VarCtx *p = sqlite3_aggregate_context(context, 0);
+ if( p && p->n>1 ){
+ double s2 = p->t * p->n / ((p->n - 1) * p->sumw);
+ sqlite3_result_double(context, s2);
+ }
+}
+static void stdevFinalize(sqlite3_context *context){
+ VarCtx *p = sqlite3_aggregate_context(context, 0);
+ if( p && p->n>1 ){
+ double s2 = p->t * p->n / ((p->n - 1) * p->sumw);
+ sqlite3_result_double(context, sqrt(s2));
+ }
+}
+
/*
** An instance of the following structure holds the context of a
** sum() or avg() aggregate computation.
@@ -1026,6 +1062,8 @@ void sqlite3RegisterBuiltinFunctions(sql
{ "max", 1, 2, 1, minmaxStep, minMaxFinalize },
{ "sum", 1, 0, 0, sumStep, sumFinalize },
{ "total", 1, 0, 0, sumStep, totalFinalize },
+ { "var", 1, 0, 0, varStep, varFinalize },
+ { "stdev", 1, 0, 0, varStep, stdevFinalize },
{ "avg", 1, 0, 0, sumStep, avgFinalize },
{ "count", 0, 0, 0, countStep, countFinalize },
{ "count", 1, 0, 0, countStep, countFinalize },
2007-Mar-29 08:18:34 by anonymous:
Is it still valid with 3.3.13 that sqrt function is not available from within SQLite? or stdev? Or does there exist anywhere in the www an extension library already (for windows and linux) to enhance SQLite 3.3.13 for mathematical/statistical functions?
Or is it the standard that everybody has to develop her/his own extensions for basic functionality?
I do not know if this is a bug/lack of function or if it's my fault to find the right way of usage. Please help!
From my point of view some few statistical functions would increase the usability and value of the SQLite database very much. |
|
1777 |
code
|
active
|
2006 Apr
|
anonymous
|
|
2006 Apr
|
|
2
|
4
|
Cygwin should be OS_UNIX target, not OS_WIN
|
edit |
Cygwin, a UNIX emulation layer on Windows, should be an OS_UNIX target (not an OS_WIN target) in order to use the UNIX filesystem calls and paths. The Cygwin GNU debugger gdb will not work correctly with a Cygwin sqlite3 built with -DOS_WIN=1 (trust me - I wasted an hour on determining why database files cannot open under cygwin/gdb).
MinGW, on the other hand should remain an OS_WIN target.
All references to cygwin should be removed from os.h, and configure.ac should have something like this pseudo-code:
if test "$CYGWIN" = "yes"; then
OS_UNIX=1
OS_WIN=0
tclsubdir=unix
TARGET_CFLAGS="$TARGET_CFLAGS -DOS_UNIX=1"
elif test "$TARGET_EXEEXT" = ".exe"; then
OS_UNIX=0
OS_WIN=1
tclsubdir=win
TARGET_CFLAGS="$TARGET_CFLAGS -DOS_WIN=1"
else
OS_UNIX=1
OS_WIN=0
tclsubdir=unix
TARGET_CFLAGS="$TARGET_CFLAGS -DOS_UNIX=1"
fi
Once sqlite3 thinks it is an OS_UNIX library under cygwin, all the strange problems I've been experiencing go away. |
2006-Apr-19 12:07:34 by anonymous:
Although gdb sqlite3.exe debugging is functional and cygwin file paths work better with OS_UNIX=1, it seems that some cygwin file locking primitives only work with OS_WIN=1. |
|
1775 |
code
|
active
|
2006 Apr
|
anonymous
|
Unknown
|
2006 Apr
|
|
1
|
1
|
strftime() not working in Windows Mobile 2005
|
edit |
The strftime() is not working in windows mobile 2005 pocket pc. I am using the beta version of visual studio 2005. |
2006-Apr-17 13:10:20 by anonymous:
Is it a compile/link problem or a runtime problem?
2006-Apr-18 07:26:08 by anonymous:
It's a runtime problem. I am not able to get the dates formated using strftime(). datetime(), date() and time() are working properly. |
|
1772 |
new
|
active
|
2006 Apr
|
anonymous
|
TclLib
|
2006 Apr
|
|
5
|
5
|
db eval {QUERY} { do something } ELSE { there was no match }
|
edit |
When you add a script to execute the eval function always returns empty string. so something like
if {[db eval {SELECT * FROM TABLE WHERE time >= $timestamp} {
puts "Found: $value1 $value2 $value3"
}] == ""} {
puts "Nothing found"
}
will not work. Thinking about that i came to the conclusion that changing the eval command to support something to execute when no match was found would be quiet handy:
db eval {SELECT * FROM TABLE WHERE time >= $timestamp} {
puts "Found: $value1 $value2 $value3"
} {
puts "Nothing Found."
} |
|
1770 |
new
|
active
|
2006 Apr
|
anonymous
|
|
2006 Apr
|
|
5
|
4
|
Request for expanded DELETE USING keyword like PostgreSQL
|
edit |
It would be nice is SQLite supported the new USING clause or allowed other tables to be referenced in delete statements.
That way this would short test case would work:
create table foo(value text);
create table bar(value text);
insert into foo values('red');
insert into foo values('blue');
insert into bar values('red');
delete from foo using bar where foo.value = bar.value;
select * from foo
Would only return 1 row containing "blue" as its value.
For more information see the USING clause notes at:
http://www.postgresql.org/docs/8.1/interactive/sql-delete.html
Thanks. |
2006-Apr-12 17:40:48 by drh:
Do it this way:
DELETE FROM foo WHERE rowid IN
(SELECT foo.rowid FROM foo JOIN bar USING(value))
2006-Apr-12 17:50:08 by anonymous:
Thanks drh! You rock. |
|
1769 |
new
|
active
|
2006 Apr
|
anonymous
|
Unknown
|
2006 Apr
|
drh
|
5
|
5
|
Is there any djgpp port for 3-3-5
|
edit |
yeah, us got 3.0.7 port.
while 3.3.5 is far far away from that.
me have tried port meself, dispointed.
did any lord get spare?
using 2.8.16 port |
|
1762 |
build
|
active
|
2006 Apr
|
anonymous
|
Unknown
|
2006 Apr
|
|
3
|
4
|
sqlite3_clear_bindings not exported in windows dll
|
edit |
While documented sqlite3_clear_bindings is not exported in the def file for the windows dll. Therefore it is unable to link. |
|
1754 |
code
|
active
|
2006 Apr
|
anonymous
|
Pager
|
2006 Apr
|
anonymous
|
2
|
2
|
Version 3.3.5 error if SQLITE_OMIT_MEMORYDB is defined
|
edit |
My solution is to move the following code to de line the the syncJournal is "forwarded" at line 1809.
#ifndef SQLITE_OMIT_MEMORYDB
/*
** Clear a PgHistory block
*/
static void clearHistory(PgHistory *pHist){
sqliteFree(pHist->pOrig);
sqliteFree(pHist->pStmt);
pHist->pOrig = 0;
pHist->pStmt = 0;
}
#else
#define clearHistory(x)
#endif
|
|
1747 |
new
|
active
|
2006 Apr
|
anonymous
|
Unknown
|
2006 Apr
|
|
4
|
4
|
Non descriptive error message
|
edit |
When operating on closed db handle, sqlite3_exec returns SQLITE_MISUSE, which IMO is quite fair name. But when using:
if( rc!=SQLITE_OK ){
fprintf(stderr, "SQL error: (%d) %s\n",rc, zErrMsg);
sqlite3_close(db);
exit (1);
}
Message printed is as follows:
SQL error: (21) library routine called out of sequence
This is a bit misleadig when starting debuging SQLite application. |
|
1743 |
code
|
active
|
2006 Mar
|
anonymous
|
Parser
|
2006 Mar
|
|
3
|
3
|
A very very deep IN statement failure
|
edit |
Ok the problem is simple. I need to create a VERY VERY large IN statement. The problem is SQLite seems to have a limit on either query length or depth of an IN statement. Here is my example
See attached 1
That would be a 2 levels deep In statement. I can only get up to 9 with SQLite but I need to get to 20. Since it works for 9 I can only assume that my 10 is correct even though the error is a syntax error. Below is the code that creates the select statement.
See attached 4
Attachment 2 and 3 show a 9 and 10 level respectively.
Thanks for your help |
2006-Mar-30 21:30:51 by anonymous:
Select "Wow !!" from "Wow !!"
:-)
Maybe VIEWs could help ??
2006-Mar-30 21:37:50 by anonymous:
This may be a work around for your problem. From looking at your sample SQL:
SELECT * FROM xs
where classname like '%Bonus_Pay_Weight_Entry%'
or classname in
(
select parentname from xs
where classname in
(
select parentname from xs
where classname in
(
select parentname from xs
where classname like '%Bonus_Pay_Weight_Entry%'
)
)
)
or classname in
(
select parentname from xs
where classname in
(
select parentname from xs
where classname like '%Bonus_Pay_Weight_Entry%'
)
)
or classname in
(
select parentname from xs
where classname like '%Bonus_Pay_Weight_Entry%'
)
;
It seems you are trying to find all the parent classes of all the classes with this magic string in their name. If so, I think there is another way to do this. Instead of using a C program to build a huge SQL statement and then collect the results, use a different C program to execute a series of small SQL commands that generate the same result set.
The following series of SQL statements should generate the same set of results.
create temp table xt as
select classname from xs
where classname like '%Bonus_Pay_Weight_Entry%';
insert into xt select parentname from xs where classname in xt and parentname not in xt;
select changes();
insert into xt select parentname from xs where classname in xt and parentname not in xt;
select changes();
insert into xt select parentname from xs where classname in xt and parentname not in xt;
select changes();
... repeat until changes returns zero
select * from xs where classname in xt;
drop table xt;
This can be execute by code that looks something like the following pseudo-C code.
string sql;
sql = "create temp table xt as select classname from xs where classname like '%Bonus_Pay_Weight_Entry%'";
sqlite3_exec(db, sql);
sql = "insert into xt select parentname from xs where classname in xt and parentname not in xt";
sqlite3_stmt* extend = sqlite3_prepare(db, sql);
sql = "select changes()"
sqlite3_stmt* check = sqlite3_prepare(db, sql);
int changes = 0;
do {
sqlite3_step(extend);
sqlite3_reset(extend);
sqlite3_step(check);
changes = sqlite3_column_int(check, 0);
sqlite3_reset(check);
} while (changes > 0);
sqlite3_finalize(extend);
sqlite3_finalize(check);
sql = "select * from xs where classname in xt";
sqlite3_stmt* get = sqlite3_prepare(db, sql);
int rc;
do {
rc = sqlite3_step(get);
if (rc == SQLITE_DONE) break;
// process a result row
} while (1);
sqlite3_finalize(get);
sql = "drop table xt";
sqlite3_exec(db, sql);
2006-Apr-05 17:25:30 by anonymous:
Where did you find the select changes(); function? I would like to find all the functions that SQLite has and their uses.
(and no I dont want the C API. I found that)
2006-Apr-05 18:53:08 by anonymous:
There is no complete listing of the functions in the documentation that I am aware of. Most are documented on this page http://www.sqlite.org/lang_expr.html but some are missing.
The ultimate list of the predefined functions is the source file func.c which implements all the functions. You can view it here http://www.sqlite.org/cvstrac/rlog?f=sqlite/src/func.c |
|
1742 |
code
|
active
|
2006 Mar
|
anonymous
|
Unknown
|
2006 Mar
|
drh
|
2
|
3
|
ORDER BY on more than one column causes a big slowdown
|
edit |
Put simply, any query which contains an ORDER BY clause that sorts on more than one column incurs a strange slowdown.
Running SQLite 3.3.4 on WindowsXPSP2 and on OS X 1.4.5, the behavior is similar; if the ORDER BY clause contains one column, the query is very fast; on two or more columns, it is terribly slow. |
2006-Mar-28 23:58:15 by anonymous:
Also worth noting that this behavior seems to start with SQLite 3.3.x; earlier versions of SQLite handle multiple ORDER BY columns much faster.
2006-Mar-29 01:22:11 by anonymous:
Note also that this behavior is being exhibited when sorting on indexed columns
2006-Mar-29 01:50:38 by drh:
Some examples would be helpful.
2006-Mar-29 18:11:43 by anonymous:
Most definitely! I will attach a sample 3.3.4 database dump, that displays this behavior. |
|
1741 |
warn
|
active
|
2006 Mar
|
anonymous
|
VDBE
|
2006 Mar
|
|
5
|
4
|
unused variable with SQLITE_OMIT_UTF16 defined
|
edit |
vdbemem.c, function sqlite3VdbeChangeEncoding():
int sqlite3VdbeChangeEncoding(Mem *pMem, int desiredEnc){
int rc;
if( !(pMem->flags&MEM_Str) || pMem->enc==desiredEnc ){
return SQLITE_OK;
}
#ifdef SQLITE_OMIT_UTF16
return SQLITE_ERROR;
#else
...
If SQLITE_OMIT_UTF16 is defined then the "rc" variable is unused and compiler (Windows Intel 7.0) emits useless warning. |
|
1735 |
code
|
active
|
2006 Mar
|
anonymous
|
Unknown
|
2006 Mar
|
|
1
|
3
|
Encoding problem
|
edit |
I use latin2 (iso-8859-2) encoding in my system. When operating on sqlite 3 I can insert data that contains national characters into a database (for example using sqlite3 console) and then when I select them back, I am given the proper result. But when I use sqlite driver from Qt4, which uses sqlite3_column_text16() to fetch data from the database, I don't get the expected result (meaning the conversion to UTF-16 probably messed things up). Now the problem can be in one of two places -- either sqlite3 console application doesn't use a proper conversion to convert from my locale encoding into its internal encoding or the database internal mechanisms mess some things up.
In short: sqlite3(somelatin2string) ==> SQLITE DMBS ==> sqlite3_column_text16() ==> garbage != somelatin2string
At first I thought this was Qt problem as data stored through sqlite console and retrieved from it was correct and data stored by Qt and retrieved by Qt was also correct whereas data stored by Qt and retrieved by sqlite3 console or stored by the console and retrieved by Qt was not correct. I contacted Qt support guys @ trolltech and talked about it and it looks like Qt side if fine -- it expects a UTF-16 encoded data (because it uses the function mentioned earlier) and it converts from UTF-16 to whatever encoding it needs (and vice versa). So the error is probably somewhere in the line between the console and the database itself or in the database internally. It could be that sqlite3 expects UTF-8 (or UTF-16) encoded data on input but is given ISO-8859-2 data (entered manually by me at the console). |
2006-Mar-27 16:36:26 by anonymous:
The console app doesn't convert from your local code page to UTF-8 (or UTF-16).
2006-Mar-27 22:45:21 by anonymous:
It probably should, in the documentation of sqlite a suggested method of converting databases between versions 2 and 3 is:
sqlite OLD.DB .dump | sqlite3 NEW.DB
Now sqlite outputs the data in "local" format and if sqlite3 doesn't encode it properly, such a conversion will be invalid because the incoming data won't be utf encoded.
A solution could be to do:
sqlite OLD.DB .dump | iconv -f <something> -t UTF-8 | sqlite3 NEW.DB
But it is the console which should be responsible for the conversion. Also because otherwise using sqlite3 console on a non-utf system with a perfectly well UTF-8 encoded database will result in improper output too. |
|
1733 |
code
|
active
|
2006 Mar
|
anonymous
|
VDBE
|
2006 Mar
|
drh
|
4
|
3
|
Unaligned Access on ia64: aggregate_context ptr isn't 16-bytes aligned
|
edit |
There is a problem on ia64 with pointer returned by sqlite3_aggregate_context function. If the size requested is less than NBFS bytes, then the pointer returned is 8 bytes aligned while every pointer returned by allocator function must be 16-bytes aligned (the specification requires that the pointer is aligned so that every basic typed can be stored there and long double is 16 bytes on Itanium).
So if a user allocates, say, 24 bytes for his context, and the first member in his context happens to be a long double, he will get unaligned access exception. This will lead to performance hit on Linux and to crash on HP-UX, since no default SIGBUS handler is present on HP-UX (IIRC). |
2006-Mar-27 10:37:37 by anonymous:
Additional details can be found in this mailing list thread: http://thread.gmane.org/gmane.comp.db.sqlite.general/18144 |
|
1732 |
doc
|
active
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
|
5
|
5
|
Info on Home page
|
edit |
According to "Check-in [3144] : Increase test coverage to above 98%. (By drh)"
the info on home page should be changed from 95% to 98%
|
|
1731 |
doc
|
active
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
|
5
|
5
|
Typo in select4.test
|
edit |
# Make sure the names of columns are takenf rom the right-most subquery
should be
# Make sure the names of columns are taken from the right-most subquery
|
|
1722 |
new
|
active
|
2006 Mar
|
anonymous
|
Unknown
|
2007 Jan
|
|
4
|
2
|
agregate sum() of strings
|
edit |
i'd like to have something like sum() i agregate functions but to work with strings. I'd like to that that function would concate strings similar to summing in sum()e.g: SELECT sum(name || ',')FROM names GROUP BY ..... etc... :) I've heard that something like this is in postgresql? |
|
1720 |
new
|
active
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
|
3
|
4
|
Actions made by a trigger are not triggered
|
edit |
Hellow,
CREATE TRIGGER trg_del_event BEFORE DELETE ON event FOR EACH ROW
BEGIN
SELECT RAISE(ROLLBACK, 'Cannot delete : event is referenced in table active_stuff')
WHERE (SELECT id FROM active_stuff WHERE event_id = OLD.id) IS NOT NULL;
DELETE from event WHERE parent_event_id = OLD.id;
END;
This trigger verify if the current event is referenced in active_stuff
table and if not, delete the row and the childs of the event.
The problem is that the delete made by this trigger is not triggered itself : There's no verification on event's child and no global rollback.
I don't know exactly if it's a feature or an incident.
If it's a feature, you can simply close this ticket. Thanks :) |
2006-Mar-19 17:38:15 by anonymous:
I believe it was mentioned on the mailing list that SQLite triggers are not recursive. However, I don't see any mention of this in the documentation: http://www.sqlite.org/lang_createtrigger.html
2006-Mar-19 17:49:57 by anonymous:
Yes, it's right, I've just found this in ML :
Re: [sqlite] Are DELETE TRIGGERS recursive or not?
drh
Tue, 25 Oct 2005 06:38:42 -0700
Ralf Junker <[EMAIL PROTECTED]> wrote:
> I wonder if a DELETE TRIGGER should trigger itself recursively
Not at this time. Though work is underway to change this.
We need recusive delete triggers in order to implement
cascadinig deletes for referential integrity.
--
D. Richard Hipp <[EMAIL PROTECTED]>
So it's not a bug :)
It's :
- a documentation problem (missing "triggers are currently no recursive")
- a feature request
:)
2006-Mar-19 19:42:58 by anonymous:
Finally I've found the limitation here : http://www.sqlite.org/omitted.html |
|
1719 |
code
|
active
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
|
4
|
4
|
Solaris 8(SQL: bus error while creating temporary file
|
edit |
The problem occours since we using gcc 4.0.2 (with gcc 3.4.3 there was no problem). This problem has the same root as Ticket #1584, with the same solution (but only needed for SQLite <= 2.8.17):
--- src/os.c.orig 2006-03-17 14:02:53.759531000 +0100
+++ src/os.c 2006-03-17 14:03:18.529535000 +0100
@@ -1652,7 +1652,9 @@
#if OS_UNIX && !defined(SQLITE_TEST)
{
int pid;
- time((time_t*)zBuf);
+ time_t t;
+ time(&t);
+ memcpy(zBuf, &t, sizeof(t));
pid = getpid();
memcpy(&zBuf[sizeof(time_t)], &pid, sizeof(pid));
}
|
|
1718 |
new
|
active
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
|
1
|
1
|
allow *.sqlite as parameter to sqlite3_analyzer
|
edit |
it would be nice if it was possible to to:
sqlite3_analyzer.exe *.sqlite
currently you cant and you have to do:
sqlite3_analyzer.exe 1.sqlite
sqlite3_analyzer.exe 2.sqlite
etc.. |
|
1714 |
code
|
active
|
2006 Mar
|
anonymous
|
CodeGen
|
2006 Mar
|
|
4
|
4
|
Slow query when tables in 2 different files
|
edit |
This slow query seems to be sped up by using an explicit CROSS JOIN. ANALYZE apparently does not help. The tables span 2 different database files.
Taken from the SQLite mailing list:
-- table1.schema (file 1)
ATTACH DATABASE './table1.db' AS t1 ;
CREATE TABLE t1.table1
(
i_id INT4,
b_id INT4,
d_id INT4,
c_id INT2,
data_in REAL,
data_out REAL
);
CREATE INDEX t1.ix_table1_b_id ON table1( b_id );
DETACH DATABASE t1 ;
-- table2.schema (file 2)
ATTACH DATABASE './table2.db' AS t2 ;
CREATE TABLE t2.table2
(
d_id INT4 PRIMARY KEY,
r_id INT2,
m_id INT2,
i TEXT,
ct TEXT,
cc TEXT,
type TEXT,
notes TEXT
);
DETACH DATABASE t2 ;
-- the slow query (does not use indexes on both tables?)
select t1.b_id, t1.c_id, t2.r_id, t2.m_id,
sum( t1.data_in ) as data_in,
sum( t1.data_out ) as data_out
from table1 t1
join table2 t2
on t2.d_id = t1.d_id and t1.b_id >= 100 and t1.b_id < 200
group by t1.b_id, t1.c_id, t2.m_id, t2.r_id;
-- the fast query (seems to use both tables' indices)
select t1.b_id, t1.c_id, t2.r_id, t2.m_id,
sum( t1.data_in ) as data_in,
sum( t1.data_out ) as data_out
from table1 t1
cross join table2 t2
where t2.d_id = t1.d_id and t1.b_id >= 100 and t1.b_id < 200
group by t1.b_id, t1.c_id, t2.m_id, t2.r_id;
More information can be found here:
http://www.mail-archive.com/sqlite-users%40sqlite.org/msg13648.html |
|
1704 |
new
|
active
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
|
4
|
3
|
extern "C" block in sqliteInt.h
|
edit |
can we put
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
} /* End of the 'extern "C"' block */
#endif
around the declarations in sqliteInt.h.
It would help as we need to access SQLite internals from our C++ code. |
|
1703 |
new
|
active
|
2006 Mar
|
anonymous
|
Pager
|
2006 Mar
|
|
2
|
3
|
Second parameter to gettimeofday() in os_unix.c should be NULL
|
edit |
in os_unix.c, function sqlite3UnixCurrentTime():
the second argument to gettimeofday() should be NULL and the declaration of sTz should be removed.
struct timezone seems to cause trouble on Linux systems. |
|
1702 |
new
|
active
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
|
5
|
4
|
feature request: API to write in-memory DB to file.
|
edit |
Hello!
A feature suggestion regarding in-mem databases:
It would be interesting to be able to save this to files as normal sqlite3 dbs. i'm assuming that this is internally a rather simple operation, but i didn't find a function for doing it.
Take care,
----- stephan |
2006-Jun-28 05:04:05 by anonymous:
There have been already good solutions. Watch this wiki page.
http://www.sqlite.org/cvstrac/wiki?p=InMemoryDatabase |
|
1701 |
doc
|
active
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
drh
|
3
|
1
|
3.3 build option not documented?
|
edit |
3.3 db can not be read in easlier 3.X versions. Ok, then it says there is a 'rare' compile option to force them to be. I can not use 3.3 yet from php and perl, so I have the rare condidtion that I prefer to have all my tools in sync more. I have searched the incompatibilies page, the ./configure -h, grepped the source and read the options page... so far none seem to have lead me to this magic compile option.
Maybe it should be documented someplace? |
2006-Mar-03 15:49:35 by anonymous:
The compilation option you are looking for is SQLITE_DEFAULT_FILE_FORMAT. I found it by looking back through the time line before version 3.3.0.
You are correct it should be added to the options displayed on http://www.sqlite.org/compile.html which is reached from the Compilation Options link on the documentation page. |
|
1700 |
code
|
active
|
2006 Mar
|
anonymous
|
Parser
|
2006 Mar
|
|
2
|
2
|
Handling column names for aliased queries is broken
|
edit |
The following query does not work,
SELECT DISTINCT * FROM (SELECT t1.ID
FROM GR_ADDRESS t1
WHERE t1.ID > 1 UNION ALL SELECT t1.ID
FROM PERSON t1) t1 ORDER BY t1.ID DESC
but this one does,
SELECT DISTINCT * FROM (SELECT t1.ID
FROM GR_ADDRESS t1
WHERE t1.ID > 1 UNION ALL SELECT t1.ID
FROM PERSON t1 ORDER BY t1.ID DESC)
Dennis Cote responded with:
I think you have found another example of the problems SQLite has
handling columns names.
The following log first shows what SQLite thinks the column name is for
the query without the order by clause (i.e. t1.ID). Then we try to order
by that column name, with or without the table alias. Both cases result
in an error. Finally there is a work around that you could use that
applies an alias to the selected columns in the two tables that are
combined by the union operation.
SQLite version 3.3.2
Enter ".help" for instructions
sqlite> create table GR_ADDRESS(id, data);
sqlite> create table PERSON(id, data);
sqlite> .mode column
sqlite> .header on
sqlite> insert into gr_address values(1, 10);
sqlite> insert into person values(2, 20);
sqlite> insert into gr_address values(3, 30);
sqlite> SELECT DISTINCT *
...> FROM
...> (SELECT t1.ID
...> FROM GR_ADDRESS t1
...> WHERE t1.ID > 1
...> UNION ALL
...> SELECT t1.ID
...> FROM PERSON t1)
...> t1;
t1.ID
----------
3
2
sqlite> SELECT DISTINCT *
...> FROM
...> (SELECT t1.ID
...> FROM GR_ADDRESS t1
...> WHERE t1.ID > 1
...> UNION ALL
...> SELECT t1.ID
...> FROM PERSON t1)
...> t1 ORDER BY t1.ID DESC;
SQL error: no such column: t1.ID
sqlite> SELECT DISTINCT *
...> FROM
...> (SELECT t1.ID
...> FROM GR_ADDRESS t1
...> WHERE t1.ID > 1
...> UNION ALL
...> SELECT t1.ID
...> FROM PERSON t1)
...> t1 ORDER BY ID DESC;
SQL error: no such column: ID
sqlite> SELECT DISTINCT *
...> FROM
...> (SELECT t1.ID as ID
...> FROM GR_ADDRESS t1
...> WHERE t1.ID > 1
...> UNION ALL
...> SELECT t1.ID as ID
...> FROM PERSON t1)
...> t1 ORDER BY t1.ID DESC;
ID
----------
3
2
You may also be interested in the discussion of a similar problem under ticket #1688. |
|
1698 |
build
|
active
|
2006 Mar
|
anonymous
|
|
2006 Mar
|
|
1
|
1
|
sqlite_4y6ngs9FlYvAMGO 0kb 3/1/2006 1:16 PM
|
edit |
sqlite_4y6ngs9FlYvAMGO 0kb 3/1/2006 1:16 PM
I like to stop this file,don't know where is coming from |
2006-Mar-02 03:50:33 by anonymous:
You might want to check the free tools on http://www.sysinternals.com to monitor file events and process state.
ProcessExplorer will tell you what files (and much more) are open per process and you can even find the process that has some file open.
FileMon will monitor all file accesses, so you can check which program is creating those files, if it doesn't let them open for enough time to use ProcessExplorer.
Hope this helps. |
|
1693 |
new
|
active
|
2006 Feb
|
anonymous
|
Parser
|
2006 Mar
|
|
4
|
4
|
Parser sensitive to position of word AUTOINCREMENT
|
edit |
Command:
create table unique_ids ( 'id' INTEGER AUTOINCREMENT PRIMARY KEY)
fails, while the
create table unique_ids ( 'id' INTEGER PRIMARY KEY AUTOINCREMENT)
suceeds. The only difference is position of the word AUTOINCREMENT. I originally expected the AUTOINCREMENT to be standalone feature, not tied with PRIMARY KEY. Perhaps the parser may be more forgiving here. |
|
1689 |
new
|
active
|
2006 Feb
|
anonymous
|
|
2006 Mar
|
|
2
|
4
|
triggers and temporary tables
|
edit |
CREATE TRIGGER trg_upd_dict AFTER UPDATE ON dict
BEGIN
UPDATE dict SET code = (SELECT code from tmp_connected_user) WHERE old.dict_id = dict_id ;
END ;
This trigger doesn't work if tmp_connected_user is a temporary table. The message is : SQL error: no such table: main.tmp_connected_user |
The goal is to have persistant triggers who works with temporary tables.
Exemple of use :
- Workarround who replace the non existing connection by user / password. When we insert/update, the database doesn't know who insert/update. If we have a table user, we can on each table fill by trigger fields like last_user_id, last_modif_d. The trigger cannot know who make the connection but we stock the user_id when he connects
to the db in a temporary table, the trigger will work.
- Security (no one can update / insert the database if a special temporary table is not created and filled).
2006-Mar-03 20:25:41 by drh:
You can create a TEMP trigger that will reference tables in
the main database and/or attached databases. But SQLite currently
does not allow triggers in the main or attached database to
reference tables in other databases.
I will enter this as an enhancement request.
2006-Mar-06 16:17:11 by anonymous:
Workarround for this ticket : if we only need 1 result, we can use user defined function instead temporary table in the trigger. Tested with php : it works :) |
|
1683 |
new
|
active
|
2006 Feb
|
anonymous
|
Unknown
|
2006 Feb
|
anonymous
|
4
|
3
|
.mode html produces uppercase tags
|
edit |
Quote from one of sqlite docs:
"The last output mode is "html". In this mode, sqlite writes the results of the query as an XHTML table. The beginning <TABLE> and the ending </TABLE> are not written, but all of the intervening <TR>s, <TH>s, and <TD>s are. The html output mode is envisioned as being useful for CGI."
I tried the ".mode html" and the result is just like the doc said.
But there is one oddity. AFAIK, XHTML discourages using uppercase tags. Inspite of that, sqlite produces uppercase tags. Why??
Now, this is a suggestion from a newbie point of view just for the sake
of sqlite's consistency: Use lowercase tags for ".mode hmtl" result.
I know browsers produce the same result for <TR>...</TR> as well as for
<tr>...</tr>. We all know xhtml 1.0 is just a more strict version of html 4.0 and xhtml is based on xml whilst html 4.o is based on sgml. Not make much any difference to me and the browsers. But following the xhtml standard and rules -that sqlite WANTS- doesn't hurt right?
I hope you can consider more seriously this lite suggestion :)
Keep up the great work!
ps:sorry for my broken english |
2006-Feb-21 14:24:54 by anonymous:
Capitals tags aren't xhtml.
Why not offering an export may be also import mode in true xml ? With xsd schema file creation as useful for direct import into spread sheet and other popular programs.
Keep on going with this beautiful program. |
|
1679 |
new
|
active
|
2006 Feb
|
anonymous
|
|
2006 Feb
|
|
4
|
4
|
SQLite requires code modification to replace memory allocation funcs
|
edit |
sqliteOsMalloc is a C macro that points to a 'generic' malloc routine by default. The same for realloc and free. This forces a SQLite user to modify the code of each realease to support their own memory functions. Allow it means that the user can no longer use a system wide SQLite library and have to ship their own.
If those memory functions where function pointers then the calling program could set them without modifying the source code. These function pointers could be global variables or set by a sqlite_memory_funcs() API function. |
|
1675 |
new
|
active
|
2006 Feb
|
anonymous
|
|
2006 Feb
|
|
5
|
4
|
sqlite3_db_dup() ?
|
edit |
I don't need this myself, as I don't write multithreaded code now, but it seems a useful addition for all those people doing mutlithreaded code:
Duplicate a db connection for use in another thread.
The new db connection should NOT be connected to any shared caches for the current thread, so that the new connection can be moved to any thread.
The idea might be a server, which starts some worker thread and wants to give that new thread a connection to the db. |
|
1663 |
new
|
active
|
2006 Feb
|
anonymous
|
Unknown
|
2006 Feb
|
|
4
|
4
|
Suggestion: DATETYPE field type using David Tribble's work?
|
edit |
How about a new field (/data) type, DATETIME, using David Tribble's excellent proposal? See here:
http://david.tribble.com/text/c0xlongtime.html |
2006-Feb-09 02:58:34 by drh:
What advantage does David Tribble's datetype design have over
the existing date and time support in SQLite? Why should we change? |
|
1656 |
doc
|
active
|
2006 Feb
|
anonymous
|
Parser
|
2006 Mar
|
|
5
|
4
|
lemon versions and changelog
|
edit |
Lemon lacks whatsnew.txt files and versioning to be used in other products than SQLite. Seems like to be useful utility. It will be nice to see some performance tests/comparison with other parsers. |
|
1655 |
new
|
active
|
2006 Feb
|
anonymous
|
VDBE
|
2006 Mar
|
|
4
|
4
|
Every function can have their private data like agreagates
|
edit |
Is it possible to modify the way functions are handled in sqlite ?
My idea is to allow functions to have their own private data space to save data from row to row like the agregates have, with that we can have functions that remember last row values, create counters and totalizers that return their updated values for each row.
Ex:
select increment(1),* from my_table;
1|car|rose|3
2|sea|bike|7
3|flower|water|33
select sum_and_return_row_by_row(row_value_to_sum),* from my_table;
3|car|rose|3
10|sea|bike|7
43|flower|water|33
select current_row_value + last_row_value(current_row_value),* from my_table;
3|car|rose|3
10|sea|bike|7
40|flower|water|33
The structure for that is already there, in fact is the same used by agregates, I was scratching the code but I could not find easily where to introduce code to push the context and pop it for functions that aren't agregates, someone know how to do that ? |
2006-Feb-04 20:45:32 by anonymous:
/*
** Implementation of the increment() function
*/
static void incrementFunc(sqlite3_context *context, int argc, sqlite3_value **argv){
assert( argc==1 );
switch( sqlite3_value_type(argv[0]) ){
case SQLITE_INTEGER: {
i64 iVal = sqlite3_value_int64(argv[0]);
i64 *pi = (i64*)&context->s.zShort;
*pi = *pi + iVal;
sqlite3_result_int64(context, *pi);
break;
}
}
}
I've tried that but context are not saved row to row, of course here I was using a hidden member (s.zShort) of the context structure that seems not to be used or damaged, ideally should have a function like
"void sqlite3_set_presistent_data(sqlite3_context *context, void value, int size_to_be_allocated)"
or something like it that will allocate memory and return the actual value stored before if any. |
|
1653 |
new
|
active
|
2006 Feb
|
anonymous
|
CodeGen
|
2006 Feb
|
|
4
|
5
|
SQLITE_OMIT_COST_REORDERING ?
|
edit |
Embedded SQLite installations could benefit from conditionally compiling out the logic of the cost-based reordering of tables (i.e., always assume cross join). It might save a few kilobytes of code when the join order is always known in advance. |
|
1648 |
new
|
active
|
2006 Jan
|
anonymous
|
Shell
|
2007 Dec
|
|
4
|
3
|
meaningful error message: constraint failed
|
edit |
create table emp( id text unique, sex text check( sex in 'm' or sex in 'f' );
insert into emp values( '1','x' );
SQL error: constraint failed
This error message could be better. If there are several constraints, which constraint failed? So I named the constraint
create table emp( id text unique, sex text constraint chk_sex check( sex in 'm' or sex in 'f' );
insert into emp values( '1','x' );
SQL error: constraint failed
Still no joy . . .
It would be nice if the error message were more specific. |
2006-Jan-30 16:22:58 by anonymous:
actually my testing was better than my typing, I used:
check (sex = 'm' or sex = 'f' )
2007-Oct-25 09:47:14 by anonymous:
This is a really big deal for me and for many others I suspect. If this is not a priority, could you at least throw out some hints about implementing it? I browsed through the code but can't seem to find where this would even go.
2007-Oct-25 10:10:36 by anonymous:
Hm, ok, the check constraints are stored in the table structure as a single expression which is the AND of all of them. This alone suggests that the task at hand is not simple...
2007-Oct-25 10:17:36 by anonymous:
Perhaps a new Check type could be created which could basically be Expr plus an extra pointer, which could then be used to make a list of them, similar to how the triggers seem to be stored. I'll keep snooping around, but I thought I'd post what I've found thus far in case anyone else looks at this.
2007-Oct-25 19:40:37 by anonymous:
I have attached a patch that implements this. I've only tested it lightly by hand. (The test suite failed to run and gave me some strange linking errors)
2007-Dec-20 11:38:03 by anonymous:
Although this is tagged as shell, the error message comes from the sqlite core.
My single biggest problem besides the lack of detail (some of my tables have 5 constraints) is that it also prevents me from localizing the error messages. If I have the constraint name then at least I can look it up in a translation table and tell non-english speakers something meaningful. |
|
1647 |
doc
|
active
|
2006 Jan
|
anonymous
|
Unknown
|
2006 Jan
|
paul
|
3
|
1
|
i want to use this lib in my project
|
edit |
HI,
I want to use this sqlite source in my project for quick firing of
quaries. I want dataled doc of source or how to use these source in my project.
Hoping for quick reply,
Bye
thaks & Regards
Sumant Kadam
9422615104 |
2006-Jan-30 20:43:26 by anonymous:
This is not a bug report. Please use the mailing list for this type of question. |
|
1638 |
warn
|
active
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
3
|
2
|
rows place change and some row element missing
|
edit |
there is a problem with my table row order.I miss one roe header and the next one come to its place.also there is a problem like this in the columns too.it does not occur when the table is list or line.but when I turn it into column mode the problem happens.my table become puzzling |
|
1637 |
code
|
active
|
2006 Jan
|
anonymous
|
Parser
|
2006 Jan
|
|
4
|
4
|
Multiple JOIN USING() doesn't work.
|
edit |
CREATE TABLE T1(T1Id, Name);
INSERT INTO T1(T1Id, Name) VALUES (0,"titi");
INSERT INTO T1(T1Id, Name) VALUES (1,"toto");
INSERT INTO T1(T1Id, Name) VALUES (2,"tutu");
INSERT INTO T1(T1Id, Name) VALUES (3,"hat");
INSERT INTO T1(T1Id, Name) VALUES (4,"socks");
CREATE TABLE T2(T2Id, Name);
INSERT INTO T2(T2Id, Name) VALUES(0,"Black");
INSERT INTO T2(T2Id, Name) VALUES(1,"Red");
INSERT INTO T2(T2Id, Name) VALUES(2,"Blue");
INSERT INTO T2(T2Id, Name) VALUES(3,"Green");
INSERT INTO T2(T2Id, Name) VALUES(4,"Yellow");
INSERT INTO T2(T2Id, Name) VALUES(5,"Brown");
INSERT INTO T2(T2Id, Name) VALUES(6,"White");
CREATE TABLE T3(T3Id,T1Id,T2Id,Number);
INSERT INTO T3(T3Id,T1Id,T2Id,Number) VALUES (1,4,0,5);
INSERT INTO T3(T3Id,T1Id,T2Id,Number) VALUES (2,4,1,4);
INSERT INTO T3(T3Id,T1Id,T2Id,Number) VALUES (3,4,2,3);
INSERT INTO T3(T3Id,T1Id,T2Id,Number) VALUES (4,4,3,2);
INSERT INTO T3(T3Id,T1Id,T2Id,Number) VALUES (5,4,4,1);
INSERT INTO T3(T3Id,T1Id,T2Id,Number) VALUES (6,4,5,0);
INSERT INTO T3(T3Id,T1Id,T2Id,Number) VALUES (7,3,0,10);
SELECT main.Number AS Number,
prod.Name AS product,
col.Name AS color,
Main.T3Id AS Id
FROM T3 AS main
LEFT JOIN T1 AS prod USING(T1Id)
LEFT JOIN T2 AS col USING(T2Id);
The second USING doesn't work. |
2006-Jan-23 16:03:17 by drh:
SQLite only looks for columns to satisfy the USING clause in the
two tables immediately tot he left and right of the join. In the
example above, it is trying to resolve "USING(t2id)" by looking
for columns t1.t2id and t2.t2id.
2006-Jan-23 23:12:32 by anonymous:
I'm not sure if you are saying that is the way SQLite should work, or just explaining the source of the error.
I believe that JOINS are supposed to combine two tables to produce a third table in a left associative manner. The sample query should join T3 and T1 using T1Id to produce an intermediate table, lets call it simply T. Then T should be joined with T2 using T2Id to produce the final result table.
As shown below, T does in fact have a column named T2Id, and this column should be used for the second join.
sqlite> CREATE table t AS SELECT *
...> FROM T3 AS main
...> LEFT JOIN T1 AS prod USING(T1Id);
sqlite>
sqlite> PRAGMA table_info(t);
0|T3Id|numeric|0||0
1|T1Id|numeric|0||0
2|T2Id|numeric|0||0
3|Number|numeric|0||0
4|Name|numeric|0||0
sqlite>
sqlite> SELECT T2ID from t;
0
1
2
3
4
5
0
One area where SQLite may have a standards compliance problem is with the name of the result set columns with column name joins (i.e. joins with a USING() clause). The standard says that the result set column that was used to join the two tables can not have a qualifier. That means it is NOT the column from either of the two input tables, and can't be qualified using either table name. The USING clause "projects out" the columns from both of the input tables and replaces them with a single column with the same name. The two columns could have different types for example, and the result set column could be yet another type.
The first two otuput columns below should generate an error. Only the third is legal according to the SQL standard.
sqlite> SELECT T3.T2Id, T2.T2Id, T2Id from T3 LEFT JOIN T2 USING(T2Id);
T2Id|T2Id|T2Id
0|0|0
1|1|1
2|2|2
3|3|3
4|4|4
5|5|5
0|0|0
The type differences between the different columns are displayed in the following example. In one table the values of column a are integers and in the other they are text. The type of the result column depends upon the order of the tables in the join.
sqlite> select a from tt1 join tt2 using(a);
a
1
2
sqlite> select typeof(a) from tt1 join tt2 using(a);
typeof(a)
integer
integer
sqlite> select typeof(a), typeof(tt1.a), typeof(tt2.a) from tt1 join tt2 using(a);
typeof(a)|typeof(tt1.a)|typeof(tt2.a)
integer|integer|text
integer|integer|text
sqlite> select * from tt1 join tt2 using(a);
a|b|c
1|1|-1
2|4|-2
sqlite> select typeof(a), typeof(tt1.a), typeof(tt2.a) from tt2 join tt1 using(a);
typeof(a)|typeof(tt1.a)|typeof(tt2.a)
text|integer|text
text|integer|text
The same rules also apply to NATURAL joins. The result columns cannot legally be qualified by either table name.
2006-Jan-23 23:45:04 by drh:
My previous remark is describe what SQLite does. You are probably
right in pointing out that what it currently does is not correct
and ought to be fixed. I merely observet that SQLite has never
worked that way and has (up until now) caused no serious concern.
So, I'm not going to consider this a high-priority bug. I will get
to it as I am able. But I need to get 3.3.x out the door first. |
|
1636 |
todo
|
active
|
2006 Jan
|
anonymous
|
Shell
|
2006 Jan
|
drh
|
4
|
3
|
stdev does not work
|
edit |
When trying to calculate standard deviation I get the following error message:
SQL error: no such function: stdev
How does SQLite support statistical function stdev? What is the correct name of the function?
The same with sqr and sqrt. What are the names for square and square-root?
Is there any other way to use SQLite for statistical calculations? |
|
1635 |
doc
|
active
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
4
|
4
|
SQLite Ticket "Version" field
|
edit |
The "Version" field in the CVSTrac ticket is ambiguous (particularly for "fixed" bugs). Can it be renamed to "Version Bug Appears" or something to that effect? Also, it would be very useful to see the SQLite version in which the ticket is fixed in addition to the SQLite version which the bug first appears. Manually correlating the date of the fix with the SQLite version is awkward. |
|
1633 |
code
|
active
|
2006 Jan
|
anonymous
|
VDBE
|
2006 Apr
|
|
3
|
3
|
sqlite3_step returns SQLITE_ERROR when interrupted
|
edit |
When interrupting an execution of sqlite3_step, sqlite3_step will return a generic SQLITE_ERROR instead of the SQLITE_INTERRUPT error code I'd expect.
This is because although in vdbe.c:4427 the SQLITE_INTERRUPT result code is set to the internal 'rc' field of the database connection, a plain SQLITE_ERROR is returned:
vdbe_halt:
if( rc ){
p->rc = rc;
rc = SQLITE_ERROR;
}else{
rc = SQLITE_DONE;
}
The SQLITE_ERROR returned is then also stored as the errCode inside the db handle by the calling function, so there's no way to find out whether the error occured due to an interrupt or some other error (since sqlite3_error() will return SQLITE_ERROR as well).
I'd like to ignore interrupt errors where I call sqlite3_step, since those are not of importance to my users, but with the current scheme, I have no way of finding out whether an sqlite3_interrupt causes the error or whether it's a serious error... |
You get a more specific error-code (for example SQLITE_INTERRUPT)
when you call sqlite3_finalize() or sqlite3_reset() on the
statement.
There shouldn't be any reason not to call one of these
functions after sqlite3_step() returns SQLITE_ERROR, as you
cannot do anything else with the statement handle at that point
anyway.
2006-Apr-26 11:58:01 by anonymous:
Well, I get SQLITE_ERROR in sqlite3_finalize(), too after I interrupted the query, so I can't even find out at finalize time.
However, it might be interesting to see the real error when stepping: in our C++ wrapper, the finalize occurs very late and we usually raise database exceptions when errors occur while stepping. I would really like to raise the proper exception (some sqlite_execution_interrupted exception) when the query was interrupted instead of raising some generic "sql error" exception...
2006-Apr-26 12:24:02 by anonymous:
Sorry, my previous comment was a bit too quick: I have to admit that most of the time, I do in fact get SQLITE_INTERRUPTED as result from sqlite3_finalize, but every now and then, I do get SQL_ERROR. Maybe this happens when I try to interrupt just before the actual statement execution has started or when execution has just finished?
2006-Jul-26 13:26:19 by anonymous:
This might, of course, be related to my incorrect usage of sqlite3_interrupt from a different thread (Ticket #1897) ? |
|
1627 |
warn
|
active
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
4
|
4
|
warnings on BCB and how to resolve them + couple of minor fixes
|
edit |
I took 3.3.1 sources (the preprocessed version)
and tried to compile them on Borland C++ Builder 6.4.
I wanted to keep all compiler warnings switched on.
I got some warnings from sqlite source.
Some due to strlen() returning unsigned,
some due signed/unsigned comparison,
some because BCB requires
if (a = b) ...
to be rewritten as
if ((a = b) != 0) ...
to avoid warnings.
List of places generating warnings
and ways to shut then up are bellow.
Perhaps these fixes may be applied to the codebase
since the warnings may happen with other
C++ compilers as well.
I cannot promise the fixes will work with 64bit
architectures but it seems likely.
Some macros, like MASTER_NAME, may cause collisions.
Perhaps they all can be prefixed with SQLITE3 or so
to avoid such accidents.
The trick to enable NDEBUG in sqliteInt.h:
#if !defined(NDEBUG) && !defined(SQLITE_DEBUG)
# define NDEBUG 1
#endif
has unfortunate property of changing NDEBUG settings
in those parts of a project using sqlite and
not in the others.
It is hard to detect reason for possible problems.
I suggest:
1) Put on top of each sqlite source file
#define THIS_IS_SQLITE_SOURCE
2) Change the trick to:
#if !defined(NDEBUG) && !defined(SQLITE_DEBUG) && (defined THIS_IS_SQLITE_SOURCE)
# define NDEBUG 1
#endif
Small wish for the documentation: could there
be information how to switch off all sqlite
memory management and checking and leave it
all to host's malloc/realloc/free?
I have very optimized dmalloc allocator
and want to be sure there are no other
layers above this. My allocator also does
boundary checking and error detection.
---- FIXES TO GET RID OF WARNINGS ON BCB ---
vdbmem.c, line 725:
assert( strlen(pMem->z)<=pMem->n );
==>>
assert( (int)strlen(pMem->z)<=pMem->n );
vdbeaux.c:
line 545:
if( strlen(zTemp)+strlen(zNum)+1<=nTemp ){
==>>
if( (int)strlen(zTemp)+(int)strlen(zNum)+1<=nTemp ){
line 1740:
if( d1>=nKey1 && sqlite3VdbeSerialTypeLen(serial_type1)>0 ) break;
==>>
if( (int)d1>=nKey1 && sqlite3VdbeSerialTypeLen(serial_type1)>0 ) break;
line 1742:
if( d2>=nKey2 && sqlite3VdbeSerialTypeLen(serial_type2)>0 ) break;
==>>
if( (int)d2>=nKey2 && sqlite3VdbeSerialTypeLen(serial_type2)>0 ) break;
line 1768:
}else if( d1<nKey1 ){
==>>
}else if( (int)d1<nKey1 ){
line 1770:
}else if( d2<nKey2 ){
==>>
}else if( (int)d2<nKey2 ){
btree.c:
line 878:
assert( iCell<get2byte(&data[pPage->hdrOffset+3]) );
==>>
assert( iCell<(int)get2byte(&data[pPage->hdrOffset+3]) );
line 932:
if( nPayload<=pPage->maxLocal ){
==>>
if( (int)nPayload<=pPage->maxLocal ){
line 1150:
assert( nCell==get2byte(&data[hdr+3]) );
==>>
assert( nCell==(int)get2byte(&data[hdr+3]) );
line 2351:
if( origSize>=PENDING_BYTE_PAGE(pBt) && finSize<=PENDING_BYTE_PAGE(pBt) ){
==>>
if( (int)origSize>=PENDING_BYTE_PAGE(pBt) && (int)finSize<=PENDING_BYTE_PAGE(pBt) ){
line 2367:
if( PTRMAP_ISPAGE(pgsz, iDbPage) || iDbPage==PENDING_BYTE_PAGE(pBt) ){
==>>
if( PTRMAP_ISPAGE(pgsz, iDbPage) || (int)iDbPage==PENDING_BYTE_PAGE(pBt) ){
line 2916:
if( offset+amt > nKey+pCur->info.nData ){
==>>
if( offset+amt > (int)(nKey+pCur->info.nData) ){
line 3056:
if( nLocal>nKey ){
==>>
if( nLocal>(int)nKey ){
line 3737:
if( *pPgno>sqlite3pager_pagecount(pBt->pPager) ){
==>
if( *pPgno>(Pgno)sqlite3pager_pagecount(pBt->pPager) ){
line 3774:
assert( *pPgno!=PENDING_BYTE_PAGE(pBt) );
==>>
assert( *pPgno!=(Pgno)PENDING_BYTE_PAGE(pBt) );
line 3779:
assert( *pPgno!=PENDING_BYTE_PAGE(pBt) );
==>>
assert( *pPgno!=(Pgno)PENDING_BYTE_PAGE(pBt) );
line 3789:
assert( *pPgno!=PENDING_BYTE_PAGE(pBt) );
==>>
assert( *pPgno!=(Pgno)PENDING_BYTE_PAGE(pBt) );
line 3879:
if( ovflPgno>sqlite3pager_pagecount(pBt->pPager) ){
==>>
if( ovflPgno>(Pgno)sqlite3pager_pagecount(pBt->pPager) ){
line 3774:
assert( *pPgno!=PENDING_BYTE_PAGE(pBt) );
==>>
assert( *pPgno!=(Pgno)PENDING_BYTE_PAGE(pBt) );
line 3938:
assert( info.nData==nData );
==>>
assert( (int)info.nData==nData );
line 4166:
assert( end <= get2byte(&data[hdr+5]) );
==>>
assert( end <= (int)get2byte(&data[hdr+5]) );
line 4972:
assert( pgnoChild<=sqlite3pager_pagecount(pPage->pBt->pPager) );
==>>
assert( pgnoChild<=(Pgno)sqlite3pager_pagecount(pPage->pBt->pPager) );
line 5399:
pgnoRoot==PENDING_BYTE_PAGE(pBt) ){
==>>
pgnoRoot==(Pgno)PENDING_BYTE_PAGE(pBt) ){
line 5491:
if( pgno>sqlite3pager_pagecount(pBt->pPager) ){
==>>
if( pgno>(Pgno)sqlite3pager_pagecount(pBt->pPager) ){
line 5616:
if( iTable==maxRootPgno ){
==>>
if( iTable==(int)maxRootPgno ){
line 5659:
if( maxRootPgno==PENDING_BYTE_PAGE(pBt) ){
==>>
if( maxRootPgno==(Pgno)PENDING_BYTE_PAGE(pBt) ){
line 5665:
assert( maxRootPgno!=PENDING_BYTE_PAGE(pBt) );
==>>
assert( maxRootPgno!=(Pgno)PENDING_BYTE_PAGE(pBt) );
if(
(rc = restoreOrClearCursorPosition(pCur, 1)) ||
(rc = saveAllCursors(pBt, pCur->pgnoRoot, pCur)) ||
(rc = sqlite3pager_write(pPage->aData))
){
==>>
if(
(rc = restoreOrClearCursorPosition(pCur, 1)) != 0 ||
(rc = saveAllCursors(pBt, pCur->pgnoRoot, pCur)) != 0||
(rc = sqlite3pager_write(pPage->aData)) != 0
){
(to get rid "possibly incorrect assigment" warning)
line 3353:
int dummy;
pCell += getVarint32(pCell, &dummy);
==>>
u32 dummy;
pCell += getVarint32(pCell, &dummy);
line 3342:
i64 nCellKey;
==>>
u64 nCellKey;
because it causes warning in line 3353 in
getVarint(pCell, &nCellKey);
build.c:
line 622:
if( (!OMIT_TEMPDB || i!=1 ) && n==strlen(pDb->zName) &&
==>>
if( (!OMIT_TEMPDB || i!=1 ) && n==(int)strlen(pDb->zName) &&
line 2367:
pIndex->aiRowEst = (int *)(&pIndex->aiColumn[nCol]);
==>>
pIndex->aiRowEst = (unsigned *)(&pIndex->aiColumn[nCol]);
(the type is defined as unsigned in sqliteInt.h)
vdbe.c:
line 1967:
assert( p2<nField );
==>>
assert( p2<(int)nField );
line 1967:
if( avail>=payloadSize ){
==>>
if( avail>=(int)payloadSize ){
line 2019:
if( !zRec && avail<offset ){
==>>
if( !zRec && avail<(int)offset ){
line 2034:
for(i=0; i<nField; i++){
==>>
for(i=0; i<(int)nField; i++){
select.c, line 113:
if( p->n==keywords[j].nChar
==>>
if( (int)(p->n)==keywords[j].nChar
expr.c, line 350:
&& pE->token.n==n
==>>
&& (int)(pE->token.n)==n
shell.c: functions isatty() and access()
are in <io.h> on Borland.
I suggest to add:
#if (defined __BORLANDC__)
# include <io.h>
#endif
and at the same time to comment out shell.c, line 59:
#if !(defined __BORLANDC__)
extern int isatty();
#endif
Prototype on BCB is
int isatty(int handle);
pager.c:
line 600:
for(i=0; i<len; i++){
==>>
for(i=0; i<(int)len; i++){
line 1016:
if( pgno==0 || pgno==PAGER_MJ_PGNO(pPager) ){
==>>
if( pgno==0 || pgno==(Pgno)PAGER_MJ_PGNO(pPager) ){
line 1341:
assert( pPager->origDbSize==0 || pPager->origDbSize==mxPg );
==>>
assert( pPager->origDbSize==0 || (Pgno)(pPager->origDbSize)==mxPg );
line 1354:
for(i=0; i<nRec; i++){
==>>
for(i=0; i<(int)nRec; i++){
line 1935:
if( pPg->pgno<=dbSize ){
==>>
if( pPg->pgno<=(Pgno)dbSize ){
line 2308:
if( pList->pgno<=pPager->dbSize ){
==>>
if( pList->pgno<=(Pgno)(pPager->dbSize) ){
line 2560:
if( pgno>PAGER_MAX_PGNO || pgno==0 || pgno==PAGER_MJ_PGNO(pPager) ){
==>>
if( pgno>PAGER_MAX_PGNO || pgno==0 || pgno==(Pgno)PAGER_MJ_PGNO(pPager) ){
line 3043:
assert( pPg->pgno!=PAGER_MJ_PGNO(pPager) );
==>>
assert( pPg->pgno!=(Pgno)PAGER_MJ_PGNO(pPager) );
line 3672:
for( i=nTrunc+1; i<=pPager->origDbSize; i++ ){
==>>
for( i=nTrunc+1; i<=(Pgno)(pPager->origDbSize); i++ ){
line 3673:
if( !(pPager->aInJournal[i/8] & (1<<(i&7))) && i!=iSkip ){
==>>
if( !(pPager->aInJournal[i/8] & (1<<(i&7))) && i!=(Pgno)iSkip ){
printf.c, line 409:
*(--bufpt) = cset[longvalue%base];
==>>
*(--bufpt) = cset[(unsigned)(longvalue%base)];
Here BCB complains on using 64 bit integer
as array index with warning "suspcious pointer conversion".
Lot of code complains on memory debug functions
not compiled in but used within asserts:
util.c:
line 1360:
assert( sqlite3ThreadData()->mallocDisallowed>=0 );
sqlite3ThreadData()->mallocDisallowed++;
==>>
#ifdef SQLITE_MEMDEBUG
assert( sqlite3ThreadData()->mallocDisallowed>=0 );
sqlite3ThreadData()->mallocDisallowed++;
#endif
line 1369:
assert( sqlite3ThreadData()->mallocDisallowed>0 );
sqlite3ThreadData()->mallocDisallowed--;
==>>
#ifdef SQLITE_MEMDEBUG
assert( sqlite3ThreadData()->mallocDisallowed>0 );
sqlite3ThreadData()->mallocDisallowed--;
#endif
line 556:
while( !(p = OSMALLOC(n)) && sqlite3_release_memory(n) );
==>>
while( (p = OSMALLOC(n))==0 && sqlite3_release_memory(n) );
This is officially BCB recommended trick to shut up
"possibly incorrect assignement" message. The docs says:
if (a = b) ...
should be rewritten as
if ((a = b) != 0) ...
line 586:
while( !(np = OSREALLOC(p, n)) && sqlite3_release_memory(n) );
==>>
while( (np = OSREALLOC(p, n))==0 && sqlite3_release_memory(n) );
line 739:
if( db && (db->pErr || (db->pErr = sqlite3ValueNew()))!=0 ){
==>>
if( db && (db->pErr || ((db->pErr = sqlite3ValueNew())!=0))!=0 ){
There are several more warnings when BCB compiler
claims a function has no prototype where it has.
It is knon Borland bug and the only way to fix
it is to add
#ifdef __BORLANDC__
# pragma -warn ...
#endif
...statements...
#ifdef __BORLANDC__
# pragma .warn ...
#endif
inside sqlite code. I do not know whether
you wish to pollute the code with such
specific workarounds. If yes, I may provide
more details.
EOF |
|
1626 |
new
|
active
|
2006 Jan
|
anonymous
|
Unknown
|
2006 Jan
|
|
4
|
4
|
ALTER TABLE BUG/MISHEAVIOR
|
edit |
I have observed a "bug" in sqlite (3.2.8). when a table is created, and
then renamed via the ALTER TABLE statement, the create statement gets
adjusted (which is correct), but the new
name appears in single quotes. according to sql syntax, table and field
names are quoted by double quotes, so this creates subsequent problems
for parsing tools and such.
to test:
create table x(id)
select * from sqlite_master (observe the create statememt)
alter table x rename to x1
select * from sqlite_master (observe the create statememt again, the name is now 'x1' in quotes)
IMHO, the name should not be quoted by default, but only if it contains spaces, special characters and such (in other words, follow the quoting rules for tables that sqlite already has) |
2006-Jan-23 00:24:34 by drh:
The result that SQLite produces is technically correct, even if
it fails to meet the aesthetic expectations of this tickets author.
Changes SQLite as suggest will make the code base larger, which
is something we are loath to do. So I am converting this to a
low-priority feature request.
2006-Feb-07 07:36:19 by anonymous:
ok, lets not do "intelligent" quoting. what about the quote format ?
should it not be DOUBLE quotes, instead of single ? |
|
1622 |
code
|
active
|
2006 Jan
|
danielk1977
|
|
2006 Jan
|
|
1
|
1
|
Compiling with OMIT_PRAGMA causes an error in the test suite
|
edit |
Compiling with OMIT_PRAGMA causes an error in the test suite. The error is a Tcl level error thrown by a [db eval] command when it encounters the unknown SQL keyword "PRAGMA". |
|
1621 |
code
|
active
|
2006 Jan
|
danielk1977
|
|
2006 Jan
|
|
5
|
5
|
Compiling with OMIT_FLOATING_POINT causes a segfault in the test suite
|
edit |
Compiling with OMIT_FLOATING_POINT causes a segfault in the test suite. |
|
1597 |
new
|
active
|
2006 Jan
|
anonymous
|
Unknown
|
2007 May
|
|
1
|
3
|
wish: support DROP COLUMN
|
edit |
Please - add support for "drop column". For GIS user, as I, the Sqlite3 is a great, lighweight, powerfull tool for mananaging spatial data attributes. However, the lack of "drop column" seriously hampers it's usefullnes and still forces many GIS folks to use eg. Postgres, which is much more hard to handle than Sqlite - especially for newbies.
Plese note that Sqlite3 support was recently added to Grass (http://grass.itc.it), the most powerfull FOSS GIS. There were even discussions about making Sqlite3 a default database driver for Grass - easy to use, powerfull and fast. Please see:
http://search.gmane.org/?query=sqlite+default&email=&group=gmane.comp.gis.grass.devel&sort=relevance&DEFAULTOP=and&%3E=Next&xP=sqlite.default.&xFILTERS=Gcomp.gis.grass.devel---A
Extending the alter table commands, "drop column" most of all, could incline Grass devs to do so even more.
There already were sevaral requests from Grass users regarding "drop column" in Grass sqlite driver:
http://article.gmane.org/gmane.comp.gis.grass.user/11141
http://thread.gmane.org/gmane.comp.gis.grass.devel/9454
http://grass.itc.it/pipermail/grass5/2006-January/020764.html
Any chances?
Maciek |
2006-Jan-10 22:51:16 by drh:
http://www.sqlite.org/faq.html#q13
2006-Oct-24 21:37:43 by anonymous:
Hope to see this feature too...
2006-Oct-24 21:44:53 by anonymous:
I did this in a way that I create a parses that undestand the drop column and modify column sintax, but they create a temporary table, copy data between old and new, then create the new table and copy data back. not efficient, but works.
2007-May-20 08:26:54 by anonymous:
Please give consideration to drop column. One of SQLite's most potent features is the tiny footprint embedding. Requiring a temporary table to perform simple structure alterations effectively halves the maximum safe size of a table with regards to its primary storage context.
There's a reason it comes up as often as it does, despite the points in the FAQ. The temporary table hack is frequently a serious limiting factor. It seems likely that this wouldn't be a huge issue for the codebase, considering that other table structural alterations (add column, most notably) are apparently workable.
Please?
2007-May-20 12:56:56 by anonymous:
What would you like DROP COLUMN to do?
Copy the old table to a new table without the column in question, or just leave the old table in place without reclaiming space and simply ignore the old column?
What about constraints on that column? If they are violated should the DROP COLUMN be ignored? |
|
1591 |
build
|
active
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
3
|
2
|
Missing TEXE suffix in linking and install rules for sqlite3
|
edit |
Suffix $(TEXE) is missing at some places in Makefile.in. It makes dependencies and rules inconsistant, when TEXE is not null (e.g. .exe when compiling with MingW for MSWin target). Those rules has to be fixed:
- When linking slqite3 executable: use -o sqlite3$(TEXE) instead of -o sqlite3 in linker command line to use (especially since $(TEXE) suffix is present in rule)
- When installing: use
$(LTINSTALL) sqlite3$(TEXE) $(DESTDIR)$(exec_prefix)/bin
instead of
$(LTINSTALL) sqlite3 $(DESTDIR)$(exec_prefix)/bin
Similar fixes need to be applied to tclsqlite3 (missing in both rule and linker command line), testfixture (in linker cmdline), crashtest (in linker cmdline), lemon (in linker cmdline, with $(BEXE) suffix). |
|
1588 |
new
|
active
|
2006 Jan
|
anonymous
|
|
2006 Jan
|
|
4
|
4
|
common subexpression elimination not performed in SELECT
|
edit |
SQLite could perform common subexpression elimination to significantly speed up certain SELECT statements.
Consider the following:
CREATE TABLE t6(a);
INSERT INTO "t6" VALUES(1);
INSERT INTO "t6" VALUES(2);
-- ...imagine 5000 more rows inserted...
INSERT INTO "t6" VALUES(4999);
INSERT INTO "t6" VALUES(5000);
CREATE VIEW v6 as
SELECT x.a as xa, y.a as yb, (123.45*x.a*y.a-x.a*x.a) AS expr
FROM t6 x, t6 y;
With the following SELECT statement:
explain select expr s1, (expr/789.3) s2 from v6 order by s1;
You can see that SQLite repeats the calculation of 'expr' three times below. If the common subexpression 'expr' was calculated just once per inner-loop iteration this query would be significantly faster.
0|OpenVirtual|3|3|keyinfo(1,BINARY)
1|Goto|0|58|
2|Integer|0|0|
3|OpenRead|1|2|
4|SetNumColumns|1|1|
5|Integer|0|0|
6|OpenRead|2|2|
7|SetNumColumns|2|1|
8|Rewind|1|46|
9|Rewind|2|45|
-- first expr
10|Real|0|0|123.45
11|Column|1|0|
12|Multiply|0|0|
13|Column|2|0|
14|Multiply|0|0|
15|Column|1|0|
16|Column|1|0|
17|Multiply|0|0|
18|Subtract|0|0|
-- second expr
19|Real|0|0|123.45
20|Column|1|0|
21|Multiply|0|0|
22|Column|2|0|
23|Multiply|0|0|
24|Column|1|0|
25|Column|1|0|
26|Multiply|0|0|
27|Subtract|0|0|
28|Real|0|0|789.3
29|Divide|0|0|
30|MakeRecord|2|0|
-- third expr
31|Real|0|0|123.45
32|Column|1|0|
33|Multiply|0|0|
34|Column|2|0|
35|Multiply|0|0|
36|Column|1|0|
37|Column|1|0|
38|Multiply|0|0|
39|Subtract|0|0|
40|Sequence|3|0|
41|Pull|2|0|
42|MakeRecord|3|0|
43|IdxInsert|3|0|
44|Next|2|10|
45|Next|1|9|
46|Close|1|0|
47|Close|2|0|
48|Sort|3|57|
49|Column|3|2|
50|Integer|2|0|
51|Pull|1|0|
52|Column|-1|0|
53|Column|-2|1|
54|Callback|2|0|
55|Pop|2|0|
56|Next|3|49|
57|Halt|0|0|
58|Transaction|0|0|
59|VerifyCookie|0|2|
60|Goto|0|2|
61|Noop|0|0|
The common sub-expression elimination may have to take into account user-defined functions that do not return the same value when given the same inputs (such as random()). Some databases fold such values into a single expression, while others evaluate each such function in a seperate expression. |
2006-Jan-08 18:55:03 by drh:
Common Subexpression Eliminationi (CSE) is a planned enhancement
to occur after the VDBE is converted from a 3-operand stack machine
to a 4-operand register machine. Perhaps this year sometime.
2006-Jan-08 19:56:47 by anonymous:
I think it would be desirable to have a seperate expression optimization pass before (and without knowledge of) the VDBE code generation phase to simplify and optimize the SQL abstract syntax tree. Such high level AST transformation appears to already happen in select.c in such routines as flattenSubquery(), but it would be great if all non-VDBE-specific expression tree manipulation code could be factored out into seperate .c files so that it would be completely independent of the code generation. This could allow you support a variety of backends. |
|
1577 |
build
|
active
|
2005 Dec
|
anonymous
|
Unknown
|
2005 Dec
|
drh
|
3
|
3
|
32bit compile on 64bit system fails to build sqlite3
|
edit |
On a linux amd64 x86_64 system (dual core cpu, smp kernel)
Recieve a
./libtool --mode=link gcc -m32 -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I../sqlite-3.2.8/src -DNDEBUG -DTHREADSAFE=1 -DSQLITE_OMIT_CURSOR -DHAVE_READLINE=1 -I/usr/include/readline -lpthread \
-o sqlite3 ../sqlite-3.2.8/src/shell.c libsqlite3.la -lncurses
gcc -m32 -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I../sqlite-3.2.8/src -DNDEBUG -DTHREADSAFE=1 -DSQLITE_OMIT_CURSOR -DHAVE_READLINE=1 -I/usr/include/readline -o .libs/sqlite3 ../sqlite-3.2.8/src/shell.c ./.libs/libsqlite3.so -lpthread -lncurses
/tmp/ccQ7Hvlw.o: In function `one_input_line':
shell.c:(.text+0x35b): undefined reference to `readline'
shell.c:(.text+0x36f): undefined reference to `add_history'
/tmp/ccQ7Hvlw.o: In function `main':
shell.c:(.text+0x4a38): undefined reference to `read_history'
shell.c:(.text+0x4a63): undefined reference to `stifle_history'
shell.c:(.text+0x4a71): undefined reference to `write_history'
--- Note that the
CFLAGS=-m32 and CPPFLAGS=-m32 and LDFLAGS=-L/usr/lib
prior to running configure
It would be nice to have configure have options for 32bit vs 64 bit compiles on 64bit systems.
The plain 64bit compile works fine. |
2006-Sep-29 01:12:00 by anonymous:
I have the same error with sqlite-3.3.5-r1 but compiling as 64bit not 32.
2006-Sep-29 01:35:55 by anonymous:
go into the generated Makefile and remove -DHAVE_READLINE, or just comment out:
# READLINE_FLAGS = -DHAVE_READLINE=1 -I/usr/include/readline
|
|
1576 |
build
|
active
|
2005 Dec
|
anonymous
|
|
2005 Dec
|
|
4
|
4
|
PREFIX is not honored (cannot install as non-root)
|
edit |
Hi, sqliters!
A minor install problem in 3.2.7:
the tree cannot be installed as non-root because it does not completely honor the configure prefix. e.g.:
./configure --prefix=$HOME
...
make install
tclsh ./tclinstaller.tcl 3.2
can't create directory "/usr/lib/tcl8.4/sqlite3": permission denied
while executing
"file mkdir $LIBDIR/sqlite3"
(file "./tclinstaller.tcl" line 15)
However, /usr/lib should presumably be $HOME/lib when --prefix=$HOME.
Doing the install as root works but of course copies most of the files under $HOME but owned by root (which of course isn't the desired behaviour).
Take care, |
This is a dupe of 1549. |
|
1573 |
code
|
active
|
2005 Dec
|
anonymous
|
Shell
|
2005 Dec
|
|
3
|
3
|
Bad CSV output when data contains double quotes
|
edit |
SQLite 3.2.7 emits invalid CSV when a field value contains double quotes (or at least, it's CSV that Gnumeric cannot parse). Here's an example:
sqlite> create table foo (a text, b text);
sqlite> insert into foo values ("hello", "world");
sqlite> insert into foo values ("mr.", "o'reilly");
sqlite> insert into foo values ('12" EP', 'blah');
sqlite> .mode csv
sqlite> .output foo.csv
sqlite> select * from foo;
Here's what foo.csv looks like:
$ cat foo.csv
"hello","world"
"mr.","o'reilly"
"12" EP","blah"
Note the ambiguous quoting on line 3. If I load this file into Gnumeric, it parses the first two lines just fine. But the last line confuses it.
It appears that doubling the quote works -- at least for Gnumeric's CSV parser. That is, if I edit foo.csv to
"hello","world"
"mr.","o'reilly"
"12"" EP","blah"
then it's OK. |
This is basically a duplicate of [1312]
and related shell problem reports, though it provides a better test case than the previous reports. |
|
1566 |
new
|
active
|
2005 Dec
|
ghaering
|
VDBE
|
2005 Dec
|
|
5
|
4
|
Implement sqlite3_clone()
|
edit |
It would be nice to have an API function
int sqlite3_clone(sqlite3_stmt *src, sqlite3_stmt **dest)
which efficiently creates a new clone of the src statement. This is useful when you need to run the same query with different parameters on the same database simultaneously, like when walking through a tree-like table:
create table node (
id integer primary key not null,
parent integer,
data
);
All in all, this is not needed very often, but I reckon implementing the API function would be relatively trivial. |
2005-Dec-19 16:04:54 by anonymous:
If you want to re-execute the same query with different parameters, you should just use sqlite3_reset() instead of sqlite3_finalize(). This will reset the query so that it is ready to be executed again. Then issue the sqlite3_bind_...() calls to bind new values to the parameters that you need to change.
2005-Dec-19 16:06:47 by anonymous:
Oops, sorry I missed the "simultaneously" in your post the first time I read it. |
|
1565 |
doc
|
active
|
2005 Dec
|
anonymous
|
|
2005 Dec
|
|
4
|
4
|
wrong return-type specified for sqlite3_db_handle in c-api-reference
|
edit |
The c-api-documentation tells, that sqlite3_db_handle returns an int. This is not true. It returns the databasehandle as sqlite3*.
The line in capi3ref:
int sqlite3_db_handle(sqlite3_stmt*);
should be replaced by
sqlite* sqlite3_db_handle(sqlite3_stmt*);
|
|
1564 |
build
|
active
|
2005 Dec
|
anonymous
|
|
2005 Dec
|
|
4
|
4
|
Need GNU awk
|
edit |
The autotools (esp. automake) need to be sure to use GNU awk. I attempted to build sqlite on the following system:
SunOS apache 5.10 Generic_118822-23 sun4u sparc SUNW,Sun-Fire-880
On this the system `which awk` is not a GNU awk. The build proceeds as follows (up to the first error):
sed -e s/--VERS--/3.2.7/ ./src/sqlite.h.in | \
sed -e s/--VERSION-NUMBER--/3002007/ >sqlite3.h
gcc -g -O2 -o lemon ./tool/lemon.c
cp ./tool/lempar.c .
cp ./src/parse.y .
./lemon -DSQLITE_OMIT_CURSOR parse.y
cat parse.h ./src/vdbe.c | awk -f ./mkopcodeh.awk >opcodes.h
awk: syntax error near line 36
Apparently this syntax is not available in the standard awk on this system. Making `which awk` point to a GNU awk resolves the issue.
Possible solutions:
0. Replace all instances of awk with gawk in the scripts
1. Use Autotools to request/use gawk instead of awk (maybe a hints file?)
Brady |
|
1562 |
warn
|
active
|
2005 Dec
|
anonymous
|
Unknown
|
2005 Dec
|
|
3
|
1
|
i64 not defined in 32bit compiler
|
edit |
Our 32-bit compiler doesn't recognize the i64 type.
To force through compilation we've defined i64 as long.
This seems to work but we have been experiencing failures in the VDBE module.
We'd rather not revert to Sqlite2.
Any suggestions?
(I'll be opening a seperate ticket regarding the VDBE failure) |
2005-Dec-16 01:22:41 by drh:
Compile with -DSQLITE_32BIT_ROWID=1 |
|
1558 |
new
|
active
|
2005 Dec
|
anonymous
|
VDBE
|
2005 Dec
|
|
3
|
4
|
Request more debugging info when SQL statements in progress
|
edit |
I am sporadically receiving the error message "Can't commit transaction - SQL statements in progress." I believe my own code is at fault, not anything in SQLite, but I would appreciate help in diagnosing the problem in my code.
SQLite obviously knows that I've lost track of one or more prepared statements that haven't run to completion, it isn't telling me what statements those are. I'm wondering if there is any way of getting that information. Armed with that knowledge, I can probably fix my code fairly quickly.
Note: DRH did provide a workaround that involved recompiling with extra debugging information, which will probably help me in the short run. This feature request is aimed at making that debugging process easier for future developers. :-) |
|
1555 |
doc
|
active
|
2005 Dec
|
anonymous
|
BTree
|
2005 Dec
|
appledev
|
2
|
4
|
sqlite+Crystal reports connection
|
edit |
I have problem of sqlite and crystal report connection |
|
1552 |
new
|
active
|
2005 Dec
|
anonymous
|
Unknown
|
2005 Dec
|
|
5
|
4
|
Adding .read FILE support to the C API
|
edit |
Hello!
i've attempted to implement an SQL function which behaves like the sqlite3 shell's .read FILE feature. The problem is that functions don't have a handle to their DB, and therefor cannot call an sqlite3_exec() to actually evaluate the read-in code. The ability to do this from client code would be "really cool." :)
On a related note: i'm using C++, and found that the following won't compile:
std::string fname( sqlite3_value_text( argv[i] ) );
because sqlite3_value_text() explicitely returns an unsigned pointer. The STL uses plain old (const char *), so the following workaround is needed:
std::string fname( static_cast<char const *>( sqlite3... ) ); |
|
1550 |
new
|
active
|
2005 Dec
|
anonymous
|
Unknown
|
2005 Dec
|
|
3
|
3
|
Triggers across attached databases
|
edit |
Support for triggers across attached databases would be very nice.
Example:
sqlite3 db1
> CREATE TABLE Test (pk integer primary key autoincrement, Data vachar(128)not null);
> ATTACH db2 AS history;
> CREATE TABLE history.TestHistory (ObjectTable_fk integer not null, Action integer not null, Timestamp smalldatetime not null);
> CREATE TRIGGER trTestHistoryUpdate UPDATE ON Test FOR EACH ROW
BEGIN
INSERT INTO TestHistory VALUES(OLD.pk, 0, CURRENT_TIMESTAMP);
END;
<Insert some posts into Test...>
> Update Test SET Data='FooBar' WHERE pk=1;
This results in the error: "SQL error: no such table: main.TestHistory"
Changing the trigger to
INSERT INTO history.TestHistory VALUES(OLD.pk,0,CURRENT_TIMESTAMP);
results in "SQL error: near ".": syntax error".
Attaching the databases in the reverse order and then create the trigger results in "SQL error: trigger trTestHistoryUpdate cannot reference objects in database db1"; |
|
1549 |
build
|
active
|
2005 Dec
|
anonymous
|
|
2005 Dec
|
|
5
|
4
|
install fails for non-root user when TCL active
|
edit |
Hi, guys!
Steps to reproduce:
As a non-root user on a system without TCL components, configure the tree with a --prefix under, e.g., your $HOME:
./configure --prefix=$HOME
Then make/make install:
If TCL is enabled, the installation of the tcl parts fail because they try to install under /usr/..., disregarding the $prefix:
Error:
tclsh ./tclinstaller.tcl 3.2
can't create directory "/usr/lib/tcl8.4/sqlite3": permission denied while executing
"file mkdir $LIBDIR/sqlite3"
(file "./tclinstaller.tcl" line 15)
i tried building with the --without-tcl option, but then configure fails:
checking for Tcl configuration... configure: error: no directory doesn't contain tclConfig.sh |
|
1547 |
event
|
active
|
2005 Nov
|
anonymous
|
Unknown
|
2005 Dec
|
|
1
|
1
|
slow insert into indexed table and slow index create on huge table
|
edit |
i have CREATE TABLE test (f1 VARCHAR(40), f2 INTEGER, f3 DOUBLE) with CREATE INDEX test_idx ON test(f1).
i try to load 270M(270,000,000) records into this table within transaction.
PRAGMA page_size = 8192
PRAGMA cache_size = 40000
PRAGMA syncronouse = OFF
i use Dell server :
2 x Intel XEON 2.8 Ghz with Multi-threading.
4 GB memory
2 x 72Gb HD UltraScsi320
for now it's run 7.5 hours and loaded just 30M records |
2005-Nov-30 19:03:42 by anonymous:
What does your INSERT statement look like? Also, its more efficient to create the index for the table AFTER the insert has completed.
2005-Nov-30 21:50:38 by anonymous:
My Insert statement: INSERT INTO test VALUES (?, ?, ?)
I already checked option to create index after insert.
Insert took 55 min. Create index was stopped after 24 hours
2005-Nov-30 22:52:32 by anonymous:
Do you make inserts inside transaction ? If not, begin
transaction before all inserts, commit it and then create
index
2005-Nov-30 22:57:07 by anonymous:
it's already done.
single begin transaction before inserts, single commit after
2005-Dec-01 00:28:06 by anonymous:
250 mln inserts in 55 min (your last statement) is about 76000 inserts/sec. That's a bit slow (for SQLite). My trivial system P-IV 3 GHz HT, 1 GB RAM, 100 GB Maxtor ATA 100 does that with a rate no lower than 105000 inserts/sec (non-indexed db, about 300 mln records, same schema, prepared statements).
Anyway, if you're not satisfied with performance, do that with MS SQL Server - you'll easily get 1000 inserts/sec or even lower with 100% CPU usage.
2005-Dec-01 00:36:37 by anonymous:
Let me guess: you are running Windows with Symantech Antivirus active and Indexing Service turned on, right?
2005-Dec-01 00:43:16 by drh:
When creating the index, entries have to be inserted at random
places throughout the (roughly) 10GiB disk file. Since you probably
do not have 10GiB or RAM for caching, you are constanting having
to read and write disk pages. In other words, you are thrashing.
To make it go faster, you need to establish some kind of
locality of reference so pages get reused more often. Reused
pages are in cache and work much faster.
After you have the data loaded but unindexed, perhaps try something
like this:
ATTACH 'new.db' AS n;
CREATE TABLE n.test(f1 text, f2 integer, f3 double);
CREATE TEMP TABLE prefix(x text) AS
SELECT DISTINCT substr(f1,1,3) FROM test ORDER BY 1;
INSERT INTO n.test
SELECT f1, f2, f3
FROM prefix, test
WHERE x=substr(f1,1,3);
CREATE INDEX n.test_idx ON test(f1);
Suppose there are N entries in the prefix table. The
INSERT statement makes N passes over the original test
table inserting all entries with that prefix into the
new test table. In the end, the entries in the new
test table are approximately sorted. So then when you
go to create the index, you have more locality of reference
and the index creation should go faster.
In theory at least. Your mileage may very. You might want
to adjust the size of your prefix depending on what your
data looks like and how it is distributed.
2005-Dec-01 07:16:27 by anonymous:
thank you for inputs.
application runing on RHEL4 without antivirus, and any unused daemons. The data is already sorted. "low" performance at insert to unindexed table caused by data generation process. but i don't understand the performance of index creation. most of time one CPU at 100% usage 3 other CPUs at 98% waits. |
|
1546 |
code
|
active
|
2005 Nov
|
anonymous
|
|
2005 Nov
|
|
1
|
1
|
Creating unique index on non-unique column leads to corr. on SQLite2
|
edit |
Like ticket #1115, SQLite version 2 suffer too from the bug where :
BEGIN;
CREATE TABLE t1(a);
INSERT INTO t1 VALUES(1);
INSERT INTO t1 VALUES(1);
CREATE UNIQUE INDEX i1 ON t1(a);
COMMIT;
PRAGMA integrity_check
fails.
When "CREATE UNIQUE INDEX" fails within a transaction, (and within a transaction only), the index is still created. |
|
1543 |
build
|
active
|
2005 Nov
|
anonymous
|
|
2005 Nov
|
|
2
|
1
|
File encrypted or corrupted while using french characters
|
edit |
Hi,
if we use the french characters in the database file path as i mentioned the characters above is throwing the error while creating a new database file or connecting with old one using realbasic as front end. |
2005-Nov-29 18:33:20 by drh:
Why do you think this is a problem with SQLite and not with realbasic?
2005-Nov-29 20:16:12 by anonymous:
If this happens using the REALbasic wrapper for SQLite, then the bug is definitely in the wrapper and not in SQLite. The bug has been fixed and should appear in the next version of REALbasic.
2005-Nov-30 06:32:25 by anonymous:
Dear drh;
In real basic folderitem is working fine with this french characters. i am getting this error in the line as "if db.connect then" it throws false and the error message shown as "File is encrypted or not a database file". Please confirm this problem is not with SqLite while using the following characters ÀàÁáÂâÃãäÄÅåÈèÉéÊêËëÌìÍíÎîÏïÒòÓóÔôÕÖö.
with Thanks,
Vinoth.
Vino_it@hotmail.com |
|
1542 |
code
|
active
|
2005 Nov
|
anonymous
|
Unknown
|
2005 Nov
|
|
2
|
4
|
wrong field names in views with quoted table name qualifiers
|
edit |
SQLite returns wrong field names in views using quoted table name qualifiers.
Examples:
The following statement
create view custview as select [customer].company from customer
creates a view with one field: customer (should be company)
The next one:
create view custview as select [customer].company, [customer].address from customer
creates a view with two fields: customer and customer:1 (should be company and address)
Reproduced with version 3.2.7 on Win32. |
|
1541 |
code
|
active
|
2005 Nov
|
anonymous
|
Unknown
|
2005 Nov
|
|
1
|
1
|
Ticket #924 not fixed in the 2.8 branch
|
edit |
Ticket 924: http://www.sqlite.org/cvstrac/tktview?tn=924
This problem seams to have been fixed on the 3.2 branch but is still in the 2.8.16 |
|
1532 |
new
|
active
|
2005 Nov
|
anonymous
|
TclLib
|
2005 Nov
|
|
4
|
4
|
Variables don't get replaced in ATTACH statements.
|
edit |
When using mydb eval {ATTACH $var as var} in tcl scripts, $var is not replaced by its corresponding value.
proc updatedb { filename } {
sqlite3 mem :memory:
...
mem eval {ATTACH $filename as file}
mem eval {REPLACE INTO file.table SELECT * FROM table}
mem close
}
Will result in the errormessage: "No such table file.table" (additionally a file called $filename will be created in the current dir). But if you quote the ATTACH statement and let TCL handle the replacement it will work just fine. |
This behavior is exactly as defined in the documentation.
Variable substitution is only allowed in places where it is valid
to put an expression. There are important technical reasons for
this restriction.
Works as designed.
On second thought, I suppose it would be possible to extend the
parser so that it allowed a (string value) expression at the
point in the ATTACH command where a filename is needed. I will
change this into an enhancment request. |
|
1528 |
new
|
active
|
2005 Nov
|
anonymous
|
Unknown
|
2005 Nov
|
|
5
|
4
|
Add Build Date To Command Line Greeting
|
edit |
When SQLite v3.x is started on the command line, show the build date and time. For example:
[rlc@bobcp4 bld]$ sqlite3
SQLite version 3.2.7 built 11/18/2005 06:44
Enter ".help" for instructions
sqlite>
|
2005-Nov-24 17:17:16 by anonymous:
The date format 11/18/2005 06:44 is USA centric, which, in my opinion, is not good for a globally used product.
Please use the human readable notation according to ISO 8601 , that is ccyy-mm-dd, or the current locale.
See also: open_directory_project |
|
1525 |
event
|
active
|
2005 Nov
|
anonymous
|
Unknown
|
2005 Nov
|
anonymous
|
1
|
2
|
error creating database
|
edit |
with the 3.2.7 sqlite.dll i could'nt create database when the directories is with 'ç' character like 'c:\françois\'
but with the 3.0.2 sqlite.dll it's work |
2005-Nov-18 01:44:28 by anonymous:
I'm pretty sure sqlite3_open() is expecting any non-ASCII characters in the filename to be encoded as UTF-8 rather than ISO8859-1; i.e. a c-cedilla needs to be encoded as two bytes, not one. |
|
1522 |
code
|
active
|
2005 Nov
|
anonymous
|
Unknown
|
2005 Nov
|
|
1
|
3
|
Make test fails in manydb 1.82-3.299 mac os x 10.4.3 ppc
|
edit |
OS: Mac OS X 10.4.3 ppc
Compiler: powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5247)
While running "make test" from a cvs checkout on Sun Nov 13 19:01:54 PST 2005, I get these errors:
653 errors out of 23390 tests
Failures on these tests: manydb-1.82 manydb-1.83 manydb-1.84 ................. manydb-3.296 manydb-3.297 manydb-3.298 manydb-3.299 |
2005-Nov-15 01:13:13 by drh:
These failures likely result from running out of file
descriptors. The manydb tests need about 1000 file descriptors.
Linux provides this many (on most distributions). But perhaps
Mac OS X does not. Does anybody know? |
|
1521 |
code
|
active
|
2005 Nov
|
anonymous
|
Unknown
|
2005 Nov
|
|
3
|
2
|
ORDER BY sorts incorrectly with aliased fields
|
edit |
When executing a SELECT call and aliasing fields that already exist in the table, sorting does not work correctly on the aliased fields.
Here's a quick example:
CREATE TABLE sort_table (name, name_alt);
INSERT INTO sort_table (name, name_alt) VALUES ("a", "z");
INSERT INTO sort_table (name, name_alt) VALUES ("b", "y");
INSERT INTO sort_table (name, name_alt) VALUES ("c", "x");
This simple query works correctly:
sqlite> SELECT name_alt FROM sort_table ORDER BY name_alt;
name_alt
x
y
z
Aliasing name_alt as name throws off the sorter:
sqlite> SELECT name_alt AS name FROM sort_table ORDER BY name;
name
z
y
x
The results should be the same as in the first query and it works correctly in MySql. I'm trying to use this kind of query for a translation library. The only workaround I can think of is something like this:
SELECT name_alt AS name, name_alt FROM sort_table ORDER BY name_alt;
This works, but is not ideal. |
2005-Nov-12 17:28:20 by anonymous:
In cases like this you can use ordinal numbers as arguments to ORDER BY; replacing the last 'name' with '1' (no quotes) returns the correct results.
2005-Nov-12 19:20:24 by anonymous:
Yes, this does indeed work, and it makes for a simpler hack than my original one. This is still not the correct behavior though, and should be fixed so that a hack is not required at all.
2005-Nov-13 15:36:22 by anonymous:
Citing one database's behavior is interesting, but can you quote the paragraph in the SQL standard that shows the behavior you seek is correct?
2005-Nov-13 17:19:37 by anonymous:
Whether or not its in the SQL standard is somewhat irrelevent if you keep up to date with the mailing list. "Expected behavior", "how do all the other databases do it" and "makes sense" are often the governing factors in implementing changes to SQLite. In this case, proposing this change meets all 3 criteria.
2005-Nov-13 18:03:49 by anonymous:
SQLite does it one way. MySQL does it another way. Both behaviors could be argued to be correct. The SQL standard is certainly a good way to decide on a valid behavior. Besides, the way MySQL does it is not necessarily representative of "all other databases". At least list the output of a few major databases before making such an assumption.
2005-Nov-13 20:22:40 by anonymous:
I'm the guy who originally filed the ticket. I'm just an average guy, without the time or resources to run this on lots of different databases. The sql standards are not free, and I don't have a copy of any of them. I've also had very little luck finding information on the internet.
All that said, I believe it would be difficult to argue that the current behavior in SQLite is correct. In all other cases, the aliased column is accepted as an ORDER BY field. If I didn't want to override the original field for the purposes of the query, why would I explicitly do so? On the other hand, there are good reasons for wanting to explicitly override the column, for goals that cannot otherwise be achieved without hacks. If I didn't want to override the field, I could get the desired effect by doing nothing.
2005-Nov-14 00:08:30 by anonymous:
This should really be taken to the mailing list; there are people there with access to many different databases and some of them own copies of the SQL standard. This issue of name resolution also touches on the concerns expressed in #1111, #1213, and #1228.
2005-Nov-14 03:40:28 by anonymous:
What should the following query return?
SELECT name_alt AS name, * FROM sort_table ORDER BY name;
Who knows - it is ambiguous.
2005-Nov-14 03:57:44 by anonymous:
I don't understand your point. Your example is ambiguous because there are two columns with the same name in the result set. The example in the original ticket is not ambiguous and should give the expected result.
2005-Nov-14 05:08:06 by anonymous:
The original query is ambiguous because you can refer to columns not explicitly mentioned in the SELECT to ORDER BY. No different from:
select a, b, c from foo order by d;
2005-Nov-14 13:41:32 by anonymous:
Not true: SELECT name_alt AS name FROM sort_table ORDER BY name. The field referenced by ORDER BY does appear in the SELECT clause, after the AS. This is perfectly legitimate and the preferred way of sorting expressions.
2005-Nov-14 14:33:21 by anonymous:
"ORDER BY name" is abmiguous because it can refer to the name_alt column via the alias OR the original name column from sort_table. You can ORDER BY things not mentioned in the SELECT.
SELECT name_alt AS name FROM sort_table ORDER BY name
2005-Nov-14 16:26:42 by anonymous:
Yeah, true -- but it's pretty obvious which one we're referring to, since we explicitly aliased the original field for the purposes of this query.
2005-Nov-14 16:48:43 by anonymous:
It's only obvious that you explicitly created an ambiguous column and that is undefined behaviour. Whether it happens to appear in the SELECT is not relevant. If you can demonstrate that the majority of databases support MySQL's behaviour, then that's another matter.
2005-Nov-14 19:35:25 by anonymous:
I just verified that this works as I expected on MySQL, PostgreSQL, and MS SQL Server. I don't have access to Oracle. |
|
1519 |
code
|
active
|
2005 Nov
|
anonymous
|
Unknown
|
2005 Nov
|
|
3
|
4
|
Size double with blob data on UPDATE ?
|
edit |
I've a table with some fields and a blob field. I execute an INSERT INTO with NULL value on the blob field and then use the sqlite3_prepare with an UPDATE statement, to load a file into the blob field.
The first time I execute an UPDATE over the record (without updating the blob field) the database size is doubled. Next UPDATEs over the same record doesn't seem to show the same problem.
Temporary solving with a VACUUM at the end of the program. |
|
1515 |
code
|
active
|
2005 Nov
|
anonymous
|
Unknown
|
2005 Nov
|
|
4
|
3
|
Quotes incorrect included in colum names.
|
edit |
The names of columns returns by sqlite_exec has the quotes which has written in the query.
I will try to show with examples in the sqlite command line.
create table test("Full Name" varchar(30), "Login" varchar(15), Age integer);
insert into test ("Full Name", "Login", Age) values ("Enrique Esquivel", "the_kique", 24);
.headers on
select * from test;
SQLite returns:
Full Name|Login|Age
Enrique Esquivel|the_kique|24
But when write:
select "Full Name", "Login", Age from test;
returns:
"Full Name"|"Login"|Age
Enrique Esquivel|the_kique|24
Moreover when quote all fields:
select "Full Name", "Login", "Age" from test;
returns:
"Full Name"|"Login"|"Age"
Enrique Esquivel|the_kique|24
Also:
select [Full Name], [Login], [Age] from test;
SQLite returns wrong:
[Full Name]|[Login]|[Age]
Enrique Esquivel|the_kique|24
The quotes should be used for SQLite only for understand the identifiers, the fields in result must be unquoted. Try to test with other dbms and anyone has this behavior. |
|
1508 |
code
|
active
|
2005 Nov
|
anonymous
|
BTree
|
2005 Nov
|
|
1
|
3
|
sqlite 2.8.16 crashes on 64-bit / strict memory alignment archs
|
edit |
A few months ago, sqlite3 was fixed on 64-bit / strict memory alignment architectures. Would it be possible for those fixes to be backported to the version_2 code? I have an OpenBSD/sparc64 machine which I can provide ssh access to (as I did before to drh). I know sqlite2 is mostly unsupported, but as php5 uses sqlite2, it would be nice to have these fixes backported. |
2006-Jan-05 02:28:23 by anonymous:
with the attached patch, sqlite 2.8.17 passes all the regressions tests on openbsd/amd64 and openbsd/sparc64. |
|
1506 |
new
|
active
|
2005 Nov
|
anonymous
|
Shell
|
2005 Nov
|
|
1
|
4
|
Add some flags to .import command
|
edit |
I think it would be very useful to be able to instruct .import to use either "INSERT INTO" or "INSERT OR REPLACE INTO" via some flag.
Something along the lines of:
.import FILE TABLE REPLACE
One other extension of .import that I'd find useful is to be able to instruct .import not to error out when malformed line of input is found, but instead just print the error message as it does now and continue on with next line.
Why is this useful? Sometimes I need to import large files with several million lines into SQLite for some statistical analysis and some of those lines are malformed sometimes. As it is now, sqlite3.exe will error out at that line and then I have to fix or remove that line from input file and restart the import. If there are other malformed lines I need to restart import again. Needless to say this is very time consuming and losing a few lines out of few millions wouldn't change my results (statistics) a bit.
Perhaps both above mentioned flags could be combined into one with 4 possible values. |
2005-Nov-02 14:43:52 by anonymous:
I've attached a patch that does what I proposed in this ticket. It uses MODE argument to set two proposed flags. Other flags can be added easily, but it's kind of cumbersome to document all posible values of MODE argument. |
|
1504 |
code
|
active
|
2005 Nov
|
anonymous
|
Pager
|
2005 Nov
|
|
1
|
3
|
Multithreaded DB lock not released using Begin/Commit between threads
|
edit |
When using transaction-based insertion of rows in v3.2.7 in a multi-threaded environment, one thread appears not to release the database lock for any competing threads to be able to issue an "INSERT" statement (the thread issuing the "COMMIT" apparently). This problem does not appear in v2.8.16. The problem also appears in Linux (RH-9) as well.
I'm attaching "testsqlite.c", a test application (compiled in a WIN32 environment) that will duplicate the issue (Define SQLITE_2_8_16 or SQLITE_3_2_7 depending on the version of SQLite library to test against).
Direct any questions to Erik -> lonepenguin@hotmail.com
Thank You. |
|
1503 |
doc
|
active
|
2005 Oct
|
anonymous
|
|
2005 Oct
|
|
5
|
4
|
typo in datatype3.html
|
edit |
http://www.sqlite.org/datatype3.html
SQLite treats the expression "a IN (x, y, z)" as equivalent to "a = z OR a = y OR a = z".
should be
... equivalent to "a = x OR ... |
|
1502 |
code
|
active
|
2005 Oct
|
anonymous
|
Unknown
|
2005 Oct
|
anonymous
|
2
|
3
|
When selected in a union, view column names are incorrect.
|
edit |
When used in a union, a view transfers an underlying table's column names into the result set.
The expected result is that column names in the second half (or further) of the union needn't match those in the first.
Problem is also visible in TCL binding.
.mode columns
.headers on
select 'Create two tables, with nasty column names.' as remark;
create table t_a (c_a integer);
create table t_b (c_a integer);
select 'Create two views which each alias the column names of the above tables.' as remark;
create view v_a as select c_a as pretty from t_a;
create view v_b as select c_a as pretty from t_b;
select 'Insert some data' as remark;
insert into t_a values (1);
insert into t_b values (2);
select 'Notice that the views work fine by themselves.' as remark;
select 'The column names are both as we asked.' as remark;
select pretty from v_a;
select pretty from v_b;
select 'Notice that used in concert, with a join, the column name is now wrong.' as remark;
select pretty from v_a
union select pretty from v_b;
select 'Aliasing the name of the column in the first half of the join is no help.' as remark;
select pretty as pretty from v_a
union select pretty from v_b;
select 'Alias the name of the column in the second half of the join "fixes" the result.' as remark;
select pretty from v_a
union select pretty as pretty from v_b;
|
2005-Oct-25 03:05:27 by anonymous:
same as ticket 1228
2005-Oct-26 07:59:17 by anonymous:
see also #1327 |
|
1500 |
code
|
active
|
2005 Oct
|
anonymous
|
Unknown
|
2005 Oct
|
|
4
|
4
|
MIssing file listing permission causes DB opening/creation to fail
|
edit |
When using SQLite in PHP 5.0.5, trying to create or open a SQLite database in a directory to which the path does not have file listing (r) permissions all the way, the opening or creation fails.
Please see PHP bug report #34868:
<A HREF="http://bugs.php.net/bug.php?id=34868" TARGET="_blank">http://bugs.php.net/bug.php?id=34868 The PHP developers say that this is phenomenon is caused by the SQLite code, and suggested that I should forward this to you for possible investigation, as they merely bundle the lib with their PHP releases (and have some kind of minimal wrapper around it).
It is worth noting that this problem seem to appear in other PHP situations as well (then mostly connected to the usage of PHP's "Safe Mode" or "open_basedir" restrictions), but should appear with just about any application using getcwd() under IBM AIX.
The underlying reason is that getcwd() under IBM AIX fails if file listing (r) permissions are missing somewhere along the path. However, I am not sure if there are other, equal, means of determining the current working directory without using getcwd().
Best regards,
Bjorn Wiberg |
|
1498 |
build
|
active
|
2005 Oct
|
anonymous
|
|
2005 Oct
|
|
4
|
3
|
SQLite Cygwin support
|
edit |
I'm attaching a patch to Makefile.in to support building sqlite3 on Cygwin, as well as the results of make test from 3.2.7.
Binary packages are available at:
ftp://sunsite.dk/projects/cygwinports/release/sqlite3/ |
|
1494 |
code
|
active
|
2005 Oct
|
anonymous
|
Unknown
|
2005 Oct
|
|
1
|
2
|
intermittent null reference exception in sqlite3_open
|
edit |
Doing a c# (.net 1.1 / visual studio 2003 / winxp) project with a (so far) small db (5 tables, max 1000 lines per table). About 10% of startups will fail with a NullReferenceException in sqlite3_open().
This is on a dell optiplex, win xp pro sp 2, 1G ram, P4@2.6GHz, using c# in visual studio 2003 version 7.1.3088 with .net framework 1.1.4322 sp 1.
Methods in Sqlite3.dll are imported with dllimport like this:
[DllImport("Sqlite3.Dll", EntryPoint="sqlite3_open")]
public static extern int sqlite3_open( string filename, out IntPtr dbhandle );
This would seem to be an error on my part or .net, except that this is the first sqlite call in the entire application and it fails only sometimes and the file name parameter is hard-coded. 90% of the time the application works fine.
Of course, it could be .net messing things up. Anyway I can't find this on the web, sorry for taking up your time if it's not a bug.
And no, I haven't got a program specifically for testing this thing.
Below is the stack trace for the System.NullReferenceException, the top line is the call into sqlite3.dll. The filename parameter is not null, it is "C:\DOCUMENTS AND SETTINGS\MARTIN.WANGEL\MY DOCUMENTS\VISUAL STUDIO PROJECTS\SOLUTION\BIN\DEBUG\SOLUTIONDATA.SQLITE" and it is thoroughly checked for null and for emptiness.
at Solution.mwDatabaseSQLite.sqlite3_open(String filename, IntPtr& dbhandle)\r\n
at Solution.mwDatabaseSQLite.Open() in c:\\documents and settings\\martin\\my documents\\visual studio projects\\solution\\mwdatabaseclasses.cs:line 149\r\n
at Solution.DBUtils.VerifyDatabase(Type t, String connstr, dbtype dbtyp) in c:\\documents and settings\\martin\\my documents\\visual studio projects\\solution\\dbutils.cs:line 287\r\n
at Solution.FrmMain..ctor() in c:\\documents and settings\\martin\\my documents\\visual studio projects\\solution\\form1.cs:line 1499\r\n
at Solution.FrmMain.Main() in c:\\documents and settings\\martin\\my documents\\visual studio projects\\solution\\form1.cs:line 1285
/Martin |
2005-Oct-27 21:12:22 by anonymous:
Maybe you should look at "Wiki", "SQLite wrappers", ".NET Framework" for an other way to do this.
2005-Oct-28 00:39:27 by anonymous:
the calling conventions of standard built DLL are __cdecl, not __stdcall (or WINAPI)... check if .NET Framework is able to call __cdecl import functions... in my mind it will call only STDCALL routines (which is the default on WIN32 API) |
|
1493 |
code
|
active
|
2005 Oct
|
anonymous
|
Parser
|
2005 Oct
|
|
3
|
3
|
lemon: pathsearch uses wrong directory separator under Win32
|
edit |
The pathsearch function in lemon.c uses a semicolon (;) to separate the directories in the path. Under Win32 systems this should be a colon (:). |
2005-Oct-18 09:37:10 by anonymous:
--- lemon.c.orig 2005-10-18 11:27:55.753467000 +0200
+++ lemon.c 2005-10-18 11:29:11.897825400 +0200
@@ -2791,13 +2791,16 @@
{
char *pathlist;
char *path,*cp;
+ char ds;
char c;
extern int access();
#ifdef __WIN32__
cp = strrchr(argv0,'\\');
+ ds = ';';
#else
cp = strrchr(argv0,'/');
+ ds = ':';
#endif
if( cp ){
c = *cp;
@@ -2812,7 +2815,7 @@
path = (char *)malloc( strlen(pathlist)+strlen(name)+2 );
if( path!=0 ){
while( *pathlist ){
- cp = strchr(pathlist,':');
+ cp = strchr(pathlist,ds);
if( cp==0 ) cp = &pathlist[strlen(pathlist)];
c = *cp;
*cp = 0;
2005-Oct-18 09:39:00 by anonymous:
More readable version of the patch:
--- lemon.c.orig 2005-10-18 11:27:55.753467000 +0200
+++ lemon.c 2005-10-18 11:29:11.897825400 +0200
@@ -2791,13 +2791,16 @@
{
char *pathlist;
char *path,*cp;
+ char ds;
char c;
extern int access();
#ifdef __WIN32__
cp = strrchr(argv0,'\\');
+ ds = ';';
#else
cp = strrchr(argv0,'/');
+ ds = ':';
#endif
if( cp ){
c = *cp;
@@ -2812,7 +2815,7 @@
path = (char *)malloc( strlen(pathlist)+strlen(name)+2 );
if( path!=0 ){
while( *pathlist ){
- cp = strchr(pathlist,':');
+ cp = strchr(pathlist,ds);
if( cp==0 ) cp = &pathlist[strlen(pathlist)];
c = *cp;
*cp = 0;
2005-Oct-19 14:05:27 by anonymous:
Cygwin and other Posix emulation layers on Windows require ':' for path separators, so you cannot blindly rely on __WIN32__ to make this determination. |
|
1491 |
new
|
active
|
2005 Oct
|
anonymous
|
Shell
|
2005 Oct
|
|
4
|
4
|
syntax error with " .mode column:
|
edit |
when I key in ".mode column" without any space, the command is work well.
If I key in "^.mode column" with a space(the ^ means a space) , it will show the following error message :
SQL error: near "syntax": syntax error
Would you like fix it on next version, please ?
Have a nice day!
John Wei |
|
1489 |
code
|
active
|
2005 Oct
|
anonymous
|
|
2005 Oct
|
|
3
|
2
|
Bad permissions on install-sh prevent 'make install' from completing
|
edit |
It's a trivial problem -
install-sh has incorrect permissions via CVS, resulting in 'make install' failing.
Error:
make installtclsh ../sqlite/tclinstaller.tcl 3.2../sqlite/install-sh -c -d /usr/local/libmake: execvp: ../sqlite/install-sh: Permission deniedmake: *** [install] Error 127
Permissions:
-rw-r--r-- 1 cat other 5598 Sep 28 2001 ../sqlite/install-sh
Fix:
chmod 755 ../sqlite/install-sh |
|
1488 |
code
|
active
|
2005 Oct
|
anonymous
|
|
2005 Oct
|
|
1
|
1
|
Collate Reverse does not exists?
|
edit |
when I execute below SQL
CREATE Unique INDEX index10 On Test2 (
F1 Collate BINARY ,
F2 Collate REVERSE DESC)
there is a error message:
no such collation sequence: REVERSE
but the latest document said that binary ,nocase , reverse is common collate function. what is wrong with my sql? |
|
1487 |
code
|
active
|
2005 Oct
|
anonymous
|
BTree
|
2005 Oct
|
|
1
|
3
|
Corrupt database causes indefinite loop in sqlite3_step()
|
edit |
I had a database become corrupt (no idea why, 57 other databases of similiar information are fine). When attempting to work with the database and execute a SELECT query the application froze in an endless loop inside sqlite3_step(). Upon further investigation (which is when I found the db was corrupt) it seems to be stuck inside the btree code (as reported by Sample). I tested the same query and alternates from sqlite3 CLI and got the same results. The exact query causes an infinite loop. Leaving off part of the WHERE statement (and making it broader) or removing one of the reporting columns simply causes a corruption error.
I have the original database as-is and the SQL query that can be run to cause the problem.
OS: Mac OS X 10.4.2 |
|
1485 |
code
|
active
|
2005 Oct
|
anonymous
|
Unknown
|
2005 Oct
|
jshen
|
3
|
1
|
cyrilic problem(suppose Unicode as a whole, for PPC)
|
edit |
I think there is a problem in the utf.c file. |
2005-Oct-14 06:18:45 by anonymous:
Pocket PC support isn't provided in the default SQLite provider. The code necessary to support the Pocket PC is at http://sourceforge.net/projects/sqlite-wince and its there that a bug report should be filed. |
|
1484 |
code
|
active
|
2005 Oct
|
anonymous
|
Unknown
|
2005 Oct
|
|
4
|
4
|
Solaris8 awk problem
|
edit |
/usr/bin/awk in Solaris8 doesn't have sub() function.
To avoid this problem, use @AWK@ in Makefile and add AC_PROG_AWK in configure.ac. |
|
1483 |
doc
|
active
|
2005 Oct
|
anonymous
|
Unknown
|
2005 Oct
|
xdong
|
1
|
3
|
expression document:describe ERROR.
|
edit |
http://www.sqlite.org/lang_expr.html about the "CASE" expression,"CASE [expr] ( WHEN expr THEN expr )+ [ELSE expr] END " does not work.
May the right is "CASE [expr] WHEN condition THEN expr [ELSE expr] END "
others:all the documents about SQLite are scattered, someone should organize them for the user.It is very useful,sometime is important than the software itself's development.
infree at Beijing
|
|
1480 |
event
|
active
|
2005 Oct
|
anonymous
|
Unknown
|
2005 Oct
|
|
1
|
3
|
Wrong SQL statement crashes PHP+Apache
|
edit |
Configuration:
- Windows NT VMSRV01 5.2 build 3790
- Apache/2.0.53 (Win32)
- PHP 5.0.5 Windows binary
- SQLite 2.8.14 (included with PHP 5.0.5)
Windows application event log error:
Faulting application Apache.exe, version 2.0.53.0, faulting module php5ts.dll, version 5.0.5.5, fault address 0x000cd0d5.
Description:
Firing a SQL statement like
SELECT A.f1, A.f2, B.f3, B.f4 FROM t1 AS INNER JOIN t2 ON A.f1 = B.f1 ORDER BY A.f1 ASC, B.f4 DESC;
where the alias for t1 is missing, crashes both PHP and Apache.
PHP code to reproduce the problem:
<?php
ob_end_flush();
$goodSql = '';
$goodSql .= 'SELECT';
$goodSql .= ' A.categoryCode,';
$goodSql .= ' A.categoryStatus,';
$goodSql .= ' A.categoryName,';
$goodSql .= ' A.categoryDescription,';
$goodSql .= ' B.documentCode,';
$goodSql .= ' B.documentStatus,';
$goodSql .= ' B.documentFile,';
$goodSql .= ' B.documentCRC32,';
$goodSql .= ' B.documentSize,';
$goodSql .= ' B.documentTitle,';
$goodSql .= ' B.documentComments,';
$goodSql .= ' B.documentMimeType,';
$goodSql .= ' B.documentAddedOn,';
$goodSql .= ' B.documentAddedBy';
$goodSql .= ' FROM categories AS A INNER JOIN documents AS B';
$goodSql .= ' ON A.categoryCode = B.categoryCode';
$goodSql .= ' WHERE A.categoryStatus = "active" AND B.documentStatus = "active"';
$goodSql .= ' ORDER BY A.categoryCode, B.documentAddedOn DESC;';
$wrongSql = '';
$wrongSql .= 'SELECT';
$wrongSql .= ' A.categoryCode,';
$wrongSql .= ' A.categoryStatus,';
$wrongSql .= ' A.categoryName,';
$wrongSql .= ' A.categoryDescription,';
$wrongSql .= ' B.documentCode,';
$wrongSql .= ' B.documentStatus,';
$wrongSql .= ' B.documentFile,';
$wrongSql .= ' B.documentCRC32,';
$wrongSql .= ' B.documentSize,';
$wrongSql .= ' B.documentTitle,';
$wrongSql .= ' B.documentComments,';
$wrongSql .= ' B.documentMimeType,';
$wrongSql .= ' B.documentAddedOn,';
$wrongSql .= ' B.documentAddedBy';
$wrongSql .= ' FROM categories AS INNER JOIN documents AS B';
$wrongSql .= ' ON A.categoryCode = B.categoryCode';
$wrongSql .= ' WHERE A.categoryStatus = "active" AND B.documentStatus = "active"';
$wrongSql .= ' ORDER BY A.categoryCode, B.documentAddedOn DESC;';
echo '<h2>Running good SQL</h2>';
flush();
test('./db/sagnedb.dat', $goodSql);
flush();
echo '<h2>Running wrong SQL in 20 seconds...</h2>';
flush();
for ($i = 20; $i > 0; $i--) {
echo "<small>$i...</small>";
echo str_repeat(' ', 4096);
flush();
sleep(1);
}
test('./db/sagnedb.dat', $wrongSql);
echo '<h1>It will never print this!!!!!!!!!!!!!!!!!!!!!<h2>';
flush();
function test($dbFilename, $sql) {
// ini_set('sqlite.assoc_case', 2);
if ($dbConn = sqlite_open($dbFilename, 0666, $dbError)) {
$sql = sqlite_escape_string($sql);
if ($queryResult = @sqlite_query($dbConn, $sql)) {
$n = sqlite_num_fields($queryResult);
echo 'cols: ' . $n . '<br />';
echo 'rows: ' . sqlite_num_rows($queryResult) . '<br />';
for ($i = 0; $i < $n; $i++) {
echo 'field[' . $i . ']: ' . sqlite_field_name($queryResult, $i) . '<br />';
}
echo '<br />data:<pre>';
$data = sqlite_fetch_all($queryResult, SQLITE_ASSOC);
print_r($data);
echo '</pre>';
}
sqlite_close($dbConn);
}
}
?>
Sergio
|
2005-Oct-11 22:19:24 by anonymous:
I had no idea to whom I'd have assigned this.
Sorry about that.
Sergio
2005-Oct-12 02:58:37 by anonymous:
This is the wrong place to file this bug. Report this to the PHP folks; Unless you can reproduce the issue with sqlite alone.
2005-Oct-12 15:05:42 by anonymous:
The alias for t1 is not missing, it's "INNER". This is a perfectly well formed SQL statement. The problem is that SQLite is not reporting the erroneous use of the reserved word INNER as an identifier when it should.
It does not do this for all reserved words as shown below.
sqlite> select * from t as join;
SQL error: near "join": syntax error
sqlite> select * from t as "join";
sqlite> select * from t as inner;
sqlite>
However, I suspect that the error reported for the first select is due to the right hand table being omitted in the join, not because it recognizes that the alias (what the standard calls a correlation name) is a reserved word. The second select does not produce an error when it should, because the alias is still a reserved word even though it is delimited by double quotes. The third select does not produce an error either.
2005-Oct-12 15:09:36 by anonymous:
Of course this lack of error reporting is not what is causing Apache and/or PHP to crash. The erroneous queries that are accepted by SQLite execute correctly.
sqlite> select * from t as inner;
1|2
2|4
sqlite> select * from t as "join";
1|2
2|4
|
|
1476 |
new
|
active
|
2005 Oct
|
anonymous
|
|
2005 Oct
|
|
5
|
4
|
Patch for SQLite sequence manipulation functions
|
edit |
This patch (against SQLite 3.2.7) implements a pair of sequence manipulation functions (nextval, curval) that provide similar functionality to the sequences found in RDBMS systems like postgresql, oracle, DB2, etc. These functions allow applications to pre-fetch a unique integer identifier for later use, or to use incremental sequences on non-primary key columns. This functionality can also alleviate the need to use sqlite3_last_insert_rowid() while building complex relationships between rows across related tables during inserts and updates. These functions should also work well in cases where primary key uniqueness is desirable across multiple tables.
ZETETIC LLC developed this code for use in an internal project, but is willing to provide the source code and test scripts to the SQLite project (under SQLite's public domain license) if you would like to incorporate them into SQLite.
[ Usage ]
- nextval - A call to this function returns the next value for a sequence
- curval - a call to this function returns the current value of a sequence
The actual sequence functions can be called in one of one of four ways:
- nextval/curval('name')
- nextval/curval('name, 'db')
- nextval/curval('name', classic)
- nextval/curval('name, 'db', classic)
Where the parameters are defined as follows:
- 'name' - is the name of the sequence to match against the first column of the sequence table
- 'db' - is the name of the optional attached database to use
- classic - is an integer flag specifying whether to operate in classic sequence mode.
By default these sequence calls use a new sequence table format, defined as sqlite3_sequence. This table defines additional columns (name, seq, incr, min, max, cycle) providing some advanced sequence functionality, including:
- variable increment - the sequence increment value is 1 by default, but can be any integer (positive or negative). This allows sequences to move up or down by any increment.
- enforced minimum constraint - the sequence table allows a definition of a minimum value. If min is not NULL and a call to nextval() would cause the sequence counter to drop below min, the call will result in an error. If min is NULL, no constraint is enforced.
- enforced maximum constraint - the sequence table allows allows a maximum value. If max is not NULL and a call to nextval() would cause the sequence counter to increase above max, the call will result in an error. If max is NULL, no constraint is enforced.
- cycling - if a call to nextval would cause a min/max constraint to be violated, the function will cause the sequence to "cycle" and begin again from the min or max value. For example, assume the current sequence number=9, max=10, min=-10, and the sequence increment=2. The next call to nextval would exceed the max constraint, after incrementing by 1, so the cycle would increment min with the difference of 1, resulting in a nextval of -10. If increment=3, nextval would equal -9 and so on.
The sqlite3_sequence table has the following definition. Your application may optionally create this table in preparation for the first call to nextval, but if the table does not exist while operating in advanced mode it will be created automatically:
CREATE TABLE {db}.sqlite3_sequence(name TEXT, seq INTEGER, incr INTEGER, min INTEGER, max INTEGER, cycle INTEGER);
If the 'classic' argument is provided and not equal to zero, then these functions will operate on the standard sqlite_sequence table. In classic mode the sequence will always increment by one, and constraints/cycling are not supported. The sqlite_sequence table will NOT be created when operating in classic mode. Thus, the sqlite_sequence table must have been created through the use of an AUTOINCREMENT field on an existing table or the function call will return with an error.
Note that these functions can be used with the following caveats:
- Despite the fact that you can simply call nextval() from a select statement "SELECT nextval('sequence_name');", it does modify the database. Therefore, if another process has the database in an active transaction or otherwise locked you cannot obtain new sequence numbers.
- You can't use the function as a default value when you create tables.
There are 2 ways to create sequences that these functions will operate on:
- Allow nextval() to create the sequence. The first time nextval is called for a sequence name a row will be created and initialized with default values.
- Via INSERT. If your sequence needs specific non-default configurations, you simply insert a row into the sqlite3_sequence or sqlite_sequence table before your first call to nextval. For example the following sql command would create a cycling sequence starting at zero, with increments of -1 a minimum value of -100 and a maximium value of 100:
INSERT INTO sqlite3_sequence(name, seq, incr, min, max, cycle) VALUES ('sequence_1', 0, -1, -100, 100, 1);
Either of the following statements will create a non-cycling sequence with an initial value of zero a positive increment of 1, with no min and max values:
INSERT INTO sqlite3_sequence(name, seq, incr, min, max, cycle) VALUES ('sequence_2', 0, 1, NULL, NULL, NULL);
INSERT INTO sqlite3_sequence(name, seq, incr) VALUES ('sequence_2', 0, 1);
It is possible to change the values of any column of sqlite3_sequence except 'name' to change the behavior, even after the first call to nextval. For example, this statement would update the previous sequence defintion to include a maximum value of 200:
UPDATE sqlite3_sequence SET max=200 WHERE name='sequence_2';
[ Implementation ]
This patch introduces three new files:
- src/sequence.h - header file for sequence functions
- src/sequence.c - implementation of sequence functions
- test/sequence.test - 50+ step regression test for sequence functions
This patch also modifies the following files:
- Makefile.in - adjusted to include the compilation of sequence.c
- src/func.c - adjusted to include sequence.h and call sqlite3_create_function to load the functions at initialization time
- src/test1.c - adjusted to setup sqlite_options for use in the ifcapable section of the regression test
In order for the nextval function to work properly, the update of the sequence and the read happen at the same time, while the database is in a locked state. The nextval function uses using the Vdbe API directly. The Vdbe script implements a certain amount of logic to support increments of arbitrary values, min/max constraint enforcement, and cycling. The Vdbe code is almost identical between the between advanced and classic sequence modes. This the basic logic that it uses:
- Create a new Vdbe for the database based on the context.
- Try to obtain an exclusive lock (OP_Transaction, P2=3).
- Open the sequence table for writes (OP_OpenWrite)
- Search the table and obtain the current value from the sequence table associate with that name. If one isn't found, start a new sequence off at 0.
- Calculate the new sequence the value, taking into account defined increment, min/max enforcement, and cycling logic
- Write the new value into the table
- Callback the new value
[ Possible Future Extensions ]
- impliment pre-fetch / sequence caching at the database handle level. This would allow a call to nextval() fetch multiple unique identifiers and cache them to avoid the need to repeatedly lock the database.
- Support for CREATE SEQUENCE statement, instead of requiring an insert to the sqlite3_sequence table or creation of an autoincrement field
- Support for alternate sequence call support like "xx_seq.nextval" or "NEXT VALUE FOR xxx_seq". This would make it easier to deal with sequences on attached database (the current scheme is usable but not elegant), and would be more similar to semantics used by other RDBMSs.
- any other recommended changes from the SQLite development team / users
Stephen J Lombardo
ZETETIC LLC
stephen dot lombardo at zetetic dot net
|
2005-Oct-11 15:06:01 by anonymous:
The C functions nextval() and curval() in sequence.c should be static, so as not to pollute the global name space with such generic names, in which case they should probably live within func.c.
Else, they should have sqlite3 prepended to put them in the sqlite3 namespace.
2005-Oct-12 01:50:09 by anonymous:
The new attached patch renames prepends the C functions with sqlite3_ (sqlite3_curval() and sqlite3_nextval()). I agree that it might be a better idea to define them as static functions in func.c if the functions are accepted into SQLite. For now, it's easier to leave them defined in separate files so they can be compiled into a program as user defined functions outside of SQLite.
Stephen |
|
1475 |
new
|
active
|
2005 Oct
|
anonymous
|
Parser
|
2005 Oct
|
anonymous
|
5
|
5
|
sytax error near autoincrement
|
edit |
Consider following sql syntax.
create table t1 (id integer primary key autoincrement); // no error
create table t2 (id integer autoincrement primary key); // error
create table t3 (id integer autoincrement, primary key(id)); // error |
2005-Oct-07 03:15:23 by anonymous:
Your last two examples don't follow the syntax shown in the documentation. AUTOINCREMENT is a modifier for a PRIMARY KEY constraint and can only come after one. |
|
1469 |
event
|
active
|
2005 Oct
|
anonymous
|
Parser
|
2005 Oct
|
|
1
|
1
|
Having problems with subselects that work on mySQL
|
edit |
I'm converting from mySQL. However I've run across several sub-selects that work on mySQL but not SQLite. Apache gives me a error. If I can't get them fixed, I will be forced back to mySQL. Not sure what I'm doing wrong. Basically trying to find the last variety record against a Wine Process Order (wpo).
Program is in PHP5 script as follows:
$sql = "
SELECT *
FROM
wpo W,
wpo_dtl as D,
wpo_varietal V,
storage S,
variety VM
WHERE S.stop_trace <> 'Y'
AND D.storage_id = S.storage_id
AND D.from_to = 'T'
AND D.wpo_num = W.wpo_num
AND D.leg_num = W.leg_num
AND V.storage_id = S.storage_id
AND V.from_to = 'T'
AND V.wpo_num = D.wpo_num
AND V.leg_num = D.leg_num
AND VM.variety_num = V.variety_num
AND VM.color = 'R'
AND W.wpo_datetime = (SELECT MAX(W1.wpo_datetime)
FROM wpo as W1,wpo_varietal as V1
WHERE V1.storage_id = S.storage_id
AND V1.from_to = 'T'
AND W1.wpo_num = V1.wpo_num
AND W1.leg_num = V1.leg_num)
ORDER BY S.storage_id";
$query = sqlite_query($link_id, $sql);
$result = sqlite_fetch_all($query, SQLITE_ASSOC);
foreach ($result as $qd)
{
...............
------------------------------------------
|
2005-Oct-05 20:08:11 by anonymous:
You've said it "gives you an error" and "doesn't work" but you don't tell anybody what error message it gives you or how it fails. Nobody here can help you solve your problem unless you provide that information. |
|
1468 |
new
|
active
|
2005 Oct
|
anonymous
|
Parser
|
2005 Oct
|
|
5
|
5
|
Added Mysql function CONCAT
|
edit |
static void concatFunc(
sqlite3_context *context,
int argc,
sqlite3_value **argv
){
unsigned char *z;
int i;
int len = 0;
for(i=0;i<argc;i++)
len+= sqlite3_value_bytes(argv[i]);
z = sqliteMalloc(len+1);
if( z==0 ) return;
for(i=0;i<argc;i++)
strcat(z, sqlite3_value_text(argv[i]));
sqlite3_result_text(context, z, len , SQLITE_TRANSIENT);
sqliteFree(z);
}
{ "concat", -1, 0, SQLITE_UTF8, 0, concatFunc },
|
2005-Oct-05 14:27:29 by drh:
Seems kind of pointless since SQLite already supports
the SQL-standard || operator.
2005-Oct-09 13:24:49 by anonymous:
sorry :-) |
|
1466 |
warn
|
active
|
2005 Oct
|
anonymous
|
|
2005 Oct
|
|
5
|
5
|
compile warnings
|
edit |
{{{
cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -c ./src/os_unix.c -KPIC -DPIC -o .libs/os_unix.o
"./src/main.c", line 644: warning: assignment type mismatch:
pointer to const char "" pointer to const unsigned char
"./src/alter.c", line 50: warning: assignment type mismatch:
pointer to const char " " pointer to const unsigned char
"./src/alter.c", line 61: warning: assignment type mismatch:
pointer to const unsigned char "" pointer to const char
"./src/alter.c", line 69: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "src/sqliteInt.h", line 1641
argument : pointer to const char
"./src/alter.c", line 99: warning: assignment type mismatch:
pointer to const char " " pointer to const unsigned char
"./src/alter.c", line 111: warning: assignment type mismatch:
pointer to const unsigned char "=" pointer to const char
"./src/alter.c", line 119: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "src/sqliteInt.h", line 1641
argument : pointer to const char
"./src/alter.c", line 445: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1414
argument : pointer to const unsigned char
cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -c ./src/func.c -KPIC -DPIC -o .libs/func.o
"./src/pragma.c", line 47: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/iso/stdlib_iso.h", line 94
argument : pointer to const unsigned char
"./src/pragma.c", line 49: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/iso/string_iso.h", line 70
argument : pointer to const unsigned char
"./src/pragma.c", line 51: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1395
argument : pointer to const unsigned char
"./src/pragma.c", line 169: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "./src/pragma.c", line 61
argument : pointer to const char
"./src/pragma.c", line 322: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "./src/pragma.c", line 61
argument : pointer to char
"./src/pragma.c", line 430: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "./src/pragma.c", line 39
argument : pointer to char
"./src/pragma.c", line 621: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "./src/pragma.c", line 61
argument : pointer to char
"./src/build.c", line 509: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1414
argument : pointer to const unsigned char
cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -c ./src/func.c -KPIC -DPIC -o .libs/func.o
"./src/pragma.c", line 47: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/iso/stdlib_iso.h", line 94
argument : pointer to const unsigned char
"./src/pragma.c", line 49: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/iso/string_iso.h", line 70
argument : pointer to const unsigned char
"./src/pragma.c", line 51: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1395
argument : pointer to const unsigned char
"./src/pragma.c", line 169: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "./src/pragma.c", line 61
argument : pointer to const char
"./src/pragma.c", line 322: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "./src/pragma.c", line 61
argument : pointer to char
"./src/pragma.c", line 430: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "./src/pragma.c", line 39
argument : pointer to char
"./src/pragma.c", line 621: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "./src/pragma.c", line 61
argument : pointer to char
"./src/build.c", line 509: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1414
argument : pointer to const unsigned char
cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -c ./src/hash.c -KPIC -DPIC -o .libs/hash.o
"./src/date.c", line 642: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "./src/date.c", line 306
argument : pointer to const unsigned char
"./src/date.c", line 645: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "./src/date.c", line 450
argument : pointer to const unsigned char
"./src/date.c", line 758: warning: assignment type mismatch:
pointer to const char "=" pointer to const unsigned char
./libtool --mode=compile cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -DTEMP_STORE=2 -c ./src/prepare.c
"parse.y", line 241: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/iso/stdlib_iso.h", line 94
argument : pointer to const unsigned char
"parse.y", line 242: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/iso/stdlib_iso.h", line 94
argument : pointer to const unsigned char
"parse.y", line 275: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "./src/sqliteInt.h", line 1456
argument : pointer to const unsigned char
cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -c ./src/date.c -o date.o >/dev/null 2>&1
"parse.y", line 885: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "./src/sqliteInt.h", line 1620
argument : pointer to const unsigned char
"parse.y", line 893: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "./src/sqliteInt.h", line 1620
argument : pointer to const unsigned char
"./src/btree.c", line 1537: warning: assignment type mismatch:
pointer to unsigned char "" pointer to char
"./src/pager.c", line 1012: warning: argument #3 is incompatible with prototype:
prototype: pointer to const char : "./src/pager.c", line 960
argument : pointer to unsigned char
"./src/build.c", line 1173: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1429
argument : pointer to unsigned char
"./src/build.c", line 2160: warning: assignment type mismatch:
pointer to const unsigned char " " pointer to char
"./src/build.c", line 2161: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/iso/string_iso.h", line 70
argument : pointer to const unsigned char
cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -c ./src/pragma.c -o pragma.o >/dev/null 2>&1
"./src/func.c", line 104: warning: assignment type mismatch:
pointer to const char "" pointer to const unsigned char
"./src/func.c", line 155: warning: assignment type mismatch:
pointer to const char " " pointer to const unsigned char
"./src/func.c", line 213: warning: argument #1 is incompatible with prototype:
prototype: pointer to char : "/usr/include/iso/string_iso.h", line 66
argument : pointer to unsigned char
"./src/func.c", line 213: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/iso/string_iso.h", line 66
argument : pointer to const unsigned char
"./src/func.c", line 217: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "./sqlite3.h", line 1073
argument : pointer to unsigned char
"./src/func.c", line 226: warning: argument #1 is incompatible with prototype:
prototype: pointer to char : "/usr/include/iso/string_iso.h", line 66
argument : pointer to unsigned char
"./src/func.c", line 226: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/iso/string_iso.h", line 66
argument : pointer to const unsigned char
"./src/func.c", line 230: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "./sqlite3.h", line 1073
argument : pointer to unsigned char
cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -c ./src/os_unix.c -o os_unix.o >/dev/null 2>&1
"./src/pager.c", line 1360: warning: statement not reached
"./src/build.c", line 2913: warning: argument #3 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1619
argument : pointer to const unsigned char
"./src/expr.c", line 238: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/iso/stdlib_iso.h", line 94
argument : pointer to const unsigned char
"./src/expr.c", line 330: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/iso/stdlib_iso.h", line 94
argument : pointer to const unsigned char
"./src/expr.c", line 418: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1414
argument : pointer to const unsigned char
"./src/expr.c", line 418: warning: assignment type mismatch:
pointer to const unsigned char "" pointer to char
"./src/expr.c", line 435: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1414
argument : pointer to const unsigned char
"./src/expr.c", line 435: warning: assignment type mismatch:
pointer to const unsigned char " " pointer to char
"./src/btree.c", line 5817: warning: statement not reached
"./src/func.c", line 498: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1601
argument : pointer to const unsigned char
"./src/func.c", line 595: warning: assignment type mismatch:
pointer to const char "=" pointer to const unsigned char
"./src/func.c", line 1103: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1539
argument : pointer to const unsigned char
./libtool --mode=compile cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -c ./src/random.c
"./src/expr.c", line 755: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1598
argument : pointer to const unsigned char
"./src/expr.c", line 1154: warning: assignment type mismatch:
pointer to const char "" pointer to const unsigned char
"./src/expr.c", line 1401: warning: initialization type mismatch
"./src/expr.c", line 1477: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "./src/expr.c", line 1423
argument : pointer to const unsigned char
"./src/expr.c", line 1485: warning: argument #5 is incompatible with prototype:
prototype: pointer to const char : "src/vdbe.h", line 103
argument : pointer to const unsigned char
"./src/expr.c", line 1498: warning: assignment type mismatch:
pointer to const char " " pointer to const unsigned char
cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -c ./src/delete.c -o delete.o >/dev/null 2>&1
argument #3 is incompatible with prototype:
prototype: pointer to const char : "src/vdbe.h", line 108
argument : pointer to const unsigned char
"./src/expr.c", line 1632: warning: assignment type mismatch:
pointer to const char "=" pointer to const unsigned char
"./src/expr.c", line 1766: warning: argument #5 is incompatible with prototype:
prototype: pointer to const char : "src/vdbe.h", line 103
argument : pointer to const unsigned char
"./src/expr.c", line 2059: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1395
argument : pointer to const unsigned char
"./src/expr.c", line 2059: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1395
argument : pointer to const unsigned char
"./src/expr.c", line 2191: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1539
argument : pointer to const unsigned char
cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -c ./src/vdbe.c -KPIC -DPIC -o .libs/vdbe.o
"./src/select.c", line 112: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1395
argument : pointer to const unsigned char
"./src/select.c", line 157: warning: assignment type mismatch:
pointer to const unsigned char "" pointer to const char
"./src/select.c", line 625: warning: assignment type mismatch:
pointer to unsigned char " " pointer to char
"./src/printf.c", line 628: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "unknown", line 0
argument : pointer to const unsigned char
"./src/trigger.c", line 240: warning: argument #3 is incompatible with prototype:
prototype: pointer to const char : "src/vdbe.h", line 108
argument : pointer to const unsigned char
"./src/trigger.c", line 281: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1414
argument : pointer to const unsigned char
"./src/trigger.c", line 281: warning: assignment type mismatch:
pointer to const unsigned char "" pointer to char
"./src/trigger.c", line 623: warning: assignment type mismatch:
pointer to const unsigned char " " pointer to char
"./src/trigger.c", line 624: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/iso/string_iso.h", line 70
argument : pointer to const unsigned char
cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -c ./src/random.c -o random.o >/dev/null 2>&1
"./src/select.c", line 869: warning: argument #3 is incompatible with prototype:
prototype: pointer to const char : "src/vdbe.h", line 120
argument : pointer to const unsigned char
"./src/select.c", line 882: warning: argument #3 is incompatible with prototype:
prototype: pointer to const char : "src/vdbe.h", line 120
argument : pointer to const unsigned char
"./src/tokenize.c", line 360: warning: assignment type mismatch:
pointer to const unsigned char "=" pointer to const char
"./src/select.c", line 2088: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1414
argument : pointer to const unsigned char
"./src/select.c", line 2187: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1395
argument : pointer to const unsigned char
"./src/select.c", line 2189: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1395
argument : pointer to const unsigned char
"./src/vacuum.c", line 61: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "./src/vacuum.c", line 40
argument : pointer to const unsigned char
"./src/vdbeaux.c", line 199: warning: integer overflow detected: op "<<"
"./src/vdbeaux.c", line 199: warning: initializer does not fit or is out of range: -1155858600
"./src/vdbeaux.c", line 1735: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "src/sqliteInt.h", line 1605
argument : pointer to char
"./src/vdbeaux.c", line 1736: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "src/sqliteInt.h", line 1605
argument : pointer to char
"./src/vdbeaux.c", line 1738: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "./src/vdbeaux.c", line 1540
argument : pointer to char
"./src/vdbeaux.c", line 1774: warning: argument #2 is incompatible with prototype:
prototype: pointer to const unsigned char : "./src/vdbeaux.c", line 1704
argument : pointer to char
cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -c ./src/tokenize.c -o tokenize.o >/dev/null 2>&1
"./src/vdbe.c", line 1873: warning: assignment type mismatch:
pointer to char "" pointer to unsigned char
"./src/vdbe.c", line 1940: warning: assignment type mismatch:
pointer to unsigned char " " pointer to char
"./src/vdbe.c", line 1940: warning: assignment type mismatch:
pointer to char "" pointer to unsigned char
"./src/vdbe.c", line 1945: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "src/sqliteInt.h", line 1605
argument : pointer to char
"./src/vdbe.c", line 1972: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "src/sqliteInt.h", line 1605
argument : pointer to char
"./src/vdbe.c", line 2026: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "src/vdbeInt.h", line 336
argument : pointer to char
"./src/vdbe.c", line 2189: warning: assignment type mismatch:
pointer to unsigned char " " pointer to char
"./src/vdbe.c", line 2223: warning: assignment type mismatch:
pointer to char "=" pointer to unsigned char
cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -c opcodes.c -KPIC -DPIC -o .libs/opcodes.o
"./src/vdbe.c", line 2920: warning: argument #2 is incompatible with prototype:
prototype: pointer to const unsigned char : "src/vdbeInt.h", line 344
argument : pointer to char
"./src/vdbe.c", line 2937: warning: argument #3 is incompatible with prototype:
prototype: pointer to const unsigned char : "src/vdbeInt.h", line 340
argument : pointer to char
"./src/vdbe.c", line 3710: warning: argument #3 is incompatible with prototype:
prototype: pointer to const unsigned char : "src/vdbeInt.h", line 340
argument : pointer to char
"./src/vdbe.c", line 3748: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "src/sqliteInt.h", line 1605
argument : pointer to const char
"./src/vdbe.c", line 3750: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "src/sqliteInt.h", line 1605
argument : pointer to const char
"./src/utf.c", line 275: warning: assignment type mismatch:
pointer to unsigned char "" pointer to char
"./src/utf.c", line 311: warning: assignment type mismatch:
pointer to unsigned char " " pointer to char
"./src/utf.c", line 363: warning: assignment type mismatch:
pointer to unsigned char "" pointer to char
"./src/utf.c", line 368: warning: assignment type mismatch:
pointer to char " " pointer to unsigned char
cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -c ./src/where.c -KPIC -DPIC -o .libs/where.o
"./src/where.c", line 514: warning: assignment type mismatch:
pointer to const char "" pointer to const unsigned char
"./src/vdbemem.c", line 76: warning: assignment type mismatch:
pointer to char " " pointer to unsigned char
"./src/vdbemem.c", line 96: warning: assignment type mismatch:
pointer to unsigned char "" pointer to char
"./src/vdbemem.c", line 109: warning: assignment type mismatch:
pointer to char " " pointer to unsigned char
"./src/vdbemem.c", line 165: warning: assignment type mismatch:
pointer to unsigned char "" pointer to char
"./src/vdbemem.c", line 177: warning: argument #2 is incompatible with prototype:
prototype: pointer to char : "./sqlite3.h", line 397
argument : pointer to unsigned char
"./src/vdbemem.c", line 180: warning: argument #2 is incompatible with prototype:
prototype: pointer to char : "./sqlite3.h", line 397
argument : pointer to unsigned char
"./src/vdbemem.c", line 182: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/iso/string_iso.h", line 70
argument : pointer to unsigned char
"./src/vdbemem.c", line 183: warning: assignment type mismatch:
pointer to char " " pointer to unsigned char
"./src/vdbemem.c", line 769: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1414
argument : pointer to const unsigned char
"./src/vdbemem.c", line 789: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "src/sqliteInt.h", line 1414
argument : pointer to const unsigned char
cc -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -DHAVE_READLINE=0 -o .libs/sqlite3 ./src/shell.c ./.libs/libsqlite3.so -lcurses -R/export/opt/svn/1.3.0/lib
"./src/shell.c", line 355: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "./src/shell.c", line 84
argument : pointer to const char
"./src/shell.c", line 523: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "./src/shell.c", line 84
argument : pointer to char
"./src/shell.c", line 694: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "./src/shell.c", line 583
argument : pointer to const unsigned char
}}} |
|
1465 |
code
|
active
|
2005 Oct
|
anonymous
|
CodeGen
|
2005 Oct
|
|
1
|
1
|
fdatasync not available and not yet fixed
|
edit |
fdatasync is still there ... i downloaded the current configure files which should check for it. do i have to use something else too?
./libtool --mode=link cc -g -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -DHAVE_READLINE=0 \
-o sqlite3 ./src/shell.c libsqlite3.la -lcurses
cc -g -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -DHAVE_READLINE=0 -o .libs/sqlite3 ./src/shell.c ./.libs/libsqlite3.so -lcurses
"./src/shell.c", line 355: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "./src/shell.c", line 84
argument : pointer to const char
"./src/shell.c", line 523: warning: argument #1 is incompatible with prototype:
prototype: pointer to const unsigned char : "./src/shell.c", line 84
argument : pointer to char
"./src/shell.c", line 694: warning: argument #2 is incompatible with prototype:
prototype: pointer to const char : "./src/shell.c", line 583
argument : pointer to const unsigned char
Undefined first referenced
symbol in file
fdatasync ./.libs/libsqlite3.so
ld: fatal: Symbol referencing errors. No output written to .libs/sqlite3
make: *** [sqlite3] Error 1 |
2005-Oct-04 21:42:26 by drh:
Clear out your build directory (or start a new one) and rerun
configure from scratch. Save the output of configure. Then
rerun make. If you still have a problem, attach the output of
configure to this ticket. |
|
1464 |
new
|
active
|
2005 Oct
|
anonymous
|
|
2005 Oct
|
|
4
|
3
|
Improving PRAGMA table_info()
|
edit |
I have a small feature request regarding PRAGMA table_info()
to add a new column named "auto_inc" which
contains 1 if the corresponding field has the AUTO INCREMENT in its
definition and 0 otherwise. |
2005-Oct-04 15:37:31 by anonymous:
Once suggestions for extending the PRAGMA table_info() are on the agenda, I would like to suggest that the COLLATION sequence used for an INDEX would be made available as well. |
|
1461 |
code
|
active
|
2005 Sep
|
anonymous
|
Unknown
|
2005 Sep
|
drh
|
1
|
2
|
3.2.7 DLL can not deal File paths with international characters
|
edit |
My platform:winxpsp2 chinese version,my database file under a path with chinese charater,with the dll(3.2.1) sqliteexplore works fine,if I change the dll to 3.2.7,it show sqlite error 14:can't open the file,and then I change the path fully english,it can work fine again,so I think mybe it relate to Check-in:2656 |
2005-Sep-28 15:31:34 by anonymous:
and more,the source version has no such problem.
2005-Sep-28 16:09:04 by anonymous:
I notice in os_win.c, function "sqlite3OsFileExists" use GetFileAttributesA and GetFileAttributesW,but I tried GetFileAttributes works ok. |
|
1458 |
code
|
active
|
2005 Sep
|
anonymous
|
Shell
|
2005 Sep
|
|
2
|
2
|
Error at .importing in csv format (another)
|
edit |
Sqlite3 version 3.2.6 :
When importing data in csv format the programa adds commas when importing strings enclosed with commas in the source file.
In particular it shouldnt add commas when field data is already enclosed in comma, but it does. Curiously enough, it correctly imports numeric data.
Example: Take de demodatabase file, and take the table clients. If you try to add these records to the table with .import, it is impossible (the only workaround is deleting commas in the file and importing it in <list .mode>
504,"New Enterprise","Mr Smart","93-2275400"
505,"Another Enterprise","John Dongu","93-8765432"
506,"And here we are","Mr Strange","973-237131"
This file would be impossible to import correctly with .import
If you set .mode list, it is imported incorrectly, since it keeps the commas around character fields in the table -which is what it should do anyway, since in this mode the program does not expect commas around field data.
But when you set <.mode csv>, it imports them also incorrectly - it adds new commas around character data.
Souce data in csv format is important, -probably the most general data format available, and often a last resort format for difficult cases...
Thank in advance. I would like to help at fixing problems myself, but I do not understand a word of C.
Antoni Francino
afrancino@mesvilaweb.com |
2005-Sep-27 23:07:43 by anonymous:
You've got the names of your punctuation characters confused. What's happening is that the double quote marks around the text fields are gettting imported, whereas the usual understanding of "CSV" is that they should be stripped off.
2005-Sep-27 23:11:27 by anonymous:
On further inspection, this turns out to be the same problem as in ticket #1312. |
|
1457 |
code
|
active
|
2005 Sep
|
anonymous
|
Shell
|
2005 Sep
|
|
3
|
1
|
non-latin chars not recognized by CLI
|
edit |
Hello,
If i am trying to execute an SQL statement via the CLI of a self-compiled (Win via MinGW) or the prebuilded exe all chars that are not iso are converted to something ugly.
For example, the German Umlaute or the è are not entered correctly into a table name, field value and so on.
If the same commands are executed from the sqlite>> promt everything works well.
As I need to compile my own sqlite.exe I need to be able to change that in code.
Thank you for this great Product and a solution to this problem.
btw: This is my first request here, so please be patient with me if I´ve set the priority wrong... It´s obviously highest priority to me ;) |
2005-Sep-26 21:44:12 by anonymous:
è should be the accented e in my post, sorry for that |
|
1455 |
code
|
active
|
2005 Sep
|
anonymous
|
Shell
|
2005 Sep
|
|
3
|
2
|
.import error: comma inside a string is read as field separator
|
edit |
In Sqlite version 3, when you need to import data into a table you use .import. (You cannot do it with COPY).
Well, if you need to import data in 'csv' format, and if there is a string in the input data that contains a <comma> inside itself, the reading is impossible since the comma is interpreted as a field separator.
Example error message: "Error: There are 10 fields in file, and 8 fields were expected."
To me its pretty much a nuisance, since csv format is the most usual format for the data I use, and I've got to change the separating character, or else locate and eliminate those extra commas.
Hope this helps
Thanks
Antoni Francino
afrancino@mesvilaweb.com |
|
1454 |
doc
|
active
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
|
4
|
4
|
Functions should all be documented in one place
|
edit |
Currently some, but not all, of SQLite's functions are documented in lang_expr.html. For example, the date/time functions are only documented in a wiki page that describes them as "experimental." It would be nice if they could be moved into the "official" documentation. |
|
1451 |
code
|
active
|
2005 Sep
|
anonymous
|
Shell
|
2005 Sep
|
|
4
|
3
|
.mode insert does not output BLOBs in an usable way
|
edit |
sqlite> CREATE TABLE a(b);
sqlite> INSERT INTO a VALUES (X'41424300500051');
sqlite> .dump
BEGIN TRANSACTION;
CREATE TABLE a(b);
INSERT INTO "a" VALUES(X'41424300500051');
COMMIT;
sqlite> .mode insert
sqlite> SELECT * FROM a;
INSERT INTO table VALUES('ABC'); It would be nice for ".mode insert" to print a command that would
actually re-create the same data, the same as ".dump" (the obvious
difference is that .dump can't filter data in any way, it just dumps
it all) or, at least, it would be very nice if the already existing
function that "prints binary data as X'-encoded-string" were reachable
from SQL, so that one could use something like:
SELECT xencode(b) FROM a;
and obtain
|
2005-Sep-25 17:03:40 by anonymous:
I am not the original ticket poster, but I noticed that this feature request is related to Monotone migrating away from Base64 encoding to using straight Sqlite blobs.
2005-Sep-26 01:49:33 by drh:
The built-in quote() function converts BLOBs into ascii BLOB
literals. Will it not server for the requested xencode() function?
SELECT quote(b) FROM a
2005-Sep-26 08:57:47 by anonymous:
Yes, I guess it can perfectly do.
What about ".mode insert" output? Is it supposed to print raw data? |
|
1447 |
code
|
active
|
2005 Sep
|
anonymous
|
BTree
|
2005 Sep
|
|
1
|
1
|
Abnormal program termination in src/btree.c line 1339
|
edit |
In some circumstances (after having used wxgrid ..) a call to sqlite
gives a strange :
Assertion Failed: pCur->idx>=0 && pCur->idx < pCur->pPage->nCell, file src/btree line 1339
abnormal program termination
there seems to be non way of making a trace back ... any idea?
Thanx
Doriaqn Tessore |
2005-Sep-23 14:32:27 by drh:
Not much to go on. What version of SQLite is being used?
("SQLite 2" is kind of vague.) |
|
1445 |
code
|
active
|
2005 Sep
|
anonymous
|
|
2006 Sep
|
|
3
|
3
|
Errors testing sqlite 3.2.6 (& v3.3.7)
|
edit |
$ make test
[...]
conflict-6.0... Ok
conflict-6.1... Ok
conflict-6.2...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
conflict-6.3...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.4... Ok
conflict-6.5... Ok
conflict-6.6... Ok
conflict-6.7...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.8...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
conflict-6.9...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.10...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
conflict-6.11...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.12...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.13...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
conflict-6.14... Ok
conflict-6.15... Ok
conflict-6.16... Ok
[...]
date-3.12... Ok
date-3.13... Ok
date-3.14... Ok
date-3.15... Ok
date-3.16... Ok
date-3.17... Ok
/tmp/sqlite-3.2.6/.libs/lt-testfixture: invalid command name "clock"
while executing
"clock seconds"
invoked from within
"clock format [clock seconds] -format "%Y-%m-%d" -gmt 1"
invoked from within
"set now [clock format [clock seconds] -format "%Y-%m-%d" -gmt 1]"
(file "./test/date.test" line 142)
invoked from within
"source $testfile"
("foreach" body line 4)
invoked from within
"foreach testfile [lsort -dictionary [glob $testdir/*.test]] {
set tail [file tail $testfile]
if {[lsearch -exact $EXCLUDE $tail]>=0} continue
so..."
(file "./test/quick.test" line 45)
make: *** [test] Error 1
|
2005-Sep-19 23:03:56 by drh:
The test scripts do not (yet) work with Tcl 8.5. Use Tcl 8.4.
2005-Sep-20 01:59:42 by anonymous:
FYI, The conflict failures occur even when using tcl-8.4. The problem was reported on the mailing list:
http://www.mail-archive.com/sqlite-users%40sqlite.org/msg10203.html
Curiously, the failures correspond exactly to the test cases that were changed by the following patch:
http://www.sqlite.org/cvstrac/filediff?f=sqlite/test/conflict.test&v1=1.24&v2=1.25
2006-Aug-31 23:49:40 by anonymous:
building v337 on OSX 10.4.7 w/ TCL8.5 installed as Framework, 'make test' still fails w/:
date-3.16... Ok
date-3.17... Ok
/usr/ports/sqlite-3.3.7/build/.libs/testfixture: invalid command name "clock"
while executing
"clock seconds"
invoked from within
"clock format [clock seconds] -format "%Y-%m-%d" -gmt 1"
invoked from within
"set now [clock format [clock seconds] -format "%Y-%m-%d" -gmt 1]"
(file "../test/date.test" line 142)
invoked from within
"source $testfile"
("foreach" body line 4)
invoked from within
"foreach testfile [lsort -dictionary [glob $testdir/*.test]] {
set tail [file tail $testfile]
if {[lsearch -exact $EXCLUDE $tail]>=0} continue
so..."
(file "../test/quick.test" line 66)
make: *** [test] Error 1
any resolution for this, other than revert to TCL 8.4?
2006-Sep-01 01:26:37 by anonymous:
SQLite under Cygwin fails all tests that involve integers larger than 32 bits. Sqlite produces the correct 64 bit values, but Tcl as distributed with Cygwin cannot grok 64 bit ints, so the comparisons fail. Would it be possible to change Sqlite's test harness to compare SQL results as strings rather than as integers? Then it would not matter if Tcl worked in 64 bit or not.
2006-Sep-01 15:50:48 by drh:
The test suite has been revised so that it now works with Tcl8.5.
But, no, it is not practical to rewrite the tests to compare the
results using strings instead of integers in order to work with
the (broken) tcl implementation that comes with cygwin.
2006-Sep-06 02:39:24 by anonymous:
updating to latest cvs-checkout to get the aforementioned fix for:
date-3.17... Ok
/usr/ports/sqlite-3.3.7/build/.libs/testfixture: invalid command name "clock"
while executing
i can verify that _that_ is now ok:
...
date-3.14... Ok
date-3.15... Ok
date-3.16... Ok
date-3.17... Ok
date-4.1...
Expected: [2006-09-01]
Got: [2006-09-06]
date-5.1... Ok
date-5.2... Ok
date-5.3... Ok
...
but now, 'make test' fails next @:
delete-8.4... Ok
delete-8.5... Ok
delete-8.6... Ok
delete-8.7... Ok
/usr/ports/sqlite-cvs/build/.libs/testfixture: error deleting "test.db": not owner
while executing
"file delete -force test.db"
(file "../test/tester.tcl" line 62)
invoked from within
"source $testdir/tester.tcl"
(file "../test/delete2.test" line 36)
invoked from within
"source $testfile"
("foreach" body line 4)
invoked from within
"foreach testfile [lsort -dictionary [glob $testdir/*.test]] {
set tail [file tail $testfile]
if {[lsearch -exact $EXCLUDE $tail]>=0} continue
so..."
(file "../test/quick.test" line 66)
make: *** [test] Error 1
2006-Sep-06 11:11:19 by drh:
Run the build starting from an empty directory as a non-root
user.
2006-Sep-06 13:27:18 by anonymous:
per INSTALL instructions, i did:
cvs -d :pserver:anonymous@www.sqlite.org:/sqlite checkout -d sqlite-cvs sqlite
cd /usr/ports/sqlite-cvs
mkdir build
cd build
../configure \
...
make
chown -R myuser:wheel /usr/ports/sqlite-cvs
sudo -u myuser make test
and, as reported, the error was the result.
2006-Sep-30 21:43:45 by anonymous:
bump.
anyone?
2006-Sep-30 22:19:24 by anonymous:
If you don't happen to be testing on Linux/gcc or Windows/VC++ I find that the Tcl test results have more than a few failures. It is not always easy to discern which failures are due to some odd quirk of Tcl or whether it is a legitimate SQLite issue on a given platform. Be prepared to change test scripts and tinker with the code. |
|
1441 |
code
|
active
|
2005 Sep
|
anonymous
|
VDBE
|
2005 Sep
|
|
4
|
4
|
sqlite3_clear_bindings routine missing
|
edit |
Implementation of sqlite3_clear_bindings routine is missing. I fix it this way, but the question is if that is correct... in vdbeapi.c :
/*
** The following routine unbind (set to NULL) binded parameters
*/
int sqlite3_clear_bindings(sqlite3_stmt *pStmt){
Vdbe *p = (Vdbe*)pStmt;
int i;
for(i = 1; i <= p->nVar; i++)
vdbeUnbind(p, i);
return SQLITE_OK;
}
|
2005-Sep-19 10:06:12 by anonymous:
The function is in experimental.c. check the source file. |
|
1431 |
doc
|
active
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
|
1
|
1
|
Please can FAQ 7 reference http://www.sqlite.org/lockingv3.html
|
edit |
FAQ item 7 is unclear on when concurrent readers and writers may block. Please add a reference to http://www.sqlite.org/lockingv3.html which makes this clear.
Also please add to http://www.sqlite.org/lockingv3.html this sumamry by Christian Smith sent to the mailing list with message-id Pine.LNX.4.58.0509161006430.16877@localhost.localdomain>
In summary:
SQLite uses multiple readers/single writer locking. A writer can operate
concurrently with readers until it is ready to commit or spill data from
it's cache. In this case, it waits for readers to finish, then gets an
exclusive write lock and writes it's data. Thus, the following concurrency
is available to SQLite:
time ---->
Reader >-------------|
Reader >-------------|
Reader >----------|
Writer >-------c***----|
Reader >***********-------------|
Key:
- Executing query
c Commit
* Blocked by lock
> Start of query
| End of query
The last reader above is blocked from starting by the writer until the
writer commits. If the writer commits before the last reader has finished,
it is blocked. |
|
1428 |
code
|
active
|
2005 Sep
|
anonymous
|
TclLib
|
2005 Sep
|
|
3
|
3
|
tclinstaller.tcl script problems
|
edit |
The pkgIndex.tcl file generated by the tclinstaller.tcl script contains absolute pathnames to the TCL extension library. This causes problems if the extension subdirectory is moved. A more portable solution is shown below.
A second problem is that the shared library does not have executable permission. This is a problem on HPUX operating systems. Adding the 0755 permission mode to the open command solves the problem for HPPA and does not cause problems for the other platforms.
Here's a diff of the changes I made to address these two problems:
cvs diff tclinstaller.tcl
Index: tclinstaller.tcl
===================================================================
RCS file: /sqlite/sqlite/tclinstaller.tcl,v
retrieving revision 1.2
diff -r1.2 tclinstaller.tcl
17c17
< puts $fd "package ifneeded sqlite3 $VERSION \[list load $LIB sqlite3\]"
---
> puts $fd "package ifneeded sqlite3 $VERSION \[list load \[file join \$dir $LIBNAME\]\]"
25c25,26
< set out [open $LIB w]
---
> #Some platforms such as the HP requre that libraries have the executable bit set
> set out [open $LIB w 0755]
|
|
1427 |
build
|
active
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
|
4
|
3
|
tclsqlite.lo target should define USE_TCL_STUBS
|
edit |
The Tcl_InitStubs routine is not called in Sqlite3_Init because USE_TCL_STUBS is never defined in the generated Makefile.
It appears that the tclsqlite.lo target is the one used in the TCL extension shared library and therefore this target should have -DUSE_TCL_STUBS defined. Below is a diff showing the changes I made to make this work properly in my environment.
There also appears to be some type of abortive effort to do this with the tclsqlite-stubs.lo target, but this target is never referenced in the Makefile and erroneously defines TCL_USE_STUBS rather than USE_TCL_STUBS.
cvs diff Makefile.in
Index: Makefile.in
===================================================================
RCS file: /sqlite/sqlite/Makefile.in,v
retrieving revision 1.134
diff -r1.134 Makefile.in
369c369
< $(LTCOMPILE) -c $(TOP)/src/tclsqlite.c
---
> $(LTCOMPILE) -DUSE_TCL_STUBS -c $(TOP)/src/tclsqlite.c
|
2005-Sep-19 21:05:50 by anonymous:
I was just going to report this Makefile bug and I see this reported
a few days ago. I think that the correct fix is two-fold: use the
correct -DUSE_TCL_STUBS=1 when building tclsqlite-stubs.lo, and then
actually use tclsqlite-stubs.lo when building libtclsqlite3.la.
While the stub-version of tclsqlite.lo may work when linked into
sqlite3_analyzer and the test drivers, it is not the proper way to
do things.
The patch for Makefile.in that I used is appended.
Dave Bodenstab
dave@bodenstab.org
--- Makefile.in 2005/09/17 23:28:06 32.6
+++ Makefile.in 2005/09/19 20:18:51
@@ -235,8 +235,8 @@
$(LTLINK) -o libsqlite3.la $(LIBOBJ) $(LIBPTHREAD) \
${ALLOWRELEASE} -rpath $(libdir) -version-info "8:6:8"
-libtclsqlite3.la: tclsqlite.lo libsqlite3.la
- $(LTLINK) -o libtclsqlite3.la tclsqlite.lo \
+libtclsqlite3.la: tclsqlite-stubs.lo libsqlite3.la
+ $(LTLINK) -o libtclsqlite3.la tclsqlite-stubs.lo \
$(LIBOBJ) @TCL_STUB_LIB_SPEC@ $(LIBPTHREAD) \
-rpath $(libdir)/sqlite \
-version-info "8:6:8"
@@ -412,7 +412,7 @@
$(LTCOMPILE) -DTCLSH=1 -o $@ -c $(TOP)/src/tclsqlite.c
tclsqlite-stubs.lo: $(TOP)/src/tclsqlite.c $(HDR)
- $(LTCOMPILE) -DTCL_USE_STUBS=1 -o $@ -c $(TOP)/src/tclsqlite.c
+ $(LTCOMPILE) -DUSE_TCL_STUBS=1 -o $@ -c $(TOP)/src/tclsqlite.c
tclsqlite3: tclsqlite-shell.lo libsqlite3.la
$(LTLINK) -o tclsqlite3 tclsqlite-shell.lo \
2005-Sep-19 21:09:14 by drh:
I think that if you want to build a shared library for use
with TCL, you ought to use the TEA-compatible tarball that is
found on the website, not the standard source delivery. The
Makefile in the TEA-compatible tarball is much, much more likely
to work correctly. |
|
1426 |
event
|
active
|
2005 Sep
|
anonymous
|
Unknown
|
2005 Sep
|
drh
|
2
|
2
|
Problem with DETACH in 2.8.16
|
edit |
sqlite1.txt:
create table documents (a);
create index i on documents(a);
sqlite2.txt:
attach 'x1.dbx' as d1;
attach 'x2.dbx' as d2;
detach d1;
Commands:
sqlite x1.dbx<script1.txt
sqlite x2.dbx<script1.txt
sqlite myfile<script2.txt
The "detach" command in the last script will crash (sqlite.exe and sqlite.dll under Windows). |
2005-Sep-13 22:55:06 by anonymous:
FWIW, this is no longer a problem in 3.2.5.
2005-Sep-14 00:36:31 by drh:
This problem does not exist in recent versions of SQLite.
The problem does not cause database corruption. And it does
not seem to impact many users since SQLite 2.x has been stable
for over 1.5 years and nobody has yet complained. For all of
these reasons, I'm going to have to give this issue a low priority.
2006-Jul-12 10:38:04 by anonymous:
The exact problem is a crash when you detach a db which is not the last attached...
Sure it's doesn't corrupt db but it's really disturbing.
The only current trick is to :
- memorize coming attached db,
- detach them in inverse mode,
- detach the one you wanted
- and reattach the memorized
|
|
1424 |
new
|
active
|
2005 Sep
|
anonymous
|
Unknown
|
2005 Sep
|
drh
|
5
|
3
|
Pivot table creation
|
edit |
The beautiful SQLite engine lacks of pivot table creation. How to create cross tables? I tried the cross join but without success.
Example: create table tab ( name, department, hours );
Populated with hours that many people spent in some departments
How to produce an answer table (with row and column totals), where the sum of hours (or another aggregate function) is shown in each cell of row=name and column=department. The SQL statement is expected to look similar like following
TRANSFORM sum(hours) as Duration
SELECT name FROM tab GROUP BY name
PIVOT department
In simple words the aggregation of two select statements on some common fields with the other fields in row respective column direction.
I would like to use aggregate functions sum, count, avg, stdev, min, max as already mentioned in ticket #1381. Introduction of sqrt and macros would be fine to create work arounds for stdev and others. |
2005-Sep-14 03:02:24 by anonymous:
This is a feature request and should be brought up on the mailing list. If you haven't already done so, read Unsupported SQL where there have been a few requests for OLAP-oriented features. |
|
1423 |
new
|
active
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
drh
|
3
|
4
|
Binding NULL does not work as expected
|
edit |
There's currently no way to compare to NULL with binding parameters.
My suggestion is that you make "= ?" with the NULL bound parameter work like "IS NULL" and "<> ?" like "IS NOT NULL".
Currently, neither this nor the normal way to bind to "IS ?" works. "IS ?" returns a syntax error even.
Testcase follows.
#include <assert.h>
#include <stdio.h>
#include "sqlite3.h"
int main()
{
sqlite3* db;
sqlite3_stmt* st;
const char* tail;
int rc;
sqlite3_open(":memory:", &db);
/* create table */
sqlite3_prepare(db, "create table test(foo)", 0, &st, &tail);
rc = sqlite3_step(st);
assert(rc == SQLITE_DONE);
rc = sqlite3_finalize(st);
assert(rc == SQLITE_OK);
/* insert row */
sqlite3_prepare(db, "insert into test(foo) values (null)", 0, &st, &tail);
rc = sqlite3_step(st);
assert(rc == SQLITE_DONE);
rc = sqlite3_finalize(st);
assert(rc == SQLITE_OK);
/* query 1 */
rc = sqlite3_prepare(db, "select count(*) from test where foo is ?", 0, &st, &tail);
if (rc != SQLITE_OK) {
printf("query 1: %s\n", sqlite3_errmsg(db));
}
/* query 2 */
sqlite3_prepare(db, "select count(*) from test where foo = ?", 0, &st, &tail);
sqlite3_bind_null(st, 0);
rc = sqlite3_step(st);
assert(rc == SQLITE_ROW);
printf("number of rows: %i\n", sqlite3_column_int(st, 0));
rc = sqlite3_finalize(st);
assert(rc == SQLITE_OK);
return 0;
}
|
2005-Sep-12 09:26:19 by ghaering:
forgot to log in ...
2005-Sep-12 09:38:22 by anonymous:
The index of the sqlite3_bind_* and sqlite3_column_* is starting from 1 not 0. see http://www.sqlite.org/capi3ref.html#sqlite3_bind_null
2005-Sep-12 09:49:26 by drh:
I think what Gerhard is proposing is to have a new operator which
can be used to compare for NULL so that it works against bound
parameters even if the parameter is bound to NULL. You cannot
use == for his. x=='abc' and x==123 both work, but x==NULL always
fails. So saying x==:param is dangerous because if :param is bound
to NULL it does not do what you really want.
I have previously proposed extending the IS operator for this
purpose. You can already say "x IS NULL". Why shouldn't you
also be able to say "x IS 'abc'" and "x IS 123"? Then you could
do things like "x IS :param" and it would work with bound
parameters.
I proposed this on the mailing list once, if I recall, and it
was resoundingly rejected. But maybe people just didn't
understand the question or the problem it was trying to resolve. |
|
1417 |
new
|
active
|
2005 Sep
|
anonymous
|
|
2005 Sep
|
drh
|
3
|
3
|
Fix successive access to a DB handler (unix broken thread file lock)
|
edit |
This patch allows threads to access successively to a DB handle
and remove the heavy restriction of the SQLITE_MISUSE.
In case of simultaneous access, concurent threads get SQLITE_BUSY
until the OsFile is unlocked.
patch against os_unix.c in version 3.2.5. |
2005-Sep-09 20:26:58 by drh:
I do not believe this patch works. When a handle is moved between
threads on a system where separate threads cannot override each others
locks, then then lockInfo structure for that handle needs to be
released and a new lockInfo structure suitable for the new thread
needs to be allocated. There is a separate lockInfo structure for
each thread/file combination so when moving a handle from one thread
to another it is important to get a new lockInfo structure.
2005-Sep-10 01:26:19 by anonymous:
Why this lockInfo structure should need to be released for another thread?
This patch resets safely the thread(a)/file combination to a thread(b)/file combination until the next move. This allows successive access to a DB handle and manage properly concurrent access with SQLITE_BUSY.
2005-Sep-21 15:16:44 by drh:
Suppose this patch is run on a system where threads cannot override
each others locks. (Ex: RedHat 9). Two handles are opened on
separate threads. This gives them different lockKey values.
After opening, the handles are passed to the same thread. The
first handle does "BEGIN; UPDATE ....;" but does not yet commit.
The second handle then does an UPDATE. The first handle does
ROLLBACK. At that point the database has likely been corrupted.
2005-Sep-21 19:50:17 by anonymous:
I can not suppose this because it's "impossible".
This patch is not active on a system where threads cannot override each others locks:
# define CHECK_THREADID(X) ( threadsOverrideEachOthersLocks>0 && check_threadid(X) )
Or if you suppose this is possible, this means that, on the current version of SQLite:
- the testThreadLockingBehavior function is wrong
- data corruption can happen on a system where threads can override each others locks
All this is nonsense. |
|
1415 |
code
|
active
|
2005 Sep
|
anonymous
|
Unknown
|
2005 Sep
|
drh
|
1
|
1
|
Querying for BLOB type fields
|
edit |
How do I query for BLOB type fields?
I tried
- field LIKE 'abc'
- field LIKE quote('abc') and
- field LIKE X'616263'
but nothing seems to return back the record that I am interested in. |
2005-Sep-13 08:00:28 by anonymous:
Using version 3.2.5,
you might use the quote function to convert a blob into a string which you can filter using the like operator:
select * from test where quote(text) like '%6263%'; is working and usable but may not work as expected because like '%26%' would find the same and this was not expected, isn't it?
select * from test where like(quote(text),'%6263%'); doesn't work and
select * from test where like(quote(text),'%6263%','%'); doesn't work either
2005-Oct-04 05:44:08 by anonymous:
This should really be taken to the mailing list, preferably with descriptions of how other DBMSs handle LIKE as applied to BLOB columns. |
|
1403 |
code
|
active
|
2005 Sep
|
anonymous
|
Pager
|
2005 Sep
|
|
4
|
4
|
Newly initialized pages aren't completely cleared
|
edit |
Rational Purify reports many, many UMRs within SQLite, all originating from the following code path:
sqlite3OsWrite [os_win.c:296]
pager_write_pagelist [pager.c:2209]
sqlite3pager_get [pager.c:2445]
getPage [btree.c:1114]
allocatePage [btree.c:3153]
At a glance, it appears that the problem lies in sqlite3pager_get, which does appear to fully clear the newly allocated page.
A portion of the Purify-generated backtrace is attached. |
2005-Sep-01 15:41:50 by drh:
SQLite does not clear "don't-care" sections of the page. Doing so
would use CPU cycles unnecessarily and hence slow things down. That
unused sections of a database page are never initialized is a feature
of SQLite, not a bug.
2005-Sep-01 16:17:17 by anonymous:
Would it be possible to clear the entire page when NDEBUG is not defined? Admittedly, not clearing the page has no ill effects; it does clutter the output from Purify quite a bit though, which will inevitably lead to missing a real error amidst the noise.
2005-Sep-01 17:59:04 by anonymous:
Actually, it looks like I was off the mark as to what's causing this. It isn't writing a newly allocated page that's causing the warning, but reuse of an existing page (from pPager->pFirstSynced). So I'm not sure what needs to be cleared to avoid the warning; some range within the page's memory area, obviously, but it's not as simple as just memset'ing the entire memory area like it would be when the page is freshly allocated earlier in sqlite3pager_get. |
|
1401 |
code
|
active
|
2005 Aug
|
anonymous
|
Shell
|
2005 Aug
|
|
4
|
4
|
concatenating html in select list
|
edit |
create table test( f1 text, f2 text );
insert into table values( 'hello', 'world' );
.mode html
select f1 || '<br>' || f2 from test;
<TR><TD>hello<br>world</TD>
</TR>
Of course, I would like to see
<TR><TD>hello<br>world</TD>
</TR>
|
|
1400 |
new
|
active
|
2005 Aug
|
anonymous
|
|
2005 Sep
|
|
5
|
5
|
Use of indexes in queries to VIEWS built from UNION SELECTS
|
edit |
Attach 2 DBs DB1 and DB2 that have each a table with same schema (say A). Create a view so that all data i seen as one piece, like:
VIEW = SELECT * from DB1.A UNION SELECT * from DB2.A
Many views are created like this (for a few tables) and queries that do joins are run on the views. Those queries do NOT to use the underlying DB1.A and DB2.A indexes (i.e. they are too slow).
Is this a bug? Is this by design? Am I confusing something?
Will "UNION ALL" make a difference?
Sorry if this is explained in docs but i did a search before entering this and could not find something. |
2005-Aug-31 13:09:30 by drh:
I have difficulty understanding this ticket, but I
I think it is an enhancement request for better query
optimization.
It is a question: does creating a view V made as above - by union-ing 2 tables that have same schema - still use indexes from constituent tables? E.g. with a quey like (select * where V.field = 'value'). It appears not to be the case. |
|
1393 |
event
|
active
|
2005 Aug
|
anonymous
|
Unknown
|
2005 Aug
|
|
4
|
3
|
failure in select2-2.0.3... test
|
edit |
The "select2-2.0.3" self-test of sqlite 3.2.5 self test returned a bogus result, quote (indented by 2 spaces each):
select2-2.0.1... Ok
time with cache: 4123975 microseconds per iteration
select2-2.0.2... Ok
time without cache: 3089313 microseconds per iteration
select2-2.0.3...
Expected: [1]
Got: [0]
select2-2.1... Ok
[...]
1 errors out of 20174 tests
Failures on these tests: select2-2.0.3
This was on SuSE Linux 9.3 (kernel 2.6.11.4-21.8-default, a SUSE modified kernel) on a ext3 file system with 850 MB free on a parallel ATA hard disk drive with UDMA (i. e. CRC checking).
The configure options were:
../configure -C CFLAGS="-O2 -march=i586 -mcpu=athlon-xp"
The compiler was:
gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
I haven't yet had the time to re-run the test with a released GCC 3.3.X or 3.4.Y compiler, but can do so if that is desired. Please send directions how to run only this test or a smaller subset of the tests. |
2005-Aug-29 02:08:53 by anonymous:
This doesn't look like a major failure. The test is timing related. Did you run "make test" on an otherwise idle machine, or did you have other cpu/disk intensive processes running?
For comparison (using kernel-2.4.31, glibc-2.3.5, and gcc-3.3.6):
# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Athlon(tm) XP 2200+
...
# ./testfixture test/select2.test
select2-1.1... Ok
select2-1.2... Ok
select2-2.0.1... Ok
time with cache: 447501 microseconds per iteration
select2-2.0.2... Ok
time without cache: 1255564 microseconds per iteration
select2-2.0.3... Ok
...
0 errors out of 21 tests
Failures on these tests:
2005-Aug-29 23:21:08 by drh:
To run the "select2" set of tests, do this:
./testfixture ../sqlite/test/select2.test
2005-Aug-29 23:25:12 by drh:
I'm running SuSE 9.2 with an 3.0GHz P4. My test times are much
faster:
select2-2.0.1... Ok
time with cache: 767370 microseconds per iteration
select2-2.0.2... Ok
time without cache: 1879281 microseconds per iteration
Since the test time should be dominated by disk I/O not CPU,
I am not sure why this is. Are you running on a laptop? |
|
1382 |
code
|
active
|
2005 Aug
|
anonymous
|
|
2005 Aug
|
drh
|
1
|
1
|
Assert nErr==0 on corrupt db
|
edit |
I'm working on an embedded filesystem where files can be randomly altered. Sometimes my .db files get messed up. I've attached an example db.
I'd like to catch the asserts and return an error rather than crash.
$ sqlite corrupt-assert.db 'select count(*) from sensor'
sqlite: src/main.c:120: sqliteInitCallback: Assertion `nErr==0' failed.
Aborted |
|
1381 |
new
|
active
|
2005 Aug
|
anonymous
|
Parser
|
2005 Aug
|
|
5
|
4
|
missing important builtin function stdev
|
edit |
I really miss function stdev for support of statistical usage of SQLite. Also missed sqr and sqrt for square and square root calculations. This would help me very much to simplify my applications if they could be integrated also into the command line tool. An avg without stdev is of no useful meaning.
Another wish is the support of date and time stamp calculations. Some few functions to convert literal expressions into float and backwards would be sufficient for me. No time zone consideration required. |
2005-Aug-25 11:35:15 by anonymous:
Proposal for powerful enhancements:
Introduce alias scripting to combine built in functions to create new function names. Similar to C language macros. SQR and SQRT to become available as builtin functions.
Example for creation:
PRAGMA FUNCTION newfunctionname(<arg1>{,<argn>+})=<macro syntax with arguments>
Example for an application:
PRAGMA FUNCTION
stdev(xsum,xsumcubed,n)=sqrt((n*xsumcubed-sqr(xsum))/(n*(n-1)));
SELECT
avg(t1.c1) as c1mean,
stdev(sum(t1.c1),sum(sqr(t1.c1)),count(t1.c1)) as c1sigma,
avg(t1.c2) as c2mean,
stdev(sum(t1.c2),sum(sqr(t1.c2)),count(t1.c2)) as c2sigma
from t1;
This would reduce typing and enables to simulate non built in functions which can be created on basis of built in functions. Should be well supported by expression optimization to gain most benefit.
2005-Aug-29 16:00:39 by anonymous:
I also lack of sqrt, sqr and stdev (beside some other basics like sin, cos, tan, atan2, deg, rad, ... ). I like the idea of macros, too, because they make simplifications in statements easy. While sqr could be written like MACRO sqr(x)= ((x)*(x)) it is very difficult to live without the sqrt. Even stdev could become a macro but without sqrt the live stays difficult.
If macros become part of SQLite3 then there should also be a command PROBE to see the expanded statement as executed by the parser; similar to EXPLAIN command.
Priority to this ticket should be higher to become realized. |
|
1379 |
warn
|
active
|
2005 Aug
|
anonymous
|
Unknown
|
2005 Aug
|
|
1
|
1
|
cannot install . phpize failed
|
edit |
Trying to install via pear on RHAT Linux Ent V3
[root@host bin]# pear install sqlite
downloading SQLite-1.0.3.tgz ...
...done: 371,189 bytes
50 source files, building
running: phpize
`phpize' failed
Tried some ln -s commands but no use. Trying to get Paypal SDK for PHP work, which requires pear mod Log, which inturn is looking for sqlite.
I appreciate any help |
2005-Aug-25 03:17:06 by anonymous:
This question should be addressed to PHP helpers not here. You should visit php.net. |
|
1365 |
code
|
active
|
2005 Aug
|
anonymous
|
|
2005 Aug
|
|
3
|
3
|
64 bit types not completely overridable
|
edit |
The current 64 bit types in sqlite3.h and sqliteInt.h do not allow the type to be overriden using a preprocessor definition, unlike all the other base types. The current 64 bit typedefs assume that a "long long" is 64 bits - this is not guaranteed (and on PS2 it is wrong, long long is 128 bits).
Here are some minor patches that should allow these types to be overriden, but keep the old behavior if they are not:
==== //sqlite-3.2.2/src/sqlite3.h#1 - sqlite-3.2.2\src\sqlite3.h ==== 81,83c81,83
< #if defined(_MSC_VER) || defined(__BORLANDC__)
< typedef __int64 sqlite_int64;
< typedef unsigned __int64 sqlite_uint64;
---
> #ifdef INT64_TYPE
> typedef INT64_TYPE sqlite_int64;
> typedef unsigned INT64_TYPE sqlite_uint64;
85,86c85,93
< typedef long long int sqlite_int64;
< typedef unsigned long long int sqlite_uint64;
---
> # if defined(_MSC_VER) || defined(__BORLANDC__)
> typedef __int64 sqlite_int64;
> typedef unsigned __int64 sqlite_uint64;
> # else
> typedef long long int sqlite_int64;
> typedef unsigned long long int sqlite_uint64;
> # endif
> # define INT64_TYPE sqlite_int64
> # define UINT64_TYPE sqlite_uint64
==== sqlite-3.2.2/src/sqliteInt.h#1 - sqlite-3.2.2\src\sqliteInt.h ==== 157,163d156
< #ifndef UINT64_TYPE
< # if defined(_MSC_VER) || defined(__BORLANDC__)
< # define UINT64_TYPE unsigned __int64
< # else
< # define UINT64_TYPE unsigned long long int
< # endif
< #endif
183c176
< typedef UINT64_TYPE u64; /* 8-byte unsigned integer */
---
> typedef sqlite_uint64 u64; /* 8-byte unsigned integer */
|
2005-Aug-27 16:45:09 by drh:
Can someone suggest a suitable #ifdef that will automatically
identify a PS and do the right thing to provide a 64-bit integer
type, similar to what is down for windows? |
|
1351 |
code
|
active
|
2005 Aug
|
anonymous
|
Shell
|
2005 Sep
|
|
1
|
1
|
Unable to parse UTF8 input
|
edit |
I'm in the process of writing a program which parses in UTF8 data, and then processes it and writes a UTF8 output into a text file. This textfile needs to be imported into SQLite.
However the commandline SQLite program doesnt support UTF8 input text files for its ".read" command. Considaring the database itself supports UTF8, would it be possible to allow UTF8 text file input.
I can't progress much further on my program if this can't be fixed. |
2005-Aug-08 13:56:24 by drh:
Please attach an example UTF-8 script that ".read" is not reading
correctly.
2005-Aug-08 17:58:44 by anonymous:
I can't seem to attach a text file, so instead i'll put it on my FTP, and it should be accessible from there. If you have trouble with that, i could email the text file. So if you have trouble, give me an email to send it to.
There will be a sample of a text file that won't ".read" available here: ftp://62.231.38.73/ in approximately 10 minutes.
Thanks for the fast reply. I'd be surprised if it was a problem with my text file generation, but stranger things have happened :p
2005-Aug-11 01:40:08 by drh:
Attach files using the [Attach] hyperlink at the top-right of this page.
Please do not send RAR files since that is an obscure archive
format. If you want to use a compressed archive, make it either
ZIP or GZIP.
2005-Aug-11 09:46:23 by anonymous:
I can only attach one because neither winzip or gzip are great at compressing text files. The files keep ending up over 100kb except for the artists.txt file. Thats the only one that went below 100kb.
I'm unwilling to try editing the file to remove lines of text from it because i want you to have the exact output that i'm getting from my program. Not the output that i'd get from notepad if i edited it. That will help identify whether it is a problem in my program, or a problem with SQLite.
Its always possible its a proglem with my source data, and its not actually proper UTF8, but i doubt that as SQLite doesn't seem to read the normal text correctly (such as the first line which is supposed to start a transaction, but SQLite instead ignores the line, and throws an error when it reachs the commit; at the end. |
|
1342 |
code
|
active
|
2005 Jul
|
anonymous
|
|
2005 Jul
|
|
1
|
1
|
sqlite 3.2.2 will not load on Suse Linux 9.3
|
edit |
when trying to load the sqlite 3.2.2 .so lib with tcl I get this problem:
couldn't load file "/usr/lib/sqlite3/tclsqlite-3.2.2.so": /usr/lib/sqlite3/tclsqlite-3.2.2.so: undefined symbol: sqlite3_version
Sqlite 3.2.1 does not give an error, with the same script |
|
1332 |
new
|
active
|
2005 Jul
|
anonymous
|
Unknown
|
2005 Jul
|
|
5
|
5
|
update 20x slower when using a temp table
|
edit |
I have two versions of the same algorithm. The first operates directly on the main db table. The second operates on a temp table containing only the working set. The problem is that the second version is about 20x slower, 1.5 sec versus 30 sec. If the EXISTS line in the second version is commented out the execution time drops to 9 sec. The test dataset has 12000 rows in group_article and the query deals with 6400 rows. The final version will be expected to work with >2 million rows.
Version 1:
UPDATE group_article SET parent=null WHERE group_id=?;
UPDATE group_article SET parent=
( SELECT article.id FROM refs ,article
WHERE refs.article_id=group_article.article_id
AND reference=hash
AND EXISTS (SELECT id FROM group_article
WHERE group_id=?1 AND article_id=article.id)
ORDER BY refs.id DESC LIMIT 1 )
WHERE group_id=?1
Version 2:
CREATE TEMP TABLE thrd(aid UNIQUE, parent);
INSERT INTO thrd(aid)
SELECT article_id FROM group_article WHERE group_id=?;
UPDATE thrd SET parent=
( SELECT article.id FROM refs ,article
WHERE refs.article_id=thrd.aid
AND reference=hash
AND EXISTS (SELECT aid FROM thrd WHERE aid=article.id)
ORDER BY refs.id DESC LIMIT 1 );
UPDATE group_article SET parent=
( SELECT parent FROM thrd WHERE aid=article_id )
WHERE group_id=? ;
Here are partial table defs.
table group_article (id PRIMARY, group_id INT, article_id INT);
UNIQUE index on (group_id, article_id);
table refs (id PRIMARY, article_id int, reference BLOB(15));
index on (article_id)
table article (id PRIMARY, hash BLOB(15));
UNIQUE index on (hash)
Almost forgot, I'm running this on windows xp, compiled with mingw gcc 3.4.4. |
The appears to be an enhancment request - you are wanting better
optimization in the SQLite. It seems to get the correct answer,
you just want to get the answer faster. So I have changed this
ticket to an enhancment request and set the priority very low.
If you want help optimizing your query, the proper place to ask
is on the mailing list.
2005-Jul-24 03:50:31 by anonymous:
After taking a day away from the code I finnaly found the problem. Declaring a column as UNIQUE without giving it a type means that either the index is not created or it's not used. A full table scan was being used each time in the second version. Adding INT as the type on thrd.aid fixed the performance problem.
Assuming I didn't miss this in the docs, this is either a bug or a note is needed so others don't make the same mistake. |
|
1327 |
code
|
active
|
2005 Jul
|
ghaering
|
VDBE
|
2005 Jul
|
|
2
|
3
|
UNION causes sqlite3_column_decltype to always return NULL
|
edit |
create table test(foo bar);
select foo from test
union
select foo from test;
Normally, sqlite3_column_decltype() will return 'bar', but with the UNION, it will always return NULL.
This is quite annoying for pysqlite users, because it renders the type detection useless for UNION queries (and EXCEPT and INTERSECT). |
|
1325 |
code
|
active
|
2005 Jul
|
anonymous
|
Unknown
|
2005 Jul
|
|
1
|
4
|
sqlite3_bind_value not implemented
|
edit |
function sqlite3_bind_value not implemented |
|
1323 |
code
|
active
|
2005 Jul
|
anonymous
|
|
2005 Jul
|
|
1
|
1
|
misuse-4.4...gmake: *** [test] Segmentation Fault (core dumped)
|
edit |
misuse-4.4...gmake: *** [test] Segmentation Fault (core dumped)
on both solaris 8 and 9
build env
export CPPFLAGS="-I/tps/include"
export LDFLAGS="-L/tps/lib -R/tps/lib"
export PKG_CONFIG_PATH=/tps/lib/pkgconfig
CC=/tps/bin/gcc
CXX=/tps/bin/g++
LD_LIBRARY_PATH=/tps/lib:/tps/lib/sparcv9:/lib:/usr/lib:/usr/local/lib:\
/usr/ccs/lib:/usr/dt/lib:/usr/ucblib:/usr/openwin/lib
PATH=/tps/bin:/tps/java/bin:/dsw/source/bin:/dsw/depot-5.13/bin:\
/usr/ccs/bin:/usr/bin:/usr/openwin/bin:/bin:/usr/local/bin:/sbin:\
/usr/sbin:/usr/ucb:/etc:.:/sfoc/bin:/usr/dt/bin:\
/dsw/source/harvest/bin:/usr/afsws/bin:/dsw/pgp-2.6.2s/bin
export CC CXX LD_LIBRARY_PATH PATH
where /tps is my version of /usr/local where I put all the configuration controlled open source and licensed s/w for my network.
<pray@fir:/export/build/sqlite-3.2.2/bld>
[525]$ ../configure --prefix=/dsw/sqlite-3.2.2 --with-tcl=/tps/lib
gmake
gmake test
then got error
gcc -v
Reading specs from
/dsw/gcc-3.4.0/lib/gcc/sparc-sun-solaris2.9/3.4.0/specs
Configured with: ../configure --prefix=/dsw/gcc-3.4.0 --disable-nls --enable-languages=c,c++,f77,objc --disable-libgcj --srcdir=/export/build/gcc-3.4.0 --with-ld=/usr/ccs/bin/ld
Thread model: posix
gcc version 3.4.0
using ActiveTcl8.4.5.0 |
|
1319 |
new
|
active
|
2005 Jul
|
anonymous
|
|
2005 Jul
|
|
5
|
4
|
Extend sqlite3_expired to detect schema changes
|
edit |
Hi,
It would be nice to have sqlite3_expired() detect if the database schema has changed by, for example, vacuuming.
This also requires the statement to be recompiled, and so IMHO it makes sense to have expired handle that.
Thanks. |
|
1318 |
build
|
active
|
2005 Jul
|
anonymous
|
|
2005 Jul
|
|
2
|
4
|
Build broken under Windows/MinGW
|
edit |
The current release doesn't build with GCC for Windows by www.mingw.org.
The compiler error "No rule to make target 'sqlite3', needed by 'install'" can be worked around by replacing "$(TEXE)" by "@TARGET_EXEEXT@" in Makefile.in.
To build a DLL, "make dll" has to be invoked manually. However, an import library (.dll.a) and a libtool library file (.la) are not generated for the DLL.
Everything was fine in 3.0.8 |
|
1313 |
new
|
active
|
2005 Jun
|
anonymous
|
|
2005 Jun
|
|
4
|
4
|
Allow headers in imported text files
|
edit |
Please enhance the '.import' command to add a switch which
allows the user to specify whether or not the imported text
file contains headers.
If it does, they can be silently discarded.
As it stands the header row will be imported as a normal data row.
|
2007-Jan-26 16:57:48 by anonymous:
This feature would be very nice, but it would also be great to be able to create a table using the header row as column names during .import. |
|
1312 |
code
|
active
|
2005 Jun
|
anonymous
|
Shell
|
2005 Sep
|
|
1
|
1
|
CSV file import / export is all wrong!
|
edit |
Four problems:
Importing a proper CSV file (which delimits strings within
double-quotes) is impossible. The '.import' command just
treats the double-quotes as ordinary text characters. So
(1) Error "expected 2 columns of data but found 3" can occur
if one of the strings contains a comma
(2) the delimiting double-quotes are NOT stripped off before
inserting the data into the table as it should
(3) it doesn't understand the standard convention that to
represent a double-quote character within a double-quoted
string you use TWO double-quote (eg. "3.5"" Floppy Drive")
(4) outputting data in CSV mode also doesn't use this standard
convention
--------------------------------------------
_Product.csv contains:
"A001","McVities"
"B001","Heinz"
"C001","Callard,Bowser"
sqlite> .mode csv
sqlite> .import _Product.csv Product
_Product.csv line 3: expected 2 columns of data but found 3
|
2005-Aug-12 23:13:54 by anonymous:
Commas are also not accounted for when using the sqlite3_mprintf() function(s). I'm guessing the %q flag should also escape these. |
|
1308 |
code
|
active
|
2005 Jun
|
anonymous
|
|
2005 Jun
|
|
3
|
4
|
PRAGMA TABLE_INFO does not recognize attached database syntax.
|
edit |
PRAGMA TABLE_INFO does not recognize the dbName.tableName syntax to distinguish between identically named tables in attached databases. |
2005-Jun-28 17:06:51 by anonymous:
The pragma command use a different syntax to select the attached database. The following should work:
PRAGMA database_name.table_info(table_name)
This should be fixed in the documentation. The optional database name is shown for the version number pragmas, but not for the others on the page http://www.sqlite.org/pragma.html#schema
This seems to be a common and natural expectation since attached tables are referred to using the database_name.table_name syntax in queries. The documentation should be very clear that it is different for the pragma commands.
2005-Jun-28 19:51:03 by anonymous:
It should also be made clear whether a single pragma value applies to all attached databases, or if each attached database has its own value for the pragma. |
|
1305 |
code
|
active
|
2005 Jun
|
anonymous
|
TclLib
|
2005 Jun
|
|
1
|
1
|
Tcl installs pkgIndex with wrong path
|
edit |
Correct script below:
# This script attempts to install SQLite3 so that it can be used
# by TCL. Invoke this script with single argument which is the
# version number of SQLite. Example:
#
# tclsh tclinstaller.tcl 3.0
#
set VERSION [lindex $argv 0]
set LIBFILE .libs/libtclsqlite3[info sharedlibextension]
if { ![info exists env(DESTDIR)] } { set DESTDIR "" } else { set DESTDIR $env(DESTDIR) }
set LIBDIR [lindex $auto_path 0]
set LIBNAME [file tail $LIBFILE]
set LIB $LIBDIR/sqlite3/$LIBNAME
file delete -force $DESTDIR$LIBDIR/sqlite3
file mkdir $DESTDIR$LIBDIR/sqlite3
set fd [open $DESTDIR$LIBDIR/sqlite3/pkgIndex.tcl w]
puts $fd "package ifneeded sqlite3 $VERSION \[list load $LIB sqlite3\]"
close $fd
# We cannot use [file copy] because that will just make a copy of
# a symbolic link. We have to open and copy the file for ourselves.
#
set in [open $LIBFILE]
fconfigure $in -translation binary
set out [open $DESTDIR$LIB w]
fconfigure $out -translation binary
puts -nonewline $out [read $in]
close $in
close $out
|
|
1302 |
event
|
active
|
2005 Jun
|
anonymous
|
Unknown
|
2005 Jun
|
|
1
|
4
|
malloc error after dumping table
|
edit |
I dumped a table then quit SQLite and received the following error while using the shell program.
sqlite> .output "/participants.csv"
sqlite> .dump part_info
sqlite> .quit
sqlite3(1593,0xa000ef98) malloc: *** Deallocation of a pointer not malloced: 0x726f7365; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug
Segmentation fault |
|
1300 |
event
|
active
|
2005 Jun
|
anonymous
|
Unknown
|
2005 Jun
|
|
2
|
2
|
Apache.exe has encountered a problem and needs to close.
|
edit |
I converted a MySql DB to SWLite. They are running on the same system and have identical data. Works on MySQL and not SQLite. SQLite gives Apache problem above. It's a very simple SQL that finds the last WPO (Wine Process Order) for each storage tank. Here is the SQL
SELECT
s.storage_id,
d.from_to,
d.leg_num,
d.wpo_num,
w.wpo_datetime,
s.descr
FROM
wpo_dtl AS d,
wpo AS w,
storage AS s
WHERE d.wpo_num = w.wpo_num
AND d.leg_num = w.leg_num
AND s.storage_id = d.storage_id
AND w.wpo_datetime = (
SELECT max(wa.wpo_datetime)
FROM
wpo as wa,
wpo_dtl as da
WHERE da.wpo_num = wa.wpo_num
AND da.leg_num = wa.leg_num
AND da.storage_id = s.storage_id)
WPO has;
wpo_num int,leg_num int , wpo_datetime datetime ...
WPO_DTL has;
wpo_num int,leg_num int, storage_id char ...
Storage has;
storage_id char ...
Thank you for your time..
Have a great day.
Dan |
2005-Jun-23 19:31:49 by drh:
Please include the database schema so that we can have at least
an outside chance of reproducing the problem.
Please also note that version 3.2.2 is current and version 2.8.16
is current in the legacy version 2 series. Your bug has likely
already been fixed. |
|
1298 |
code
|
active
|
2005 Jun
|
anonymous
|
Shell
|
2005 Oct
|
drh
|
4
|
3
|
sqlite3.exe not recognizing newline as comment terminator
|
edit |
The sqlite3.exe program does not recognize comments that end in a newline if there is valid SQL before them on the same line.
The statement:
"SELECT 1; -- this is a comment"
should be valid SQL, but sqlite3.exe still requires a semicolon after the comment.
Please look at the test below:
C:\Temp\SQLite>sqlite3
SQLite version 3.2.1
Enter ".help" for instructions
sqlite> select 1;
1
sqlite> select 1; -- test comment
...> ;
1
sqlite> select 1; -- test;
1
sqlite> |
2005-Jun-22 18:20:37 by anonymous:
The string "SELECT 1; -- this is a comment" is not valid SQL. SQL does not use the semicolon character inside SQL statements except to seperate the constituent statements of a trigger, stored procedure, or an embedded program.
The semicolon is used by sqlite3.exe (and standard SQL) as a end of statement marker that triggers it to parse and execute the input up to that point. From the SQL 2003 standard:
21 Direct invocation of SQL
21.1 <direct SQL statement>
Function
Specify direct execution of SQL.
Format
<direct SQL statement> ::= <directly executable statement> <semicolon>
This SQL statement should be "SELECT 1 --this is a comment" followed by a semicolon to mark the end of the statement. Putting the semicolon in the middle terminates the first statement at that point, executes it, and then starts collecting input for a second statement (which in this case does not have a terminating semicolon).
Note that sqlite3 also accepts the word GO (used by SQL server) or the Oracle compatible character "/" as the end of statement marker, but only when they appear on a line of input by themselves (i.e. at the continuation prompt in the shell).
sqlite> SELECT 1 --this is a comment
...> go
1
sqlite> SELECT 1 --this is a comment
...> /
1
sqlite>
|
|
1295 |
event
|
active
|
2005 Jun
|
anonymous
|
Unknown
|
2005 Jun
|
|
1
|
1
|
SQL query involving subqueries causes reproduceable segfault in 2.8.14
|
edit |
The query is
SELECT COUNT(g.gid)
FROM kestassd_games g
WHERE (
(
SELECT COUNT(m1.gid)
FROM kestassd_memberships m1
WHERE m1.gid=g.gid
)
=
(
SELECT COUNT(m2.gid)
FROM kestassd_memberships m2
WHERE m2.gid=g.gid
AND m2.finalized=1
)
OR (".time()." > g.nextproc)
)
AND NOT (g.mode = 0)
When executed Apache 2 logs a segfault, and you disconnect with no error message. The error which Apache reports is "[Tue Jun 21 15:39:05 2005] [notice] child pid 1107 exit signal Segmentation fault (11)"
Here's a zip/tar.gz of the database file which causes the segfault to occur if you run the query, along with a PHP script which will connect and execute the query:
http://www.kuliukas.com/segfault.zip or
http://www.kuliukas.com/segfault.tar.gz
Thanks for the help, please e-mail me if you need more info. |
2005-Jun-21 09:28:35 by drh:
I will look at this. But because there is no easily reproducible
script and the bug is against an older version of SQLite (a version
to which many bug fixes have already been published), this problem
will be investigated at a lower priority. I've attached
a copy of the segfault.tar.gz file so that if the files on the
http://www.kuliukas.com/ website go away we will still have a copy
available.
2005-Jun-21 14:27:27 by anonymous:
Bear in mind that this is the version used in PHP 5 currently, it's quite a commonly used version I imagine, but I see your point. |
|
1294 |
new
|
active
|
2005 Jun
|
anonymous
|
|
2005 Jun
|
|
3
|
3
|
API to get ordinal table name
|
edit |
When a select statement returns a recordset, SQLite current implementation has an API to retrieve all column names. It is great to have an API to retrieve table names for each columns. This is especial usefull to deal with joins and dynamic queries and update the recordset on the fly. I believe MySQL has this feature. It would be great to port this feature over. |
|
1293 |
build
|
active
|
2005 Jun
|
anonymous
|
|
2005 Jun
|
|
1
|
1
|
No file .LIB in sqlitedll-3_2_2.zip for links in Windows.
|
edit |
No file .LIB in sqlitedll-3_2_2.zip for links in Windows. |
2005-Jun-18 22:48:55 by anonymous:
the idea is to generate a .lib from the .def, read your compiler docs on how. (vc++ comes with lib.exe) |
|
1286 |
code
|
active
|
2005 Jun
|
anonymous
|
|
2005 Jun
|
|
4
|
4
|
The downloadable DLL file does not work with Intel VTune
|
edit |
The DLL which can be downloaded in sqlitedll-3_2_2.zip does not work with the Intel VTune profiler version 7.2. I don't know the cause of the problem, but after recreating the DLL with Visual Studio 2003 from the source found in sqlite-source-3_2_2.zip, it works well. |
|
1278 |
code
|
active
|
2005 Jun
|
anonymous
|
|
2005 Jun
|
|
1
|
2
|
sqlite3_finalize doesn't clear previous error code or message
|
edit |
A call to sqlite3_finalize(), after an error during sqlite3_prepare() of another statement, returns the correct result SQLITE_OK, but does not reset the error code or error message returned by sqlite3_errcode() and sqlite3_errmsg(). The error reporting functions still return the error code and message associated with the error that occurred during the previous prepare.
The attached code demonstrates the problem. One statement is prepared successfully. Then an second statement is prepared. This one fails and returns an error result. The correct error code and message are retrieved using the error reporting API functions. Next, the first statement is finalized, which returns SQLITE_OK. Calling the sqlite_errcode() function at this point still returns the error code from the previous error.
I believe the error code and message should be cleared by the successful call to the sqlite3_finalize() API function. |
|
1264 |
code
|
active
|
2005 May
|
anonymous
|
Unknown
|
2005 May
|
|
3
|
3
|
access() undefined on MSVC
|
edit |
shell.c(1705) : warning C4013: 'access' undefined; assuming extern returning int
Add this:
#if defined(_WIN32) && defined(_MSC_VER)
# include <io.h>
#endif
|
|
1262 |
new
|
active
|
2005 May
|
anonymous
|
VDBE
|
2005 May
|
|
5
|
3
|
5-15% performance increase for slow joins
|
edit |
Attaching an optimization to sqlite3VdbeRecordCompare() that gives a speedup of 5-15% for certain SELECTs with join.
The optimization does comparisons directly on serialized data instead of deserializing and then comparing.
It also inlines sqlite3GetVarint32 partly. The way the __inline keyword is used needs to be made portable. |
2005-May-22 12:52:08 by anonymous:
I don't have the neccessary infrastructure to run the unit tests, so it's likely that unit tests fail since I only have done limited testing of the code.
As long as it doesn't contain any fundamental logic flaws any bugs should be possible to fix.
2005-May-22 19:56:29 by anonymous:
Looks like negative doubles don't compare as easy as I thought. Please wait for a fix before comitting.
2005-May-22 21:25:49 by anonymous:
Attaching file that passes the unit tests. |
|
1255 |
code
|
active
|
2005 May
|
anonymous
|
|
2005 May
|
|
4
|
3
|
Decrease number of warnings with Microsoft Visual C++
|
edit |
Add this to sqliteInt.h to decrease the number of warnings produced by sqlite:
#if defined(_MSC_VER)
#pragma warning (disable: 4018) // signed/unsigned mismatch
#pragma warning (disable: 4244) // conversion from 'unsigned __int64 ' to 'unsigned char ', possible loss of data
#pragma warning (disable: 4761) // integral size mismatch in argument; conversion supplied
#endif
|
2005-May-20 19:27:50 by drh:
Is there no command-line option on microsoft to disable these
warnings?
2005-May-21 08:56:15 by anonymous:
It's possible to lower the warning level, from say 3 to 2 using the command line. But this is not as selective and will remove more warnings than those #pragmas. |
|
1254 |
new
|
active
|
2005 May
|
anonymous
|
Pager
|
2005 May
|
|
3
|
3
|
better pager_cksum
|
edit |
pager_cksum currently reads one byte every 200 bytes in a page and computes a checksum from this.
Suggest changing this to reading 32-bits every 200 bytes. This will run a the same speed, but the likelyhood of detecting errors is larger, since 400% more data is used in the checksumming. |
|
1250 |
new
|
active
|
2005 May
|
anonymous
|
Pager
|
2005 May
|
|
1
|
3
|
FlushFileBuffers makes Windows sqlite dead slow compared to Linux
|
edit |
On Windows, FlushFileBuffers is used to commit changes to the disk. This makes Windows sqlite very slow in comparison with sqlite on Linux, because fsync() doesn't flush the disk controller's cache like FlushFileBuffers does.
When opening the database file and journal file, there should be an option to use the FILE_FLAG_WRITE_THROUGH file flag. This will make sure that all writes go through the OS cache directly to the disk before the write function returns.
This will give a small slowdown for HUGE commits, but the speedup for small commits is substantial. FILE_FLAG_WRITE_THROUGH is 5-10x faster than FlushFileBuffers for all commits that don't write to a huge number of pages. For commits in the size range of 5-10 megabytes, FILE_FLAG_WRITE_THROUGH is around 2x slower. |
2005-May-18 17:49:22 by anonymous:
Attaching sqlite.patch that adds a global variable that controls the write through status. This is not ideal, but it allows you to benchmark the differences easily.
2006-Jun-06 18:34:18 by anonymous:
FILE_FLAG_WRITE_THROUGH is the norm for Microsoft's SQL Server.
http://support.microsoft.com/default.aspx?scid=kb;en-us;234656 |
|
1249 |
new
|
active
|
2005 May
|
anonymous
|
Unknown
|
2005 May
|
|
5
|
4
|
transaction
|
edit |
It would be handy to have a sqlite3_in_transaction function that would return whether or not a databases connection was in the middle of a transaction or not. I'm thinking this could be as simple as just returning the value of the autoCommit flag. I suppose it might be interesting to have it return the type of the transaction, but that would be strictly for extra credit. |
2005-May-18 15:20:00 by anonymous:
Actually, what we probably really want is a call that tells us the value of the autoCommit flag. |
|
1248 |
code
|
active
|
2005 May
|
anonymous
|
Unknown
|
2005 May
|
|
3
|
1
|
sqlite3_get_table returns garbage for BLOB data
|
edit |
BLOB data returned by sqlite_get_table() is garbage when it contains data bytes holding '0' values.
Code: Windows, 3.2.1, VC 6.0
char data[128];
for(int i = 0;i<128;i++)
{
data[i] = i+1;
}
sqlite3_exec(thedb,"CREATE TABLE test (b BLOB)",NULL,NULL,NULL);
result = sqlite3_prepare(thedb,"INSERT INTO test (b) VALUES (?)",-1,&cstate,NULL);
sqlite3_bind_blob(cstate,1,data,128,SQLITE_STATIC); // bind the data to the statement
result = sqlite3_step(cstate);
result = sqlite3_finalize(cstate);
sqlite3_get_table(thedb,"SELECT * FROM test",result,rows,columns,NULL);
this sqlite3_get_table() returns a properly layed out table. However, it looks like sqlite_get_table() is converting blob data to another type of data (string?) as it processes the command. The BLOB data it returns using this call is completely corrupted, due to processing '0' valued bytes as EOS characters. Instead it should be inferring BLOB data where appropriate, and returning a correct data block.
As a workaround I've been using the prepare/step functions instead. However, the sqlite3_get_table() is a neccessity for many users of this library, as it allows a simple and elegant SQL query mechanism, and should be fixed ASAP to support BLOB data properly. |
2005-Sep-27 01:44:39 by anonymous:
sqlite3_get_table is considered legacy code, intended to make porting of sqlite2 applications (which never had to deal with BLOBs) easier. Its use in new applications is deprecated. If you need something like it that can handle BLOBs, you're best off writing a wrapper function for the prepare/step interface (you can use the sqlite3_get_table code as a template). |
|
1246 |
warn
|
active
|
2005 May
|
anonymous
|
|
2005 May
|
|
4
|
3
|
Many warnings from gcc4
|
edit |
Compiling 3.2.0 on Fedora Core 4 Test 3 with gcc 4 gives MANY:
'pointer targets in assignment differ in signedness'
warnings |
|
1242 |
code
|
active
|
2005 May
|
anonymous
|
Shell
|
2007 Aug
|
|
3
|
4
|
EXPLAIN causes segmentation fault on OSX (and linux)
|
edit |
Under Mac OS X, EXPLAIN causes a segmentation fault:
[jacob@046] ~$ sqlite3 foo.db
SQLite version 3.2.1
Enter ".help" for instructions
sqlite> CREATE TABLE test (a int, b int);
sqlite> EXPLAIN SELECT * FROM test;
Segmentation fault
The crash dump follows:
Host Name: jacobian
Date/Time: 2005-05-13 09:17:04.860 -0500
OS Version: 10.4 (Build 8A428)
Report Version: 3
Command: sqlite3
Path: /usr/local/bin/sqlite3
Parent: bash [15421]
Version: ??? (???)
PID: 15544
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x1400fffc
Thread 0 Crashed:
0 libSystem.B.dylib 0x90003228 strlen + 8
1 libsqlite3.0.dylib 0x002387c8 sqlite3VdbeList + 284 (vdbeaux.c:609)
2 libsqlite3.0.dylib 0x002376e0 sqlite3_step + 312 (vdbeapi.c:207)
3 libsqlite3.0.dylib 0x0023e5d8 sqlite3_exec + 260 (legacy.c:82)
4 sqlite3 0x00005b64 process_input + 808 (shell.c:1504)
5 sqlite3 0x000062bc main + 1528 (shell.c:1790)
6 sqlite3 0x00001db4 _start + 348 (crt.c:272)
7 sqlite3 0x00001c54 start + 60
Thread 0 crashed with PPC Thread State:
srr0: 0x90003228 srr1: 0x0000d030 vrsave: 0x00000000
cr: 0x22444428 xer: 0x00000006 lr: 0x002387c8 ctr: 0x90003220
r0: 0x002387c8 r1: 0xbfffef40 r2: 0x00249a00 r3: 0x1400fffe
r4: 0x00000028 r5: 0x00000000 r6: 0x00000001 r7: 0xffffffff
r8: 0x00000001 r9: 0x1400fffc r10: 0x00000086 r11: 0x00249180
r12: 0x90003220 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000
r16: 0x00000000 r17: 0xbffff0f8 r18: 0x00000000 r19: 0xbffff17c
r20: 0x00000000 r21: 0x000036d0 r22: 0x00303d90 r23: 0x00303d74
r24: 0x01805700 r25: 0x01807e00 r26: 0x00000001 r27: 0x00000004
r28: 0x01805640 r29: 0x01805600 r30: 0x01805200 r31: 0x002386bc
Binary Images Description:
0x1000 - 0x7fff sqlite3 /usr/local/bin/sqlite3
0x205000 - 0x248fff libsqlite3.0.dylib /usr/local/lib/libsqlite3.0.dylib
0x8fe00000 - 0x8fe50fff dyld 43 /usr/lib/dyld
0x90000000 - 0x901a6fff libSystem.B.dylib /usr/lib/libSystem.B.dylib
0x901fe000 - 0x90202fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib
0x91d33000 - 0x91d53fff libmx.A.dylib /usr/lib/libmx.A.dylib
0x9680c000 - 0x9683afff libncurses.5.4.dylib /usr/lib/libncurses.5.4.dylib
0x969a3000 - 0x969b9fff libedit.2.dylib /usr/lib/libedit.2.dylib
|
Happening to me as well on FC6 sqlite3 version 3.3.6
2007-Aug-21 17:09:34 by anonymous:
Try to upgrade to 3.4.2. |
|
1241 |
code
|
active
|
2005 May
|
anonymous
|
|
2005 May
|
|
4
|
5
|
sqlite3_create_collation16 - should have 'const void* zName' arg
|
edit |
sqlite3_create_collation16 - should have 'const void* zName' arg NOT 'const char* zName'
I believe that:
int sqlite3_create_collation16(
sqlite3*,
const char *zName,
int eTextRep,
void*,
int(*xCompare)(void*,int,const void*,int,const void*)
);
in sqlite3.h should be:
int sqlite3_create_collation16(
sqlite3*,
const void *zName, /* <<== CHANGE HERE <<== */
int eTextRep,
void*,
int(*xCompare)(void*,int,const void*,int,const void*)
);
|
|
1240 |
new
|
active
|
2005 May
|
anonymous
|
Pager
|
2005 May
|
drh
|
1
|
3
|
Need integration of Apple's file locking callbacks improvement
|
edit |
Now that OSX 10.4 has been released to the public; Apple has dedicated their changes to improve and support locking on the OSX platform (as well as others) to the public domain. These changes will also make it possible to use sqlite on prior versions of OSX. They externalize the necessary file locking into a callback system which greatly simplifies maintaining this area of persistent headaches.
Apple has also included support for F_FULLFSYNC as described here:
http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html
Apple's changes are to a base distro of sqlite 3.1.3
The sources can be found at:
http://www.opensource.apple.com/darwinsource/tarballs/other/SQLite-28.tar.gz |
|
1235 |
code
|
active
|
2005 May
|
anonymous
|
Unknown
|
2005 May
|
drh
|
4
|
3
|
inconsistent pragma handling
|
edit |
The pragma user_version and schema_version are handled inconsistently in this respect : the result set returned contains a single column that has no name. all other pragmas return named columns. since some high-level languages complain about db fields with no names (most wrappers will gag at this), I suggest that a simulated "column_name" is also generated here, as with all other pragmas. |
|
1228 |
code
|
active
|
2005 Apr
|
anonymous
|
Unknown
|
2005 Apr
|
|
4
|
3
|
problem with select+union on a view with aliased columns
|
edit |
CREATE TABLE tbl1 (col1 VARCHAR PRIMARY KEY);
INSERT INTO tbl1 VALUES ('1');
INSERT INTO tbl1 VALUES ('2');
CREATE VIEW view1 AS SELECT col1 AS col1a FROM tbl1;
This creates a view with one column (col1a). Normal SELECTs on this view return results as expected, but the following:
SELECT col1a FROM view1 WHERE col1a = 1
UNION
SELECT col1a FROM view1 WHERE col1a = 2;
Produces:
col1
1
2
When the column name should in fact be col1a (this is the behaviour in postgres). You can work around this by doing:
SELECT col1a AS col1a FROM view1 WHERE col1a = 1
UNION
SELECT col1a AS col1a FROM view1 WHERE col1a = 2;
But that shouldn't be necessary. Thanks. --Sebastian Kun |
|
1227 |
new
|
active
|
2005 Apr
|
anonymous
|
Shell
|
2005 Apr
|
|
5
|
2
|
Small patch for timing commands in shell.c
|
edit |
Please find attached small patch for timing commands in shell.
Patch explains usage of a new .timer command.
Patch is tested with OpenWatcom 1.4 + Windows
20a21
> #include <time.h>
80d80
<
778a779
> ".timer start|show Internal timer functions\n"
1385a1387,1414
> }else
>
> /*
> Bartosz Polednia 27.04.2005 - free for SQLite community
>
> .timer start
> Starts internal clock counter and prints it in form :
> Start time: Sat Mar 21 15:58:27 2005
>
> .timer show
> Shows time elapsed in form :
> Exec time: nnnnnn.nnn s. Sat Mar 21 15:58:27 2005
> where nnnnnn.nnn is time in sec. since last .timer start command.
> Timer is not stopped so user can issue next .timer show command.
> To start timer user has to exec .timer start command again.
>
> */
> if( c=='t' && strncmp(azArg[0], "timer", n)==0 && nArg>=2 ){
> static clock_t timerstart = 0;
> time_t now = time( NULL );
> if( strcmp(azArg[1],"start")==0 ){
> timerstart = clock();
> printf("Start time: %13s %s", "", ctime( &now ) );
> }else if (strcmp(azArg[1],"show")==0 ){
> clock_t tmp = clock();
> printf("Exec time: %10.3lf s. %s", (1.0*tmp - timerstart)/CLOCKS_PER_SEC, ctime( &now ) );
> }
Regards,
Bartosz
|
|
1223 |
code
|
active
|
2005 Apr
|
anonymous
|
|
2005 Apr
|
|
3
|
4
|
.read FILENAME fails
|
edit |
on win xp with an uft-8 encoded file saved by notepad : "SQLerror:near
"´╗┐": syntax error"
sqlite-3_2_1 (precompiled binaries for windows). |
2005-Apr-26 12:33:32 by drh:
Without some additional hints (such as the text of the file
containing the syntax error) we cannot diagnose this problem.
2005-Apr-26 14:55:33 by anonymous:
to produce the problem :
from win use notepad, enter any valid sql, save as with encoding utf8 (the file begin with the utf8 BOM &ef &bb &bf), from sqlit3 use the .read and you get it ... |
|
1222 |
code
|
active
|
2005 Apr
|
anonymous
|
Unknown
|
2005 Apr
|
|
2
|
4
|
spec file errors
|
edit |
the "spec.template" file as included with sqlite-3.2.1.tar.gz does not work. the following fixes need to be made:
(1) on the "%prep" line, change "-n %{name}" to "-n %{name}-%{version}" since that's the directory name that the source tarball expands into.
(2) the main package needs a dependency on "tcl" and a build dependency on "tcl-devel". this is done by adding "Requires: tcl" and "Buildrequires: tcl-devel" below the "BuildRoot" line.
(3) i suspect the devel package will also have a dependency on "tcl-devel"- as long as the user is required to have tcl in order to install sqlite from RPM files, does it make sense to have "sqlite-devel" without also having "tcl-devel" installed?
in addition, it looks like when "make tcl_install" runs as part of the rpmbuild process, it isn't picking up $DESTDIR from the environment and is therefore trying to create "/usr/share/tcl8.4/sqlite3" on the system instead of within the virtual root created by rpm. rpmbuild's "%make" script contains the following:
#!/bin/sh
RPM_SOURCE_DIR="/home/jms1/rpm/SOURCES"
RPM_BUILD_DIR="/home/jms1/rpm/BUILD"
RPM_OPT_FLAGS="-O2 -g -march=i386 -mcpu=i686"
RPM_ARCH="i386"
RPM_OS="linux"
export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_ARCH RPM_OS
RPM_DOC_DIR="/usr/share/doc"
export RPM_DOC_DIR
RPM_PACKAGE_NAME="sqlite"
RPM_PACKAGE_VERSION="3.2.1"
RPM_PACKAGE_RELEASE="1"
export RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE
RPM_BUILD_ROOT="/var/tmp/sqlite-3.2.1-root"
export RPM_BUILD_ROOT
set -x
umask 022
cd /home/jms1/rpm/BUILD
cd sqlite-3.2.1
install -d $RPM_BUILD_ROOT//usr
install -d $RPM_BUILD_ROOT//usr/bin
install -d $RPM_BUILD_ROOT//usr/include
install -d $RPM_BUILD_ROOT//usr/lib
make install prefix=$RPM_BUILD_ROOT//usr
/usr/lib/rpm/brp-compress
/usr/lib/rpm/brp-strip
/usr/lib/rpm/brp-strip-static-archive
/usr/lib/rpm/brp-strip-comment-note
and when it runs, it generates the following output:
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.11845
+ umask 022
+ cd /home/jms1/rpm/BUILD
+ cd sqlite-3.2.1
+ install -d /var/tmp/sqlite-3.2.1-root//usr
+ install -d /var/tmp/sqlite-3.2.1-root//usr/bin
+ install -d /var/tmp/sqlite-3.2.1-root//usr/include
+ install -d /var/tmp/sqlite-3.2.1-root//usr/lib
+ make install prefix=/var/tmp/sqlite-3.2.1-root//usr
tclsh ./tclinstaller.tcl 3.2
can't create directory "/usr/share/tcl8.4/sqlite3": permission denied
while executing
"file mkdir $LIBDIR/sqlite3"
(file "./tclinstaller.tcl" line 15)
make: *** [tcl_install] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.11845 (%install)
looking at tclinstaller.tcl, it looks like it sets DESTDIR to an empty string if the variable doesn't already exist (i will admit i'm guessing here, i'm not an expert with tcl) which causes LIBDIR to point to "/usr/share/tcl8.4" (instead of "/var/tmp/sqlite-3.2.1-root/usr/share/tcl8.4", which is what one would expect.) the "rpmbuild" process, running as non-root, doesn't have permission to create this system directory, hence the error message.
i don't know enough about tcl to figure out how to make DESTDIR carry into the script correctly, or even how to debug it to make sure that's what's actually going on. |
|
1221 |
new
|
active
|
2005 Apr
|
anonymous
|
|
2005 Apr
|
|
5
|
4
|
Implementation of PRAGMA trigger_info(table)
|
edit |
Although this is not a bug it would be nice to implement the feature, as it can help developers to get information about table triggers. Also the code to do this is quite simple. See below the part of the code that should be inserted in the PRAGMA section:
/// Editing pragma.c and insert this
if( sqlite3StrICmp(zLeft, "trigger_info")==0 ){
Table *pTab = sqlite3FindTable(db, zRight, 0);
Trigger *pTrg = pTab->pTrigger;
sqlite3VdbeSetNumCols(v, 4);
sqlite3VdbeSetColName(v, 0, "table", P3_STATIC);
sqlite3VdbeSetColName(v, 1, "trigger", P3_STATIC);
sqlite3VdbeSetColName(v, 2, "op", P3_STATIC);
sqlite3VdbeSetColName(v, 3, "tr_tm", P3_STATIC);
while(pTrg)
{
sqlite3VdbeOp3 (v, OP_String, 0, 0, pTrg->table, 0);
sqlite3VdbeOp3 (v, OP_String, 0, 0, pTrg->name, 0);
sqlite3VdbeAddOp(v, OP_Integer, pTrg->op, 0);
sqlite3VdbeAddOp(v, OP_Integer, pTrg->tr_tm, 0);
sqlite3VdbeAddOp(v, OP_Callback, 4, 0);
pTrg = pTrg->pNext;
}
}else
/// End of new Insertion |
|
1220 |
new
|
active
|
2005 Apr
|
anonymous
|
|
2005 Apr
|
|
4
|
3
|
Selectable calling convention
|
edit |
It would be helpful to be able to specify the calling convention for the SQLite API functions when building the library. This is sometimes an issue when writing wrapper libraries, specifically for .NET, which assumes a stdcall calling convention when calling DLL's. The default cdecl calling convention of a C DLL such as SQLite causes a bit of unnecessary overhead for the .NET runtime.
This is accomplished with Visual C++ (and GCC is similar) by adding a modifier to a function declaration...
void __stdcall sqlite3_open ();
This can be implemented using a macro, so the library can be compiled with the desired calling convention...
void SQLITE_CALL sqlite3_open ();
In sqlite3.h, the default macro would be empty...
#ifndef SQLITE_CALL
#define SQLITE_CALL
#endif |
|
1214 |
code
|
active
|
2005 Apr
|
anonymous
|
Unknown
|
2005 Apr
|
|
2
|
3
|
sqlite3_column_bytes returns 0 on p3 column with EXPLAINed selects
|
edit |
Both functions
sqlite3_column_bytes()
sqlite3_column_bytes16()
do not return the correct length for the p3 text column of EXPLAIN select queries. Both functions always return 0, even if the p3 column contains text.
The bug can be easily reproduced with the following query:
EXPLAIN SELECT 'text';
The p3 column, row 2, contains the word 'text', but the functions return 0 regardles.
I have not seen this bug with non EXPLAIN queries, but it breaks code which relies on the fact that sqlite3_column_bytes always retun the correct length of the text and needs to preallocate memory accordingly. |
|
1213 |
code
|
active
|
2005 Apr
|
anonymous
|
Parser
|
2005 Apr
|
|
3
|
2
|
Problem with alias columns in subqueries
|
edit |
The following query create an SQL error while it seems to me to be SQL complient (in fact it works fine with a lot database servers):
sqlite> select i from (select 0 as i union all select 1) as tmp;
SQL error: no such column: i
I found a workaround writting the following SQL query (it works well if you explicits the implicit variable i) :
select i from (select 0 as i union all select 1 as i) as tmp;
Thanks for your help
Jerome |
2005-Apr-17 11:03:52 by anonymous:
SQLite appears to take the column names from the last clause in a UNION (your originally query works if you reverse the order of the clauses).
IIRC, the standard says that the column names in a UNION of clauses with different column names is DBMS-dependent and while many DBMSs take them from the first clause, this is not something to count on.
2005-Apr-18 19:53:09 by anonymous:
You're perfectly right, but it seems to me that it should be better that sqlite do respect the "de facto" standard. |
|
1209 |
doc
|
active
|
2005 Apr
|
anonymous
|
Unknown
|
2005 Apr
|
anonymous
|
3
|
5
|
SQLite3_Free_Table returns not #SQLITE_OK if suceeds
|
edit |
Using the function SQLITE3_Get_Table I get back a pointer to memory where the data table is stored.
After reading this table I try to free the memory under use of command SQLITE3_Free_Table (using Windows DLL V3.2.1).
I expect that, if freeing succeds, the answer "#SQLITE_OK". But instead I get mostly #SQLITE_ERROR, but sometimes very big numbers.
In fact I checked the memory usage of my program.
When I use SQLITE_Free_Table with a wrong pointer, the answer of DLL is #SQLITE_OK while the memory usage of my program increases.
Whe I use the correct pointer the answer of SQLITE3_Free_Table us #SQLITE_ERROR, but the memory usage of my program remains the same as before the SQLITE3_Get_Table command.
For me it seems as if the answer for the "free" command is not correct. |
|
1208 |
new
|
active
|
2005 Apr
|
anonymous
|
Unknown
|
2005 Apr
|
|
4
|
4
|
no version info provided in precompiled sqlite3.dll
|
edit |
sometimes i get confused which version i'm using. it would be nice to have an easy way to view the sqlite version. |
2005-Jul-14 12:43:28 by anonymous:
Yes, would be great if the version information could be put in the resources of the dll and not only be accessible through the exported function!
Tools like the popular Installer "InnoSetup" could recognize the version of the sqlite3.dll then and check if a newer version is already installed... |
|
1205 |
code
|
active
|
2005 Apr
|
anonymous
|
Unknown
|
2005 Apr
|
|
3
|
1
|
accent ecu etc. in connectionstring
|
edit |
Hi
Whenever I use a accent grave or accent ecu or whatever accented characters in the connectionstring sqlite turns this into weird characters (in the file name of the database. Since my database name is dependent on user input I can't eliminate this situation...
bart@arlanet.com |
2005-Apr-13 12:16:08 by drh:
What version of SQLite? What operating system?
2005-Apr-14 12:22:32 by anonymous:
Windows 2000 (dutch version) Sqlite version 3.
the word privé in the connectionstring becomes privé.db3 on the disk, which causes errors afterwards when opening the database
2005-Apr-14 12:23:06 by anonymous:
I see something goes wrong with the accents as well on the previous remark
2005-Apr-14 12:29:41 by anonymous:
It really sounds to me like you're taking an accented character encoded in ISO8859-1 or some similar single-byte encoding and feeding it to something that's expecting a UTF-8 encoded string. In UTF-8, any byte that has its high bit set must be part of a multi-byte sequence.
2005-Apr-14 14:00:56 by anonymous:
After converting my string to an UTF8 encoded string, it still does the same thing....
2005-Apr-14 14:06:41 by anonymous:
using sqlite.net |
|
1204 |
new
|
active
|
2005 Apr
|
anonymous
|
TclLib
|
2005 Apr
|
drh
|
4
|
2
|
(visible) version provided by tclsqlite package
|
edit |
As a new version of sqlite is released it would be good to see the tclsqlite package version modified accordingly.
On the file tclsqlite.c, function Sqlite3_Init, it gives a fixed version to the function Tcl_PkgProvide "3.0". I believe this should be replaced with SQLITE_VERSION (macro defined in sqlite3.h).
Is there a reason this should not happen? Or was simply overlooked? |
|
1203 |
todo
|
active
|
2005 Apr
|
anonymous
|
|
2005 Apr
|
|
4
|
5
|
Web site problem, download links
|
edit |
it seems that your download links are broken. the starting http:// is missing at the begin of a href-anchors.. |
|
1201 |
code
|
active
|
2005 Apr
|
anonymous
|
CodeGen
|
2005 Apr
|
danielk1977
|
1
|
1
|
erro defined type UINT8_TYPE
|
edit |
In file sqliteInt.h line 203
typedef UINT8_TYPE i8; /* 1-byte signed integer */
it should be INT8_TYPE. |
|
1200 |
code
|
active
|
2005 Apr
|
anonymous
|
|
2005 Apr
|
|
2
|
3
|
new versions of SQLite return different (incorrect) results.
|
edit |
Newer versions of SQLite are returning different, and I believe incorrect, results compared to those returned by older versions.
Using version 3.0.8 the following query returns the correct results given the attached database.
sqlite> select * from device_property_list where device_property_value = 0;
1|Station|3|Initial Volume|0
1|Station|1|Template|0
2|Station|3|Initial Volume|0
2|Station|1|Template|0
3|Station|3|Initial Volume|0
3|Station|1|Template|0
This same query does not return any results using versions 3.1.6 and 3.2. If the query is changed slightly, by quoting the zero in the where condition, then both of the newer versions return the same set of results as 3.0.8.
sqlite> select * from device_property_list where device_property_value = '0';
1|Station|3|Initial Volume|0
1|Station|1|Template|0
2|Station|3|Initial Volume|0
2|Station|1|Template|0
3|Station|3|Initial Volume|0
3|Station|1|Template|0
The device_property_list is a view that hides a complex join of several tables, and a long case expression that select the value to return for device_property_value; the field that is being tested by the condition.
I have attached a sample database and the sql script used to create it for testing. |
|
1199 |
doc
|
active
|
2005 Apr
|
anonymous
|
|
2005 Apr
|
|
4
|
3
|
Update the README file
|
edit |
The README file gives the following instructions:
tar xzf sqlite.tar.gz ;
mkdir bld ;
cd bld ;
../sqlite/configure ; <==
make ;
make install ;
I guess the indicated line should be changed to "../configure ; " since there is no "../sqlite/" directory.
Kind regards. |
2005-Apr-02 12:44:19 by drh:
The directory is named ../sqlite-VERSION/ where VERSION is the
current version number. |
|
1191 |
code
|
active
|
2005 Mar
|
anonymous
|
Unknown
|
2005 Mar
|
|
2
|
3
|
last_insert_id() Does Not Work after Insert on View
|
edit |
If I have a view with an INSERT trigger attached to it, and then use the view to insert a record, last_insert_rowid() does not return the ID inserted. For example, given this DDL:
CREATE TABLE _simple (
id INTEGER NOT NULL PRIMARY KEY,
name TEXT
);
CREATE VIEW simple AS
SELECT _simple.id AS id, _simple.name AS name
FROM _simple;
CREATE TRIGGER insert_simple
INSTEAD OF INSERT ON simple
FOR EACH ROW BEGIN
INSERT INTO _simple (name)
VALUES (NEW.name);
END;
This is what I get when I use the view to insert:
sqlite> insert into simple (name) values ('foo');
sqlite> select last_insert_rowid();
last_insert_rowid()
-------------------
0
It does work if I insert directly into the table, of course:
sqlite> insert into _simple (name) values ('foo');
sqlite> select last_insert_rowid();
last_insert_rowid()
-------------------
2
|
2005-Mar-31 06:04:59 by anonymous:
VIEWs are read-only so you can not INSERT into them.
See: http://www.sqlite.org/omitted.html
Regards,
Bartosz.
2005-Mar-31 18:12:10 by anonymous:
Bartosz,
Please note that triggers have been applied to the view, so you can actually insert into them. I do it all the time. For example, given my previous examples, this insert will work:
sqlite> insert into simple (id, ame) values (1, 'foo');
Pretty coole, eh? See:
http://www.sqlite.org/lang_createtrigger.html
--Theory
2005-Mar-31 18:21:08 by drh:
The last_insert_rowid() routine does return the correct insert rowid
while you are still within the trigger. Once you leave the trigger,
last_insert_rowid() returns the rowid of the most recently inserted row
outside of any trigger. This is by design. If last_insert_rowid()
were to be responsive to inserts done by triggers, then any
AFTER INSERT trigger that happened to update a logfile would
overwrite the last_insert_rowid() from the actual INSERT.
One could argue, I suppose that last_insert_rowid() should work
for inserts performed by an INSTEAD OF trigger but not by other
kinds of triggers. I will ponder that notion and might implement
it if I cannot think of any objections.
2005-Mar-31 18:25:14 by anonymous:
Allowing it to persist past the trigger in an INSTEAD OF trigger would certainly do what I need. I think that'd make a lot of sense.
All of this should probably be well-documented somewhere. I'd be happy to add a page to the wiki once you've decided how to proceed with this issue.
Thanks!
Theory
2005-Apr-27 02:21:21 by anonymous:
Have you had a chance to think more on this issue?
Thanks,
Theory
2005-Nov-08 03:06:51 by anonymous:
Just checking in on this issue again. Do you think that it's something that will be resolved, one way or the other, soon?
Thanks,
Theory
2005-Nov-08 17:44:14 by anonymous:
The instead of insert trigger can't, in general, update the last_insert_rowid value automatically and do it correctly, since a trigger may do multiple inserts into multiple tables. SQLite has no idea which rowid should be reported back outside the trigger. This is left to the user (i.e. the author of the trigger). You can get the last_insert_rowid after the appropriate insert in the trigger and then save that value into an auxillary table that is visible outside the trigger.
This is especially important when your view is created from entries in several joined tables. Your instead of insert trigger must do inserts into the individual tables, and may need to use the last_insert_rowid function to link the records in the tables together correctly. It then needs to return the "master" rowid for the table. SQL doesn't have any syntax to specify which value is returned as the rowid of the instead of trigger, so SQLite doesn't do anything automatically. You need to create a sperate last_rowid table, and inside the trigger you update the value of a row in that table (possibly the only row) with the value you want to return. Then the code that does the insert into the view needs to get the value of that row instead of calling last_insert_rowid.
This type of behavior is needed since there is no limit to the number of nested instead of triggers that could be executed by a single SQL statement (i.e. one instead of trigger could do an insert into another view... and so on).
The current behavior isn't quite as convenient in the simplest case, but it works correctly in the more complicated general case, where simply updating the last_insert_rowid value would be wrong.
2005-Nov-08 22:51:56 by anonymous:
I think that there's an argument to be made that last_insert_rowid() should return the last inserted row ID, even if a trigger inserted a bunch. It should simply return the last one entered.
However, I agree with your analysis. Could there perhaps be a set_insert_id() function, or some such, that the trigger could use to tell last_insert_row_id() what to return? |
|
1190 |
new
|
active
|
2005 Mar
|
anonymous
|
Unknown
|
2005 Mar
|
drh
|
4
|
4
|
strftime() does not Support Years with 3 or 5 digits
|
edit |
It looks like strftime() doesn't support years before 1000 CE or after 9999 CE:
sqlite> select strftime('%Y', '2004-01-01T02:34:56');
strftime('%Y', '2004-01-01T02:34:56')
-------------------------------------
2004
sqlite> select strftime('%Y', '200-01-01T02:34:56');
strftime('%Y', '200-01-01T02:34:56')
------------------------------------
[null]
sqlite> select strftime('%Y', '20000-01-01T02:34:56');
strftime('%Y', '20000-01-01T02:34:56')
--------------------------------------
[null]
The same applies to years BCE:
strftime('%Y', '-2000-01-01T02:34:56')
--------------------------------------
-2000
sqlite> select strftime('%Y', '-20000-01-01T02:34:56');
strftime('%Y', '-20000-01-01T02:34:56')
---------------------------------------
[null]
sqlite> select strftime('%Y', '-200-01-01T02:34:56');
strftime('%Y', '-200-01-01T02:34:56')
-------------------------------------
[null]
One can get around the requirement for pre-1000 by using a preceding 0 (and the ISO-8601 spec may well require this; I'm not sure), but the lack of support for five or more digits in the year has no workaround.
So much for my science fiction database! ;-) |
2005-Mar-30 23:45:53 by anonymous:
Ah, found this link, which says that years must be represented by at least four digits. So 0200 is correct and works, while 200 is not. Sorry 'bout that. Ignore that part of the report.
http://www.absoluteastronomy.com/encyclopedia/I/IS/ISO_86012.htm
But it still would be nice to support more than four digits for the year, so that astronomy folks can use SQLite. :-)
2005-Mar-31 18:24:53 by drh:
I think this is an enhancement request, not a bug report.
I deliberately limited the span of years that SQLite would handle
to be 1000 through 9999 as a means of detecting faulty input.
I reasoned that astronomers and others who were doing date calculations
outside of this range are likely using their on date/time library
anyhow and so the limited range of dates that SQLite would handle
was not seen as a serious handicap. Even if an astronomer wanted
to use SQLite, the changes to the SQLite code base to enable
a larger span of years are minor and could be done on a case
by case basis.
I'm not sure this is something that needs to be in the standard
release.
2005-Mar-31 18:32:36 by anonymous:
I certainly understand the desire to detect faulty input, but since dates are simply stored in TEXT columns in SQLite (I think that's right--please correct me if I'm wrong), there isn't actually any fault input detection going on until someon uses strftime() or another date/time function.
Furthermore, 10000-12-19 is not faulty input; it's perfectly valid. So is -10001-02-28 (for the archaeologists). It may be easy to patch SQLite to support such dates, but that's relatively out of the hands of mere mortals.
Now if there was a compile directive to enable such support, that might be a decent compromise. Then, you'd still have the validation support, but at the same time, those who need astronomical or archaeological dates could easily get them without having to learn any C or the SQLite source code.
2005-Mar-31 18:55:48 by drh:
I will consider the request to support 5- or 6-digit dates. But
the date algorithms used in SQLite doe not work correctly for
negative Julian days (that is, dates prior to -4713-11-24T12:00:00).
In fact, the date algorithms always assume the Gregorian calendar,
which wasn't invented until the 16th century, was not in wide use
until the 18th century. So any really old dates are suspect.
Due to changing standards and politics, date/time computations
can be amazingly complex, especially when you start to consider
things like daylight savings time. It is not the mission of
SQLite to provide a complete date/time management system. The
date/time functions provided are intended to give a baseline of
functionality that meets 90% of the need. Users who need more
can add their own code using the sqlite3_create_function() API.
The date/time functions are already one of the largest modules
within SQLite and I am very hesitant to go make them even larger.
2005-Mar-31 19:08:30 by anonymous:
Understood, thanks for the consideration. |
|
1189 |
new
|
active
|
2005 Mar
|
anonymous
|
Parser
|
2005 Mar
|
|
1
|
1
|
Make where-clause item count limit dynamic
|
edit |
If you enter a query with more then 100 'where clause items' (pieces of a where clause joined by AND or OR) then you get an error saying you must limited yourself to 100 or less items. This is fine for 99.9% of the time, but I ran into a problem when trying to implement ad-hoc bitmap indexes -- in other words, hundreds of columns in a table and therefor hundreds of items in the where clause. I was able to work around this, at the sqlite level, by simply changing a constant in where.c from 101 to 1001 (437 was what was needed for this specific application).
The requested I'd like to see filled is that this be more-or-less a dynamic value. Perhaps it reads from some environment variable to determine this, and defaults to 100(+1). This would likely result in a bit of code rewrite as to how where.c works, but I don't think it would be a terribly huge amount. |
|
1187 |
build
|
active
|
2005 Mar
|
anonymous
|
Parser
|
2005 Mar
|
drh
|
3
|
3
|
OMIT_TRIGGER OMIT_VIEW do not compile properly
|
edit |
SQLITE_OMIT_TRIGGER and SQLITE_OMIT_VIEW are needed by lemon to process parse.y
They are not passed from CFLAGS to Makefile.in OPTS. |
|
1186 |
new
|
active
|
2005 Mar
|
anonymous
|
Shell
|
2005 Mar
|
|
4
|
4
|
Pragma page_size doesn't set the pagesize immediately
|
edit |
Sqlite3 doesn't change the page_size of a DB until you run a ddl command. Allthough this behavior doesn't really qualify as a bug, it is an annoyance to us.
Thanks for your great work
K.- M. Hansche |
|
1184 |
todo
|
active
|
2005 Mar
|
danielk1977
|
CodeGen
|
2005 Mar
|
|
4
|
3
|
UTF-8 and UTF-16 substr() functions are subtly different
|
edit |
If you pass 0 as the second argument of substr() it
is interpreted differently by the two different substr()
functions. The documentation doesn't say what the correct
result should be.
SQLite version 3.2.0
Enter ".help" for instructions
sqlite> select substr('ABCDE', 0, 2);
AB
sqlite> pragma encoding = "utf-16";
sqlite> select substr('ABCDE', 0, 2);
sqlite>
|
|
1177 |
code
|
active
|
2005 Mar
|
anonymous
|
Shell
|
2005 Mar
|
|
1
|
4
|
(Win32) .import inserts extra carrier character in every row
|
edit |
Hi,
Please investigate the following .import problem. I assume no one would expect a \r character be appeneded at the end of the values of the last column.
Step 1: Type the below text in Notepad and save as test.txt:
Row1 try1
Row2 try2
Row3 try3
Step 2: In sqlite3, type the following:
CREATE TABLE test (col1 char(4), col2 char(4));
.separator \t
.import test.txt test
.mode csv
SELECT * FROM test;
The following results are observed:
"Row1","try1\r"
"Row2","try2\r"
"Row3","try3"
I'm new to sqlite and I'm not sure whom shall I assign this ticket to. Please help me to re-assign to the right person if I've set it wrong.
Thanks.
Amanda |
2005-Mar-24 02:53:08 by anonymous:
Seems this is also related to ticket #939 ... there it says it's been solved, but as far as I'm using 3.20, it seems that it's not been fixed completely.
Please note that Windows use BOTH \r and \n for every new line break. |
|
1176 |
new
|
active
|
2005 Mar
|
anonymous
|
Unknown
|
2005 Mar
|
|
4
|
3
|
Blocking Writes
|
edit |
I would be nice if there was an option where a write query would block when the database was locked by another process/thread. I would prefer this over returning SQLITE_BUSY and looping...Is this planned at some point? |
|
1162 |
new
|
active
|
2005 Mar
|
anonymous
|
|
2005 Mar
|
drh
|
1
|
2
|
Column names in sqlite views differ from oracle/informix column names
|
edit |
I tried to use views with sqlite 3.1.5 with short_column_names
(as default within 3.x). Below is the script of my try.
As with CheckIns 2230 - 2232 (Tickets #269, etc.) I thought I
can access view elements without defining an alias. That does work
if I create the view like this:
create view yy2 as select y1.*, y2.* from y1, y2 where y1.a=y2.c;
But does not work, if I create it this way.
create view yy as select y1.a, y1.b, y2.c, y2.d from y1, y2 where y1.a=y2.c;
It would be a hard job to change all my view definitions (which where fine for informix and oracle) to fit sqlite.
Reply from Dr Richard Hipp:
If you will write a ticket that describes the column names assigned
to views by Informix, Oracle, and PostgreSQL, I'll change SQLite to
generate exactly the same column names.
Below i posted the behaviour of informix 9.3 and oracle. I currently have no postgreSQl available.
C:\devel\js\head\dst>sqlite3 ..\..\sqlite\problem.db
SQLite version 3.1.5
Enter ".help" for instructions
sqlite> create table y1(a,b);
sqlite> create table y2(c,d);
sqlite> create view yy as select y1.a, y1.b, y2.c, y2.d from y1, y2 where y1.a=y2.c;
sqlite> insert into y1 values (1,2);
sqlite> insert into y2 values (1,3);
sqlite> .headers on
sqlite> select * from yy;
y1.a|y1.b|y2.c|y2.d
1|2|1|3
sqlite> select * from yy where a=1;
SQL error: no such column: a
sqlite> select * from yy where y1.a=1;
SQL error: no such column: y1.a
sqlite> pragma short_column_names;
short_column_names
1
sqlite> pragma full_column_names;
full_column_names
0
sqlite> create view yy2 as select y1.*, y2.* from y1, y2 where y1.a=y2.c;
sqlite> select a,b,c,d from yy2;
a|b|c|d
1|2|1|3
sqlite> select * from yy2;
a|b|c|d
1|2|1|3
------------- INFORMIX -----------
CREATE TABLE y1 (a CHAR(20), b CHAR(20));
Table created
CREATE TABLE y2 (c CHAR(20), d CHAR(20));
Table created
INSERT INTO y1 VALUES ('1','2');
1 row(s) inserted
INSERT INTO y2 VALUES ('1','3');
1 row(s) inserted
CREATE VIEW yy AS SELECT y1.a, y1.b, y2.c, y2.d FROM y1, y2 WHERE y1.a=y2.c;
View created
select * from yy;
a 1
b 2
c 1
d 3
1 row(s) retrieved.
----------- Oracle ---------
CREATE TABLE y1 (a VARCHAR2(20), b VARCHAR2(20));
Table created.
CREATE TABLE y2 (c VARCHAR2(20), d VARCHAR2(20));
Table created.
INSERT INTO y1 VALUES ('1','2');
1 row created.
INSERT INTO y2 VALUES ('1','3');
1 row created.
CREATE VIEW yy AS SELECT y1.a, y1.b, y2.c, y2.d FROM y1, y2 WHERE y1.a=y2.c;
View created.
DESC yy;
Name Null? Type
A VARCHAR2(20)
B VARCHAR2(20)
C VARCHAR2(20)
D VARCHAR2(20)
SELECT * FROM yy;
A B C D
1 2 1 3
|
|
1158 |
code
|
active
|
2005 Mar
|
anonymous
|
VDBE
|
2005 Mar
|
|
1
|
1
|
core dump on solaris,
|
edit |
some sqlite functions core dumped on solaris. I tracked this back to a byte alignment problem in Vdbeint.h. I added the
__attribute__ ((__aligned__(16))) to the zshort character string.
/*
** A single level of the stack or a single memory cell
** is an instance of the following structure.
*/
struct Mem {
int i; /* Integer value */
int n; /* Number of characters in string value, including '\0' */
int flags; /* Some combination of MEM_Null, MEM_Str, MEM_Dyn, etc. */
double r; /* Real value */
char *z ; /* String value */
char zShort[NBFS] __attribute__ ((__aligned__(16))); /* Space for short strings */
};
typedef struct Mem Mem;
|
2005-Mar-09 22:06:47 by anonymous:
I think this is a duplicate of bug #700....
simply adding the attribute seems to reslove the bug...
select the sum of an integer column, to reproduce....
sqlite> select sum(seqval) from tbl;
Bus Error(coredump) |
|
1149 |
code
|
active
|
2005 Feb
|
anonymous
|
|
2005 Feb
|
|
2
|
1
|
VACUUM, DUMP/RESTORE fail in certain cases
|
edit |
When a database has interacting views, such as the following:
CREATE VIEW test1 AS SELECT * FROM tableA;
CREATE VIEW test AS SELECT COUNT(*) FROM test1;
then a dump and restore fails, because the views will be created in the alphabetical order of the table names, rather than the order of their dependence. Thus, the create of table test will fail. Because the script otherwise runs to completion, the restore will usually be adequate except that the views are not recreated.
VACUUM appears to fail the same way, probably for the same reason. In this case, however, the VACUUM fails without clearly alerting the user.
I ran into this problem trying to VACUUM a large file, which produced the otherwise inexplicable error message about the syntax of a dependent view definition.
Users can workaround, once the problem is understood, either by renaming views so that their names have alphabetical sequence consistent with their dependency, or by dropping them prior to a vacuum or dump/restore and then recreating them later.
Of course, the view order can be repaired in the dump file, but this usually requires patience with a powerful text editor, and some capacity to understand the problem. |
|
1142 |
code
|
active
|
2005 Feb
|
anonymous
|
Parser
|
2005 Feb
|
danielk1977
|
1
|
1
|
Column names
|
edit |
create table a (id, x);
create table b (id, y);
insert into a values (1,1);
insert into b values (1,2);
select * from a inner join b;
column names returned: id,x,id,y
How am I supposed to use such column names? Ouwey. |
2005-Mar-15 07:28:43 by anonymous:
This bug breaks existing applications where 'SELECT rowid, * FROM table' was used to open any table and then precompiled statements were used to update the changed record by using 'UPDATE table SET <field1>=?, <field2>=? ... WHERE rowid=?'.
We cannot update to sqlite v3.1.x because of this.
2005-Mar-15 08:36:31 by drh:
There are lots of people telling me the current behavior is
wrong. But nobody has yet suggested what the
correct behavior should be. Until I know what the correct
behavior should be, there is little I can do to fix the problem.
Rather than just telling me the current behavior is wrong,
please offer an explanation of what the correct behavior should
be. What do Oracle and PostgreSQL do in the same situation?
2005-Mar-16 09:04:30 by anonymous:
Dr. Hipp,
very sorry for the confusion I've caused! My comments were actually targeted at bug #1141! I've included the same remarks there.
As for this bug:
I can only tell you how SQL Server reacts:
select * from a inner join b
Line 1: Incorrect syntax near 'b'.
select * from a inner join b on a.id = b.id
So SQL Server behaves like sqlite in returning column names, although it doesn't accept the syntax 'select * from a inner join b'
I guess this behavior is normal and it's the programmer's resposability to use aliases in sql statement. Just my personal oppinion, though. |
|
1138 |
build
|
active
|
2005 Feb
|
anonymous
|
|
2005 Feb
|
|
4
|
3
|
make install fails on MinGW/MSYS trying to install into tclsh
|
edit |
I'm building SQLite on WinXP using MinGW/MSYS system. The makefile generated with:
../sqlite/configure --with-tcl=/c/Tcl/lib
works correctly to build the default target as well as the test suite, windows DLL, and import library using:
make
make test
make implib
However, I get an error whe I try to install the new version using:
make install
The error I get is:
$ make install
tclsh ../sqlite/tclinstaller.tcl 3.1
can't read "env(DESTDIR)": no such variable
while executing
"set LIBDIR $env(DESTDIR)[lindex $auto_path 0]"
(file "../sqlite/tclinstaller.tcl" line 10)
make: *** [tcl_install] Error 1
This is because the makefile is trying to install the tcl library into tcl (I think) before it installs the shell and libraries into the system. In my case this fails, so the install step never completes. I don't really care if the tcl install works or not since I'm not using it.
It seems to me that the Makefile should be changed to ignore any error during this step by adding a '-' character to the beginning of the tclsh... line as shown below:
tcl_install: libtclsqlite3.la
-tclsh $(TOP)/tclinstaller.tcl $(VERSION)
Or the install target should be split into 2 subtargets so that the normal installation subtarget is completed first as shown below:
install: sqlite_install ${HAVE_TCL:1=tcl_install}
sqlite_install: sqlite3 libsqlite3.la sqlite3.h
$(INSTALL) -d $(DESTDIR)$(libdir)
$(LTINSTALL) libsqlite3.la $(DESTDIR)$(libdir)
$(INSTALL) -d $(DESTDIR)$(exec_prefix)/bin
$(LTINSTALL) sqlite3 $(DESTDIR)$(exec_prefix)/bin
$(INSTALL) -d $(DESTDIR)$(prefix)/include
$(INSTALL) -m 0644 sqlite3.h $(DESTDIR)$(prefix)/include
$(INSTALL) -d $(DESTDIR)$(libdir)/pkgconfig;
$(INSTALL) -m 0644 sqlite3.pc $(DESTDIR)$(libdir)/pkgconfig;
tcl_install: libtclsqlite3.la
tclsh $(TOP)/tclinstaller.tcl $(VERSION)
This way if an error occurrs when doing the tcl_install it will not stop the normal sqlite installation. |
|
1134 |
code
|
active
|
2005 Feb
|
anonymous
|
|
2005 Feb
|
drh
|
3
|
3
|
select command with a view and a condition gets no result
|
edit |
In a view with more than one tables it is no longer possible to use that view within a select command; the columns of the view are not found. |
|
1128 |
event
|
active
|
2005 Feb
|
anonymous
|
Shell
|
2005 Feb
|
|
2
|
3
|
sqlite3-3.1.2.bin segfaults
|
edit |
Linux 2.4.26 (Knoppix 3.4 on hard drive)
download: http://sqlite.org/sqlite3-3.1.2.bin.gz
attached: strace log
In the strace log I notice that the segfault happens just after /etc/nsswitch.conf has been read, if that's of any consequence. |
|
1126 |
new
|
active
|
2005 Feb
|
anonymous
|
Unknown
|
2007 Jan
|
drh
|
2
|
3
|
sqlite 2.8.16 port to djgpp
|
edit |
here is a diff to be applied on sqlite 2.8.16 to make it work with djgpp.
some of the fixes are needed for general purpose, such as relative path handling, and bypass of history and readline wherever not functional.
dear drh, please apply this patch to mainstream sqlite. waiver of copyright in the patch itself.
best regards,
alex <alexbodn@012.net.il> |
2005-Feb-16 14:14:56 by drh:
I applied these patches. But then the regression tests
fail under unix. The patches much have broken something.
No time to fix it now....
2005-Feb-17 11:46:57 by anonymous:
thanks for your time. i will try to compile on linux and compare results.
2005-Oct-11 14:58:05 by anonymous:
i have to appologize for the long time it took me to get to it.
i have found the flaw in the patch that made the fulltest fail on unix.
now, that tests pass, please incorporate the diff in mainstream.
i will fix the ports for sqlite3 too.
2007-Jan-31 01:33:52 by anonymous:
it seems someone has accidentally changed the diff i've provided for an invalid binary file. |
|
1123 |
build
|
active
|
2005 Feb
|
anonymous
|
TclLib
|
2005 Feb
|
|
3
|
4
|
cannot find tcl.h
|
edit |
Apparently in the new version the tcl.h (and maybe other files of tcl) is needed by default.
So if you configure without any options, it will need tcl.h but the configuration script will not check for it. So the compilation will fail.
The workaround is one of two:
1. Install the tcl-devel (so you have the headers like tcl.h installed)
2. run configure with --disable-tclI could not find any documentation related to it.
This is new problem - I had no problems compile the former release just by running configure without options. |
2005-Feb-21 11:19:55 by drh:
The change to compile TCL by default appeared in 3.1.0.
2005-Jul-28 02:50:05 by anonymous:
I found another simple method to resolve the problem,if you needn't tcl interface.Just remove the tclsqlite.c from the project,then all is ok.
|
|
1112 |
code
|
active
|
2005 Feb
|
anonymous
|
|
2005 Feb
|
|
3
|
4
|
make test failures (108 out of 19721) on AIX 5.2, Power5 CPU
|
edit |
Platform is an IBM p5-570 running AIX 5.2. sqlite built with
CC=xlc ./configure --enable-shared=NO --disable-shared \
--enable-static=YES \
--enable-tempstore \
--enable-threads=POSIX \
--enable-tempdb-in-ram
and GNU make.
'make test' ends with '108 errors out of 19721 tests'. Here are the lines that did not end with Ok:
attach2-4.12...
Expected: [0 {}]
Got: [1 {disk I/O error}]
attach2-4.15...
Expected: [1 2 1 2]
Got: [1 2]
attach2-5.2...
Error: disk I/O error
autovacuum-ioerr-5.56.3...
Expected: [1]
Got: [0]
bigfile-1.2...
Error: file is encrypted or is not a database
bigfile-1.3...
Error: file is encrypted or is not a database
bigfile-1.4...
Error: file is encrypted or is not a database
bigfile-1.5...
Error: file is encrypted or is not a database
bigfile-1.6...
Error: file is encrypted or is not a database
bigfile-1.7...
Error: file is encrypted or is not a database
bigfile-1.8...
Error: file is encrypted or is not a database
bigfile-1.9...
Error: file is encrypted or is not a database
bigfile-1.10...
Error: file is encrypted or is not a database
bigfile-1.11...
Error: file is encrypted or is not a database
bigfile-1.12...
Error: file is encrypted or is not a database
bigfile-1.13...
Error: file is encrypted or is not a database
bigfile-1.14...
Error: file is encrypted or is not a database
bigfile-1.15...
Error: file is encrypted or is not a database
bigfile-1.16...
Error: file is encrypted or is not a database
ioerr-5.53.3...
Expected: [1]
Got: [0]
misc4-5.2...
Expected: [a 1 b 2 a:1 1 c 3]
Got: []
misc4.test did not close all files: 1
notnull.test did not close all files: 1
null.test did not close all files: 1
pager.test did not close all files: 1
pager2.test did not close all files: 1
pager3.test did not close all files: 1
pagesize.test did not close all files: 1
pragma.test did not close all files: 1
printf.test did not close all files: 1
progress.test did not close all files: 1
quote.test did not close all files: 1
reindex.test did not close all files: 1
rollback.test did not close all files: 1
rowid.test did not close all files: 1
safety.test did not close all files: 1
schema.test did not close all files: 1
select1.test did not close all files: 2
time with cache: 895550 microseconds per iteration
time without cache: 2262076 microseconds per iteration
select2.test did not close all files: 2
select3.test did not close all files: 2
select4.test did not close all files: 2
select5.test did not close all files: 2
select6.test did not close all files: 2
select7.test did not close all files: 2
sort.test did not close all files: 2
subquery.test did not close all files: 2
subselect.test did not close all files: 2
table-8.1...
Expected: [desc a asc b key 9 14_vac 0 fuzzy_dog_12 xyz begin hi end y'all]
Got: []
table-8.1.1...
Expected: [{CREATE TABLE t2(
"desc" text,
"asc" text,
"key" int,
"14_vac" boolean,
fuzzy_dog_12 varchar(10),
"begin" blob,
"end" clob
)}]
Got: []
table-8.3...
Expected: [cnt 1 max(b+c) 5]
Got: []
table-8.3.1...
Expected: [{CREATE TABLE "t4""abc"(cnt,"max(b+c)")}]
Got: []
table-8.4...
Expected: [y'all 1]
Got: []
table-8.5...
Error: no such table: t4"abc
table-8.6...
Error: no such table: t2
table.test did not close all files: 3
tableapi.test did not close all files: 3
tclsqlite.test did not close all files: 3
temptable.test did not close all files: 3
thread1.test did not close all files: 3
trace.test did not close all files: 3
trans-6.1...
Expected: [a 1 b 2 c 3]
Got: []
trans-6.3...
Expected: [p 1 q 2 r 3]
Got: []
trans-6.4...
Expected: [a 4 b 5 c 6]
Got: []
trans-6.5...
Expected: [p 1 q 2 r 3]
Got: []
trans-6.6...
Expected: [a 4 b 5 c 6]
Got: []
trans-6.7...
Expected: [1 {no such table: t1}]
Got: [1 {cannot commit - no transaction is active}]
trans-6.10...
Error: table t1 already exists
trans-6.12...
Expected: [p 1 q 2 r 3]
Got: []
trans-6.13...
Expected: [a 4 b 5 c 6]
Got: []
trans-6.14...
Expected: [p 1 q 2 r 3]
Got: []
trans-6.15...
Expected: [a 4 b 5 c 6]
Got: []
trans-6.16...
Expected: [1 {no such table: t1}]
Got: [1 {cannot commit - no transaction is active}]
trans-6.20...
Error: table t1 already exists
trans-6.21...
Expected: [4 -5 -6 1 -2 -3]
Got: []
trans-6.22...
Expected: [1 -2 -3 4 -5 -6]
Got: []
trans-6.23...
Expected: [4 -5 -6 1 -2 -3]
Got: []
trans-6.24...
Expected: [4 -5 -6 1 -2 -3]
Got: []
trans-6.25...
Expected: [1 -2 -3 4 -5 -6]
Got: []
trans-6.26...
Expected: [4 -5 -6 1 -2 -3]
Got: []
trans-6.27...
Expected: [4 -5 -6 1 -2 -3]
Got: []
trans-6.28...
Expected: [1 -2 -3 4 -5 -6]
Got: []
trans.test did not close all files: 4
trigger-10.3...
Error: disk I/O error
trigger-10.7...
Error: disk I/O error
trigger-10.10...
Error: disk I/O error
trigger-10.11...
Expected: [main 21 22 23 temp 24 25 26 aux 27 28 29]
Got: [main 21 22 23]
trigger1.test did not close all files: 4
trigger2.test did not close all files: 4
trigger3.test did not close all files: 4
trigger4.test did not close all files: 4
trigger5.test did not close all files: 4
trigger6.test did not close all files: 4
types.test did not close all files: 4
types2.test did not close all files: 4
unique.test did not close all files: 4
update.test did not close all files: 4
vacuum.test did not close all files: 4
varint.test did not close all files: 4
view-3.3...
Expected: [xyz 2 pqr 7 c-b 1]
Got: []
view-3.4...
Expected: [b 2 b 3 b 5 b 6]
Got: []
view-3.5...
Expected: [y 2 y 3 y 5 y 6]
Got: []
view-8.1...
Error: no such column: pqr
view-8.2...
Error: no such table: v6
view-8.3...
Error: no such table: main.v6
view-8.6...
Error: no such table: v6
view-8.7...
Error: no such table: v6
view.test did not close all files: 5
where.test did not close all files: 5
108 errors out of 19721 tests
Failures on these tests: attach2-4.12 attach2-4.15 attach2-5.2
autovacuum-ioerr-5.56.3 bigfile-1.2 bigfile-1.3 bigfile-1.4
bigfile-1.5 bigfile-1.6 bigfile-1.7 bigfile-1.8 bigfile-1.9
bigfile-1.10 bigfile-1.11 bigfile-1.12 bigfile-1.13 bigfile-1.14
bigfile-1.15 bigfile-1.16 ioerr-5.53.3 misc4-5.2 misc4.test
notnull.test null.test pager.test pager2.test pager3.test
pagesize.test pragma.test printf.test progress.test quote.test
reindex.test rollback.test rowid.test safety.test schema.test
select1.test select2.test select3.test select4.test select5.test
select6.test select7.test sort.test subquery.test subselect.test
table-8.1 table-8.1.1 table-8.3 table-8.3.1 table-8.4 table-8.5
table-8.6 table.test tableapi.test tclsqlite.test temptable.test
thread1.test trace.test trans-6.1 trans-6.3 trans-6.4 trans-6.5
trans-6.6 trans-6.7 trans-6.10 trans-6.12 trans-6.13 trans-6.14
trans-6.15 trans-6.16 trans-6.20 trans-6.21 trans-6.22 trans-6.23
trans-6.24 trans-6.25 trans-6.26 trans-6.27 trans-6.28 trans.test
trigger-10.3 trigger-10.7 trigger-10.10 trigger-10.11 trigger1.test
trigger2.test trigger3.test trigger4.test trigger5.test
trigger6.test types.test types2.test unique.test update.test
vacuum.test varint.test view-3.3 view-3.4 view-3.5 view-8.1 view-8.2
view-8.3 view-8.6 view-8.7 view.test where.test
|
|
1111 |
code
|
active
|
2005 Feb
|
anonymous
|
Unknown
|
2005 Jun
|
|
3
|
1
|
no such column error with a subselect as a table
|
edit |
Execute the following script. In 3.0.8, you get the following results:
line 0
line 2
in 3.1.1 beta, you get the following error:
SQL error: no such column: bb.a
SCRIPT:
create table test1 (a int);
insert into test1 values (0);
insert into test1 select max(a)+1 from test1;
insert into test1 select max(a)+1 from test1;
create table test2 (a int, b text);
insert into test2 select a,'line ' || a from test1;
select test2.b from (select test1.a from test1 where a%2 = 0) as bb join test2 on bb.a = test2.a;
|
2005-Feb-21 17:48:20 by anonymous:
Tested in 3.1.3, issue still exists
2005-Jun-12 22:09:08 by drh:
Workaround:
select test2.b
from (select test1.a as a from test1 where a%2=0) as bb
join test2 on bb.a=test2.a;
|
|
1100 |
code
|
active
|
2005 Feb
|
anonymous
|
|
2005 Feb
|
|
3
|
3
|
make test segfaults at capi2-7.12 on amd64 system
|
edit |
System is Gentoo Linux 2004.1 on Opteron processor; gcc v3.3.3, creating 64 bit binaries.
Here is a traceback:
capi2-7.11... Ok
capi2-7.11a... Ok
capi2-7.12...
Program received signal SIGSEGV, Segmentation fault.
0x0000002a95b25830 in strlen () from /lib/libc.so.6
(gdb) where
#0 0x0000002a95b25830 in strlen () from /lib/libc.so.6
#1 0x000000000043991c in sqlite3VdbeList (p=0x5aab60) at src/vdbeaux.c:528
#2 0x0000000000438737 in sqlite3_step (pStmt=0x13000a6023d0064)
at src/vdbeapi.c:207
#3 0x0000000000416a80 in test_step (clientData=0x13000a6023d0064,
interp=0x55a450, objc=0, objv=0x4) at src/test1.c:2070
#4 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
#5 0x0000002a956ba181 in TclCompEvalObj () from /usr/lib/libtcl8.4.so
#6 0x0000002a956b9648 in TclCompEvalObj () from /usr/lib/libtcl8.4.so
#7 0x0000002a956e4f66 in TclObjInterpProc () from /usr/lib/libtcl8.4.so
#8 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
#9 0x0000002a956982d8 in Tcl_EvalEx () from /usr/lib/libtcl8.4.so
#10 0x0000002a95698097 in Tcl_EvalTokensStandard () from /usr/lib/libtcl8.4.so
#11 0x0000002a95698273 in Tcl_EvalEx () from /usr/lib/libtcl8.4.so
#12 0x0000002a95698767 in Tcl_EvalObjEx () from /usr/lib/libtcl8.4.so
#13 0x0000002a956e4a93 in Tcl_UplevelObjCmd () from /usr/lib/libtcl8.4.so
#14 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
#15 0x0000002a956ba181 in TclCompEvalObj () from /usr/lib/libtcl8.4.so
#16 0x0000002a956b9648 in TclCompEvalObj () from /usr/lib/libtcl8.4.so
#17 0x0000002a956e4f66 in TclObjInterpProc () from /usr/lib/libtcl8.4.so
#18 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
#19 0x0000002a956982d8 in Tcl_EvalEx () from /usr/lib/libtcl8.4.so
#20 0x0000002a95698767 in Tcl_EvalObjEx () from /usr/lib/libtcl8.4.so
#21 0x0000002a956e4a93 in Tcl_UplevelObjCmd () from /usr/lib/libtcl8.4.so
#22 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
#23 0x0000002a956ba181 in TclCompEvalObj () from /usr/lib/libtcl8.4.so
#24 0x0000002a956b9648 in TclCompEvalObj () from /usr/lib/libtcl8.4.so
#25 0x0000002a95698815 in Tcl_EvalObjEx () from /usr/lib/libtcl8.4.so
#26 0x0000002a9569c486 in Tcl_CatchObjCmd () from /usr/lib/libtcl8.4.so
#27 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
#28 0x0000002a956ba181 in TclCompEvalObj () from /usr/lib/libtcl8.4.so
#29 0x0000002a956b9648 in TclCompEvalObj () from /usr/lib/libtcl8.4.so
#30 0x0000002a95698815 in Tcl_EvalObjEx () from /usr/lib/libtcl8.4.so
#31 0x0000002a9569ef7e in Tcl_IfObjCmd () from /usr/lib/libtcl8.4.so
#32 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
#33 0x0000002a956ba181 in TclCompEvalObj () from /usr/lib/libtcl8.4.so
#34 0x0000002a956b9648 in TclCompEvalObj () from /usr/lib/libtcl8.4.so
#35 0x0000002a956e4f66 in TclObjInterpProc () from /usr/lib/libtcl8.4.so
#36 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
#37 0x0000002a956982d8 in Tcl_EvalEx () from /usr/lib/libtcl8.4.so
#38 0x0000002a956d1e41 in Tcl_FSEvalFile () from /usr/lib/libtcl8.4.so
#39 0x0000002a956d120e in Tcl_EvalFile () from /usr/lib/libtcl8.4.so
#40 0x0000000000424641 in main (argc=2, argv=0x7fbffff138)
at src/tclsqlite.c:1744
(gdb)
|
2005-Feb-04 23:11:02 by anonymous:
Some more information from a gdb session (I added the printf at line 527 and recompiled; the line numbers below will be off by one from the stack trace above):
(gdb) up
#1 0x000000000043996d in sqlite3VdbeList (p=0x5aab60) at src/vdbeaux.c:529
529 pMem->n = strlen(pMem->z);
(gdb) list 525,535
525
526 pMem->flags = MEM_Static|MEM_Str|MEM_Term;
527 printf("src/vdbeaux.c sqlite3VdbeList pOp->opcode= %d\n", pOp->opcode);
528 pMem->z = sqlite3OpcodeNames[pOp->opcode]; /* Opcode */
529 pMem->n = strlen(pMem->z);
530 pMem->type = SQLITE_TEXT;
531 pMem->enc = SQLITE_UTF8;
532 pMem++;
533
534 pMem->flags = MEM_Int;
535 pMem->i = pOp->p1; /* P1 */
(gdb) p pOp->opcode
$1 = 40 '('
(gdb) p pMem->z
$2 = 0x175002100200173 <Address 0x175002100200173 out of bounds>
|
|
1085 |
code
|
active
|
2005 Jan
|
anonymous
|
|
2005 Jan
|
|
2
|
3
|
pragma full_column_names and short_column_names still broken
|
edit |
the following statement :
SELECT T1.*,D1.*
FROM test T1,dt D1
WHERE T1.id=D1.id
does not give "long" column names, even if full_column_names is ON.
But, the following does:
SELECT T1.ID,D1.NAME
FROM test T1,dt D1
WHERE T1.id=D1.id
in other words, tablename prefix is applied only to explicit columns,
not to "*" selected columns. |
|
1078 |
code
|
active
|
2005 Jan
|
anonymous
|
|
2005 Jan
|
|
2
|
3
|
Lemon destructor bugs that don't affect sqlite
|
edit |
I found a few bugs Lemon's destructor handling code. I don't think that they affect sqlite, but the do affect other grammars.
- The code that collapses cases for default destructors erroneously
assumes that all symbols have the same type.
- If a reduction rule doesn't have code, then the RHS symbols will not
have their destructors called.
- The default destructor shouldn't be called on the auto-generated "error" symbol
- In the internal function "append_str", zero-length strings may be returned un-terminated.
I have some proposed fixes that I'll try to attach to this ticket. |
2005-Jan-14 13:33:52 by drh:
Do you also have some test grammars? That would really be helpful.
2005-Jan-14 17:14:15 by anonymous:
Sure. Here is one grammar that will demonstrate the "Tokens leak when rule has no code" bug:
%token_type { char * }
%token_destructor
{
printf("Deleting token '%s' at %x\n", $$, (int)$$);
free($$);
}
result ::= nt.
nt ::= FOO BAR.
Running the following code against the grammar should theoretically
show 2 allocations and two destructions. It won't though, unless you
modify the rule for nt to have an empty body, like:
nt ::= FOO BAR. {}
char *mkStr(const char *s)
{
printf("Allocating '%s' at 0x%x\n", s, (int)(s));
return strdup(s);
}
int main(int argc, char **argv)
{
void *parser = ParseAlloc(malloc);
Parse(parser, FOO, mkStr("foo"));
Parse(parser, BAR, mkStr("bar"));
Parse(parser, 0, 0);
ParseFree(parser, free);
return 0;
}
2005-Jan-14 17:50:26 by anonymous:
Here is another test grammar. This one demonstrates (a) default destructors being called on the 'error' symbol, and (b) problems with default destructors being called on the wrong symbol type.
%token_type { char * }
%token_destructor { delete [] $$; }
%default_destructor { delete $$; }
%type result { int }
%destructor result { }
result ::= fooStruct barStruct. { }
%type fooStruct { Foo * }
fooStruct(lhs) ::= FOO(f). { lhs = new Foo(f); }
%type barStruct { Bar * }
barStruct(lhs) ::= BAR(b). { lhs = new Bar(b); }
Here is the code generated by lemon (with comments added & removed for clarity):
typedef union {
ParseTOKENTYPE yy0;
int yy4;
Bar * yy5;
Foo * yy7;
int yy15;
} YYMINORTYPE;
static const char *const yyTokenName[] = {
"$", "FOO", "BAR", "error",
"result", "fooStruct", "barStruct",
};
static void yy_destructor(YYCODETYPE yymajor, YYMINORTYPE *yypminor){
switch( yymajor ){
case 1:
case 2:
{ delete [] (yypminor->yy0); }
break;
case 3: /* error */
case 5: /* fooStruct of type "Foo *" */
case 6: /* barStruct of type "Bar *" */
#line 3 "typeBug.y"
{ delete (yypminor->yy5); } /* Yikes! yy5 is a "Bar *" */
#line 308 "typeBug.c"
break;
case 4:
#line 6 "typeBug.y"
{ }
#line 313 "typeBug.c"
break;
default: break; /* If no destructor action specified: do nothing */
}
}
|
|
1070 |
build
|
active
|
2005 Jan
|
anonymous
|
CodeGen
|
2005 Jan
|
|
1
|
1
|
error by compiling windows vcc / vc# <sqlite.h> not found
|
edit |
Cannot build sqlite.lib.
reason sqlite.h not found |
|
1063 |
code
|
active
|
2005 Jan
|
anonymous
|
|
2005 Jan
|
|
1
|
3
|
Lemon bug: Strings in rule code should not be interpreted
|
edit |
There are two related bugs in the lemon parser related to processing code snippets defined in rule actions.
Here is a simple grammar that demonstrates the problem:
%include {
extern int line_number;
extern const char *file_name;
}
result(r) ::= TOKEN(s).
{
printf("BAD: Got a token on line '%d'\n", line_number);
printf("BAD: \tFile = '%s'\n", file_name);
r = s;
}
The first bug is that the "%d" in the first printf is interpreted by the append_str function, when it shouldn't be, producing code that looks like:
printf("BAD: Got a token on line '0d'\n", line_number);
I believe that the solution is to have append_str() NOT do %d substitution when it is copying the code.
The second bug is that the "s" in the "%s" format is being interpreted as a symbolic name, producing code that looks like:
printf("BAD: \tFile = '%yymsp[0].minor.yy0'\n", file_name);
I believe that the solution is to have translate_code() ignore symbolic names inside of quoted strings. |
|
1061 |
new
|
active
|
2005 Jan
|
anonymous
|
Shell
|
2005 Jan
|
|
4
|
4
|
shell.c .import from stdin
|
edit |
e.g.:
in = ( 0 == strcmp( "-", zFile ) ) ? stdin : fopen(zFile, "rb"); |
|
1059 |
doc
|
active
|
2005 Jan
|
anonymous
|
Unknown
|
2005 Jan
|
|
5
|
4
|
Full support for IEEE 754 floating points
|
edit |
Current situation:
IEEE standard 754 allows for the following special cases of double values:
Zero. Denoted as an exponent field of zero and a fraction field of zero
Denormalized. Denoted as an all 0 exponent field with a non zero fraction field
Infinity. Denoted as an all 1 exponent field and an all zero fraction field(sign bit indicates +infinity or -infinity)
NaN. Denoted with an all 1 exponent field and a non zero fraction field. The most significant bit fraction indicates type of NaN.
SQLite converts these values to 0.
Request option to store these special values.
Current workaround:
If only one type of special value is to be used, replace it with NULL.
If multiple types are used add a type column to each floating point column indicating what is stored in the linked floating point column. |
2005-Jul-25 01:46:58 by anonymous:
Here is some partial support for Infinity and NaN given C99 support. Both quantities are input and output correctly, and arithmetic works. I haven't defined what happens when storing these quantities on non-REAL columns. I also haven't added tests; I'm allergic to tcl. (note: gcc needs -std=gnu9x or -std=c99 to fully support Inf and NaN.)
The float i/o needs some serious work; are there any non-licensing constraints on what someone can replace it with?
If the patch is mangled, mail me. Jason Riedy <jason@acm.org>
Index: Makefile.linux-gcc
===================================================================
RCS file: /sqlite/sqlite/Makefile.linux-gcc,v
retrieving revision 1.3
diff -u -3 -p -r1.3 Makefile.linux-gcc
--- Makefile.linux-gcc 11 Mar 2005 18:06:41 -0000 1.3
+++ Makefile.linux-gcc 25 Jul 2005 01:41:34 -0000
@@ -41,6 +41,12 @@ THREADSAFE = -DTHREADSAFE=0
#THREADLIB = -lpthread
THREADLIB =
+#### If you have C99's INFINITY, NAN, and the testing macros,
+# define appropriately.
+#
+FPVALUES =
+#FPVALUES = -DHAVE_INFINITY=1 -DHAVE_ISINF=1 -DHAVE_NAN=1 -DHAVE_ISNAN=1
+
#### Leave SQLITE_DEBUG undefined for maximum speed. Use SQLITE_DEBUG=1
# to check for memory leaks. Use SQLITE_DEBUG=2 to print a log of all
# malloc()s and free()s in order to track down memory leaks.
Index: configure.ac
===================================================================
RCS file: /sqlite/sqlite/configure.ac,v
retrieving revision 1.17
diff -u -3 -p -r1.17 configure.ac
--- configure.ac 6 Jul 2005 13:51:27 -0000 1.17
+++ configure.ac 25 Jul 2005 01:41:37 -0000
@@ -608,6 +608,44 @@ AC_SUBST(TARGET_DEBUG)
AC_CHECK_FUNC(usleep, [TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_USLEEP=1"])
#########
+# Check for C99 INFINITY macro and isinf test.
+# C99 defines isinf to be a macro, but it is a macro on some systems
+# and a function on others.
+AC_MSG_CHECKING([for INFINITY])
+AC_LINK_IFELSE(
+[#include <math.h>
+int main () { double x; x = INFINITY; return((int)x); }],
+ [AC_MSG_RESULT([yes])
+ TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_INFINITY=1"],
+ [AC_MSG_RESULT([no])])
+AC_MSG_CHECKING([for isinf])
+AC_LINK_IFELSE(
+[#include <math.h>
+int main () { return (0 != isinf(0.0)); }],
+ [AC_MSG_RESULT([yes])
+ TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_ISINF=1"],
+ [AC_MSG_RESULT([no])])
+
+#########
+# Check for C99 NAN macro and isnan test.
+# C99 defines isnan to be a macro, but it is a macro on some systems
+# and a function on others.
+AC_MSG_CHECKING([for NAN])
+AC_LINK_IFELSE(
+[#include <math.h>
+int main () { double x; x = NAN; }],
+ [AC_MSG_RESULT([yes])
+ TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_NAN=1"],
+ [AC_MSG_RESULT([no])])
+AC_MSG_CHECKING([for isnan])
+AC_LINK_IFELSE(
+[#include <math.h>
+int main () { return (0 != isnan(0.0)); }],
+ [AC_MSG_RESULT([yes])
+ TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_ISNAN=1"],
+ [AC_MSG_RESULT([no])])
+
+#########
# Generate the output files.
#
AC_OUTPUT([
Index: src/printf.c
===================================================================
RCS file: /sqlite/sqlite/src/printf.c,v
retrieving revision 1.43
diff -u -3 -p -r1.43 printf.c
--- src/printf.c 5 Nov 2004 17:17:50 -0000 1.43
+++ src/printf.c 25 Jul 2005 01:41:37 -0000
@@ -51,6 +51,14 @@
**
*/
#include "sqliteInt.h"
+#ifndef etNOFLOATINGPOINT
+#include <float.h>
+#include <math.h>
+#endif
+
+static const char infinity_string[] = "Infinity";
+static const char negative_infinity_string[] = "-Infinity";
+static const char NaN_string[] = "NaN";
/*
** Conversion types fall into various categories as defined by the
@@ -413,6 +421,10 @@ static int vxprintf(
case etGENERIC:
realvalue = va_arg(ap,double);
#ifndef etNOFLOATINGPOINT
+ /* XXX: This needs some serious help.
+ Multiplying by 0.1 is not an exact operation, so rounding
+ may change.
+ */
if( precision<0 ) precision = 6; /* Set default precision */
if( precision>etBUFSIZE-10 ) precision = etBUFSIZE-10;
if( realvalue<0.0 ){
@@ -435,14 +447,34 @@ static int vxprintf(
if( infop->type==etFLOAT ) realvalue += rounder;
/* Normalize realvalue to within 10.0 > realvalue >= 1.0 */
exp = 0;
+#if defined(HAVE_ISINF)
+ if( isinf(realvalue) ){
+ if( '-' == prefix ){
+ bufpt = negative_infinity_string;
+ length = (sizeof(negative_infinity_string)/sizeof(char)) - 1;
+ }
+ else {
+ bufpt = infinity_string;
+ length = (sizeof(infinity_string)/sizeof(char)) - 1;
+ }
+ break;
+ }
+#endif
+#if defined(HAVE_ISNAN)
+ if( isnan(realvalue) ){
+ bufpt = NaN_string;
+ length = (sizeof(NaN_string)/sizeof(char)) - 1;
+ break;
+ }
+#endif
if( realvalue>0.0 ){
while( realvalue>=1e8 && exp<=350 ){ realvalue *= 1e-8; exp+=8; }
while( realvalue>=10.0 && exp<=350 ){ realvalue *= 0.1; exp++; }
while( realvalue<1e-8 && exp>=-350 ){ realvalue *= 1e8; exp-=8; }
while( realvalue<1.0 && exp>=-350 ){ realvalue *= 10.0; exp--; }
if( exp>350 || exp<-350 ){
- bufpt = "NaN";
- length = 3;
+ bufpt = NaN_string;
+ length = (sizeof(NaN_string)/sizeof(char)) - 1;
break;
}
}
Index: src/util.c
===================================================================
RCS file: /sqlite/sqlite/src/util.c,v
retrieving revision 1.141
diff -u -3 -p -r1.141 util.c
--- src/util.c 20 Jul 2005 14:31:53 -0000 1.141
+++ src/util.c 25 Jul 2005 01:41:37 -0000
@@ -19,6 +19,8 @@
#include "sqliteInt.h"
#include <stdarg.h>
#include <ctype.h>
+#include <float.h>
+#include <math.h>
#if SQLITE_MEMDEBUG>2 && defined(__GLIBC__)
#include <execinfo.h>
@@ -541,6 +543,52 @@ int sqlite3IsNumber(const char *z, int *
int incr = (enc==SQLITE_UTF8?1:2);
if( enc==SQLITE_UTF16BE ) z++;
if( *z=='-' || *z=='+' ) z += incr;
+#if defined(HAVE_INFINITY)
+ if( *z=='I' || *z=='i' ){
+ /*
+ May be Infinity. The SQL standard says that 'Infinity' and
+ '-Infinity' are the only spellings, but this code accepts
+ '+Infinity'.
+ */
+ z += incr;
+ if (*z=='N'||*z=='n') z += incr;
+ else goto not_inf;
+ if (*z=='F'||*z=='f') z += incr;
+ else goto not_inf;
+ if (*z=='I'||*z=='i') z += incr;
+ else goto not_inf;
+ if (*z=='N'||*z=='n') z += incr;
+ else goto not_inf;
+ if (*z=='I'||*z=='i') z += incr;
+ else goto not_inf;
+ if (*z=='T'||*z=='t') z += incr;
+ else goto not_inf;
+ if (*z=='Y'||*z=='y') z += incr;
+ else goto not_inf;
+ if (realnum) *realnum = 1;
+ goto done;
+ not_inf:
+ return 0;
+ }
+#endif
+#if defined(HAVE_NAN)
+ if( *z=='N' || *z=='n' ){
+ /*
+ May be NaN. The SQL standard says that 'NaN' is the only
+ spelling. IEEE-754 does not attribute meaning to the sign
+ bit of NaN, so this code also allows '+NaN' and '-NaN'.
+ */
+ z += incr;
+ if (*z=='A'||*z=='a') z += incr;
+ else goto not_nan;
+ if (*z=='N'||*z=='n') z += incr;
+ else goto not_nan;
+ if (realnum) *realnum = 1;
+ goto done;
+ not_nan:
+ return 0;
+ }
+#endif
if( !isdigit(*(u8*)z) ){
return 0;
}
@@ -560,6 +608,7 @@ int sqlite3IsNumber(const char *z, int *
while( isdigit(*(u8*)z) ){ z += incr; }
if( realnum ) *realnum = 1;
}
+done:
return *z==0;
}
@@ -585,6 +634,46 @@ int sqlite3AtoF(const char *z, double *p
}else if( *z=='+' ){
z++;
}
+#if defined(HAVE_INFINITY)
+ if( *z=='I' || *z=='i' ){
+ const char *saved_z = z;
+ /* May be Infinity. See sqlite3IsNumber for caveats. */
+ z++;
+ if (*z=='N'||*z=='n') z++;
+ else goto not_inf;
+ if (*z=='F'||*z=='f') z++;
+ else goto not_inf;
+ if (*z=='I'||*z=='i') z++;
+ else goto not_inf;
+ if (*z=='N'||*z=='n') z++;
+ else goto not_inf;
+ if (*z=='I'||*z=='i') z++;
+ else goto not_inf;
+ if (*z=='T'||*z=='t') z++;
+ else goto not_inf;
+ if (*z=='Y'||*z=='y') z++;
+ else goto not_inf;
+ v1 = INFINITY;
+ goto done;
+ not_inf:
+ z = saved_z;
+ }
+#endif
+#if defined(HAVE_NAN)
+ if( *z=='N' || *z=='n' ){
+ const char *saved_z = z;
+ /* May be NaN. See sqlite3IsNumber for caveats. */
+ z++;
+ if (*z=='A'||*z=='a') z++;
+ else goto not_nan;
+ if (*z=='N'||*z=='n') z++;
+ else goto not_nan;
+ v1 = NAN;
+ goto done;
+ not_nan:
+ z = saved_z;
+ }
+#endif
while( isdigit(*(u8*)z) ){
v1 = v1*10.0 + (*z - '0');
z++;
@@ -624,6 +713,7 @@ int sqlite3AtoF(const char *z, double *p
v1 *= scale;
}
}
+done:
*pResult = sign<0 ? -v1 : v1;
return z - zBegin;
}
|
|
1058 |
code
|
active
|
2005 Jan
|
anonymous
|
BTree
|
2005 Jan
|
|
3
|
3
|
btree.c pageSize -> usableSize
|
edit |
Check-in [2125]
was a fix for Ticket #1010, but left out some of the fixes proposed in the ticket. I'm not sure whether this was an oversight or an intentional omission. I tried to re-open the ticket, but those edits didn't persist (I'm not sure why).
Here are the remaining instances of pageSize that I believe should be changed to usableSize in btree.c:
--- sqlite/src/btree.c.ORIG Wed Nov 24 18:54:30 2004
+++ sqlite/src/btree.c Wed Nov 24 20:29:21 2004
@@ -220,13 +220,13 @@
/* The following value is the maximum cell size assuming a maximum page
** size give above.
*/
-#define MX_CELL_SIZE(pBt) (pBt->pageSize-8)
+#define MX_CELL_SIZE(pBt) (pBt->usableSize-8)
/* The maximum number of cells on a single page of the database. This
** assumes a minimum cell size of 3 bytes. Such small cells will be
** exceedingly rare, but they are possible.
*/
-#define MX_CELL(pBt) ((pBt->pageSize-8)/3)
+#define MX_CELL(pBt) ((pBt->usableSize-8)/3)
/* Forward declarations */
typedef struct MemPage MemPage;
@@ -1745,7 +1745,7 @@
Pgno finSize; /* Pages in the database file after truncation */
int rc; /* Return code */
u8 eType;
- int pgsz = pBt->pageSize; /* Page size for this database */
+ int pgsz = pBt->usableSize;/* Usable bytes on each page */
Pgno iDbPage; /* The database page to move */
MemPage *pDbMemPage = 0; /* "" */
Pgno iPtrPage; /* The page that contains a pointer to iDbPage */
|
|
1056 |
code
|
active
|
2004 Dec
|
anonymous
|
Shell
|
2004 Dec
|
|
3
|
3
|
test pragma-9.4 fails during second pass in "make fulltest"
|
edit |
During a "make fulltest" run, the pragma tests appear to run twice. On the first run, pragma-9.4 runs properly. On the second run, it gives an error:
pragma-9.4...
Expected: []
Got: [/Volumes/Local/Users/sqlite/test/bld]
(where the path listed is the build directory for this build of sqlite).
The pragma-9.4 test is a recent addition to sqlite.
This is currently the only failure I'm seeing in a "make fulltest" of the current cvs tree on Mac OS X when the build/test directory is on a hard drive.
1 errors out of 68411 tests
Failures on these tests: pragma-9.4
make: *** [fulltest] Error 1
|
|
1053 |
code
|
active
|
2004 Dec
|
anonymous
|
Pager
|
2004 Dec
|
|
3
|
3
|
SQLITE_IOERR and strange rollback when db is busy
|
edit |
Environment on which bug was found:
Windows XP, both SP1 and SP2, on different computers.
The SQLite library was built using the precompiled source from the download page (as static library).
Description of bug scenario:
One process performs very long reads from a db (multiple joins, so the cartesian product is very large, and the reader needs a while to complete).
Another process performs a BEGIN TRANSACTION , then executes lots of INSERT INTO ... VALUES .
At some point, this process will end up in sqlite3pager_get, when it tries to read some page from the database file (the main file, not a temp file or a journal). It detects that the page is not in the page cache (it ends up in the 'else' branch of if( pPg==0 ) ). It runs down to the block of code covered by the following comment:
/* Write the page to the database file if it is dirty.
*/
In this block, pager_write_pagelist( pPg ) returns with SQLITE_BUSY. As a consequence, the changes are rolled back and SQLITE_IOERR is returned.
And here seems to be the problem:
First, the database file is locked, so I don't understand why the SQLITE_BUSY value isn't propagated back to the caller. If SQLITE_BUSY would be returned, then the application could restart the command.
Seconds, sqlite3VdbeHalt decides to perform a sqlite3BtreeRollbackStmt, so only the last command should be rolled back. However, this is not what happens! In fact, all commands back to the beginning of the transaction are rolled back; the transaction, however is not closed. Doesn't this violate the default rollback behaviour (roll back last command, keep transaction open)? As a consequence, even if the application would get SQLITE_BUSY, it couldn't properly react on it.
There are other places in sqlite3pager_get where SQLITE_IOERR are returned; I've not checked whether these can also be triggered by the db being locked or if they indicate serious problem.
I will attach the code I used to reproduce and track down the problem, together with a Visual Studio 2003 project.
If you extract the archive, on toplevel you will find the following:
- Reader: the directory containing the source for the reader
- Writer: the directory contaiing the source for the writer
- SQLite: A directory in which to place the precompiled source for windows users, which is used to build the library. If you want to use the provided project file with Visual Studio, just copy the source in there and everything will build with a single mouse click.
- BugDemo.sln: The Visual Studio project file.
- bugdemo.sql: The SQL statements used to create the test database.
How to reproduce:
- Create a database using bugdemo.sql
- Adapt reader.cpp and writer.cpp to include the sqlite3 headers, and set the define at the top of the files to the path of the test database.
- Compile everything.
- Start the reader.
- Start the writer, and wait until it reports an error (for me, it takes < 30 seconds).
I tried to keep the source portable, so it shouldn't be too hard to make it compile on Unix. |
|
1043 |
doc
|
active
|
2004 Dec
|
anonymous
|
|
2004 Dec
|
|
3
|
3
|
SQLITE3_ANY does not exist
|
edit |
The file "www/capi3.tcl" refers to SQLITE3_encodings, such as SQLITE3_UTF8. In the header file, these are prefixed with SQLITE_ and not SQLITE3_. |
|
1040 |
new
|
active
|
2004 Dec
|
anonymous
|
Unknown
|
2005 Apr
|
|
4
|
4
|
pragma needed to enable flexibility of insert statements (esp. for awk-like filter use)
|
edit |
In order to work around http://www.sqlite.org/cvstrac/tktview?tn=1032,3 it is possible to create insert statements manually using sed.
However, those insert statements are not as flexible as they are documented to be. An error is generated if there are more data than columns. It is too slow to count the number of columns in each row to work around it.
This makes the use of sqlite as an awk-like filter impossible, since
you can't just define columns f1 through f9 and insert rows that have fewer columns into it. Defaulting is not done.
This is inconsistent with the sqlite2 copy command, which is flexible.
I propose a pragma to allow more flexibility.
There is no fast workaround, but I am not assigning that severity, because in principle it is possible to much more slowly create a disk db and use .import for most purposes. |
|
1034 |
build
|
active
|
2004 Dec
|
anonymous
|
TclLib
|
2004 Dec
|
|
2
|
4
|
configure generated Makefile doesn't use TCL on MinGW on Windows
|
edit |
When using MinGW/MSYS on Windows XP, the Makefile generated by the configure script fails while building the testfixture. The makefile is generated using
../sqlite/configure --with-tcl=/c/mingw/lib
The configure script correctly locates the tclConfig.sh file in this directory and loads it.
When I try to run the test suite, the build fails while linking the testfixture as shown below:
$ make test
./libtool --mode=link gcc -g -O2 -DOS_WIN=1 -I. -I../sqlite/src -DNDEBUG -I/mingw/include -DSQLITE_OMIT_CURSOR -DTCLSH=1 -DSQLITE_TEST=1\
-DTHREADSAFE=0 -DTEMP_STORE=2\
-o testfixture ../sqlite/src/btree.c ../sqlite/src/date.c ../sqlite/src/func.c ../sqlite/src/os_mac.c ../sqlite/src/os_unix.c ../sqlite/src/os_win.c ../sqlite/src/pager.c ../sqlite/src/pragma.c ../sqlite/src/printf.c ../sqlite/src/test1.c ../sqlite/src/test2.c ../sqlite/src/test3.c ../sqlite/src/test4.c ../sqlite/src/test5.c ../sqlite/src/utf.c ../sqlite/src/util.c ../sqlite/src/vdbe.c ../sqlite/src/md5.c ../sqlite/src/tclsqlite.c \
libtclsqlite3.la
gcc -g -O2 -DOS_WIN=1 -I. -I../sqlite/src -DNDEBUG -I/mingw/include -DSQLITE_OMIT_CURSOR -DTCLSH=1 -DSQLITE_TEST=1 -DTHREADSAFE=0 -DTEMP_STORE=2 -o testfixture ../sqlite/src/btree.c ../sqlite/src/date.c ../sqlite/src/func.c ../sqlite/src/os_mac.c ../sqlite/src/os_unix.c ../sqlite/src/os_win.c ../sqlite/src/pager.c ../sqlite/src/pragma.c ../sqlite/src/printf.c ../sqlite/src/test1.c ../sqlite/src/test2.c ../sqlite/src/test3.c ../sqlite/src/test4.c ../sqlite/src/test5.c ../sqlite/src/utf.c ../sqlite/src/util.c ../sqlite/src/vdbe.c ../sqlite/src/md5.c ../sqlite/src/tclsqlite.c ./.libs/libtclsqlite3.a -L/mingw/lib -ltclstub84
C:/DOCUME~1/DennisC/LOCALS~1/Temp/cc2taaaa.o(.text+0x511): In function `sqlite3TestErrCode':
c:/SQLite/SQLiteV3/build2/../sqlite/src/test1.c:77: undefined reference to `_imp__Tcl_ResetResult'
It looks like the code is being linked against the tclstub84 library which doesn't contain the needed code.
To work around this problem, I needed to modify the Makefile that configure generated. I modified the line:
LIBTCL =
to use the correct library like this:
LIBTCL = -L/mingw/lib -ltcl84
Now the testfixture builds correctly and I can run the test suite.
Someone more familiar with the automake tools will need to correct this problem on a more permanent basis. |
2004-Dec-10 02:15:25 by drh:
You can help us to troubleshoot this by attaching
the following files to the ticket:
- tclConfig.sh
- the complete output of configure and make
2004-Dec-10 16:08:05 by anonymous:
I have attached the requested files. Note, these files were generated from the latest CVS source after checkin 2162.
The tclConfig.sh file is exactly as is was installed by the MinGW tcltk binary package in the last stable version of MinGW/MSYS (I just checked and they have released a newer stable version of MinGW/MSYS since I installed mine. It seems the only package which is newer than my installation is the gcc compiler. I have the current version of the tcl/tk package.) |
|
1031 |
new
|
active
|
2004 Dec
|
anonymous
|
|
2005 Jan
|
|
3
|
4
|
sqlite command line does not allow intermixing of dot commands and sql
|
edit |
Dot commands are not fully intermixable with sql commands in sqlite3.
Please see bug 1030. |
|
1030 |
code
|
active
|
2004 Dec
|
anonymous
|
Shell
|
2005 Apr
|
|
2
|
3
|
impossible to import a file and do other things in the same invocation (strongly affects scripting)
|
edit |
The sqlite2 shell can be scripted in 2 ways:
1. sqlite mydb 'commands'
2. commands | sqlite mydb
The first form has a bug, which I have not submitted, and which also
occurs in sqlite3:
o dot commands are not fully intermixable with sql commands
It will also fail for long command lines.
To work around this, it is necessary to use the second form of
scripting. However:
o for entering data via COPY or .import, a separator is
necessary to allow sql after the data
o COPY has \. as a separator
Here is the sqlite3 bug:
o .import has no separator that I know of
The only possible workaround seems to be to call the executable more
than once. However:
o this makes :memory: databases impossible
Therefore, I said this is major with a workaround. The workaround is
to use temporary files instead of memory databases, and:
o inconveniently kludge the sqlite2 behavior using multiple
calls to the executable
However, files are far slower than memory, making the use of sqlite as
an awk-like filter less attractive than it was with sqlite2.
Here are 2 solutions to fix the problem, both of which are desirable:
o allow dot commands and sqlite commands to be intermixable on
the command line such as with "sqlite :memory:
'.show;.import ...;select ...;.import ...; select ...'"
o allow a separator for .import
Here are some related bugs, also not submitted:
o .separator is overloaded to mean input and output
separators, but for scripting it would be useful to have
them separate
o csv mode and tabs mode are lightly documented. what are the
exact syntaxes for them (line continuation, quoting, etc.),
and what is the difference between tabs mode and .separator
set to tab?
o it might also be useful to have a .with command so that you
can do .with .separator ","; .import ...; .endwith to
effectively emulate (let ((...)) ...) in lisp.
i.e. temporarily set a value to something without having to
know what to set it back to when you are done.
Sqlite rocks.
Thanks. |
|
1029 |
doc
|
active
|
2004 Dec
|
anonymous
|
Unknown
|
2004 Dec
|
|
4
|
5
|
SQLITE_ not SQLITE3_ constants in the C/C++ interface . html
|
edit |
in this file :
http://www.sqlite.org/capi3.html
there are constants :
#define SQLITE3_UTF8 1
#define SQLITE3_UTF16 2
#define SQLITE3_UTF16BE 3
#define SQLITE3_UTF16LE 4
#define SQLITE3_ANY 5
but in the code , they are SQLITE_* not SQLITE3_* |
|
1026 |
code
|
active
|
2004 Dec
|
anonymous
|
Unknown
|
2004 Dec
|
|
3
|
3
|
sqlite automake sqlite3.pc file does not have version information
|
edit |
When the configure of sqlite has been done, the sqlite3.pc file does not have information in the Version: section. This means there's no way to check for versions in other autogen/configure files concerning the sqlite version in the system, style:
PKG_CHECK_MODULES(SQLITE, sqlite >= 3.0.3,
AC_MSG_ERROR([$SQLITE_PKG_ERRORS])) |
|
1020 |
doc
|
active
|
2004 Nov
|
anonymous
|
|
2004 Nov
|
|
5
|
4
|
in html (.tcl) <,> is not always <, >
|
edit |
I created a .chm and got some error messages for invalid htm content. Here's the list:
datatype3.tcl (342):
For binary comparison operators (, <, >, < and >=) if either operand is a
should be: (replace <>)
For binary comparison operators (, <, >, < and >=) if either operand is a
version3.tcl (199)
sorts (or uses a comparison operator like "<" or ">=") the sort order
should be:
sorts (or uses a comparison operator like "<" or ">=") the sort order
I put it temporarily online here:
http://www.hbreitner.de/tmp/sqlite3.0.8chm.zip
Feel free to put it online!
Harald |
|
1011 |
new
|
active
|
2004 Nov
|
anonymous
|
|
2004 Nov
|
|
5
|
4
|
No .lib file for in windows precompiled binaries
|
edit |
It would be nice if there was .lib file available in precompiled binaries, so one could compile interface modules (like python sqlite) without building the full source. |
2004-Nov-21 23:53:45 by anonymous:
Does the information under "MSVC and SQLite DLL" in http://www.sqlite.org/cvstrac/wiki?p=HowToCompile help you?
2004-Nov-23 05:21:41 by anonymous:
There should be sqlite3.h with dll for C-compiler. |
|
974 |
new
|
active
|
2004 Oct
|
anonymous
|
|
2005 Dec
|
|
5
|
4
|
Version-Resource in pre-compiled windows dll
|
edit |
It would be nice if the precompiled windows-dll would include a version-resource so that an installer or any user (via file-properties) can determine the version of the sqlite3.dll |
2004-Oct-26 17:27:51 by anonymous:
The attached 'sqlite.rc' works under mingw32. Add the following lines to your makefile to add the version:
sqliterc.res: sqlite.rc
windres sqlite.rc sqliterc.res
sqliterc.o: sqliterc.res
windres sqliterc.res sqliterc.o
sqlite3.dll: sqliterc.o etc...
|
|
972 |
warn
|
active
|
2004 Oct
|
anonymous
|
|
2005 May
|
|
3
|
3
|
building SQLite on Irix
|
edit |
Hi,
Here are the warnings I got while building SQLite 3.0.8 on Irix 6.5 using SGI's MIPSpro 7.3.1.1m compiler. Most of the warnings are about signed/unsigned char issues (these warnings are common with commercial Unix compilers) and I'm not sure you're willing to fix them. Some other warnings should probably be fixed (unused variables, missing return values, and the like).
cc-1116 cc: WARNING File = ./tool/lemon.c, Line = 2352
Non-void function "preprocess_input" (declared at line 2308) should return a
value.
}
^
cc-1164 cc: WARNING File = ./src/attach.c, Line = 170
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( sqlite3StrNICmp(pDb->zName, pDbname->z, pDbname->n)==0 ) break;
^
cc-1515 cc: WARNING File = ./src/btree.c, Line = 1251
A value of type "char *" cannot be assigned to an entity of type "u8 *".
pPage->aData = &((char*)pPage)[-pBt->pageSize];
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 1901
The variable "pBt" is set but never used.
Btree *pBt;
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 2005
The variable "oldPgno" is set but never used.
Pgno oldPgno;
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 2936
The variable "idxDiv" is set but never used.
int idxDiv[NB]; /* Indices of divider cells in pParent */
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 4186
The variable "cur" is set but never used.
BtCursor cur;
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 4188
The variable "maxLocal" is set but never used.
int maxLocal, usableSize;
^
cc-1164 cc: WARNING File = ./src/build.c, Line = 461
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
zName = sqliteStrNDup(pName->z, pName->n);
^
cc-1164 cc: WARNING File = ./src/build.c, Line = 490
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
0==sqlite3StrNICmp(pDb->zName, pName->z, pName->n) ){
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 580
The variable "pIdx" is set but never used.
Index *pIdx;
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 780
The variable "pz" is set but never used.
char *z, **pz;
^
cc-1164 cc: WARNING File = ./src/build.c, Line = 1195
Argument of type "unsigned char *" is incompatible with parameter of type
"const char *".
|| sqlite3KeywordCode(zIdent, j)!=TK_ID;
^
cc-1164 cc: WARNING File = ./src/build.c, Line = 1370
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3VdbeChangeP3(v, -1, pParse->sNameToken.z, n);
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 1904
The variable "pISameName" is set but never used.
Index *pISameName; /* Another index with the same name */
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 1905
The variable "pTSameName" is set but never used.
Table *pTSameName; /* A table with same name as the index */
^
cc-1515 cc: WARNING File = ./src/build.c, Line = 1948
A value of type "char *" cannot be assigned to an entity of type
"const unsigned char *".
nullId.z = pTab->aCol[pTab->nCol-1].zName;
^
cc-1164 cc: WARNING File = ./src/build.c, Line = 1949
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
nullId.n = strlen(nullId.z);
^
cc-1164 cc: WARNING File = ./src/build.c, Line = 2109
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3VdbeChangeP3(v, -1, pName->z, n);
^
cc-1164 cc: WARNING File = ./src/date.c, Line = 648
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
parseDateOrTime(sqlite3_value_text(argv[0]), p) ) return 1;
^
cc-1164 cc: WARNING File = ./src/date.c, Line = 651
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
parseModifier(sqlite3_value_text(argv[i]), p) ) return 1;
^
cc-1140 cc: WARNING File = ./src/date.c, Line = 764
A value of type "const unsigned char *" cannot be used to initialize an entity
of type "const char *".
const char *zFmt = sqlite3_value_text(argv[0]);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 286
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
pExpr->iTable = i = atoi(&pToken->z[1]);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 359
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
pNew->token.z = sqliteStrDup(p->token.z);
^
cc-1515 cc: WARNING File = ./src/expr.c, Line = 359
A value of type "char *" cannot be assigned to an entity of type
"const unsigned char *".
pNew->token.z = sqliteStrDup(p->token.z);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 375
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
pTo->z = sqliteStrNDup(pFrom->z, pFrom->n);
^
cc-1515 cc: WARNING File = ./src/expr.c, Line = 375
A value of type "char *" cannot be assigned to an entity of type
"const unsigned char *".
pTo->z = sqliteStrNDup(pFrom->z, pFrom->n);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 573
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( sqlite3GetInt32(p->token.z, pValue) ){
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 583
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( n==0 && sqlite3GetInt32(p->token.z, pValue) ){
^
cc-1515 cc: WARNING File = ./src/expr.c, Line = 1039
A value of type "const unsigned char *" cannot be assigned to an entity of
type "const char *".
*pzName = pExpr->token.z;
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 1212
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
codeInteger(v, pExpr->token.z, pExpr->token.n);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 1219
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3VdbeOp3(v, op, 0, 0, pExpr->token.z, pExpr->token.n);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 1225
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3VdbeOp3(v, op, 0, 0, pExpr->token.z+1, pExpr->token.n-1);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 1236
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3VdbeChangeP3(v, -1, pExpr->token.z, pExpr->token.n);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 1466
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
pExpr->token.z, pExpr->token.n);
^
cc-1552 cc: WARNING File = ./src/expr.c, Line = 1491
The variable "v" is set but never used.
Vdbe *v;
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 1733
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( sqlite3StrNICmp(pA->token.z, pB->token.z, pB->token.n)!=0 ) return 0;
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 1733
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( sqlite3StrNICmp(pA->token.z, pB->token.z, pB->token.n)!=0 ) return 0;
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 1805
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
pExpr->token.z, pExpr->token.n,
^
cc-1140 cc: WARNING File = ./src/func.c, Line = 100
A value of type "const unsigned char *" cannot be used to initialize an entity
of type "const char *".
const char *z = sqlite3_value_text(argv[0]);
^
cc-1515 cc: WARNING File = ./src/func.c, Line = 151
A value of type "const unsigned char *" cannot be assigned to an entity of
type "const char *".
z = sqlite3_value_text(argv[0]);
^
cc-1164 cc: WARNING File = ./src/func.c, Line = 209
Argument of type "unsigned char *" is incompatible with parameter of type
"char *".
strcpy(z, sqlite3_value_text(argv[0]));
^
cc-1164 cc: WARNING File = ./src/func.c, Line = 209
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
strcpy(z, sqlite3_value_text(argv[0]));
^
cc-1164 cc: WARNING File = ./src/func.c, Line = 213
Argument of type "unsigned char *" is incompatible with parameter of type
"const char *".
sqlite3_result_text(context, z, -1, SQLITE_TRANSIENT);
^
cc-1164 cc: WARNING File = ./src/func.c, Line = 222
Argument of type "unsigned char *" is incompatible with parameter of type
"char *".
strcpy(z, sqlite3_value_text(argv[0]));
^
cc-1164 cc: WARNING File = ./src/func.c, Line = 222
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
strcpy(z, sqlite3_value_text(argv[0]));
^
cc-1164 cc: WARNING File = ./src/func.c, Line = 226
Argument of type "unsigned char *" is incompatible with parameter of type
"const char *".
sqlite3_result_text(context, z, -1, SQLITE_TRANSIENT);
^
cc-1140 cc: WARNING File = ./src/func.c, Line = 562
A value of type "const unsigned char *" cannot be used to initialize an entity
of type "const char *".
const char *zArg = sqlite3_value_text(argv[0]);
^
cc-1515 cc: WARNING File = ./src/main.c, Line = 876
A value of type "const unsigned char *" cannot be assigned to an entity of
type "const char *".
z = sqlite3_value_text(db->pErr);
^
cc-1552 cc: WARNING File = ./src/os_unix.c, Line = 1185
The variable "inMutex" is set but never used.
static int inMutex = 0;
^
cc-1164 cc: WARNING File = ./src/pager.c, Line = 873
Argument of type "u8 *" is incompatible with parameter of type "const char *".
if( pager_cksum(pPager, pgno, aData)!=cksum ){
^
cc-1164 cc: WARNING File = parse.y, Line = 193
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
{ yygotominor.yy284 = atoi(yymsp[0].minor.yy98.z); }
^
cc-1164 cc: WARNING File = parse.y, Line = 194
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
{ yygotominor.yy284 = -atoi(yymsp[0].minor.yy98.z); }
^
cc-1164 cc: WARNING File = parse.y, Line = 215
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
{sqlite3AddCollateType(pParse, yymsp[0].minor.yy98.z, yymsp[0].minor.yy98.n);}
^
cc-1164 cc: WARNING File = parse.y, Line = 753
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( p ) p->pColl = sqlite3LocateCollSeq(pParse, yymsp[-1].minor.yy98.z, yymsp[-1].minor.yy98.n);
^
cc-1164 cc: WARNING File = parse.y, Line = 761
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( p ) p->pColl = sqlite3LocateCollSeq(pParse, yymsp[-1].minor.yy98.z, yymsp[-1].minor.yy98.n);
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 31
Argument of type "const u8 *" is incompatible with parameter of type
"const char *".
if( sqlite3IsNumber(z, 0, SQLITE_UTF8) ){
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 32
Argument of type "const u8 *" is incompatible with parameter of type
"const char *".
return atoi(z);
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 35
Argument of type "const u8 *" is incompatible with parameter of type
"const char *".
if( sqlite3StrICmp(z,azTrue[i])==0 ) return 1;
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 35
Argument of type "const u8 *" is incompatible with parameter of type
"const char *".
if( sqlite3StrICmp(z,azTrue[i])==0 ) return 1;
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 65
Argument of type "u8 *" is incompatible with parameter of type "const char *".
if( sqlite3IsNumber(z, 0, SQLITE_UTF8) ){
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 66
Argument of type "u8 *" is incompatible with parameter of type "const char *".
return atoi(z);
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 69
Argument of type "u8 *" is incompatible with parameter of type "const char *".
if( sqlite3StrICmp(z,aKey[i].zWord)==0 ) return aKey[i].val;
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 69
Argument of type "const u8 *" is incompatible with parameter of type
"const char *".
if( sqlite3StrICmp(z,aKey[i].zWord)==0 ) return aKey[i].val;
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 158
Argument of type "const char *" is incompatible with parameter of type
"const u8 *".
}else if( getBoolean(zRight) ){
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 351
Argument of type "char *" is incompatible with parameter of type "u8 *".
pDb->safety_level = getSafetyLevel(zRight)+1;
^
cc-1164 cc: WARNING File = ./src/printf.c, Line = 594
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
(*func)(arg, pToken->z, pToken->n);
^
cc-1164 cc: WARNING File = ./src/select.c, Line = 105
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
&& sqlite3StrNICmp(p->z, keywords[j].zKeyword, p->n)==0 ){
^
cc-1515 cc: WARNING File = ./src/select.c, Line = 150
A value of type "const char *" cannot be assigned to an entity of type
"const unsigned char *".
p->z = z;
^
cc-1515 cc: WARNING File = ./src/select.c, Line = 575
A value of type "char *" cannot be assigned to an entity of type "u8 *".
pInfo->aSortOrder = (char*)&pInfo->aColl[nCol];
^
cc-1164 cc: WARNING File = ./src/select.c, Line = 761
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3VdbeSetColName(v, i, p->span.z, p->span.n);
^
cc-1164 cc: WARNING File = ./src/select.c, Line = 774
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3VdbeSetColName(v, i, p->span.z, p->span.n);
^
cc-1164 cc: WARNING File = ./src/select.c, Line = 1957
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
pList->a[i].zName = sqliteStrNDup(pExpr->span.z, pExpr->span.n);
^
cc-1164 cc: WARNING File = ./src/select.c, Line = 2060
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( sqlite3StrNICmp(pExpr->token.z,"min",3)==0 ){
^
cc-1164 cc: WARNING File = ./src/select.c, Line = 2062
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
}else if( sqlite3StrNICmp(pExpr->token.z,"max",3)==0 ){
^
cc-1515 cc: WARNING File = ./src/tokenize.c, Line = 427
A value of type "const char *" cannot be assigned to an entity of type
"const unsigned char *".
pParse->sLastToken.z = &zSql[i];
^
cc-1164 cc: WARNING File = ./src/trigger.c, Line = 237
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3VdbeChangeP3(v, addr+6, pAll->z, pAll->n);
^
cc-1164 cc: WARNING File = ./src/trigger.c, Line = 276
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
p->target.z = sqliteStrNDup(p->target.z, p->target.n);
^
cc-1515 cc: WARNING File = ./src/trigger.c, Line = 276
A value of type "char *" cannot be assigned to an entity of type
"const unsigned char *".
p->target.z = sqliteStrNDup(p->target.z, p->target.n);
^
cc-1515 cc: WARNING File = ./src/trigger.c, Line = 627
A value of type "char *" cannot be assigned to an entity of type
"const unsigned char *".
sDb.z = pParse->db->aDb[iDb].zName;
^
cc-1164 cc: WARNING File = ./src/trigger.c, Line = 628
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sDb.n = strlen(sDb.z);
^
cc-1164 cc: WARNING File = ./src/vacuum.c, Line = 61
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
rc = execSql(db, sqlite3_column_text(pStmt, 0));
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1176
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3SetString(&p->zErrMsg, sqlite3_value_text(pTos), (char*)0);
^
cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 1737
A value of type "u8 *" cannot be assigned to an entity of type "char *".
zRec = pC->aRow;
^
cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 1802
A value of type "char *" cannot be assigned to an entity of type "u8 *".
zRec = pC->aRow = zData;
^
cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 1802
A value of type "u8 *" cannot be assigned to an entity of type "char *".
zRec = pC->aRow = zData;
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1807
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
idx = sqlite3GetVarint32(zData, &szHdr);
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1833
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
idx += sqlite3GetVarint32(&zData[idx], &aType[i]);
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1873
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
sqlite3VdbeSerialGet(zData, aType[p2], pTos);
^
cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 2018
A value of type "char *" cannot be assigned to an entity of type
"unsigned char *".
zNewRecord = zTemp;
^
cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 2060
A value of type "unsigned char *" cannot be assigned to an entity of type
"char *".
pTos->z = zNewRecord;
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 2715
Argument of type "char *" is incompatible with parameter of type "const u8 *".
szRowid = sqlite3VdbeIdxRowidLen(nKey, zKey);
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 2732
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
rc = sqlite3VdbeIdxKeyCompare(pCx, len, zKey, &res);
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3383
Argument of type "const char *" is incompatible with parameter of type
"const u8 *".
len = nKey - sqlite3VdbeIdxRowidLen(nKey, zKey);
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3389
Argument of type "const char *" is incompatible with parameter of type
"const unsigned char *".
if( sqlite3VdbeIdxKeyCompare(pC, len, zKey, &c)==SQLITE_OK && c==0 ){
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3539
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
rc = sqlite3VdbeIdxKeyCompare(pC, pTos->n, pTos->z, &res);
^
cc-1552 cc: WARNING File = ./src/vdbe.c, Line = 3525
The variable "pCrsr" is set but never used.
BtCursor *pCrsr;
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3577
Argument of type "const char *" is incompatible with parameter of type
"const unsigned char *".
k = sqlite3GetVarint32(z, &serial_type);
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3579
Argument of type "const char *" is incompatible with parameter of type
"const unsigned char *".
k += sqlite3GetVarint32(&z[k], &serial_type);
^
cc-1119 cc: WARNING File = ./src/vdbeapi.c, Line = 47
The "return" expression type differs from the function return type.
return (const char *)sqlite3ValueText(pVal, SQLITE_UTF8);
^
cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1746
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
sqlite3GetVarint32(m.z, &szHdr);
^
cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1747
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
sqlite3GetVarint32(&m.z[szHdr-1], &typeRowid);
^
cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1749
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
sqlite3VdbeSerialGet(&m.z[m.n-lenRowid], typeRowid, &v);
^
cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1785
Argument of type "char *" is incompatible with parameter of type "const u8 *".
lenRowid = sqlite3VdbeIdxRowidLen(m.n, m.z);
^
cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 65
A value of type "u8 *" cannot be assigned to an entity of type "char *".
pMem->z = z;
^
cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 85
A value of type "char *" cannot be assigned to an entity of type "u8 *".
z = pMem->zShort;
^
cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 98
A value of type "u8 *" cannot be assigned to an entity of type "char *".
pMem->z = z;
^
cc-1140 cc: WARNING File = ./src/vdbemem.c, Line = 154
A value of type "char *" cannot be used to initialize an entity of type "u8 *".
u8 *z = pMem->zShort;
^
cc-1164 cc: WARNING File = ./src/vdbemem.c, Line = 166
Argument of type "u8 *" is incompatible with parameter of type "char *".
sqlite3_snprintf(NBFS, z, "%.15g", pMem->r);
^
cc-1164 cc: WARNING File = ./src/vdbemem.c, Line = 169
Argument of type "u8 *" is incompatible with parameter of type "char *".
sqlite3_snprintf(NBFS, z, "%lld", pMem->i);
^
cc-1164 cc: WARNING File = ./src/vdbemem.c, Line = 171
Argument of type "u8 *" is incompatible with parameter of type "const char *".
pMem->n = strlen(z);
^
cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 172
A value of type "u8 *" cannot be assigned to an entity of type "char *".
pMem->z = z;
^
cc-1515 cc: WARNING File = ./src/utf.c, Line = 274
A value of type "char *" cannot be assigned to an entity of type
"unsigned char *".
zIn = pMem->z;
^
cc-1515 cc: WARNING File = ./src/utf.c, Line = 310
A value of type "char *" cannot be assigned to an entity of type
"unsigned char *".
zIn = pMem->z;
^
cc-1515 cc: WARNING File = ./src/utf.c, Line = 362
A value of type "char *" cannot be assigned to an entity of type
"unsigned char *".
zOut = pMem->zShort;
^
cc-1515 cc: WARNING File = ./src/utf.c, Line = 367
A value of type "unsigned char *" cannot be assigned to an entity of type
"char *".
pMem->z = zOut;
^
cc-1164 cc: WARNING File = ./src/shell.c, Line = 353
Argument of type "const char *" is incompatible with parameter of type
"const unsigned char *".
}else if( isNumber(z, 0) ){
^
cc-1164 cc: WARNING File = ./src/shell.c, Line = 519
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
}else if( isNumber(azArg[i], 0) ){
^
cc-1164 cc: WARNING File = ./src/shell.c, Line = 682
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
zSelect = appendText(zSelect, sqlite3_column_text(pTableInfo, 1), '"');
^
ld32: WARNING 84 : /usr/lib32/libcurses.so is not used for resolving any symbol.
creating sqlite3 |
2005-Jan-24 23:04:23 by anonymous:
Hi,
Here are the warnings I got while building SQLite 3.1.0 alpha on Irix 6.5 using SGI's MIPSpro 7.3.1.1m compiler.
cc-1116 cc: WARNING File = ./tool/lemon.c, Line = 2352
Non-void function "preprocess_input" (declared at line 2308) should return a
value.
}
^
cc-1164 cc: WARNING File = ./src/attach.c, Line = 170
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( sqlite3StrNICmp(pDb->zName, pDbname->z, pDbname->n)==0 ) break;
^
cc-1515 cc: WARNING File = ./src/btree.c, Line = 1494
A value of type "char *" cannot be assigned to an entity of type "u8 *".
pPage->aData = &((char*)pPage)[-pBt->psAligned];
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 2444
The variable "pBt" is set but never used.
Btree *pBt;
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 2548
The variable "oldPgno" is set but never used.
Pgno oldPgno;
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 3757
The variable "idxDiv" is set but never used.
int idxDiv[NB]; /* Indices of divider cells in pParent */
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 5384
The variable "cur" is set but never used.
BtCursor cur;
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 5386
The variable "maxLocal" is set but never used.
int maxLocal, usableSize;
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 128
The variable "rc" is set but never used.
int rc;
^
cc-1164 cc: WARNING File = ./src/build.c, Line = 499
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
zName = sqliteStrNDup(pName->z, pName->n);
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 626
The variable "pIdx" is set but never used.
Index *pIdx;
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 849
The variable "pz" is set but never used.
char *z, **pz;
^
cc-1164 cc: WARNING File = ./src/build.c, Line = 1281
Argument of type "unsigned char *" is incompatible with parameter of type
"const char *".
|| sqlite3KeywordCode(zIdent, j)!=TK_ID;
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 2191
The variable "pISameName" is set but never used.
Index *pISameName; /* Another index with the same name */
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 2192
The variable "pTSameName" is set but never used.
Table *pTSameName; /* A table with same name as the index */
^
cc-1515 cc: WARNING File = ./src/build.c, Line = 2235
A value of type "char *" cannot be assigned to an entity of type
"const unsigned char *".
nullId.z = pTab->aCol[pTab->nCol-1].zName;
^
cc-1164 cc: WARNING File = ./src/build.c, Line = 2236
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
nullId.n = strlen(nullId.z);
^
cc-1164 cc: WARNING File = ./src/build.c, Line = 2923
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
pColl = sqlite3FindCollSeq(db, db->enc, pName1->z, pName1->n, 0);
^
cc-1164 cc: WARNING File = ./src/date.c, Line = 646
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
parseDateOrTime(sqlite3_value_text(argv[0]), p) ) return 1;
^
cc-1164 cc: WARNING File = ./src/date.c, Line = 649
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
parseModifier(sqlite3_value_text(argv[i]), p) ) return 1;
^
cc-1140 cc: WARNING File = ./src/date.c, Line = 762
A value of type "const unsigned char *" cannot be used to initialize an entity
of type "const char *".
const char *zFmt = sqlite3_value_text(argv[0]);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 226
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
depth = atoi(&pToken->z[1]);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 322
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
pExpr->iTable = i = atoi(&pToken->z[1]);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 395
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
pNew->token.z = sqliteStrNDup(p->token.z, p->token.n);
^
cc-1515 cc: WARNING File = ./src/expr.c, Line = 395
A value of type "char *" cannot be assigned to an entity of type
"const unsigned char *".
pNew->token.z = sqliteStrNDup(p->token.z, p->token.n);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 411
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
pTo->z = sqliteStrNDup(pFrom->z, pFrom->n);
^
cc-1515 cc: WARNING File = ./src/expr.c, Line = 411
A value of type "char *" cannot be assigned to an entity of type
"const unsigned char *".
pTo->z = sqliteStrNDup(pFrom->z, pFrom->n);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 663
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( sqlite3GetInt32(p->token.z, pValue) ){
^
cc-1515 cc: WARNING File = ./src/expr.c, Line = 946
A value of type "const unsigned char *" cannot be assigned to an entity of
type "const char *".
*pzName = pExpr->token.z;
^
cc-1174 cc: WARNING File = ./src/expr.c, Line = 993
The variable "i" was declared but never referenced.
int i;
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 1402
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
codeInteger(v, pExpr->token.z, pExpr->token.n);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 1409
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3VdbeOp3(v, op, 0, 0, pExpr->token.z, pExpr->token.n);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 1416
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3VdbeOp3(v, op, 0, 0, pExpr->token.z+1, pExpr->token.n-1);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 1428
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3VdbeChangeP3(v, -1, pExpr->token.z, pExpr->token.n);
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 1673
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
pExpr->token.z, pExpr->token.n);
^
cc-1552 cc: WARNING File = ./src/expr.c, Line = 1726
The variable "v" is set but never used.
Vdbe *v;
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 1968
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( sqlite3StrNICmp(pA->token.z, pB->token.z, pB->token.n)!=0 ) return 0;
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 1968
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( sqlite3StrNICmp(pA->token.z, pB->token.z, pB->token.n)!=0 ) return 0;
^
cc-1164 cc: WARNING File = ./src/expr.c, Line = 2037
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
pExpr->token.z, pExpr->token.n,
^
cc-1140 cc: WARNING File = ./src/func.c, Line = 100
A value of type "const unsigned char *" cannot be used to initialize an entity
of type "const char *".
const char *z = sqlite3_value_text(argv[0]);
^
cc-1515 cc: WARNING File = ./src/func.c, Line = 151
A value of type "const unsigned char *" cannot be assigned to an entity of
type "const char *".
z = sqlite3_value_text(argv[0]);
^
cc-1164 cc: WARNING File = ./src/func.c, Line = 209
Argument of type "unsigned char *" is incompatible with parameter of type
"char *".
strcpy(z, sqlite3_value_text(argv[0]));
^
cc-1164 cc: WARNING File = ./src/func.c, Line = 209
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
strcpy(z, sqlite3_value_text(argv[0]));
^
cc-1164 cc: WARNING File = ./src/func.c, Line = 213
Argument of type "unsigned char *" is incompatible with parameter of type
"const char *".
sqlite3_result_text(context, z, -1, SQLITE_TRANSIENT);
^
cc-1164 cc: WARNING File = ./src/func.c, Line = 222
Argument of type "unsigned char *" is incompatible with parameter of type
"char *".
strcpy(z, sqlite3_value_text(argv[0]));
^
cc-1164 cc: WARNING File = ./src/func.c, Line = 222
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
strcpy(z, sqlite3_value_text(argv[0]));
^
cc-1164 cc: WARNING File = ./src/func.c, Line = 226
Argument of type "unsigned char *" is incompatible with parameter of type
"const char *".
sqlite3_result_text(context, z, -1, SQLITE_TRANSIENT);
^
cc-1164 cc: WARNING File = ./src/func.c, Line = 479
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( sqlite3utf8CharLen(zEsc, -1)!=1 ){
^
cc-1140 cc: WARNING File = ./src/func.c, Line = 560
A value of type "const unsigned char *" cannot be used to initialize an entity
of type "const char *".
char const *zCsr = zSql;
^
cc-1515 cc: WARNING File = ./src/func.c, Line = 571
A value of type "const char *" cannot be assigned to an entity of type
"const unsigned char *".
tname.z = zCsr;
^
cc-1164 cc: WARNING File = ./src/func.c, Line = 579
Argument of type "const char *" is incompatible with parameter of type
"const unsigned char *".
len = sqlite3GetToken(zCsr, &token);
^
cc-1140 cc: WARNING File = ./src/func.c, Line = 611
A value of type "const unsigned char *" cannot be used to initialize an entity
of type "const char *".
char const *zCsr = zSql;
^
cc-1515 cc: WARNING File = ./src/func.c, Line = 623
A value of type "const char *" cannot be assigned to an entity of type
"const unsigned char *".
tname.z = zCsr;
^
cc-1164 cc: WARNING File = ./src/func.c, Line = 631
Argument of type "const char *" is incompatible with parameter of type
"const unsigned char *".
len = sqlite3GetToken(zCsr, &token);
^
cc-1140 cc: WARNING File = ./src/func.c, Line = 713
A value of type "const unsigned char *" cannot be used to initialize an entity
of type "const char *".
const char *zArg = sqlite3_value_text(argv[0]);
^
cc-1515 cc: WARNING File = ./src/main.c, Line = 888
A value of type "const unsigned char *" cannot be assigned to an entity of
type "const char *".
z = sqlite3_value_text(db->pErr);
^
cc-1552 cc: WARNING File = ./src/os_unix.c, Line = 1217
The variable "inMutex" is set but never used.
static int inMutex = 0;
^
cc-1164 cc: WARNING File = ./src/pager.c, Line = 922
Argument of type "u8 *" is incompatible with parameter of type "const char *".
if( pager_cksum(pPager, pgno, aData)!=cksum ){
^
cc-1164 cc: WARNING File = parse.y, Line = 201
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
{ yygotominor.yy60 = atoi(yymsp[0].minor.yy406.z); }
^
cc-1164 cc: WARNING File = parse.y, Line = 202
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
{ yygotominor.yy60 = -atoi(yymsp[0].minor.yy406.z); }
^
cc-1164 cc: WARNING File = parse.y, Line = 230
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
{sqlite3AddCollateType(pParse, yymsp[0].minor.yy406.z, yymsp[0].minor.yy406.n);}
^
cc-1164 cc: WARNING File = parse.y, Line = 804
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( p ) p->pColl = sqlite3LocateCollSeq(pParse, yymsp[-1].minor.yy406.z, yymsp[-1].minor.yy406.n);
^
cc-1164 cc: WARNING File = parse.y, Line = 812
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( p ) p->pColl = sqlite3LocateCollSeq(pParse, yymsp[-1].minor.yy406.z, yymsp[-1].minor.yy406.n);
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 47
Argument of type "const u8 *" is incompatible with parameter of type
"const char *".
return atoi(z);
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 49
Argument of type "const u8 *" is incompatible with parameter of type
"const char *".
n = strlen(z);
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 51
Argument of type "const u8 *" is incompatible with parameter of type
"const char *".
if( iLength[i]==n && sqlite3StrNICmp(&zText[iOffset[i]],z,n)==0 ){
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 163
Argument of type "const char *" is incompatible with parameter of type
"const u8 *".
}else if( getBoolean(zRight) ){
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 309
Argument of type "char *" is incompatible with parameter of type "const u8 *".
sqlite3BtreeSetAutoVacuum(pBt, getBoolean(zRight));
^
cc-1164 cc: WARNING File = ./src/pragma.c, Line = 417
Argument of type "char *" is incompatible with parameter of type "const u8 *".
pDb->safety_level = getSafetyLevel(zRight)+1;
^
cc-1164 cc: WARNING File = ./src/printf.c, Line = 600
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
(*func)(arg, pToken->z, pToken->n);
^
cc-1164 cc: WARNING File = ./src/select.c, Line = 105
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
&& sqlite3StrNICmp(p->z, keywords[j].zKeyword, p->n)==0 ){
^
cc-1515 cc: WARNING File = ./src/select.c, Line = 150
A value of type "const char *" cannot be assigned to an entity of type
"const unsigned char *".
p->z = z;
^
cc-1515 cc: WARNING File = ./src/select.c, Line = 591
A value of type "char *" cannot be assigned to an entity of type "u8 *".
pInfo->aSortOrder = (char*)&pInfo->aColl[nCol];
^
cc-1164 cc: WARNING File = ./src/select.c, Line = 789
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3VdbeSetColName(v, i, p->span.z, p->span.n);
^
cc-1164 cc: WARNING File = ./src/select.c, Line = 802
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3VdbeSetColName(v, i, p->span.z, p->span.n);
^
cc-1164 cc: WARNING File = ./src/select.c, Line = 2037
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
pList->a[i].zName = sqliteStrNDup(pExpr->span.z, pExpr->span.n);
^
cc-1164 cc: WARNING File = ./src/select.c, Line = 2140
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
if( sqlite3StrNICmp(pExpr->token.z,"min",3)==0 ){
^
cc-1164 cc: WARNING File = ./src/select.c, Line = 2142
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
}else if( sqlite3StrNICmp(pExpr->token.z,"max",3)==0 ){
^
cc-1515 cc: WARNING File = ./src/tokenize.c, Line = 356
A value of type "const char *" cannot be assigned to an entity of type
"const unsigned char *".
pParse->sLastToken.z = &zSql[i];
^
cc-1164 cc: WARNING File = ./src/trigger.c, Line = 236
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3VdbeChangeP3(v, addr+6, pAll->z, pAll->n);
^
cc-1164 cc: WARNING File = ./src/trigger.c, Line = 275
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
p->target.z = sqliteStrNDup(p->target.z, p->target.n);
^
cc-1515 cc: WARNING File = ./src/trigger.c, Line = 275
A value of type "char *" cannot be assigned to an entity of type
"const unsigned char *".
p->target.z = sqliteStrNDup(p->target.z, p->target.n);
^
cc-1515 cc: WARNING File = ./src/trigger.c, Line = 612
A value of type "char *" cannot be assigned to an entity of type
"const unsigned char *".
sDb.z = pParse->db->aDb[iDb].zName;
^
cc-1164 cc: WARNING File = ./src/trigger.c, Line = 613
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sDb.n = strlen(sDb.z);
^
cc-1164 cc: WARNING File = ./src/vacuum.c, Line = 61
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
rc = execSql(db, sqlite3_column_text(pStmt, 0));
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1193
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
sqlite3SetString(&p->zErrMsg, sqlite3_value_text(pTos), (char*)0);
^
cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 1748
A value of type "u8 *" cannot be assigned to an entity of type "char *".
zRec = pC->aRow;
^
cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 1815
A value of type "char *" cannot be assigned to an entity of type "u8 *".
zRec = pC->aRow = zData;
^
cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 1815
A value of type "u8 *" cannot be assigned to an entity of type "char *".
zRec = pC->aRow = zData;
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1820
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
idx = sqlite3GetVarint32(zData, &szHdr);
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1846
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
idx += sqlite3GetVarint32(&zData[idx], &aType[i]);
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1885
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
sqlite3VdbeSerialGet(zData, aType[p2], pTos);
^
cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 2030
A value of type "char *" cannot be assigned to an entity of type
"unsigned char *".
zNewRecord = zTemp;
^
cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 2064
A value of type "unsigned char *" cannot be assigned to an entity of type
"char *".
pTos->z = zNewRecord;
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 2728
Argument of type "char *" is incompatible with parameter of type "const u8 *".
szRowid = sqlite3VdbeIdxRowidLen(nKey, zKey);
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 2745
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
rc = sqlite3VdbeIdxKeyCompare(pCx, len, zKey, &res);
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3439
Argument of type "const char *" is incompatible with parameter of type
"const u8 *".
len = nKey - sqlite3VdbeIdxRowidLen(nKey, zKey);
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3445
Argument of type "const char *" is incompatible with parameter of type
"const unsigned char *".
if( sqlite3VdbeIdxKeyCompare(pC, len, zKey, &c)==SQLITE_OK && c==0 ){
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3595
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
rc = sqlite3VdbeIdxKeyCompare(pC, pTos->n, pTos->z, &res);
^
cc-1552 cc: WARNING File = ./src/vdbe.c, Line = 3581
The variable "pCrsr" is set but never used.
BtCursor *pCrsr;
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3633
Argument of type "const char *" is incompatible with parameter of type
"const unsigned char *".
k = sqlite3GetVarint32(z, &serial_type);
^
cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3635
Argument of type "const char *" is incompatible with parameter of type
"const unsigned char *".
k += sqlite3GetVarint32(&z[k], &serial_type);
^
cc-1119 cc: WARNING File = ./src/vdbeapi.c, Line = 47
The "return" expression type differs from the function return type.
return (const char *)sqlite3ValueText(pVal, SQLITE_UTF8);
^
cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1747
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
sqlite3GetVarint32(m.z, &szHdr);
^
cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1748
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
sqlite3GetVarint32(&m.z[szHdr-1], &typeRowid);
^
cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1750
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
sqlite3VdbeSerialGet(&m.z[m.n-lenRowid], typeRowid, &v);
^
cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1786
Argument of type "char *" is incompatible with parameter of type "const u8 *".
lenRowid = sqlite3VdbeIdxRowidLen(m.n, m.z);
^
cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 76
A value of type "u8 *" cannot be assigned to an entity of type "char *".
pMem->z = z;
^
cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 96
A value of type "char *" cannot be assigned to an entity of type "u8 *".
z = pMem->zShort;
^
cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 109
A value of type "u8 *" cannot be assigned to an entity of type "char *".
pMem->z = z;
^
cc-1140 cc: WARNING File = ./src/vdbemem.c, Line = 165
A value of type "char *" cannot be used to initialize an entity of type "u8 *".
u8 *z = pMem->zShort;
^
cc-1164 cc: WARNING File = ./src/vdbemem.c, Line = 177
Argument of type "u8 *" is incompatible with parameter of type "char *".
sqlite3_snprintf(NBFS, z, "%.15g", pMem->r);
^
cc-1164 cc: WARNING File = ./src/vdbemem.c, Line = 180
Argument of type "u8 *" is incompatible with parameter of type "char *".
sqlite3_snprintf(NBFS, z, "%lld", pMem->i);
^
cc-1164 cc: WARNING File = ./src/vdbemem.c, Line = 182
Argument of type "u8 *" is incompatible with parameter of type "const char *".
pMem->n = strlen(z);
^
cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 183
A value of type "u8 *" cannot be assigned to an entity of type "char *".
pMem->z = z;
^
cc-1552 cc: WARNING File = ./src/where.c, Line = 883
The variable "pTab" is set but never used.
Table *pTab; /* Left-most table in the FROM clause */
^
cc-1515 cc: WARNING File = ./src/utf.c, Line = 275
A value of type "char *" cannot be assigned to an entity of type
"unsigned char *".
zIn = pMem->z;
^
cc-1515 cc: WARNING File = ./src/utf.c, Line = 311
A value of type "char *" cannot be assigned to an entity of type
"unsigned char *".
zIn = pMem->z;
^
cc-1515 cc: WARNING File = ./src/utf.c, Line = 363
A value of type "char *" cannot be assigned to an entity of type
"unsigned char *".
zOut = pMem->zShort;
^
cc-1515 cc: WARNING File = ./src/utf.c, Line = 368
A value of type "unsigned char *" cannot be assigned to an entity of type
"char *".
pMem->z = zOut;
^
cc-1164 cc: WARNING File = ./src/shell.c, Line = 353
Argument of type "const char *" is incompatible with parameter of type
"const unsigned char *".
}else if( isNumber(z, 0) ){
^
cc-1164 cc: WARNING File = ./src/shell.c, Line = 519
Argument of type "char *" is incompatible with parameter of type
"const unsigned char *".
}else if( isNumber(azArg[i], 0) ){
^
cc-1164 cc: WARNING File = ./src/shell.c, Line = 682
Argument of type "const unsigned char *" is incompatible with parameter of
type "const char *".
zSelect = appendText(zSelect, sqlite3_column_text(pTableInfo, 1), '"');
^
2005-Feb-13 13:59:50 by anonymous:
Hi,
Here are the warnings I got while building SQLite 3.1.1 beta on Irix 6.5 using SGI's MIPSpro 7.3.1.1m compiler.
I've removed all the signed/unsigned issues, since I suspect you're not interested...
cc-1552 cc: WARNING File = ./src/btree.c, Line = 2444
The variable "pBt" is set but never used.
Btree *pBt;
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 2548
The variable "oldPgno" is set but never used.
Pgno oldPgno;
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 3757
The variable "idxDiv" is set but never used.
int idxDiv[NB]; /* Indices of divider cells in pParent */
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 5384
The variable "cur" is set but never used.
BtCursor cur;
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 5386
The variable "maxLocal" is set but never used.
int maxLocal, usableSize;
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 131
The variable "rc" is set but never used.
int rc;
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 629
The variable "pIdx" is set but never used.
Index *pIdx;
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 2238
The variable "pISameName" is set but never used.
Index *pISameName; /* Another index with the same name */
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 2239
The variable "pTSameName" is set but never used.
Table *pTSameName; /* A table with same name as the index */
^
cc-1552 cc: WARNING File = ./src/expr.c, Line = 996
The variable "pSrcList" is set but never used.
SrcList *pSrcList;
^
cc-1552 cc: WARNING File = ./src/expr.c, Line = 1696
The variable "v" is set but never used.
Vdbe *v;
^
cc-1552 cc: WARNING File = ./src/os_unix.c, Line = 1217
The variable "inMutex" is set but never used.
static int inMutex = 0;
^
cc-1552 cc: WARNING File = ./src/vdbe.c, Line = 3586
The variable "pCrsr" is set but never used.
BtCursor *pCrsr;
^
cc-1552 cc: WARNING File = ./src/where.c, Line = 899
The variable "pTab" is set but never used.
Table *pTab; /* Left-most table in the FROM clause */
^
2005-Feb-20 16:37:31 by anonymous:
Hi,
Here are the warnings I got while building SQLite 3.1.3 on Irix 6.5 using SGI's MIPSpro 7.3.1.1m compiler.
Once again I've removed all the signed/unsigned issues, since I suspect you're not interested in them.
cc-1552 cc: WARNING File = ./src/btree.c, Line = 2425
The variable "pBt" is set but never used.
Btree *pBt;
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 2529
The variable "oldPgno" is set but never used.
Pgno oldPgno;
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 3741
The variable "idxDiv" is set but never used.
int idxDiv[NB]; /* Indices of divider cells in pParent */
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 5372
The variable "cur" is set but never used.
BtCursor cur;
^
cc-1552 cc: WARNING File = ./src/btree.c, Line = 5374
The variable "maxLocal" is set but never used.
int maxLocal, usableSize;
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 133
The variable "rc" is set but never used.
int rc;
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 631
The variable "pIdx" is set but never used.
Index *pIdx;
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 2244
The variable "pISameName" is set but never used.
Index *pISameName; /* Another index with the same name */
^
cc-1552 cc: WARNING File = ./src/build.c, Line = 2245
The variable "pTSameName" is set but never used.
Table *pTSameName; /* A table with same name as the index */
^
cc-1552 cc: WARNING File = ./src/expr.c, Line = 1021
The variable "pSrcList" is set but never used.
SrcList *pSrcList;
^
cc-1552 cc: WARNING File = ./src/expr.c, Line = 1721
The variable "v" is set but never used.
Vdbe *v;
^
cc-1552 cc: WARNING File = ./src/where.c, Line = 899
The variable "pTab" is set but never used.
Table *pTab; /* Left-most table in the FROM clause */
^
|
|
971 |
todo
|
active
|
2004 Oct
|
anonymous
|
Unknown
|
2004 Oct
|
peter
|
2
|
1
|
how to recompile sqlite with THREADSAFE preprocessor macro set to 1?
|
edit |
I have just installed sqlite-2.8.15 on my linux machine. After that I've tried to run the sqlite.php file which returns the fatal error as like below:
Call to undefined function: sqlite_open() in /home/maintain/public_html/tmp/sqlite.php on line 2
As per the instruction given in the forum, I have learn that I have to recompile the sqlite with THREADSAFE preprocessor macro set to 1, but I really don't know how to do this. Kindly help me on this issue.
Thanks and Regards,
Rajesh Kannan M |
|
965 |
new
|
active
|
2004 Oct
|
anonymous
|
VDBE
|
2004 Oct
|
|
3
|
3
|
Busy Handler not invoked for SELECT et.al. in SQLite <= 2.8.15
|
edit |
There exist very rare cases when sqlite_exec() can return SQLITE_BUSY
but the user-provided busy handler although set with sqlite_busy_handler() was never invoked. Please consider
the following patch against vdbe.c. It primarily affects SELECT statements. For PRAGMA similar code snippets might be necessary for
the VDBE opcodes ReadCookie/SetCookie.
--- sqlite.orig/src/vdbe.c Mon Jul 19 21:30:50 2004
+++ sqlite/src/vdbe.c Tue Oct 19 14:45:11 2004
@@ -2325,8 +2325,11 @@
*/
case OP_VerifyCookie: {
int aMeta[SQLITE_N_BTREE_META];
+ int busy = 1;
assert( pOp->p1>=0 && pOp->p1<db->nDb );
- rc = sqliteBtreeGetMeta(db->aDb[pOp->p1].pBt, aMeta);
+ while( (rc = sqliteBtreeGetMeta(db->aDb[pOp->p1].pBt,aMeta))==SQLITE_BUSY
+ && db->xBusyCallback
+ && db->xBusyCallback(db->pBusyArg, "", busy++)!=0 ){}
if( rc==SQLITE_OK && aMeta[1]!=pOp->p2 ){
sqliteSetString(&p->zErrMsg, "database schema has changed", (char*)0);
rc = SQLITE_SCHEMA;
|
|
960 |
doc
|
active
|
2004 Oct
|
anonymous
|
|
2004 Oct
|
|
3
|
2
|
Make archive unpack into directory sqlite-VERSION/
|
edit |
Please make the sqlite to unpack to separate directory, so that
upgrading won't overwrite previous sources.
sqlite-3.0.7.tar.gz
Should unpack all files under:
sqlite-3.0.7/
This is the de facto format for all internet projects, |
|
955 |
warn
|
active
|
2004 Oct
|
anonymous
|
Unknown
|
2004 Oct
|
|
1
|
1
|
When installing SQLite it says that a file is missing.
|
edit |
I downloaded sqlite-2.8.15-1.i386.rpm.
I tried to install it but is says that libreadline.so.4 is missing or something. When i go to KFind it says it is in /lib/ , i go there and i find it.
I really need SQLite to play a game from freashmeat.net.
PLEASE HELP ME !!! |
|
947 |
warn
|
active
|
2004 Oct
|
anonymous
|
Unknown
|
2004 Oct
|
|
3
|
3
|
Cygwin: integer constant is too large for "long" type
|
edit |
During porting to Cygwin, following is displayed
...
gcc -DOS_WIN=1 -DHAVE_USLEEP=1 -I. -I/cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src -DNDEBUG -c /cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src/util.c -DPIC -o .libs/util.o
/cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src/util.c: In function `sqlite3PutVarint':
/cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src/util.c:861: warning: integer constant is too large for "long" type |
2004-Oct-06 22:18:17 by anonymous:
[Forgot to paste this too]
gcc -DOS_WIN=1 -DHAVE_USLEEP=1 -I. -I/cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src -DNDEBUG -c /cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src/vdbe.c -DPIC -o .libs/vdbe.o
/cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src/vdbe.c: In function `sqlite3VdbeExec':
/cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src/vdbe.c:2890: warning: integer constant is too large for "long" type
/cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src/vdbe.c:2897: warning: integer constant is too large for "long" type
2004-Oct-07 03:54:36 by dougcurrie:
This is a duplicate of ticket #828
Are there any issues with using the LL suffix on these constants? |
|
944 |
new
|
active
|
2004 Oct
|
anonymous
|
Shell
|
2004 Oct
|
|
4
|
3
|
Command to abort current expression.
|
edit |
It would be convenient if, at the sqlite prompt, it was possible to abort the current expression by entering e.g. a singel dot on a new line. I.e.:
sqlite> SELECT * FROM
...> .
sqlite>
|
|
931 |
new
|
active
|
2004 Sep
|
anonymous
|
|
2006 Dec
|
|
5
|
4
|
Makefile for mingw on Win32, makes DLL, EXE and docs
|
edit |
This is a more compact and easier to understand makefile which will work out-of-the box (well, almost) for people using mingw32 on Windows platforms.
MSYS is not needed, but it does require gawk, sed and grep (well, and GNU make too). |
2005-Aug-27 01:07:30 by anonymous:
Has anybody compiled successfully sqlite3 3.2.x with mingw? how?
2005-Aug-27 02:13:20 by anonymous:
From version 2.8.14 to 3.2.4 I have no problems.
2005-Aug-27 12:24:58 by anonymous:
1. installed msys -c:\msys
2. installed mingw - c:\msys\mingw
3. installed msys toolkit and mingw make. see http://mingw.org/download.shtml
4. run msys.
5. go to sqlite directory.
6. ./configure
7. make
So easy so I can't tell more.
2005-Aug-27 13:14:58 by drh:
The precompiled windows binaries on the SQLite website have always
been generated using mingw running as a cross-compiler on a linux
host.
2005-Aug-27 15:14:09 by anonymous:
Ok, I got it working. There is just one discrepancy - I end up with the following:
291840 sqlite3.dll
1280564 sqlite3.exe
Whereas the downloadable "precompiled" binaries are just:
248320 sqlite3.dll
330203 sqlite3.exe
Is there anything else I need to do to get the exact same byte-size?
(this is 3.2.4)
2005-Aug-27 15:18:55 by anonymous:
Is it possible that you're compiling with readline support (which isn't present in the distributed binary due to licensing issues)?
2005-Aug-27 15:27:43 by anonymous:
I do not know how to enable/disable readline support. I have not changed or added any switch to the above. Besides, I think the .dll does not use readline.
2005-Dec-27 10:55:55 by anonymous:
see also BuildOnWindowsWithoutTcl
2006-Dec-28 19:18:55 by anonymous:
Does this also generate a .a for use in applications? Still needing the .dll that is. I don't need sqlite.exe at all...
2006-Dec-28 19:51:44 by anonymous:
I assume you mean .a for MinGW or Cygwin. Using Cygwin or MinGW/MSYS just download and untar the sqlite3 source and issue these commands:
cd sqlite
./configure
make sqlite3.dll
The .a file will be located in sqlite/.libs/libsqlite3.a |
|
930 |
new
|
active
|
2004 Sep
|
anonymous
|
Unknown
|
2007 Mar
|
drh
|
2
|
2
|
djgpp port for sqlite3
|
edit |
hello,
attached is a diff to sqlite 3.0.7 for dos, using free djgpp.
i did it in the spirit of the isolated platform files, and the generic changes (such as creation of os_dependent functions) have been implemented for all platforms available.
as required, the following copyright applies:
The author or authors of this code dedicate any and all copyright interest in this code to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights this code under copyright law.
thanks for sqlite,
and enjoy coding,
alex
p.s. i see that the diff i provided got mangled, and i'm changing it for the original one. since i'm unable to delete the wrong attachment, i would urge you to use the second one.
alex |
|
923 |
code
|
active
|
2004 Sep
|
anonymous
|
|
2004 Sep
|
anonymous
|
3
|
2
|
Missing quotes in 2.8.15 .dump cause data loss when loading in sqlite3
|
edit |
When converting a database by means of the command:
sqlite old.db .dump | sqlite3 new.db
the content of char/varchar fields is dumped by sqlite without quotes (e.g. 00001) and then when reloaded by sqlite3 it looses the heading
zeroes (i.e. becomes '1', which is a really different thing for an alphanumeric field).
This could be solved by a new release (sqlite 2.8.16 ?) which add quotes to alphanumeric fields (as sqlite3 does), or by a filter script that adds the quotes to the sqlite2 .dump output (I used a quick and dirty perl script to fix my dump...). |
2005-Jul-11 20:08:11 by anonymous:
This does not appear to be solved in sqlite 2.8.16. |
|
919 |
event
|
active
|
2004 Sep
|
anonymous
|
Unknown
|
2004 Sep
|
|
1
|
1
|
'make test' RESETS macOSX at ioerr 2.73.1
|
edit |
make test..
as ioerr 2.73.1 prints, the whole system freezes and MacOSX tells me to restart |
2004-Sep-30 06:37:01 by anonymous:
I run "make test" often on a PowerBook G4 running Mac OS X 10.3.5. I've never seen this behavior. It might be helpful for you to include more information about the circumstances of the crash. --SCG |
|
916 |
new
|
active
|
2004 Sep
|
anonymous
|
Unknown
|
2007 Dec
|
|
1
|
1
|
No delete notification for INSERT OR REPLACE
|
edit |
It would be nice if the "ON DELETE" trigger is called for the row substituted with a new one during REPLACE. Or, even better, one could add the OLD statement for the "ON INSERT" trigger and set it to point to the same row as NEW if a new row is inserted or to the deleting row if replace occurs. Thanks. |
2007-Dec-17 21:36:40 by anonymous:
I have the same problem. My solution would be to stick with the documentation of the ON REPLACE algorithm: "When a UNIQUE constraint violation occurs, the pre-existing rows that are causing the constraint violation are removed prior to inserting or updating the current row". That is, to call ON DELETE trigger whenever rows are removed. Thank you, and keep going, you do wonderful job anyway. |
|
883 |
new
|
active
|
2004 Sep
|
anonymous
|
Shell
|
2004 Sep
|
|
1
|
4
|
Choose appropriate column widths for column output
|
edit |
Currently, when you use a select statement and have .mode set to column, it truncates the data based on the values in .width. It can be a problem to set .width properly because sometimes you are only selecting some columns and sometimes all of them. This means you really have to set .width before each select statement. Even when you do, sometimes the width is too wide and space is wasted unless you know in advance the width of the widest value being printed.
What I would like is another mode or some option to have SQLite figure out the optimal width of the columns. It would simply set the width of each column to the width of the widest value in the column. MySQL does this. |
2004-Sep-02 15:18:20 by drh:
There are two ways of doing this:
- Run the query twice. Record the maximum column witdh on the first
run then display the results on the second run.
- Store the entire result set in memory. Compute the maximum column
widths prior to displaying anything.
Either approach requires a significant increase in resources
to do the query.
2005-Jan-21 20:56:53 by anonymous:
How about instead of, or in addition to this feature, a mode where each column has a default width which corresponds to the data type? E.g. if the type is CHAR(50) the column would be 50 wide. That would be faster and would be good enough for my purposes.
2005-Apr-09 19:41:59 by anonymous:
I don't need this feature after all, since I wrote a filtering program to convert the tab-separated data from sqlite to produce the column-separated data I wanted. In case someone wants to use the code to implement this feature in sqlite, or in case someone wanting this functionality wants to use it directly, you can download the code for free from:
http://personal.nbnet.nb.ca/aerichar/tab2col/ |
|
878 |
build
|
active
|
2004 Aug
|
anonymous
|
Unknown
|
2004 Aug
|
|
5
|
5
|
Wrong shared library file-names
|
edit |
Shared libraries created by SQLite 3.0.5 build don't have '.so' extension. Therefore installation can be broken.
Another bug is_ -lpthread is not linked to the library/executable when --enable-thread-safe is specified.
/usr/bin/install -c .libs/libsqlite3-3.0.5.0.8.6/usr/lib/libsqlite3-3.0.5.0.8.6
(cd /usr/lib && rm -f libsqlite3-3.0.5.0 && ln -s libsqlite3-3.0.5.0.8.6 libsqlite3-3.0.5.0)
(cd /usr/lib && rm -f libsqlite3 && ln -s libsqlite3-3.0.5.0.8.6 libsqlite3)
/usr/bin/install -c .libs/libsqlite3.lai /usr/lib/libsqlite3.la
|
|
867 |
new
|
active
|
2004 Aug
|
anonymous
|
Parser
|
2006 Jan
|
|
3
|
2
|
update on multiple tables
|
edit |
I would like to have update working on multi tables; It is not written
as possible thus it is a request for enhancement.
basic example:
create table a ( id integer primary key, val integer );
create table b ( id integer primary key, val integer );
insert into a (val) values (314);
insert into a (val) values (315);
insert into b (val) values (314);
insert into b (val) values (314);
update a, b set b.val = a.val; |
2006-Jan-24 19:01:31 by anonymous:
I would prefer another syntax - using a SELECT as the source for data to be updated.
UPDATE <DESTINATION_TABLE> SET <DESTINATION_FIELD>=<SOURCE_FIELD>...
WHERE <DESTINATION_OTHERFIELD> = <XPTOVALUE>...
SELECT <SOURCE_FIELD>
FROM <SOURCE_TABLE>
WHERE <SOURCE_OTHERFIELD>=<DESTINATION_OTHERFIELD>...
This is the update syntax used in PostgreSQL and other databases.
I also believe this is easier to understand and easier to implement (since the select is just the source for data)
2006-Jan-24 19:21:15 by anonymous:
Already supported via correlated subquery:
update b set val = (select a.val from a where a.id = b.id);
See: http://www.sqlite.org/lang_update.html |
|
865 |
build
|
active
|
2004 Aug
|
anonymous
|
Unknown
|
2004 Aug
|
|
1
|
1
|
Building problems with v3.0.3 and v3.0.4 on Fedora Core 2
|
edit |
SQLite is configured with: CFLAGS="-DNDEBUG=1" CXXFLAGS="-DNDEBUG=1" ./configure --enable-threadsafe --prefix=/usr
------------------8<------------------
.
.
.
./.libs/libsqlite3.so: undefined reference to `pthread_create'
./.libs/libsqlite3.so: undefined reference to `pthread_join'
collect2: ld returned 1 exit status
make: *** [sqlite3] Error 1
fel: Dålig slutstatus från /var/tmp/rpm-tmp.33961 (%build)
RPM-byggfel:
Dålig slutstatus från /var/tmp/rpm-tmp.33961 (%build)
------------------8<------------------
Some additional information:
[root@gnu SOURCES]# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
[root@gnu SOURCES]# uname -a
Linux gnu.nu6.org 2.6.8-1.521 #1 Mon Aug 16 09:01:18 EDT 2004 i686 i686 i386 GNU/Linux |
2004-Aug-21 17:36:56 by dougcurrie:
You can use the environment variable
config_TARGET_LIBS
to add any libraries you need to the link. See configure.ac.
-- e |
|
864 |
build
|
active
|
2004 Aug
|
anonymous
|
Unknown
|
2004 Aug
|
|
2
|
2
|
3.0.4 uses readling
|
edit |
on netbsd, I was compiling sqlite. It tried to use the readline library even though it did not exist. I edited the makefile to not use readline and it works, but config should have done this. Also, the best fix on the *BSDs is to also detect and use libedit instead of libreadline. |
2004-Sep-16 08:47:00 by anonymous:
I don't know how to add the logic to the config system, but on BSD systems with libedit, changing the makefile to read
LIBREADLINE = -ledit -ltermcap
allows it to compile and use libedit.
On some older versions of NetBSD it was also needed to ln the header files to where sqlite it looking for them. Newer versions worked with just the Makefile change above. |
|
853 |
doc
|
active
|
2004 Aug
|
anonymous
|
Parser
|
2004 Aug
|
|
4
|
3
|
syntax of DEFAULT in a CREATE TABLE statement not as documented
|
edit |
The syntax (as found under the syntax link on the website) indicates that a column default in a create table statement is like a column constraint definition. However, explicitly naming the column default fails. Consider:
CREATE TABLE FOO(
BAR VARCHAR(50) CONSTRAINT DEF_1 DEFAULT '(default)'
)
yields
SQL error: near "DEFAULT": syntax error
|
|
852 |
doc
|
active
|
2004 Aug
|
anonymous
|
|
2004 Aug
|
|
5
|
4
|
Typos found in the Syntax documentation
|
edit |
Here are all of the typos I have found in the online documentation.
I noticed them after opening the saved .html file in Microsoft Word.
"percisely" should be "precisely"
"a transaction will also ROLLBACK" should be "transactions will also ROLLBACK"
"documention" should be "documentation"
"multiline" should be "multi-line"
"whitespace" should be "white-space" (3 instances)
"baskslash" should be "backslash" (3 instances)
"entires" should be "entries"
"Everytime" should be "Every time" (3 instances)
"datatype" should be "data type" (6 instances)
"If a is specified" ??
"specify both a and the TEMP" ??
"The default is abort ABORT." should be "The default is ABORT."
"The text of CREATE TEMPORARY TABLE statements are" should be "The text of CREATE TEMPORARY TABLE statements is"
"one or more specified columns of a table are updated" should be "one or more specified columns of a table is updated"
"(either ABORT, FAIL or ROLLBACK)" should be "(ABORT, FAIL or ROLLBACK)"
"comparision" should be "comparison"
"globbing" should maybe be "globing"
"yeilds" should be "yields"
"mminimum" should be "minimum"
"negative the the first character" should be "negative the first character"
"constraint violation continue" should be "constraint violation will continue"
"statisfy" should be "satisfy"
"eachother" should be "each other"
"modelled" should be "modeled"
"reimplimented" should be "re-implemented"
"but can speed up inserts." should be "but can speed up insertions."
"views, ...)" should be "views ...)"
"identifer" should be "identifier"
I have a Word modified HTML document if it would help. Email me if you have any questions.
ps. SQLite is AWESOME! |
|
851 |
doc
|
active
|
2004 Aug
|
anonymous
|
Parser
|
2004 Aug
|
|
5
|
2
|
SQLite allows Zero length table column names
|
edit |
SQLite allows zero length identifiers, that is, a statement like:
CREATE TABLE [] (
"" not null
, name
)
does in fact create a (nameless) table with two (2) columns, be it that the first one ("", or []) is nameless. Although everything is still consistent (SELECT [] FROM "", or SELECT "" from [] does project the nameless column) it can be quit confusing. Consider this:
INSERT
INTO ""(name)
VALUES ('value')
generates SQL error:
. may not be NULL
At least the syntax documentation should state that it is in fact allowed to use zero length identifiers. |
2004-Aug-10 16:03:02 by anonymous:
C:\database>sqlite3.exe temp.db
SQLite version 3.0.4
Enter ".help" for instructions
sqlite> create table [] ( "" int,name);
sqlite> insert into [] values (1,'t');
sqlite> select * from [];
1|t
sqlite> .mode column
sqlite> .header on
sqlite> select * from [];
name
---------- ----------
1 t
sqlite>
sqlite> create table "" (i int);
SQL error: table "" already exists
sqlite>
2004-Aug-10 16:04:50 by anonymous:
we can say sqlite allows zero length table & column name. |
|
845 |
new
|
active
|
2004 Aug
|
anonymous
|
|
2004 Aug
|
|
5
|
4
|
Support shared-memory databases
|
edit |
It would be nice to have shared memory databases. In-memory databases with :memory are supported, but they can't be shared among multiple processes. |
|
843 |
new
|
active
|
2004 Aug
|
anonymous
|
Unknown
|
2004 Aug
|
|
3
|
3
|
Introducing I64 printf size prefix
|
edit |
sqlite3_mprintf supports the ll size prefix, so int64 can be formatted using the %llu format specifier.
VC++ printf routines doesn't support the ll size prefix but use the I64 prefix, so a int64 must be formatted as %I64d or %I64u
I think that sqlite3_mprintf should support both size prefixes, so a developer could use the same prefix independently to the function he will use (sqlite3_mprintf, printf, Format, etc....) |
|
841 |
code
|
active
|
2004 Aug
|
anonymous
|
Unknown
|
2004 Aug
|
|
3
|
2
|
inner group by query isn't honored by outer count(*) aggregate
|
edit |
CREATE TEMP TABLE A(a int NOT NULL, b int NOT NULL, c int NOT NULL);
INSERT INTO A VALUES (1, 1, 1);
INSERT INTO A VALUES (1, 2, 1);
INSERT INTO A VALUES (2, 1, 1);
-- typical behaviour is for this to behave like the DISTINCT query below
-- but instead it shows a=1 as having occured twice (but it was grouped in the inner query)
SELECT a, count(*) FROM (
SELECT a, c FROM A GROUP BY 1, 2) GROUP BY a;
Result:
2|1
1|2
-- shows a=1 as having occured once (correctly)
SELECT a, count(*) FROM (
SELECT DISTINCT a, c FROM A) GROUP BY a;
Result:
2|1
1|1
-- the top query performs better, which is why I am reporting this bug
|
2004-Aug-08 18:42:00 by drh:
SQLite ignores the ORDER BY clause if there are no
aggregate functions. |
|
833 |
todo
|
active
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Jul
|
|
1
|
3
|
port of sqlite 2.8.15 to djgpp
|
edit |
here is a diff to be applied on sqlite 2.8.15 to make it work with djgpp.
some of the fixes are needed for general purpose, such as relative path handling, and bypass of history and readline wherever not present.
anyway, i see no harm to apply this patch to mainstream sqlite.
best regards,
alex <alexbodn@012.net.il> |
|
832 |
code
|
active
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Jul
|
anonymous
|
4
|
4
|
os_win.c :: sqlite3OsUnlock() method has an unused variable: rc
|
edit |
os_win.c :: sqlite3OsUnlock() method has an unused variable: rc |
|
828 |
warn
|
active
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Jul
|
|
3
|
3
|
integer constants to long
|
edit |
when compiling sqlite3 on windows using msys/mingw I get the following warnings:
src/util.c: In function `sqlite3PutVarint':
src/util.c:1022: warning: integer constant is too large for "long" type
src/vdbe.c: In function `sqlite3VdbeExec':
src/vdbe.c:2917: warning: integer constant is too large for "long" type
src/vdbe.c:2924: warning: integer constant is too large for "long" type
src/vdbeaux.c: In function `sqlite3VdbeSerialType':
src/vdbeaux.c:1440: warning: integer constant is too large for "long" type
src/vdbeaux.c:1440: warning: integer constant is too large for "long" type
|
2004-Aug-30 16:06:52 by anonymous:
I had the same problem in Solaris.
2004-Dec-09 09:31:46 by anonymous:
I have the same problem compiling Sqlite 3.0.8 on Mac OS X 10.3.6.
I got rid of the warnings by added the LL suffix to the offending constants.
Since the line numbers producing the warnings have changed over time, below is a list that includes the statements, which might help the Sqlite developer looking for them in the current code:
vdbeaux.c:1496: integer constant is too large for "long" type
vdbeaux.c:1496: integer constant is too large for "long" type
if( i>=-140737488355328L && i<=140737488355328L ) return 5;
vdbe.c:2867: integer constant is too large for "long" type
if( v==0x7fffffffffffffff ){
vdbe.c:2874: integer constant is too large for "long" type
if( v==0x7fffffffffffffff ){
util.c:799: integer constant is too large for "long" type
if( v & 0xff00000000000000 ){
|
|
824 |
new
|
active
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Jul
|
|
5
|
4
|
StrSum - new build-in aggreate function suggestion
|
edit |
StrSum(string aggregatingFiels, string separator ) - aggregate function.
create table x (y);
insert into x(y) values ('one');
insert into x(y) values ('two');
insert into x(y) values ('three');
insert into x(y) values ('four');
insert into x(y) values ('five');
select StrSum(y, ' / ') from x == 'one / two / three / four / five'
I have coded this function myself into my wrapper but I think this function will be usefull for all users :) |
|
823 |
new
|
active
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Jul
|
|
5
|
4
|
absent VERSIONINFO into any Win32 DLL
|
edit |
Hi! There are sqlite_version API entry BUT I need VERSIONINFO resource into WIN32 DLL to create CAB-file witch will replace older shared sqliteX.dll with new versions automaticaly |
2004-Jul-26 12:49:33 by drh:
I have no idea what a VERSIONINFO resource is.
2004-Jul-26 15:19:14 by dougcurrie:
VERSIONINFO is built with the resource compiler (mingw handles this).
Here's how VIM added it: http://www.math.technion.ac.il/pub/vim/patches/6.1.374
Here some MS docn: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tools/tools/versioninfo_resource.asp
Maybe someday I'll have time for adding this, but not now. -- e |
|
822 |
code
|
active
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Jul
|
drh
|
1
|
4
|
port of sqlite to dos with djgpp + small general bugfixes
|
edit |
here is a diff to be applied on sqlite 2.8.14 to make it work with djgpp.
some of the fixes are needed for general purpose, such as relative path handling, and bypass of history and readline wherever not present.
anyway, i see no harm to apply this patch to mainstream sqlite. port for version 2.8.15 will come soon.
best regards,
alex <alexbodn@012.net.il> |
|
816 |
doc
|
active
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Jul
|
|
1
|
4
|
sqlite3_changes - absent in sqlitedll-3_0_2.zip
|
edit |
trying to make COM-Wrapper for SQLite in VC++ 6.0. can't find such entry point in any 3.x precompiled win32 dll |
|
815 |
build
|
active
|
2004 Jul
|
anonymous
|
|
2004 Jul
|
|
2
|
1
|
SQLite3.dll exports
|
edit |
The SQLite3.dll does not export all of its documented api. I.e. SQLite_gettable/freetable is not exported. This is a similar error as before and can be easily fixed (I think) since I can download a correct dll from www.squeakycode.net (one of the other sqlite users). Since the exports are mentioned in the .def file I think there might be an error in the build of the windows dll. (without tcl bindings). I like to deploy my (freeware) delphi components for version 3, but they require the squeakycode dll. This is a nice temporarely solution but I need a more structural one before I can deploy.
Best regards,
Albert Drent
aducom software |
|
802 |
warn
|
active
|
2004 Jul
|
anonymous
|
|
2004 Jul
|
anonymous
|
1
|
1
|
Unable to compile the sqlite
|
edit |
- compilation of many modules produces warnings, warnings, warnings, warnings ...................... warnings.
- Borland 5.02 is not able to compile some modules at all (compiler internal error). |
|
798 |
code
|
active
|
2004 Jul
|
anonymous
|
Unknown
|
2004 Jul
|
|
1
|
1
|
Unable to run tests on Tru64 bit Linux platform
|
edit |
I was able to compile SQLite 3.0.2 on a RedHat 64-bit Linux system; however, when running the tests I would get a segmentation fault when executing a blob test. I was wondering if anyone has attempted to build SQLite for a 64-bit architecture and run all tests successfully. If so I was hoping to get any configuration parameters needed. |
|
797 |
new
|
active
|
2004 Jul
|
anonymous
|
Parser
|
2004 Jul
|
|
4
|
3
|
require basic named subquery / WITH sql support
|
edit |
This ticket, derived from a recent discussion list posting, is a request for simple named subquery / WITH sql support. The level of support that I'm looking for should only require and update to the "Parser" subsystem, or possibly "CodeGen" too.
The fundamental implementation of how SQLite handles subqueries is not changed at all. You still execute the subqueries exactly once, prior to the main queries, as you do now.
The subset would be compliant with the SQL-1999 standard. As an additional reference, you can see SQL-2003 Foundation, 7.13 "<query expression>" (p351).
What I want is to be able to make a query like this:
WITH
first_subq AS (
SELECT id FROM foo WHERE name LIKE '%zoo%'
),
second_subq AS (
SELECT a, b, COUNT(c) AS d FROM bar GROUP BY a, b
)
SELECT *
FROM second_subq AS s INNER JOIN baz AS z ON z.a = s.a AND z.b = s.b
WHERE (z.opt1 IN first_subq OR z.opt2 IN first_subq) AND s.d >= z.boo
ORDER BY s.d DESC
One of the main advantages I cite is that SQL code is a lot cleaner and easier to understand. You can do within complex selects the same thing you can do in complex routines, which is akin to breaking out blocks into named subroutines.
This advantage is particularly seen where the same subquery would be getting invoked multiple times within the main query (see example). It now does not have to be declared multiple times, leading to shorter and easier to parse SQL, and the code runs faster, because the subquery only has to be run once. As such, developers can also reduce some use of explicit temporary tables.
This ticket is not requesting support for passing arguments to the named subqueries, as SQL-1999 allows, nor having support for recursive named subqueries (those that invoke themselves). Those would be nice some day, but would require more substantial changes to SQLite, such as invoking subqueries during the main query, and multiple times, rather than in advance. So I am not requesting those today. (Note that, should you ever decide to support recursive subqueries later, it should be done the SQL-1999 way, and not Oracle 8's way of start-with connect-by.)
In summary, I propose that in the long run, named subqueries should be a lot more useful than inlined subqueries, both for programmer efficiency, and because SQLite itself has less work to do when parsing or optimizing sql queries; the programmer can tell you ways to optimize by reducing redundancy.
Thank you. -- Darren Duncan
P.S. On the list, Dennis Cote also showed a desire for the same features, saying:
I also believe support for named subqueries would be a valuable addition to
SQLite.
I have previously advocated for this feature on the list as well, though I
called it a WITH clause rather than a named subquery. It seems to me to be a
fairly simple extension to SQLite that would allow the user to manually
perform common sub-expression elimination optimizations. These optimizations
are done automatically by other, not so lite, database engines. I also think
they make the resulting SQL select statements easier to read. |
|
783 |
code
|
active
|
2004 Jun
|
anonymous
|
Unknown
|
2004 Jun
|
|
3
|
3
|
Build on MAC with -DSQLITE_DEBUG=1 compile error
|
edit |
MacOS 10.3.4
gcc 3.3
Compileing with -DSQLITE_DEBUG=1 gives following error
./libtool --mode=compile gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DSQLITE_DEBUG=1 -I. -I../sqlite/src -DTHREADSAFE=0 -c ../sqlite/src/os_unix.c
gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DSQLITE_DEBUG=1 -I. -I../sqlite/src -DTHREADSAFE=0 -c ../sqlite/src/os_unix.c -fno-common -DPIC -o .libs/os_unix.o
../sqlite/src/os_unix.c: In function `sqlite3OsRead':
../sqlite/src/os_common.h:31: error: inconsistent operand constraints in an `asm'
make: *** [os_unix.lo] Error 1 |
|
780 |
warn
|
active
|
2004 Jun
|
anonymous
|
Unknown
|
2004 Jun
|
|
3
|
2
|
Builkd gice src code errors on MacOS
|
edit |
Building/testing MacOSX 10.3.4
gcc 3.3
Building sqlite & test gave error "constant too long for long"
util.c line 1180
vdbe.c lines 2979 and 2986
vdbeaux.c line 1482 (twice)
running full test gave following errors
printf-1.11.1...
Expected: [Three integers: -2 fffffffffffffffe 1777777777777777777776]
Got: [Three integers: -1 fffffffffffffffe 1777777777777777777776]
printf-1.11.2...
Expected: [Three integers: ( -2) (fffffffffffffffe) (1777777777777777777776)]
Got: [Three integers: ( -1) (fffffffffffffffe) (1777777777777777777776)]
printf-1.11.3...
Expected: [Three integers: (-2 ) (fffffffffffffffe) (1777777777777777777776)]
Got: [Three integers: (-1 ) (fffffffffffffffe) (1777777777777777777776)]
printf-1.11.4...
Expected: [Three integers: ( -2) (fffffffffffffffe) (1777777777777777777776)]
Got: [Three integers: ( -1) (fffffffffffffffe) (1777777777777777777776)]
printf-1.11.5...
Expected: [Three integers: (-00002) (fffffffffffffffe) (1777777777777777777776)]
Got: [Three integers: (-00001) (fffffffffffffffe) (1777777777777777777776)]
printf-1.11.6...
Expected: [Three integers: ( -2) (fffffffffffffffe) (1777777777777777777776)]
Got: [Three integers: ( -1) (fffffffffffffffe) (1777777777777777777776)]
printf-1.12.1...
Expected: [Three integers: -5 fffffffffffffffb 1777777777777777777773]
Got: [Three integers: -1 fffffffffffffffb 1777777777777777777773]
printf-1.12.2...
Expected: [Three integers: ( -5) (fffffffffffffffb) (1777777777777777777773)]
Got: [Three integers: ( -1) (fffffffffffffffb) (1777777777777777777773)]
printf-1.12.3...
Expected: [Three integers: (-5 ) (fffffffffffffffb) (1777777777777777777773)]
Got: [Three integers: (-1 ) (fffffffffffffffb) (1777777777777777777773)]
printf-1.12.4...
Expected: [Three integers: ( -5) (fffffffffffffffb) (1777777777777777777773)]
Got: [Three integers: ( -1) (fffffffffffffffb) (1777777777777777777773)]
printf-1.12.5...
Expected: [Three integers: (-00005) (fffffffffffffffb) (1777777777777777777773)]
Got: [Three integers: (-00001) (fffffffffffffffb) (1777777777777777777773)]
printf-1.12.6...
Expected: [Three integers: ( -5) (fffffffffffffffb) (1777777777777777777773)]
Got: [Three integers: ( -1) (fffffffffffffffb) (1777777777777777777773)]
printf-1.13.1...
Expected: [Three integers: -10 fffffffffffffff6 1777777777777777777766]
Got: [Three integers: -1 fffffffffffffff6 1777777777777777777766]
printf-1.13.2...
Expected: [Three integers: ( -10) (fffffffffffffff6) (1777777777777777777766)]
Got: [Three integers: ( -1) (fffffffffffffff6) (1777777777777777777766)]
printf-1.13.3...
Expected: [Three integers: (-10 ) (fffffffffffffff6) (1777777777777777777766)]
Got: [Three integers: (-1 ) (fffffffffffffff6) (1777777777777777777766)]
printf-1.13.4...
Expected: [Three integers: ( -10) (fffffffffffffff6) (1777777777777777777766)]
Got: [Three integers: ( -1) (fffffffffffffff6) (1777777777777777777766)]
printf-1.13.5...
Expected: [Three integers: (-00010) (fffffffffffffff6) (1777777777777777777766)]
Got: [Three integers: (-00001) (fffffffffffffff6) (1777777777777777777766)]
printf-1.13.6...
Expected: [Three integers: ( -10) (fffffffffffffff6) (1777777777777777777766)]
Got: [Three integers: ( -1) (fffffffffffffff6) (1777777777777777777766)]
printf-1.14.1...
Expected: [Three integers: -99 ffffffffffffff9d 1777777777777777777635]
Got: [Three integers: -1 ffffffffffffff9d 1777777777777777777635]
printf-1.14.2...
Expected: [Three integers: ( -99) (ffffffffffffff9d) (1777777777777777777635)]
Got: [Three integers: ( -1) (ffffffffffffff9d) (1777777777777777777635)]
printf-1.14.3...
Expected: [Three integers: (-99 ) (ffffffffffffff9d) (1777777777777777777635)]
Got: [Three integers: (-1 ) (ffffffffffffff9d) (1777777777777777777635)]
printf-1.14.4...
Expected: [Three integers: ( -99) (ffffffffffffff9d) (1777777777777777777635)]
Got: [Three integers: ( -1) (ffffffffffffff9d) (1777777777777777777635)]
printf-1.14.5...
Expected: [Three integers: (-00099) (ffffffffffffff9d) (1777777777777777777635)]
Got: [Three integers: (-00001) (ffffffffffffff9d) (1777777777777777777635)]
printf-1.14.6...
Expected: [Three integers: ( -99) (ffffffffffffff9d) (1777777777777777777635)]
Got: [Three integers: ( -1) (ffffffffffffff9d) (1777777777777777777635)]
printf-1.15.1...
Expected: [Three integers: -100 ffffffffffffff9c 1777777777777777777634]
Got: [Three integers: -1 ffffffffffffff9c 1777777777777777777634]
printf-1.15.2...
Expected: [Three integers: ( -100) (ffffffffffffff9c) (1777777777777777777634)]
Got: [Three integers: ( -1) (ffffffffffffff9c) (1777777777777777777634)]
printf-1.15.3...
Expected: [Three integers: (-100 ) (ffffffffffffff9c) (1777777777777777777634)]
Got: [Three integers: (-1 ) (ffffffffffffff9c) (1777777777777777777634)]
printf-1.15.4...
Expected: [Three integers: ( -100) (ffffffffffffff9c) (1777777777777777777634)]
Got: [Three integers: ( -1) (ffffffffffffff9c) (1777777777777777777634)]
printf-1.15.5...
Expected: [Three integers: (-00100) (ffffffffffffff9c) (1777777777777777777634)]
Got: [Three integers: (-00001) (ffffffffffffff9c) (1777777777777777777634)]
printf-1.15.6...
Expected: [Three integers: ( -100) (ffffffffffffff9c) (1777777777777777777634)]
Got: [Three integers: ( -1) (ffffffffffffff9c) (1777777777777777777634)]
printf-1.16.1...
Expected: [Three integers: -9999999 ffffffffff676981 1777777777777731664601]
Got: [Three integers: -1 ffffffffff676981 1777777777777731664601]
printf-1.16.2...
Expected: [Three integers: (-9999999) (ffffffffff676981) (1777777777777731664601)]
Got: [Three integers: ( -1) (ffffffffff676981) (1777777777777731664601)]
printf-1.16.3...
Expected: [Three integers: (-9999999) (ffffffffff676981) (1777777777777731664601)]
Got: [Three integers: (-1 ) (ffffffffff676981) (1777777777777731664601)]
printf-1.16.4...
Expected: [Three integers: (-9999999) (ffffffffff676981) (1777777777777731664601)]
Got: [Three integers: ( -1) (ffffffffff676981) (1777777777777731664601)]
printf-1.16.5...
Expected: [Three integers: (-9999999) (ffffffffff676981) (1777777777777731664601)]
Got: [Three integers: (-00001) (ffffffffff676981) (1777777777777731664601)]
printf-1.16.6...
Expected: [Three integers: (-9999999) (ffffffffff676981) (1777777777777731664601)]
Got: [Three integers: ( -1) (ffffffffff676981) (1777777777777731664601)]
misuse-1.1...
Error: invalid command name "sqlite_exec_printf"
misuse-1.2...
Error: invalid command name "sqlite_exec_printf"
misuse-1.3...
Error: invalid command name "sqlite_create_function"
misuse-1.4...
Error: invalid command name "sqlite_exec_printf"
misuse-1.5...
Error: invalid command name "sqlite_exec_printf"
misuse-1.6... Ok
misuse-2.1... Ok
misuse-2.2...
Error: invalid command name "sqlite_exec_printf"
misuse-2.3...
Expected: [1 {library routine called out of sequence}]
Got: [1 {invalid command name "sqlite_create_function"}]
misuse-2.4...
Error: invalid command name "sqlite_exec_printf"
misuse-2.5...
Expected: [1 {library routine called out of sequence}]
Got: [0 {1 2}]
misuse-3.1... Ok
misuse-3.2...
Error: invalid command name "sqlite_exec_printf"
misuse-3.3...
Expected: [1 {library routine called out of sequence}]
Got: [1 {invalid command name "sqlite_create_aggregate"}]
misuse-3.4...
Error: invalid command name "sqlite_exec_printf"
misuse-3.5...
Expected: [1 {library routine called out of sequence}]
Got: [0 {1 2}]
misuse-4.1... Ok
misuse-4.2...
Error: invalid command name "sqlite_exec_printf"
misuse-4.3...
Expected: [1 {library routine called out of sequence}]
Got: [1 {invalid command name "sqlite_close"}]
misuse-4.4...
Error: invalid command name "sqlite_exec_printf"
misuse-4.5...
Expected: [1 {library routine called out of sequence}]
Got: [0 {1 2}]
misuse-5.1... Ok
misuse-5.2...
Error: invalid command name "sqlite_exec_printf"
misuse-5.3...
Error: invalid command name "sqlite_exec_printf"
Skipping malloc tests: not compiled with -DMEMORY_DEBUG...
59 errors out of 22454 tests
Failures on these tests: crash-1.2 crash-1.4 crash-1.5 printf-1.11.1 printf-1.11.2 printf-1.11.3 printf-1.11.4 printf-1.11.5 printf-1.11.6 printf-1.12.1 printf-1.12.2 printf-1.12.3 printf-1.12.4 printf-1.12.5 printf-1.12.6 printf-1.13.1 printf-1.13.2 printf-1.13.3 printf-1.13.4 printf-1.13.5 printf-1.13.6 printf-1.14.1 printf-1.14.2 printf-1.14.3 printf-1.14.4 printf-1.14.5 printf-1.14.6 printf-1.15.1 printf-1.15.2 printf-1.15.3 printf-1.15.4 printf-1.15.5 printf-1.15.6 printf-1.16.1 printf-1.16.2 printf-1.16.3 printf-1.16.4 printf-1.16.5 printf-1.16.6 printf-5.2 misuse-1.1 misuse-1.2 misuse-1.3 misuse-1.4 misuse-1.5 misuse-2.2 misuse-2.3 misuse-2.4 misuse-2.5 misuse-3.2 misuse-3.3 misuse-3.4 misuse-3.5 misuse-4.2 misuse-4.3 misuse-4.4 misuse-4.5 misuse-5.2 misuse-5.3
make: *** [fulltest] Error 1
[ |
|
763 |
code
|
active
|
2004 Jun
|
anonymous
|
Unknown
|
2004 Jun
|
|
5
|
4
|
tclsqlite.dll not showing the correct version
|
edit |
The TCL binding of SQLite indicates that the current binary version available for download is 2.0 (determined with the "package require sqlite" command). I suppose that's because tclsqlite.c has the following statement in it: tcl_PkgProvide(interp, "sqlite", "2.0");
Is it possible that the binary distribution of tclsqlite.dll is really version 2.8 and NOT 2.0? It could be that the reference to version # 2.0 in tclsqlite.c needs to be corrected to some other number! |
|
762 |
todo
|
active
|
2004 Jun
|
anonymous
|
Unknown
|
2004 Jun
|
anonymous
|
4
|
3
|
Windows pre-compiled binaries are 2.8.13, not 2.8.14
|
edit |
Windows pre-compiled binaries are 2.8.13, not 2.8.14 |
|
755 |
new
|
active
|
2004 Jun
|
anonymous
|
TclLib
|
2004 Jun
|
drh
|
5
|
2
|
Adding aggregate function to the tcl binding
|
edit |
The diff against tclsqlite.c to solve the problem can be also submitted by email |
|
754 |
code
|
active
|
2004 Jun
|
anonymous
|
Shell
|
2004 Jun
|
drh
|
2
|
3
|
problem opening a dbfile in the upper directory (../dbname)
|
edit |
there is a problem in the calculation of a full path name based on a relative path name in an uproot location (../).
i have fixed this during my porting to dos, and the relevant diff is at http://www.sqlite.org/cvstrac/tktview?tn=524.
best regards
alex |
|
752 |
doc
|
active
|
2004 Jun
|
anonymous
|
|
2004 Jun
|
|
4
|
4
|
FAQ-Entry: How to escape quotes
|
edit |
Ticket #497 (not able to escape quotes) should really be mentioned in the FAQ. I'm sure many users (including me...) try to escape quotes using a backslash (C-style, like MySQL accepts it). |
|
748 |
new
|
active
|
2004 May
|
anonymous
|
|
2004 May
|
|
3
|
3
|
option to allow ignoring trailing whitespace in selects
|
edit |
According to the SQL-92, when comparing strings using the = operator, the strings are supposed to be padded out with spaces to the same length. For example, a char(5) column contains 'abc ' (two spaces at the end) and you perform
select * from table1 where field1 = 'abc'
This should match that 'abc ' row. This is because both terms would have been padded with spaces to be matching lengths before comparison.
SQLite should at least have the option to turn on SQL-92 compliant padding. |
|
746 |
warn
|
active
|
2004 May
|
anonymous
|
CodeGen
|
2004 May
|
anonymous
|
5
|
5
|
How can I make sqlite support serial term?
|
edit |
How can I make sqlite support "serial" term?
I just put some code into build.c and this is the cord that I changed.
void sqlite3AddPrimaryKey(Parse *pParse, IdList *pList, int onError){
...
if( zType && ( sqlite3StrICmp(zType, "INTEGER")==0 ||
sqlite3StrICmp(zType, "SERIAL")==0 )
){
...
void sqlite3AddColumnType(Parse *pParse, Token *pFirst, Token *pLast){
Table *p;
int iCol, i, j;
int n;
char *z, **pz, *t=0;
Column *pCol;
if( (p = pParse->pNewTable)==0 ) return;
iCol = p->nCol-1;
if( iCol<0 ) return;
pCol = &p->aCol[iCol];
pz = &pCol->zType;
n = pLast->n + Addr(pLast->z) - Addr(pFirst->z);
sqliteSetNString(pz, pFirst->z, n, 0);
z = *pz;
if( z==0 ) return;
for(i=j=0; z[i]; i++){
int c = z[i];
if( isspace(c) ) continue;
z[j++] = c;
}
z[j] = 0;
if( pParse->db->file_format>=4 ){
pCol->sortOrder = sqliteCollateType(z, n);
}else{
pCol->sortOrder = SQLITE_SO_NUM;
}
t = p->aCol[iCol].zType;
if( t && sqliteStrICmp(t, "SERIAL")==0 ){
if( p->iPKey == -1 ) p->iPKey = i;
else {
/* it has already "INTEGER PRIMARY KEY" or "SERIAL" */
sqliteErrorMsg(pParse,
"table \"%s\" has more than one serial type column", p->zName);
}
}
}
the result is "<column-name> serial primary key" is OK, but "<column-name> serial" has a bug. the program exits abnormally.
I just want to change it for my own. anybody give me some advice. thanks. |
2004-May-24 12:30:21 by anonymous:
1.Add following code to the end of sqliteAddColumnType function in build.c
if( z && sqliteStrICmp(z, "SERIAL")==0 ){
if( p->iPKey == -1 ) p->iPKey = iCol;
else {
/* it has already "INTEGER PRIMARY KEY" or "SERIAL" */
sqliteErrorMsg(pParse,
"table \"%s\" has more than one serial type column", p->zName);
}
}
2. Change some code of sqliteAddPrimaryKey function so that it looks like this
if( pParse->db->file_format>=1 &&
zType && ( sqliteStrICmp(zType, "INTEGER")==0 ||
sqliteStrICmp(zType, "SERIAL")==0 )
){
2004-May-24 13:16:08 by anonymous:
Ups... the second code above has a bug.
correct one is this:
if( pParse->db->file_format>=1 &&
zType && ( sqliteStrICmp(zType, "INTEGER")==0 ||
sqliteStrICmp(zType, "SERIAL")==0 )
){
/* If there is already a serial */
if( pTab->iPKey>=0 && sqliteStrICmp(zType, "INTEGER")==0 ){
sqliteErrorMsg(pParse,
"table \"%s\" has more than one serial column type", pTab->zName);
goto primary_key_exit;
}
the result :
C:\test>sqlite.exe test.db
SQLite version 2.8.13
Enter ".help" for instructions
sqlite> create table t1 (id integer primary key, t text, i int);
sqlite> insert into t1 values (null, 'a', 1);
sqlite> insert into t1 values (null, 'b', 2);
sqlite> select * from t1;
1|a|1
2|b|2
sqlite> create table t2 (id serial primary key, t text, i int);
sqlite> insert into t2 values (null, 'a', 1);
sqlite> insert into t2 values (null, 'b', 2);
sqlite> select * from t2;
1|a|1
2|b|2
sqlite> create table t3 (id serial, t text, i int);
sqlite> insert into t3 values (null, 'a', 1);
sqlite> insert into t3 values (null, 'b', 2);
sqlite> select * from t3;
1|a|1
2|b|2
sqlite> create table t4 (id serial, t text primary key, i int);
sqlite> insert into t4 values (null, 'a', 1);
sqlite> insert into t4 values (null, 'b', 2);
sqlite> insert into t4 values (null, 'b', 2);
SQL error: column t is not unique
sqlite> select * from t4;
1|a|1
2|b|2
sqlite> create table t5 (id serial, t text, i integer primary key);
SQL error: table "t5" has more than one serial column type
sqlite> create table t5 (id serial, t text, i serial primary key);
SQL error: table "t5" has more than one serial type column
sqlite> create table t5 (id serial, t text, i serial);
SQL error: table "t5" has more than one serial type column
sqlite> create table t5 (id integer primary key, t text, i serial);
SQL error: table "t5" has more than one serial type column
sqlite>
|
|
744 |
code
|
active
|
2004 May
|
anonymous
|
BTree
|
2004 May
|
anonymous
|
2
|
2
|
make test seg faults on x86_64 Linux
|
edit |
I'm running the 64 bit version of Gentoo Linux on an AMD Opteron
system. Ordinarily I'd install software with "emerge <package>" but
"emerge sqlite" only gives me version 2.8.11. I downloaded the
2.8.13 source and did the usual ./configure; make; make test. The
configure and make steps went OK but make test fails half way
through:
bind-1.99... Ok
btree-1.1... Ok
btree-1.1.1... Ok
btree-1.2... Ok
btree-1.3... Ok
btree-1.4... Ok
btree-1.4.1... Ok
btree-1.5... Ok
btree-1.6...make: *** [test] Segmentation fault
The code was built with GCC 3.3.3.
As sqlite is a known 'emerge' option for 64 bit Gentoo I'm guessing
sqlite is known to work on 64 bit platforms?
I didn't mark this as a severe error because in theory I should be
able to create a statically linked executable on a 32 bit linux
system and run this on the Opteron box. Haven't been successful at that yet however. |
2004-May-25 04:35:32 by anonymous:
It's pretty clear that sqlite has never been compiled on a 64-bit system, much less run. The test problems are fatal bugs caused by type conversions between 64-bit and 32-bit values, including truncating pointers and other sins. The fixes look quite involved. |
|
742 |
new
|
active
|
2004 May
|
anonymous
|
VDBE
|
2004 May
|
anonymous
|
5
|
5
|
database is locked
|
edit |
when I tried to access your site, sometimes I could see the message like "the database is locked", and could not access.
I think it's because of the so called "SQLITE_BUSY". if SQLITE_BUSY happens, can't we just access the website? if so, it would be nice to have an waiting time option, that is if SQLITE_BUSY happens the vdbe waits a little time and tries again till the appointed times even after if it is impossible, then show "database is locked". How about it? |
2004-May-19 10:03:54 by drh:
The SQLite website is database driven. Not every page requires
database access, but many do. If an SQLITE_BUSY occurs, the request
is automatically retried multiple times. But if SQLITE_BUSY keeps
occurring, the request will eventually timeout.
www.sqlite.org runs on User-Mode Linux (UML) partition at
http://www.linode.org/. It is a Linode-64 (at the moment) meaning
that there are 31 other linux instances running on the same CPU.
Sometimes one or more of the other 32 linux instances get really
busy and clog up the shared disk I/O channel, resulting in long
delays for disk access. When this happens and there are multiple
people trying to access the data at the same time, timeouts can
occur. |
|
741 |
new
|
active
|
2004 May
|
anonymous
|
CodeGen
|
2004 May
|
anonymous
|
5
|
5
|
command tool does not support history
|
edit |
if command tool support history, it would be great. windows supports its own history but on linux system command tool doesn't support history. |
2004-May-23 18:07:31 by anonymous:
The sqlite command on linux and cygwin have history (internal to sqlite at least).
This capability comes from readline if it is installed on your systems. For some more details including libedit and OSX support see ReadLine |
|
739 |
new
|
active
|
2004 May
|
anonymous
|
Unknown
|
2004 May
|
danielk1977
|
3
|
1
|
Suggestion speed query
|
edit |
Suggestion
If possible cache the result of query similar or identical.
For example I have a table of 100000 record.
I do a query with where clausal, this takes 2 seconds.
Ok, next time I remake the same query, I spend self time. Is advantageous?
No, my idea is to cache results until there are not changes or update.
The cache has to be done with caution, invisible for user and without compromise the performance.
For example of query result of 100 rows, I must wait another time the time needed to obtain the result. It is not fine!
Piero Romani |
|
738 |
new
|
active
|
2004 May
|
anonymous
|
|
2004 May
|
danielk1977
|
4
|
1
|
Sort order array in memory
|
edit |
Order is a problem when I have in memory a result of a long query, because I must order the array of the result.
For example in Ado I can use recordset.order . Is it possible with sqlite?
WHere is the problem?
I must do a query very time long ; if I want to sort the array that give me sqlite, I must remake the query. IT is very bad :).
This because I use in virtual listview the array.
char** paszResults for example
Very thanks |
|
737 |
new
|
active
|
2004 May
|
anonymous
|
Shell
|
2004 May
|
anonymous
|
3
|
3
|
xml export
|
edit |
Export a sql statement to an oracle-style export xml.
<ROWSET>
<ROW>
<cost>30.0</cost>
<quant>30</quant>
</ROW>
...
</ROWSET>
This can be done in shell.c following the xthml-table model except without the field escapes (in case we are putting xml in a column).Sqlite will not be able to say what xml a column should have without some kind of schema integration, which seems too complex. |
|
736 |
new
|
active
|
2004 May
|
anonymous
|
|
2004 May
|
|
4
|
4
|
Would like to be able to list the LAST 10 lines of a query
|
edit |
This falls outside the scope of pretty much everything, but still...
I'd like to be able to get the last 10 lines of a query. You may argue (as the mySQL people did about 2 years back) that I can just reverse the ORDER BY direction, but it wasn't a good argument then either, because I may not be setting a specific order (I call this the natural database order).
SELECT * FROM myTable LIMIT -10
makes good sense, especially as it is usually the last n items that a person tends to be most interested in. Since, as far as I know, negative limits are an undefined area, why not stake your claim to SQL fame and introduce something that will be wildly popular?
Specifically:
LIMIT -n should return the last n rows of a query.
LIMIT k, -n should return the n rows just before the kth row
LIMIT -k, n should return the n rows starting k rows before the end
LIMIT -k, -n should return the kth row from the end till n rows before the end.
There is good precedent for this in PHP and javascript string handling, and PHP array handling (see especially http://php.net/array_slice)
Anyway, thanks for listening,
Csaba Gabor |
2004-May-13 16:53:56 by drh:
"Natural" database order in SQLite is equivalent to "ORDER BY rowid".
So you you can say:
SELECT whatever FROM whatever ORDER BY rowid DESC LIMIT 10;
And it will do what you want. And it is very fast at this.
2004-May-14 02:10:20 by anonymous:
Cool, that is great, thanks very much.
If I understand this correctly, whenever a new insert is made (regardless of whether the location used is that of a deleted row), there is an internal rowid that always gets incremented (and would overwrite any existing rowid if a deleted row was being reused). This is, therefore, essentially an inherent PRIMARY KEY with the restriction that it can't be changed. But it could be used to access and update any existing row. Very handy, thanks.
I have a related question/comment. There is a function last_insert_rowid(), but in the case of ignore (or abort) this value does not change (and why should it, after all?). But I may be interested in finding the location that the conflict occurred at. (For example, in my current application, I am entering edges in a graph. That is, I first enter the two vertices that define an edge by doing an INSERT. If the vertices already exist, however, it would be improper to do a REPLACE because previous vertex references would become invalid. No, I should really get the location of the existing vertes causing the conflict). Of course, I could manually wade through all the indeces checking to see if/where there is a conflict, but this could seriously increase my access time (we're talking thousands to millions of points) but is there not a shorthand way to find out last_attemptedInsert_row()? - well, you get the idea.
Finally, since this is too tiny to make a separate thread, the last "not" of the first paragraph of text for the insert command (http://sqlite.org/lang.html#insert) should be "no". Also, I would remark that last sentence of the second paragraph for ATTACH DATABASE (http://sqlite.org/lang.html#attach) running into the third paragraph is confusing to me because the first clause of the third paragraph is repeating part of what that previous sentence was saying. Why not remove the entire first clause in the third paragraph and merge the remaining paragraph with the second one.
Csaba Gabor |
|
735 |
code
|
active
|
2004 May
|
anonymous
|
Shell
|
2004 May
|
|
4
|
3
|
.sqliterc not processed if running on a driver other than C:
|
edit |
In shell.c there is a snippet that reads:
if (!home_dir) {
home_dir = getenv("HOMEPATH"); /* Windows? */
}
The HOMEPATH environment variable does not include the drive letter and needs to be concatenated with the HOMEDRIVE environment variable. |
2004-May-12 14:43:40 by anonymous:
That should read "drive" in the title, not "driver" |
|
734 |
build
|
active
|
2004 May
|
anonymous
|
TclLib
|
2004 May
|
|
4
|
4
|
libtclsqlite.xxx not built by default make all target
|
edit |
Not a big deal but the Quickstart documentation assumes that the libtclsqllite.so (or
dylib (macosx) in my case) is made & installed but the default make all target
doesn't make it. You have to explicitly specify that to be made. Although, the
'Building from Source' documentation page does say that make all makes
just sqlite and the basic libsqlite.{a, so, whatever} in the comment.
Just a bit confusing. |
|
732 |
doc
|
active
|
2004 May
|
anonymous
|
|
2004 May
|
|
5
|
5
|
Odd columns lead to odder selections
|
edit |
This is not (necessarily) a bug, just some documentation about escaping funny column names. The idea is that if you make a column name having a quote character of one type (single or double), to make the name most easily, you surround the proposed column name with the other types of quotes. So far, so good, and OK, I agree that you really have no business doing this in the first place.
However, to reference this column, you should be a little more careful. Normally this would mean specifying it exactly as you had in the CREATE TABLE statement. This does not work on the first column of the example below (sqlite just treats it as constant text). In fact, you should double quote the column name and then escape the inner part as necessary, where this escaping means to double up the internal quotes. Here's an example to illustrate. Notice that when outer single quotes are used, sqlite does not match up the columns.
sqlite> create table test5 ('One"Two' integer, "Two'One" integer);
sqlite> insert into test5 values (1,2);
sqlite> insert into test5 values (3,4);
sqlite> select "One""Two" from test5;
1
3
sqlite> select 'One"Two' from test5;
One"Two
One"Two
sqlite> select "Two'One" from test5;
2
4
sqlite> select 'Two''One' from test5;
Two'One
Two'One
Csaba Gabor |
2004-May-21 22:10:06 by anonymous:
I'd just like to add that if you prefix columns by the table name, then things seem to work as expected. Thus,
select test5.'One"Two' from test5;
yields the expected result of:
1
3
Csaba |
|
727 |
event
|
active
|
2004 May
|
anonymous
|
|
2004 May
|
|
4
|
3
|
"wrong" affected row value returned by REPLACE
|
edit |
When updating an existing row using the REPLACE syntax sqlite returns 1. This makes it impossible to know of an existing row was affected by the REPLACE call (1: no existing call was affected; 2: an existing row was affected).
MySQL (which I assume was used as the example of the REPLACE syntax) returns a more hopeful 2 in this case. This may be due to their implementation which does an INSERT and a conditional DELETE if a contraint violation was detected due to the INSERT. |
|
726 |
new
|
active
|
2004 May
|
anonymous
|
Parser
|
2004 May
|
anonymous
|
5
|
5
|
As to single quote
|
edit |
Hello
when we insert single quote(') into the query, currently it should be added a more single quote. I think it is not good for most of program espcially in database system uses backslash(\) not single quote.
To be appliable to other program, would you change this? |
2004-May-07 15:31:06 by anonymous:
if you don't have any plan, I think putting an escaping option will be great. thanks. |
|
725 |
new
|
active
|
2004 May
|
anonymous
|
|
2006 Aug
|
anonymous
|
5
|
5
|
Implement ATTACH LIB comand
|
edit |
It would be nice to mantain some functions in separate library, and be able to reuse in command line sqlite or in other projects.
Syntax should be something like:
ATTACH LIB "some_lib_name"
some_lib_name should export function like
RegisterSQLiteFunctions |
|
724 |
new
|
active
|
2004 May
|
anonymous
|
|
2004 May
|
|
4
|
5
|
VACUUM resets settings for the current session
|
edit |
All settings tuned in current session are reverted to default values after VACUUM command execution.
Example:
sqlite> PRAGMA synchronous;
1
sqlite> PRAGMA synchronous=off;
sqlite> PRAGMA synchronous;
0
sqlite> VACUUM;
sqlite> PRAGMA synchronous;
1
I am convinced that this behavior is defined by VACUUM command implementation which reopens the database in the end.
However, I think that this is an implementation detail and should not affect the session state. |
|
723 |
new
|
active
|
2004 May
|
anonymous
|
Unknown
|
2004 May
|
|
5
|
4
|
BatchScript: Example windows batch script for creating databases.
|
edit |
echo CREATE TABLE employee (id, name); | sqlite db
echo INSERT INTO employee VALUES (1, 'Adam'); | sqlite db
echo INSERT INTO employee VALUES (2, 'Eve'); | sqlite db |
|
721 |
code
|
active
|
2004 May
|
anonymous
|
Shell
|
2004 May
|
drh
|
3
|
2
|
empty .databases information
|
edit |
in file shell.c around line 570 the callback_data structure needs to be added:
data.cnt = 0;
so the column widths are correctly used. or else, it will display empty lines.
this problem is visible after executing one sql command |
|
720 |
event
|
active
|
2004 May
|
anonymous
|
|
2004 May
|
|
1
|
1
|
Write problem on MS Windows 98
|
edit |
I've installed Python 2.3 and PDO on my Win98 machine and use SQLite as my DB. When script is running data is writing into tables, but after it quit there is no data in tables.
The same script I run on Linux and Win98, but on Win98 it does not "leave" data in tables. On Linux all is right.
(sorry for my English :) |
|
718 |
new
|
active
|
2004 May
|
anonymous
|
|
2004 May
|
anonymous
|
2
|
2
|
Case insensitive index ?
|
edit |
It does not seem to be possible to create case-insensitive indices.
Using UPPER() or LIKE is not as efficient and it usually requires
to tweak applications in an ugly way to support case-insensitive searches.
Maybe the new file format will support this ?
If difficult to make it a feature, is it possible to compile sqlite to be case-insensitive for indicies (even for ones built previously); i.e. provide a #ifdef SQLITE_CASE_INSENSITIVE_INDICES |
|
717 |
new
|
active
|
2004 May
|
anonymous
|
Unknown
|
2004 May
|
drh
|
2
|
2
|
minor fixes and port to dos
|
edit |
attached is a diff for sqlite 2.8.13 that allows work in dos gnu environment (32 bit djgpp), even without support of long file names.
it also contains minor adjacent bugfixes, in the file names handling area, and for the case of missing libreadline.
please take a look, and do apply to the main source tree. i do not ask for anything, even not for personal credits. it is a very small contribution, to make your wonderful work even more popular.
best regards,
alex |
2004-Jul-09 02:22:15 by anonymous:
after feedback, mainly from hans-juergen taenzer, i have reviewed the port to dos and made better relative path support, applying to unix also.
for any questions or remarks, please feel free to contact me,
alex,
alexbodn@012.net.il. |
|
714 |
new
|
active
|
2004 Apr
|
anonymous
|
Unknown
|
2004 Apr
|
drh
|
3
|
3
|
Change sqlite_decode_binary to return buffer size
|
edit |
It would be nice to be able to have sqlite_decode_binary return the required buffer size, like the encode routine does. The reason is that in managed systems (we're using this in .NET) it avoids a needless allocation and then a copy. For example, without it, we need to allocate a buffer as big as the incoming one, decode, allocate one of the proper size, then copy the bytes. Otherwise, the array we return is incorrectly sized. I've made the following change...
// TODO: Mark this up... was... out[i++] = c + e;
if (out) out[i++] = c + e; else i++;
By checking the out argument, we still get the increment count, but we don't write anywhere. |
|
712 |
new
|
active
|
2004 Apr
|
anonymous
|
Unknown
|
2004 Apr
|
drh
|
3
|
3
|
Allow temporary databases to be created in specified folder
|
edit |
Right now temporary databases are created in a default folder, for example the Temp folder under Windows. It should be possible to customize this location by passing the "context" of the current database to the temporary OS.C function. If that function received the current database, it could parse the folder and optionally create the temporary file in the same location. |
|
711 |
new
|
active
|
2004 Apr
|
anonymous
|
|
2004 Apr
|
drh
|
3
|
3
|
Provide a callback function to verify values before insert or update
|
edit |
Such a function would be called during an insert or update with the column name, column type, and the value. The function could set an error and error message to deny the action. This would allow develops to create virtual datatypes with very little effort. For example, if a column was defined as type "Fruit", a function could check if the value was "Apple" and allow it, or "Cat" and deny it. |
2004-Apr-28 23:00:07 by anonymous:
use triggers |
|
710 |
new
|
active
|
2004 Apr
|
anonymous
|
Unknown
|
2004 Apr
|
drh
|
3
|
4
|
Provide the ability to pass a user-data value during sqlite_compile
|
edit |
It would be very useful to be able to pass a user-data value during the sqlite_compile command, that could then be retrieved in a user function. This would allow context-sensitive responses by the functions, by allowing them to know what "command" is executing them. I can provide further details if required. |
|
709 |
code
|
active
|
2004 Apr
|
anonymous
|
Unknown
|
2005 Jan
|
drh
|
1
|
1
|
Unable to unregister or replace functions
|
edit |
I believe this started with 2.8.13, as it did work previously. There appears to be a show-stopper with unregistering or replacing existing functions. Specifically, if one tries to replace (or remove by passing nulls) one of the built-in functions, for example "like" or "upper", the function does not get replaced, and is in fact still called and available. The odd thing is that if you try to replace one of the functions with an underscore, such as "change_count", it works fine! This is causing problems as we replace a lot of the existing functions, and allow users to add and replace their own functions, which are now failing. |
2004-Apr-26 20:56:19 by anonymous:
Alright, turns out this is due to mismatch in argument count when unregistering functions. It would be useful if we could unregister all instances of a function name, irregardless of argument counts.
2004-Apr-26 23:11:43 by anonymous:
Turns out there really is a bug... the problem is in the sqliteFindFunction function's matching of inexact argument counts, when being called from sqliteExprCheck with >0 argument count. This is the scenario. I override the "upper" function with my own, but first removing the old "upper", specifying 1 argument and null for the function. I then register a new "upper" with -1 for the argument count, and a valid function.
When sqliteFindFunction attempts to locate the upper function, It locates the new function, but because it is registered with -1, it tries to find a better match. It then runs into the original one, and because it has a null function pointer, it fails. This causes sqliteExprCheck to try again with -1 as the count, and since that matches, it reports an error of wrong_num_args.
Unfortunately this means there is no way to override an existing method (it would be good if we could just delete them, rather than override them, although I still think this behaviour with -1 is wrong).
2004-Apr-26 23:29:23 by anonymous:
I've applied the following patch in the sqliteFindFunction function, that I believe addresses the problem:
/* Change this
if( p && !createFlag && p->xFunc==0 && p->xStep==0 ){
return 0;
}
*/
/* To this */
if( p && !createFlag && p->xFunc==0 && p->xStep==0 ){
return pMaybe;
By returning pMaybe we provide a function that will work, while returning 0 if no variable argument function was found. |
|
707 |
new
|
active
|
2004 Apr
|
anonymous
|
Unknown
|
2004 Apr
|
drh
|
3
|
3
|
how to use internal functions?
|
edit |
to name a few:
- "SELECT @@CHECK_INTEGRITY", it will return the integrity of the database.
- "SELECT @@DATABASE_VERSION", it will return the version of the database.
- "SELECT @@ENGINE_VERSION", it will return the current version of the sqlite engine
- "SELECT @@ENGINE_ENCODING", it will return the encoding of the sqlite engine.
etc. |
|
700 |
code
|
active
|
2004 Apr
|
anonymous
|
VDBE
|
2004 Apr
|
|
2
|
3
|
Solaris-sparc segfaults on sum()
|
edit |
On Solaris (sparc) trying to do a sum() (sometimes) SEGVs: this is because the result is placed in a chunk of memory which is allocated as a char * and therefore isn't aligned to 16-byte boundaries (which SPARC-Solaris seems to want).
One fix for this which seems to work for me is to change vdbeInt.h:118 to
char zShort[NBFS] __attribute__ ((__aligned__(16))); /* Space for short strings */
and change sqlite_aggregate_context to assign p->pAgg to zShort rather than z (since z is malloc()ed you can't align it) - I don't know if this would cause problems elsewhere though. |
2004-Apr-22 16:10:37 by dougcurrie:
malloc() should always return memory aligned for any purpose; I don't think this is the problem.
Looking at the function sqlite_aggregate_context though, I wonder:
- where is p->z initialized?
- where is p->pAgg sqliteFree()d?
- what happens when sqlite_aggregate_context and sqlite_set_result_string share Mem.zShort?
2004-Apr-23 09:58:03 by anonymous:
> malloc() should always return memory aligned for any purpose; I don't think this is the problem.
I didn't make it clear: I'm getting a Bus Error, not just a normal SEGV.
There are several places mentioned on the web which suggests that solaris' malloc() aligns memory to 8-byte boundaries, while (on 64-bit, I assume) a double is 128 bits... however you're correct, the manpage does insist that all malloc()s are aligned to data large enough for any purpose. I suppose if s.z isn't even assigned at this point (but hasn't been cleared at initialisation) it might contain something completely non-aligned.
However I now can't reproduce the problem, although that's not to say that it means the thing isn't broken... I'll try and break it again and let you know.
As to your other point: the reason I posted was because of exactly this: I don't know the code well enough (I'd never heard of it until yesterday!) to be able to say whether .zShort could be used elsewhere at the same time as a sum() function.
2004-Apr-23 10:35:11 by anonymous:
Aha. A core file lying around may well help.
...
Program terminated with signal 10, Bus Error.
...
#0 0xff33d4a4 in sumStep (context=0x2a158, argc=203556, argv=0x3ac08)
at src/func.c:421
421 p->sum += sqliteAtoF(argv[0], 0);
...
(gdb) list
416 static void sumStep(sqlite_func *context, int argc, const char **argv){
417 SumCtx *p;
418 if( argc<1 ) return;
419 p = sqlite_aggregate_context(context, sizeof(*p));
420 if( p && argv[0] ){
421 p->sum += sqliteAtoF(argv[0], 0);
422 p->cnt++;
423 }
424 }
....
(gdb) print &p.sum
$5 = (double *) 0x31b24
Now my basic maths (a hex 16-byte aligned number should end in 0, right?) says that somehow p.sum has become misaligned by 4 bytes.
sqlite_aggregate_sum simply assigns p->pAgg to p->s.z and returns p->pAgg, which means that p->s.z is misaligned also.
Further investigation makes more worrying reading:
(gdb) print *context
$18 = {pFunc = 0x75736572, s = {i = 0, n = 0, flags = 16, z = 0x0,
r = 3.6586602629506839e-309,
zShort = '\000' <repeats 11 times>, "\020\000\000\000\000\000\002¡\230", '\000' <repeats 11 times>}, pAgg = 0x10, isError = 0 '\000', isStep = 0 '\000',
cnt = 172464}
Note that pAgg is 0x10 (!?) and s.z is 0. Something seriously unhappy going on there: I think it's likely there's some corruption going on due to some specific set of events which was being run.
I'll rerun the exact scenario and try again.
2004-May-03 02:27:25 by anonymous:
i have seen this exact same problem on sparc/solaris. my core looks exactly the same. it really does look like an alignment issue.
2004-Jul-12 13:09:26 by anonymous:
I had this exact problem on solaris 8 with gcc3.3.4 and well, every version of sqlite over 2.5.
Heres my solution, hopefully it will help someone with more time and IQ points to figure out the real problem
After forcing PTR_FMT to %x in test1.c (so i can run all the tests) I changed src/vbdeInt.h #define NBFS from 32 to 15 (one less than a long double on a sparc) thus forcing all long doubles to be malloced.
This allowed me to run all the tests (and my application) bus error free. 5 of the tests failed, which looks like a precision problem and seems harmless in my applications.
date-1.19...
Expected: [2451545.00000116]
Got: [2451545.00000]
date-1.20...
Expected: [2451545.00000012]
Got: [2451545.00000]
date-1.21...
Expected: [2451545.00000001]
Got: [2451545.00000]
expr-2.4...
Expected: [0.525641025641026]
Got: [0.52564102564]
expr-2.5...
Expected: [1.90243902439024]
Got: [1.90243902439]
2004-Jul-17 12:26:31 by anonymous:
I found a better solution than my changing NBFS solution. from what little info i found, doubles in a structure are aligned to 8. so align zShort to 8 and it works with NBFS as 32. change PTR_FMT to %X instead of %x and it passes all the tests. |
|
699 |
new
|
active
|
2004 Apr
|
anonymous
|
|
2004 Apr
|
|
5
|
4
|
Data types and implicit conversions
|
edit |
I am a long-time (since 1986 ...) Oracle user and I tend to use Oracle, definitely more than MySQL, as my reference.
I currently have a project of writing a SQL*Plus-like interface to SQLite, rather than the sqlite program, with the idea of providing people with something which can be used for educational purposes on hardware much less impressive than what the latest Oracle versions require.
Part of the project includes adding most of the (numerous) Oracle functions. I see dates as a major annoyance. I think that SQLite should be able to return DATE as a basic type besides TEXT and NUMERIC. I understand (even if I don't fully agree with) the type-less philosophy, but my belief is that, even if ordering doesn't belong to relational theory proper, a difference should be made where the expected ordering is different.
If DATE is recognized as a basic type, it should also allow some type-checking in functions, more importantly some integrity checking (preventing from entering 06/31/2004 for instance), as well as implicit conversions. Oracle uses a default DD-MON-YY date format (which can be redefined), any string conforming to the default format which is inserted into a DATE column becomes a date without any fuss. Of course, an explicit conversion can be obtained through TO_DATE().
Currently, having a consistent usage of dates in SQLite relies on the user's own discipline - good enough in a carefully written program, but not for an interactive interface. |
2004-Apr-21 15:08:39 by anonymous:
You can let DBMS check the dates. But a good Front-End should check the date before trying a wrong 'insert' or 'update'. |
|
698 |
code
|
active
|
2004 Apr
|
anonymous
|
Unknown
|
2004 Apr
|
|
1
|
3
|
.mode list - not going to next line
|
edit |
To create a comma delimited output file:
------------------------------------------------
C:\SQLite>sqlite locate.db
SQLite version 2.8.13
Enter ".help" for instructions
sqlite> .mode list
sqlite> .separator ", "
sqlite> .output data.cdf
sqlite> select * from parts;
sqlite> .quit
That should create a text file of something like this:
1st rec field 1, 1st rec field 2, 1st rec field 3, 1st rec field 4
2nd rec field 1, 2nd rec field 2, 2nd rec field 3, 2nd rec field 4
3rd rec field 1, 3rd rec field 2, 3rd rec field 3, 3rd rec field 4
but it does not provide a line break after each record, so the output looks like this:
1st rec field 1, 1st rec field 2, 1st rec field 3, 1st rec field 42nd rec field 1, 2nd rec field 2, 2nd rec field 3, 2nd rec field 43rd rec field 1, 3rd rec field 2, 3rd rec field 3, 3rd rec field 4
Each record is butted up against the previous record, without even a space. This is inconsitant with the instruction on how it is supposed to work, via this page:
http://www.sqlite.org/sqlite.html
Also, can you please refer me to somewhere that would explain how I can use SQLite with a batchfile, EG: using a batchfile to add a record, delete a record, query, Etc...
Thanks,
Tom |
|
697 |
event
|
active
|
2004 Apr
|
anonymous
|
Unknown
|
2004 May
|
|
3
|
4
|
Questionable locking
|
edit |
Situation: SELECT some data into a statement handle. Loop through that statement handle using fetchrow_hashref(). For each row, do something, and then UPDATE the database with the return code. My UPDATES were failing with little to no information coming back from the DBI layer. (Even w/ trace on.)
Solution: As it turns out, the DB was locked from the first SELECT, and the UPDATES couldn't be written. So, I used fetchall_hashref() instead. That way, I took all the info in, undefined the statement handle, and the UPDATES work fine.
This may be as-intended, I can understand the appeal of simple locking for the niche SQLite fills. But, 1) the FAQ item 7, sentence one leads me to believe that SELECTS don't lock, and 2) common sense tells me that SELECTS are read-only and shouldn't lock.
I also wrote this up at perlmonks.org as the problem was found.
http://www.perlmonks.org/index.pl?node_id=345931
Thanks for SQLite -- it's one of my favorite open source packages. Do one thing and do it well. Thank you. |
2004-May-03 19:26:07 by anonymous:
Well, it seems that SqlLite only allows for one query to be completely executed at a time. This includes SELECT.
To test this, create a database test as follows,
create table test_table(a);
INSERT INTO test_table VALUES('test');
Then run the following program. Executing another query does not work, even using a seperate VM. Right now, SELECT blocks, which makes things more difficult... :( Even worse, the DELETE does not even return an error - just fails silently.
#include <sqlite.h>
#include <stdio.h>
int main()
{
sqlite *d1, *d2;
const char *tail1, *tail2;
const char **col_data1, **col_names1;
const char **col_data2, **col_names2;
sqlite_vm *v1, *v2;
int i, j;
int pN;
char del_msg[255];
char *err;
d1 = sqlite_open( "test", 0, &err );
if( err != 0 ) printf( "Open error: %s\n", err );
d2 = sqlite_open( "test", 0, &err );
if( err != 0 ) printf( "Open error: %s\n", err );
/* Select one row */
printf( " allocated: %d %d\n", (int)d1, (int)d2 );
i = sqlite_compile( d1, "select * from test_table", &tail1, &v1, &err );
sqlite_step( v1, &pN, &col_data1, &col_names1 );
if( err != 0 ) printf( "Select error: %s\n", err );
printf( "nCols: %d\n", pN );
sprintf( del_msg, "delete from test_table where a=\"%s\"", col_data1[0]);
printf( "%s\n", del_msg );
/* // UNCOMMENT FOR THIS TO WORK
*
* sqlite_finalize( v1, &err );
* if( err != 0 ) printf( "Finalize error: %s\n", err );
*
*/
/* Delete that row */
j = sqlite_compile( d2, del_msg, &tail2, &v2, &err );
if( err != 0 ) printf( "Delete error: %s\n", err );
sqlite_step( v2, &pN, &col_data2, &col_names2 );
sqlite_finalize( v2, &err );
if( err != 0 ) printf( "Finalize error: %s\n", err );
/* COMMENT FOR THIS TO WORK */
sqlite_finalize( v1, &err );
if( err != 0 ) printf( "Finalize error: %s\n", err );
/****************************/
sqlite_close( d1 );
sqlite_close( d2 );
return 0;
}
|
|
691 |
code
|
active
|
2004 Apr
|
anonymous
|
Unknown
|
2004 Apr
|
drh
|
1
|
1
|
OS X File Sharing
|
edit |
Hello Sir:
This ticket may be considered a duplicate of ticket #301. I am unable to access SQLite databases from HFS or SMB network shares when using Mac OS X (10.3.3) as a client.
The more technical aspects of the problem are explained well in ticket #301.
I am using SQLabs SQLite plugin for RealBasic 5.5, and would like to use SQLite exclusively as my DB. I am concerned that the original ticket was submitted approximately one year ago. So I am submitting this to see if this issue is being addressed, and if there is a timetable set for its resolution.
Thank you,
Tony Dellos
Milwaukee WI |
|
689 |
doc
|
active
|
2004 Apr
|
anonymous
|
|
2004 Apr
|
anonymous
|
4
|
4
|
Old Comment for sqlite_decode_binary in sources ?
|
edit |
Comments in sqlite.h.in & encode.c refer to a return of -1 for an invalid data-block. I believe -1 cannot be returned. Maybe missed during jump from 1.11 to 1.12 of encode.c
Works perfectly though :) |
|
685 |
code
|
active
|
2004 Apr
|
anonymous
|
CodeGen
|
2004 Apr
|
|
1
|
3
|
SELECT from a VIEW with GROUP BY
|
edit |
When you SELECT from a VIEW (which is having a GROUP BY statement) and try to apply another GROUP BY statement you get:
$ sqlite ../../db/main.db
SQLite version 2.8.13
Enter ".help" for instructions
sqlite> .dump prod_elem_totals
BEGIN TRANSACTION;
CREATE VIEW prod_elem_totals AS
SELECT
pe.elem_id AS elem_id, p.prod_id AS prod_id, e.name AS name,
p.name AS p_name, pe.count AS count,
SUM(b.count) / pe.count AS p_max,
SUM(b.count) AS total, SUM(b.price * b.count) / SUM(b.count) AS price,
e.min AS min
FROM
products AS p, elements AS e, batches AS b, prod_elems AS pe
WHERE
p.prod_id = pe.prod_id AND
pe.elem_id = b.elem_id AND
pe.elem_id = e.elem_id
GROUP BY
p.prod_id,
pe.elem_id
ORDER BY
e.name;
COMMIT;
sqlite> SELECT * FROM prod_elem_totals GROUP BY elem_id;
sqlite: src/select.c:1775: flattenSubquery: Assertion `p->pGroupBy==0' failed.
Aborted
It seams it doesn't matter which column I GROUP BY. I can prepare a full test case if needed.
Maybe somehow connected with #678.
After further investigation I found that when I add a aggregate function like "SUM (count * 10) AS min" it works... |
|
684 |
code
|
active
|
2004 Apr
|
anonymous
|
Unknown
|
2004 Apr
|
|
3
|
2
|
Incorrect function result type when using SQLITE_ARGS
|
edit |
I registered a function using the SQLITE_ARGS return type. I then execute the statement "select test('sample')". The type information returned from sqlite_step in the pazColName is incorrectly reported as "NUMERIC". If I use a "0", specifying the first column, instead of SQLITE_ARGS when registering the function, the return value is correctly set to "TEXT". |
|
682 |
new
|
active
|
2004 Apr
|
anonymous
|
|
2004 Apr
|
|
5
|
1
|
sqlite_aggregate_context() valid in xFunc callback routine
|
edit |
One of BIG limitations of SQL i suffer is that no information about previous row(s) is available in current row.
Supose a table
oChar | oNum
a | 3
j | 2
w | 4
i would like to get
oChar | oNum | SQLConcat(oChar) | SQLContSum(oNum)
a | 3 | a | 3
j | 2 | aj | 5
w | 4 | ajw | 9
If in xFunc routine sqlite_aggregate_context() were valid, then functions like SQLConcat and SQLContSum will be possible, and multi-instace-able.
BTW i see no advantage in using pUserData instead of any other global data, since it will be the same data for all instances of the function. Am i wrong?
Thank you for SQLite!
Best regards.
Marcelo |
|
676 |
build
|
active
|
2004 Mar
|
anonymous
|
|
2005 Aug
|
|
1
|
1
|
Problem with Makefile
|
edit |
On Solaris 8-patchlevel 21, after running configure with no problems, running make halts with the following message:
make:make: fatal error in reader: Makefile, line 79: Unexpected end of line seen
Line 79 is part of an "ifeq" phrase. I do not know much about Makefile syntax or understand how configure could create a defective one. Thanks for your help. |
Use gmake instead of make. I know nothing much about make or gmake, but gmake works and make does not. whoo hoo. |
|
673 |
new
|
active
|
2004 Mar
|
anonymous
|
Shell
|
2004 Apr
|
|
4
|
3
|
Format .dump nicer (patch)
|
edit |
(I've already tried to mail this.So it goes here again.)I wanted the .dump and .schema commands to have niceroutput (better to read).So I wrote a small and simple formatter for sql.Note, that it is really simple, but should grok mostthings.Hope you like it. |
|
666 |
code
|
active
|
2004 Mar
|
anonymous
|
Unknown
|
2004 Mar
|
anonymous
|
5
|
4
|
Error message indicates wrong error
|
edit |
This is just a message problem. When creating objects if the object alread exists (be it table, view) you always get the table already exist error. Perhapes a change to object alread exists would be better |
|
662 |
new
|
active
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
drh
|
5
|
5
|
Stored Procedures?
|
edit |
I know that sqlite demands not to support Stored Procedures, but why? it is quite good. |
2005-Aug-30 20:23:58 by anonymous:
Stored procedures are becoming a standard practice with database development. Not supporting them in any form makes SQLite obsolete.
2005-Aug-30 20:43:25 by anonymous:
This is really something that deserves to be discussed on the mailing list. |
|
660 |
new
|
active
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
|
5
|
5
|
compression/encoding feature?
|
edit |
Would sqlite support built-in compression/encoding feature like http://www.sqliteplus.com/ does? and I think that the compression feature should use zlib which has source code. |
2004-Mar-15 13:01:18 by anonymous:
I check http://www.sqliteplus.com/ and fount that they have these features:
1.Stored Procedures
2.Encryption
3.Compression
4.Binary encoding for BLOB data
will sqlite add these built-in features? |
|
656 |
code
|
active
|
2004 Mar
|
anonymous
|
Unknown
|
2004 May
|
|
5
|
5
|
The 'sum' and 'avg' functions don't work on Solaris (UNIX)
|
edit |
I have a database that was created by a previous version of Sqlite.
I tried to find the average age of the people in the database. "age" was declared as an integer in the create part. The odd thing is that both 'sum' ans 'age' seem to work fine under Windows but not under UNIX (I am using Solaris!). Also, when I used a very old version of Sqlite, the 'age' and 'sum' functions worked.
Bob |
The sum() and avg() functions work correctly for the 194 and 111 cases
(respectively) where they are used in the test suite. This trouble
report is too vague to be useful. Without additional information,
there is little that can be done to address the issue.
Information missing from the trouble report:
- What is meant by "it doesn't work". Does it get the wrong answer?
Is there an error message? Does the program crash?
- What was the input data? Be specific. Provide the table
schema. Vague references to "age" are not helpful. How many
entries are in the table? How many of those entries are NULL?
- What is the exact text of the query that failed?
- What was the version number of SQLite that originally created
the database? What version number of SQLite does sum() and
avg() work for? Saying "an earlier version" is not helpful.
There are 127 earlier versions.
2004-May-11 04:31:48 by anonymous:
I have the same problem. The version of SQLite is the latest 2.8.13, and we are running Solaris as well. The definition statement for the table is
CREATE TABLE alert_source (
src NOT NULL,
dst NOT NULL,
tcp NOT NULL,
udp NOT NULL,
icmp NOT NULL,
first NOT NULL,
last NOT NULL,
);
The view made for it is
create view sum_view as
select tcp+udp+icmp as cnt, *
FROM alert_source;
This query core dumps:
select sum(cnt) from sum_view;
It isn't too complicated but it definitely dumps in as many permutations of a summarizing select statement as I can come up with.... |
|
652 |
doc
|
active
|
2004 Mar
|
anonymous
|
Unknown
|
2004 Mar
|
anonymous
|
5
|
5
|
small addition needed in pragma table_info
|
edit |
Small addition to the sql page:
PRAGMA table_info(table-name);
For each column in the named table, invoke the callback function once with information about that column, including the column name, data type, whether or not the column can be NULL, and whether or not the column is part of the primary key.
Last part should be added.
Best regards,
Albert Drent |
|
651 |
new
|
active
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
|
5
|
4
|
Update optimisation
|
edit |
Possible optimisation on updates
I have a big table in my DB. One column is a number which, in my case, can be either 0 or 1
The statement
update info set new=0 where type='book'
always takes about 60 seconds to run (even though 'type' is indexed)
If I change the statement to
update info set new=0 where type='book' and new=1
it's usually almost instantaneous.
It looks as if SQLite is rewriting the row even though no actual data is being changed, so maybe the update code could be optimised to only rewrite the row if necessary. |
|
647 |
warn
|
active
|
2004 Mar
|
anonymous
|
Shell
|
2004 Mar
|
|
5
|
4
|
Shell.c compilation warnings
|
edit |
Compilation of shell.c with OpenWatcom 1.3 reports
d:\!progs\sqlite\src\shell.c(156): Warning! W111: Meaningless use of an expression
d:\!progs\sqlite\src\shell.c(1337): Warning! W111: Meaningless use of an expression
d:\!progs\sqlite\src\shell.c(272): Warning! W202: Symbol 'interrupt_handler' has been defined, but not referenced
Bartosz Polednia
|
|
646 |
warn
|
active
|
2004 Mar
|
anonymous
|
Pager
|
2004 Mar
|
|
5
|
4
|
Pager.c compilation warnings
|
edit |
Compilation of pager.c with OpenWatcom 1.3 reports
d:\!progs\sqlite\src\pager.c(360): Warning! W201: Unreachable code
d:\!progs\sqlite\src\pager.c(1674): Warning! W201: Unreachable code
Bartosz Polednia
|
|
645 |
new
|
active
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
|
5
|
5
|
OpenWatcom makefile
|
edit |
I have prepared initial version of makefile for OpenWatcom
compiler. I use OpenWatcom 1.3 compiled from sources synced
yesterday with OpenWatcom Perforce (CVS) server.
SQLite.exe gets compiled and linked directly from
sources in SQLite /src directory.
To get compilation done you need two external tools:
egrep - it could be find in source tree for OpenWatcom
any wersion of awk.exe - I've used
'gwk311b GNU Awk 3.1.1 for DJGPP v2'
vi.exe editor in sed/ex/ed - like mode - vi is included
in OpenWatcom package as standard editor.
Please create directory /watcom under SQLite dir - on the same
level as /src. Copy makefile to it and do wmake.
To get lemon.c compiled with no errors I've had to change it.
Please find attached diff file. Changes are cosmetic ones so it
shouldn't broke anything:
15,21d14
< extern void qsort();
< extern double strtod();
< extern long strtol();
< extern void free();
< extern int access();
< extern int atoi();
<
43d35
< void Action_add();
377c369
< ap = (struct action *)msort(ap,&ap->next,actioncmp);
---
> ap = (struct action *)msort((char *)ap,(char **)&ap->next,actioncmp);
814c806
< Action_add(&stp->ap,SHIFT,sp,newstp);
---
> Action_add(&stp->ap,SHIFT,sp,(char *)newstp);
915c907
< Action_add(&stp->ap,REDUCE,lemp->symbols[j],cfp->rp);
---
> Action_add(&stp->ap,REDUCE,lemp->symbols[j],(char *)cfp->rp);
1191c1183
< current = (struct config *)msort(current,&(current->next),Configcmp);
---
> current = (struct config *)msort((char *)current,(char **)&(current->next),Configcmp);
1198c1190
< basis = (struct config *)msort(current,&(current->bp),Configcmp);
---
> basis = (struct config *)msort((char *)current,(char **)&(current->bp),Configcmp);
1449a1442
> return (lem.errorcnt + lem.nconflict);
Makefile is not the best one but it works. Futer version will be better.
Bartosz Polednia
|
2004-Mar-04 09:32:30 by anonymous:
I forgot to append makefile:
#
# OpenWatcom makefile for SQLite
#
# Bartosz Polednia
# bartosz@chill.com.pl
#
# 04.03.2004 - 0.01
#
# set database version
SQLITEVERSION = 2.8.12
# sqlite directory
TOP = d:\!progs\sqlite
#compiler settings
CC = wcc386
CCL = wcl386
C_FLAGS = -wx -I$(TOP)\;.\
CCL_FLAGS = $(C_FLAGS)
EXE_OUTPUT = -fe
# Should the database engine assume text is coded as UTF-8 or iso8859?
#
# ENCODING = UTF8
# ENCODING = ISO8859
ENCODING = ISO8859
# Flags controlling use of the in memory btree implementation
#
# SQLITE_OMIT_INMEMORYDB is defined in order to omit the in-memory
# red/black tree driver in the file btree_rb.c
#
# TEMP_STORE is 0 to force temporary tables to be in a file, 1 to
# default to file, 2 to default to memory, and 3 to force temporary
# tables to always be in memory.
#
INMEMORYDB = 1
INCOREFLAGS = -DTEMP_STORE=@TEMP_STORE@
!ifeq $(INMEMORYDB) 0
INCOREFLAGS += -DSQLITE_OMIT_INMEMORYDB=1
!endif
# You should not have to change anything below this line
###############################################################################
all: sqlite.h sqlite.lib sqlite.exe
# Object files for the SQLite library.
#
LIBOBJ = attach.obj auth.obj btree.obj build.obj copy.obj date.obj &
delete.obj expr.obj func.obj hash.obj insert.obj &
main.obj opcodes.obj os.obj pager.obj parse.obj pragma.obj &
printf.obj random.obj select.obj table.obj tokenize.obj &
update.obj util.obj vacuum.obj vdbe.obj vdbeaux.obj &
where.obj trigger.obj btree_rb.obj
# Only build the in-core DB if it is required.
!ifeq $(INMEMORYDB) 1
LIBOBJ += btree_rb.obj
!endif
# Header files used by all library source files.
#
HDR = sqlite.h $(TOP)\src\btree.h config.h $(TOP)\src\hash.h opcodes.h &
$(TOP)\src\os.h $(TOP)\src\sqliteInt.h $(TOP)\src\vdbe.h parse.h
# Header files used by the VDBE submodule
#
VDBEHDR = $(HDR)$(TOP)\src\vdbeInt.h
# This is the default Makefile target. The objects listed here
# are what get build when you type just "make" with no arguments.
#
sqlite.lib: sqlite.h config.h parse.h opcodes.h lemon.exe $(LIBOBJ)
for %i in ($(LIBOBJ)) do wlib sqlite.lib -+%i > nul
sqlite.exe: $(TOP)\src\shell.c sqlite.lib
$(CCL) $(CCL_FLAGS) $(TOP)\src\shell.c sqlite.lib $(EXE_OUTPUT)=sqlite.exe
# Rules to build the LEMON compiler generator
#
lemon.exe: lemon.c $(TOP)\tool\lempar.c
$(CCL) $(CCL_FLAGS) $(EXE_OUTPUT)=lemon.exe lemon.c
copy $(TOP)\tool\lempar.c .
main.obj: $(TOP)\src\main.c $(HDR)
$(CC) $(TOP)\src\main.c $(C_FLAGS)
# $(CC) $(TOP)\src\$[&.c $(C_FLAGS)
# ${INCOREFLAGS}
# $(LTCOMPILE) -c ${INCOREFLAGS} $(TOP)\src\main.c
opcodes.obj: opcodes.c
$(CC) $[@ $(C_FLAGS)
opcodes.c: $(TOP)\src\vdbe.c
%create temp.vi
%write temp.vi set magic
%append temp.vi set magicstring = ()
%append temp.vi atomic
%append temp.vi %s/^.*OP_/ "/
%append temp.vi %s/:.*$$/", /
%append temp.vi x
%create opcodes.c
%write opcodes.c /* Automatically generated file. Do not edit */
%write opcodes.c char *sqliteOpcodeNames[] = { "???",
egrep "^case OP_" $(TOP)\src\vdbe.c > opcodes.tmp
vi -s temp.vi opcodes.tmp
rm temp.vi
copy opcodes.c+opcodes.tmp opcodes.c
echo }; >> opcodes.c
rm opcodes.tmp
opcodes.h: $(TOP)\src\vdbe.h $(TOP)\src\vdbe.c
%create temp.vi
%write temp.vi set magic
%append temp.vi set magicstring = ()
%append temp.vi atomic
%append temp.vi %s/://
%append temp.vi x
%create opcodes.h
%write opcodes.h /* Automatically generated file. Do not edit */
egrep "^case OP_" $(TOP)\src\vdbe.c > opcodes.tmp
vi -s temp.vi opcodes.tmp
rm temp.vi
awk '{printf "$#define %-30s %3d\n", $$2, ++cnt}' opcodes.tmp > temp.awk
type temp.awk >> opcodes.h
rm opcodes.tmp
rm temp.awk
parse.obj: parse.c $(HDR)
$(CC) $[@ $(C_FLAGS) -I$(TOP)\src\
parse.h: parse.c
@echo parse.h
parse.c: $(TOP)\src\parse.y lemon.exe
copy $(TOP)\src\parse.y .
.\lemon .\parse.y
rm parse.y
rm lempar.c
# The config.h file will contain a single #define that tells us how
# many bytes are in a pointer. This only works if a pointer is the
# same size on the host as it is on the target. If you are cross-compiling
# to a target with a different pointer size, you'll need to manually
# configure the config.h file.
#
config.h:
%write temp.c $#include <stdio.h>
%append temp.c int main(){
%append temp.c printf("$#define SQLITE_PTR_SZ %d\n",sizeof(char*));
%append temp.c return (0);}
$(CCL) $(C_FLAGS) $(EXE_OUTPUT)=temp.exe temp.c
.\temp.exe >config.h
rm -f temp.c temp.exe temp.obj
sqlite.h: $(TOP)\src\sqlite.h.in
copy $(TOP)\src\sqlite.h.in sqlite.h
%create temp.vi
%write temp.vi set magic
%append temp.vi set magicstring = ()
%append temp.vi atomic
%append temp.vi %s/--VERS--/$(SQLITEVERSION)/
%append temp.vi %s/--ENCODING--/$(ENCODING)/
%append temp.vi x
vi -s temp.vi sqlite.h
rm temp.vi
.c: $(TOP)\src\
#
.c.obj:
$(CC) $(TOP)\src\$[&.c $(C_FLAGS)
Bartosz |
|
644 |
todo
|
active
|
2004 Mar
|
anonymous
|
Unknown
|
2004 Mar
|
|
1
|
3
|
How do you fix "SQL error: database disk image is malformed"
|
edit |
I have a program, that I exit using ^C.
When that happens and I attempt to access the table that it
was writing to, I sometimes get the following error.
How do you fix "SQL error: database disk image is malformed"
Isn't the database supposed to be able to rollback partial writes? |
|
638 |
new
|
active
|
2004 Mar
|
anonymous
|
|
2004 Mar
|
|
5
|
5
|
Lemon.c could not be compiled - source dated 27.02.2004
|
edit |
I try to prepare makefile for OpenWatcom 1.3 and compile SQLite using
standard source tree but compilation of lemon ends as in the attachment.
Bartosz Polednia |
2004-Mar-01 07:57:58 by anonymous:
Open Watcom Make Version 1.3beta1 Limited Availability
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
wcl386 -wx -zm -fe=lemon.exe d:\!progs\sqlite\tool\lemon.c
Open Watcom C/C++32 Compile and Link Utility Version 1.3beta1 LA
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
wcc386 d:\!progs\sqlite\tool\lemon.c -wx -zm
Open Watcom C32 Optimizing Compiler Version 1.3beta1 LA
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
d:\!progs\sqlite\tool\lemon.c(814): Error! E1071: Type of parameter 4 does not agree with previous definition
d:\!progs\sqlite\tool\lemon.c(814): Note! N2003: source conversion type is 'struct state *'
d:\!progs\sqlite\tool\lemon.c(814): Note! N2004: target conversion type is 'char *'
d:\!progs\sqlite\tool\lemon.c(915): Error! E1071: Type of parameter 4 does not agree with previous definition
d:\!progs\sqlite\tool\lemon.c(915): Note! N2003: source conversion type is 'struct rule *'
d:\!progs\sqlite\tool\lemon.c(915): Note! N2004: target conversion type is 'char *'
d:\!progs\sqlite\tool\lemon.c(1450): Warning! W107: Missing return value for function 'main'
d:\!progs\sqlite\tool\lemon.c(377): Error! E1071: Type of parameter 1 does not agree with previous definition
d:\!progs\sqlite\tool\lemon.c(377): Note! N2003: source conversion type is 'struct action *'
d:\!progs\sqlite\tool\lemon.c(377): Note! N2004: target conversion type is 'char *'
d:\!progs\sqlite\tool\lemon.c(377): Note! N2002: 'msort' defined in: d:\!progs\sqlite\tool\lemon.c(1547)
d:\!progs\sqlite\tool\lemon.c(377): Error! E1071: Type of parameter 2 does not agree with previous definition
d:\!progs\sqlite\tool\lemon.c(377): Note! N2003: source conversion type is 'struct action **'
d:\!progs\sqlite\tool\lemon.c(377): Note! N2004: target conversion type is 'char **'
d:\!progs\sqlite\tool\lemon.c(1191): Error! E1071: Type of parameter 1 does not agree with previous definition
d:\!progs\sqlite\tool\lemon.c(1191): Note! N2003: source conversion type is 'struct config *'
d:\!progs\sqlite\tool\lemon.c(1191): Note! N2004: target conversion type is 'char *'
d:\!progs\sqlite\tool\lemon.c(1191): Note! N2002: 'msort' defined in: d:\!progs\sqlite\tool\lemon.c(1547)
d:\!progs\sqlite\tool\lemon.c(1191): Error! E1071: Type of parameter 2 does not agree with previous definition
d:\!progs\sqlite\tool\lemon.c(1191): Note! N2003: source conversion type is 'struct config **'
d:\!progs\sqlite\tool\lemon.c(1191): Note! N2004: target conversion type is 'char **'
d:\!progs\sqlite\tool\lemon.c(1198): Error! E1071: Type of parameter 1 does not agree with previous definition
d:\!progs\sqlite\tool\lemon.c(1198): Note! N2003: source conversion type is 'struct config *'
d:\!progs\sqlite\tool\lemon.c(1198): Note! N2004: target conversion type is 'char *'
d:\!progs\sqlite\tool\lemon.c(1198): Note! N2002: 'msort' defined in: d:\!progs\sqlite\tool\lemon.c(1547)
d:\!progs\sqlite\tool\lemon.c(1198): Error! E1071: Type of parameter 2 does not agree with previous definition
d:\!progs\sqlite\tool\lemon.c(1198): Note! N2003: source conversion type is 'struct config **'
d:\!progs\sqlite\tool\lemon.c(1198): Note! N2004: target conversion type is 'char **'
d:\!progs\sqlite\tool\lemon.c: 4388 lines, included 1949, 1 warnings, 8 errors
Error: Compiler returned a bad status compiling 'd:\!progs\sqlite\tool\lemon.c'
2004-Mar-01 11:20:38 by anonymous:
The code is K&R style with mismatched prototypes eg.:
......
extern void qsort();
extern double strtod();
extern long strtol();
extern void free();
extern int access();
extern int atoi();
........
void Action_add();
.....
void Action_add(app,type,sp,arg)
struct action **app;
enum e_action type;
struct symbol *sp;
char *arg;
{
Bartosz
2004-Mar-01 13:15:19 by drh:
Lemon was written before ANSI C compilers were widely available.
It uses char* where void* would be more appropriate, because void*
was not available on common compilers when lemon was written.
Probably there is an option to Watcom to get it to accept char*
in place of void*. I am disinclined to rewrite lemon to accomodate
a compiler which I do not use. |
|
637 |
code
|
active
|
2004 Mar
|
anonymous
|
Parser
|
2004 Mar
|
|
5
|
4
|
union uses non-standard column names
|
edit |
for other dbms, such as postgresql, mysql, etc, issuing a
select x as name,
y as value
from first_table
union
select x,
y
from second_table
will produce a resultset with column names of 'name' and 'value' (the first resultset). in sqlite it will produce a resultset with column names of 'x' and 'y' (the last resultset). Code causing this appears to be in multiSelect function in src/select.c. |
|
633 |
build
|
active
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
1
|
1
|
new build system does not run correctly under MinGW/MSYS
|
edit |
The new build system added with checkin 1274 does not run correctly with MinGW/MSYS environment on Windows XP PC.
The sqlite library and shell exe are built correctly with the default make target, but the install and implib targets now fail.
I have attached a log of the build on my system showing the error messages produced. |
|
627 |
code
|
active
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
3
|
3
|
sqliteRunVacuum returning wrong code?
|
edit |
The last 3 lines of sqliteRunVacuum, as of the version checked in on Feb 12 2004, are:
if( rc==SQLITE_ABORT ) rc = SQLITE_ERROR;
if( sVac.rc!=SQLITE_OK ) rc = sVac.rc;
return sVac.rc;
It seems suspicious to set a local variable, rc, that one is never going to use again. I suspect that the last line should be
return rc; |
2004-Feb-27 00:54:03 by anonymous:
The fix by check-in 1271 still doesn't look right to me. If one of the execsql calls returns SQLITE_CANTOPEN (which I have seen happen), then rc will be SQLITE_CANTOPEN and sVac.rc will be 0, and sqliteRunVacuum will return 0. |
|
622 |
doc
|
active
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
1
|
3
|
Should mention PRAGMA table_info() in FAQ
|
edit |
This is just a simple documentation suggestion. In your FAQ (www.hwaci.com/sw/sqlite/faq.html) you mention how to get a list of tables/indices by querying the schema_master, however this begs the next natural question, how can I get a list column names for each table? It is very easy to overlook the small mention of the PRAGMA table_info() command on the SQL reference page which may lead some people to pursue more awkward techniques such as attempting to parse the CREATE TABLE statement they get back from the schema_master query. Mentioning this handy little pragma near the question regarding tables/indicies would be very useful. |
|
621 |
todo
|
active
|
2004 Feb
|
anonymous
|
Unknown
|
2004 Feb
|
anonymous
|
3
|
3
|
Assorted errors running test's on MAC OSX
|
edit |
Mac OSX 10.3.2, gcc 3.3
sqlite 2.8.12 built from tarball
Running tests gave following errors
date-8.1...
Expected: [{2003-10-26 12:34:00}]
Got: [{2004-02-22 21:46:56}]
date-8.2...
Expected: [{2003-10-27 12:34:00}]
Got: [{2004-02-23 21:46:56}]
date-8.3...
Expected: [{2003-10-28 12:34:00}]
Got: [{2004-02-24 21:46:56}]
date-8.4...
Expected: [{2003-10-22 12:34:00}]
Got: [{2004-02-25 21:46:56}]
date-8.5...
Expected: [{2003-10-01 00:00:00}]
Got: [{2004-02-01 00:00:00}]
date-8.6...
Expected: [{2003-01-01 00:00:00}]
Got: [{2004-01-01 00:00:00}]
date-8.7...
Expected: [{2003-10-22 00:00:00}]
Got: [{2004-02-20 00:00:00}]
date-8.8...
Expected: [{2003-10-23 12:34:00}]
Got: [{2004-02-21 21:46:56}]
date-8.9...
Expected: [{2003-10-23 12:34:00}]
Got: [{2004-02-21 21:46:56}]
date-8.10...
Expected: [{2003-10-23 18:34:00}]
Got: [{2004-02-22 03:46:56}]
date-8.11...
Expected: [{2003-10-21 12:34:00}]
Got: [{2004-02-19 21:46:56}]
*** Giving up...
11 errors out of 103 tests
Failures on these tests: date-8.1 date-8.2 date-8.3 date-8.4 date-8.5 date-8.6 date-8.7 date-8.8 date-8.9 date-8.10 date-8.11
format3-5.1...
Expected: [3 121 3]
Got: [3 121 0]
format3-5.2...
Expected: [3 144 3]
Got: [3 144 0]
format3-5.3...
Expected: [3 144 3]
Got: [3 144 0]
format3-5.4...
Expected: [3 144 3]
Got: [3 144 0]
format3-5.5...
Expected: [3 144 3]
Got: [3 144 0]
format3-5.6...
Expected: [3 144 3]
Got: [3 144 0]
format3-5.7...
Expected: [3 144 3]
Got: [3 144 0]
format3-5.8...
Expected: [3 144 3]
Got: [3 144 0]
format3-5.9...
Expected: [3 144 3]
Got: [3 144 0]
format3-5.10...
Expected: [3 121 3]
Got: [3 121 0]
format3-5.11...
Expected: [3 100 3]
Got: [3 100 0]
*** Giving up...
11 errors out of 48 tests
Failures on these tests: format3-5.1 format3-5.2 format3-5.3 format3-5.4 format3-5.5 format3-5.6 format3-5.7 format3-5.8 format3-5.9 format3-5.10 format3-5.11
index-11.1...
Expected: [0.10 3]
Got: [0.10 0]
index-11.2... Ok
1 errors out of 84 tests
Failures on these tests: index-11.1
intpkey-3.2... Ok
intpkey-3.3...
Expected: [5 hello world 2]
Got: [5 hello world 0]
intpkey-3.4...
Expected: [5 hello world 3]
Got: [5 hello world 0]
intpkey-3.5... Ok
intpkey-3.6...
Expected: [5 hello world 3]
Got: [5 hello world 0]
intpkey-3.7...
Expected: [5 hello world 11 hello world 5]
Got: [5 hello world 11 hello world 0]
intpkey-3.8...
Expected: [11 hello world 5]
Got: [11 hello world 0]
intpkey-3.9...
Expected: [11 hello world 1]
Got: [11 hello world 0]
intpkey-4.1... Ok
intpkey-4.7...
Expected: [11 hello world 1]
Got: [11 hello world 0]
intpkey-4.8...
Expected: [11 hello world 1]
Got: [11 hello world 0]
intpkey-4.9...
Expected: [11 hello world 1]
Got: [11 hello world 0]
intpkey-4.10...
Expected: [-4 y z 1]
Got: [-4 y z 0]
intpkey-4.11...
Expected: [-4 y z 1]
Got: [-4 y z 0]
*** Giving up...
11 errors out of 54 tests
Failures on these tests: intpkey-3.3 intpkey-3.4 intpkey-3.6 intpkey-3.7 intpkey-3.8 intpkey-3.9 intpkey-4.7 intpkey-4.8 intpkey-4.9 intpkey-4.10 intpkey-4.11
ioerr-1.1.3... Ok
ioerr-2.1.1...
Error: no such function: randstr
ioerr-2.1.2... Ok
testfixture: can't read "cksum": no such variable
while executing
"do_test ioerr-2.$n.3 {
set r [catch {db eval {
VACUUM;
}} msg]
# puts "error_pending=$::sqlite_io_error_pending"
# if {$r} {puts..."
("for" body line 32)
invoked from within
"for {set n 1} {$go} {incr n} {
do_test ioerr-2.$n.1 {
set ::sqlite_io_error_pending 0
db close
catch {file delete -force test.db}
ca..."
(file "../sqlite/test/ioerr.test" line 73)
memdb-1.1...
Error: no such function: randstr
memdb-1.2.1-0...
Error: cannot start a transaction within a transaction
memdb-1.2.2-0...
Error: cannot start a transaction within a transaction
memdb-1.2.9-0...
Error: no such function: randstr
memdb-1.3.1-0...
Error: cannot start a transaction within a transaction
memdb-1.3.2-0...
Error: cannot start a transaction within a transaction
memdb-1.3.9-0...
Error: no such function: randstr
memdb-1.4.1-0...
Error: cannot start a transaction within a transaction
memdb-1.4.2-0...
Error: cannot start a transaction within a transaction
memdb-1.4.9-0...
Error: no such function: randstr
memdb-1.5.1-0...
Error: cannot start a transaction within a transaction
*** Giving up...
11 errors out of 11 tests
Failures on these tests: memdb-1.1 memdb-1.2.1-0 memdb-1.2.2-0 memdb-1.2.9-0 memdb-1.3.1-0 memdb-1.3.2-0 memdb-1.3.9-0 memdb-1.4.1-0 memdb-1.4.2-0 memdb-1.4.9-0 memdb-1.5.1-0
minmax-1.1... Ok
minmax-1.2...
Expected: [19]
Got: [0]
minmax-1.3... Ok
minmax-1.4...
Expected: [19]
Got: [0]
minmax-1.5... Ok
minmax-1.6...
Expected: [1]
Got: [0]
minmax-1.7... Ok
minmax-1.8...
Expected: [1]
Got: [0]
minmax-1.9... Ok
minmax-1.10...
Expected: [19]
Got: [0]
minmax-2.0... Ok
5 errors out of 38 tests
Failures on these tests: minmax-1.2 minmax-1.4 minmax-1.6 minmax-1.8 minmax-1.10
rowid-4.5...
Expected: [4 3]
Got: [4 0]
rowid-4.5.1...
Expected: [3 3]
Got: [3 0]
rowid-4.6... Ok
rowid-11.4... Ok
2 errors out of 123 tests
Failures on these tests: rowid-4.5 rowid-4.5.1
select2-3.2d...
Expected: [3]
Got: [0]
select2-3.2e...
Expected: [3]
Got: [0]
select2-3.3...
Expected: [29999]
Got: [0]
select2-4.1... Ok
3 errors out of 19 tests
Failures on these tests: select2-3.2d select2-3.2e select2-3.3
trans-8.3... Ok
trans-9.1...
Error: no such function: randstr
trans-9.2.1-0...
Error: cannot start a transaction within a transaction
trans-9.2.2-0...
Error: cannot start a transaction within a transaction
trans-9.2.9-0...
Error: no such function: randstr
trans-9.3.1-0...
Error: cannot start a transaction within a transaction
trans-9.3.2-0...
Error: cannot start a transaction within a transaction
trans-9.3.9-0...
Error: no such function: randstr
trans-9.4.1-0...
Error: cannot start a transaction within a transaction
trans-9.4.2-0...
Error: cannot start a transaction within a transaction
trans-9.4.9-0...
Error: no such function: randstr
trans-9.5.1-0...
Error: cannot start a transaction within a transaction
*** Giving up...
11 errors out of 130 tests
Failures on these tests: trans-9.1 trans-9.2.1-0 trans-9.2.2-0 trans-9.2.9-0 trans-9.3.1-0 trans-9.3.2-0 trans-9.3.9-0 trans-9.4.1-0 trans-9.4.2-0 trans-9.4.9-0 trans-9.5.1-0
vacuum-1.1...
Error: no such function: randstr
testfixture: can't read "cksum": no such variable
while executing
"do_test vacuum-1.2 {
execsql {
VACUUM;
}
cksum
} $cksum"
(file "../sqlite/test/vacuum.test" line 53)
where-1.0... Ok
where-1.1...
Expected: [3 121 3]
Got: [3 121 0]
where-1.2...
Expected: [3 144 3]
Got: [3 144 0]
where-1.3...
Expected: [3 144 3]
Got: [3 144 0]
where-1.4...
Expected: [3 144 3]
Got: [3 144 0]
where-1.5...
Expected: [3 144 3]
Got: [3 144 0]
where-1.6...
Expected: [3 144 3]
Got: [3 144 0]
where-1.7...
Expected: [3 144 3]
Got: [3 144 0]
where-1.8...
Expected: [3 144 3]
Got: [3 144 0]
where-1.9...
Expected: [3 144 3]
Got: [3 144 0]
where-1.10...
Expected: [3 121 3]
Got: [3 121 0]
where-1.11...
Expected: [3 100 3]
Got: [3 100 0]
*** Giving up...
11 errors out of 12 tests
Failures on these tests: where-1.1 where-1.2 where-1.3 where-1.4 where-1.5 where-1.6 where-1.7 where-1.8 where-1.9 where-1.10 where-1.11
|
2004-Feb-20 22:48:00 by anonymous:
I looked up a previous bug I reported, and following the recommended
solution , reran configure with --disable-shared.
running 'make test' showed only one error remained
format 3-11.3
expected [1]
got [0] |
|
613 |
doc
|
active
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
3
|
4
|
Doc is wrong with some prototypes and const is missing for errmsg
|
edit |
The C language interface to the SQLite library is incorrect in some
function-prototypes regardning constness.
For example, it says
" int sqlite_exec(
sqlite *db,
char *sql,
int (*xCallback)(void*,int,char**,char**),
void *pArg,
char **errmsg
);"
In this example, the parameter "char *sql" is "const char *sql" in
my sqlite.h.
In addition to this, the parameter char **errmsg
should be const-ified in many functions (at the moment, they're still
non-const).
This is especially important to C++ developers. |
|
611 |
new
|
active
|
2004 Feb
|
anonymous
|
VDBE
|
2004 Feb
|
|
1
|
3
|
Remove giant SWITCH statement in VM for better portability
|
edit |
This is not really a bug but a major drawback to the platform portability of SQLite. Specifically, this relates to the ease of support for segmented architectures such as Palm OS. The problem is that the enormous SWITCH statement in the sqliteVdbeExec() function contains more than 64K of code. In a 64K segmented architecture this exceeds the code segment limit and the ONLY workaround is to break up the code into subfunctions. This is not an easy task.
At present our "workaround" involves creating a "context" data structure that holds necessary state for execution (essentially the locals of sqliteVdbeExec()) then running an elaborate AWK script that parses each CASE in the switch statement and generates a separate function for the CASE that receives the execution context structure (functions are indexed by opcode for speed). This, followed by some hand tuning is our process of porting whenever we need to pick up a new release of SQLite. Over time this has proven to be the easiest way to integrate new releases, however, it is far from optimial and because of the non-automated steps involved, bug prone.
After making this change the SQLite engine runs fine on the Palm OS segmented architecture and suffers no visible performance drawbacks. If a similar approach were to be integrated directly into the SQLite codebase it would GREATLY improve the portability of the engine. |
2004-Feb-16 23:05:07 by drh:
I experimented with using separate functions for each opcode
and found the results to be about 20% slower than using a switch
on GCC for i386. So changing the code to use functions only is
clearly not an option for most users.
Modifying the code so that it could be compiled either way would
complicate the code and it would eliminate the opportunity to use
persistent local variables. If absolutely necessary, this could
be tolerated. But is it really necessary?
The sqliteVdbeExec() function is only about 21K in size when
compiled using GCC for i386 - less than a third of the maximum
size allowed by PalmOS. Why is it so much bigger on Palm?
Wouldn't a better approch to this problem be to fix the
compiler on the Palm so that it generated binaries of a more
modest size? Surely the Palm does not require more than three
times the code space as an i386.
Is there a GCC implementation available that targets palm?
Have you tried compiling using it?
2004-Mar-24 11:22:01 by anonymous:
>Why is it so much bigger on Palm?
The reason is not the compiler, but processor architecture. Palm's processor is a RISC (reduced instruction set computer) processor (in opposite to x86 CICS (complex instruction set compute)). That means that in general RISC code is much bigger, because action performed by one CISC instruction, takes several RISC instructions to do the same.
2006-Jun-06 18:38:46 by anonymous:
Perhaps the "workaround" could be implemented as a Palm-specific build script, augmented by some source-level "hints" (ala lint comments) to automate the tasks currently hand-tuned. |
|
609 |
build
|
active
|
2004 Feb
|
anonymous
|
Unknown
|
2004 Feb
|
|
1
|
4
|
Makefile errors
|
edit |
bastion# make
"Makefile", line 73: Missing dependency operator
"Makefile", line 75: Need an operator
"Makefile", line 90: Missing dependency operator
"Makefile", line 92: Need an operator
Fatal errors encountered -- cannot continue
I followed the instructions as per the sqlite/README file -- I cannot build any of it. configure script complains of nothing. I'm available for testing if you need me to. |
2004-Mar-14 11:19:09 by anonymous:
Also tried with 2.8.13, same exact error.
2004-Mar-15 00:34:54 by anonymous:
using OpenBSD's 'make' program fails. you MUST install gmake and run gmake to compile and gmake to install it.
The people here at sqlite may want to find how to get bsd's make to work.
Thanks, issue closed.
2004-Apr-13 18:24:04 by anonymous:
I've tried everything suggested in this forum and can't get SQlite to compile properly.
Any chance I can get someone to post the exact steps they used to get it to work.
Or provide a binary. |
|
608 |
code
|
active
|
2004 Feb
|
anonymous
|
|
2004 Feb
|
|
3
|
3
|
Problem with "pragma show_datatypes = on" and busy timeout
|
edit |
When a busy timeout is set, pragma show_datatypes = on and SQLite sleeps some time on the lock, no datatypes are passed to the exec callback function.
The attachment is an archive with a Makefile, a shell script and a program that reproduce the error. |
2004-Feb-12 21:05:28 by anonymous:
This problem breaks the auto-typing feature of PySQLite when a busy timeout is used. |
|
592 |
event
|
active
|
2004 Feb
|
anonymous
|
Unknown
|
2004 Feb
|
|
1
|
1
|
VIEW produces strange result set
|
edit |
VIEW produces strange result set, which is different from the select-statment that created the VIEW does. I'll use a simple database to show the problem. My current Sqlite version is : 2.8.11 running on WinXP
definition: a simple database to manage purchase and sale of a book
CREATE TABLE buy(book,num);
CREATE TABLE sell(book,num);
INSERT INTO buy values(1,10);
INSERT INTO sell values(1,5);
INSERT INTO sell values(1,5);
so now I have two tables like these:
table buy:
sqlite> select * from buy;
book num
---------- ----------
1 10
table sell:
sqlite> select * from sell;
book num
---------- ----------
1 5
1 5
now create a view to see how many book 1 are sold:
CREATE VIEW v_sell AS
SELECT book,sum(num) AS num
FROM sell
GROUP BY book;
view v_sell:
sqlite> select * from v_sell;
book num
---------- ----------
1 10
then create a view to see how many book 1 are in stock:
CREATE VIEW v_stock AS
SELECT buy.book AS book,buy.num - v_sell.num AS stock
FROM buy,v_sell
WHERE buy.book=v_sell.book;
but this produces a strange table:
sqlite> select * from v_stock;
book stock
---------- ----------
1 0
1 0
there should be only one row in VIEW v_stock, but it gives out two. when run the query
SELECT buy.book AS book,buy.num - v_sell.num AS stock
FROM buy,v_sell
WHERE buy.book=v_sell.book;
in CREATE VIEW v_stock alone, it works just fine, and produces table as this:
sqlite> SELECT buy.book AS book,buy.num - v_sell.num AS stock
...> FROM buy,v_sell
...> WHERE buy.book=v_sell.book;
book stock
---------- ----------
1 0
I wonder why VIEW v_stock produces a table which is not exactly the same as the select-
statement created it does. Need some help ... :( |
|
591 |
todo
|
active
|
2004 Feb
|
anonymous
|
Unknown
|
2004 Feb
|
anonymous
|
5
|
4
|
"PRAGMA table_info" doesn't show you which column is unique
|
edit |
"PRAGMA table_info" doesn't show you which column is unique.
If we want to know if any column is unique, we have to use this query : select **** from sqlite_master. |
|
590 |
new
|
active
|
2004 Jan
|
anonymous
|
Parser
|
2004 Jan
|
|
5
|
4
|
Treat ` like spaces outside of quoted strings.
|
edit |
Mysql allows the usage of ` for quoting field names in queries. SQLite interrupts with "unrecognized token". To improve compatibility with mysql ` should either be handled correctly or simply ignored.
For ignoring ` the following code can be used:
case ' ': case '\t': case '\n': case '\f': case '\r': case '`': {
for(i=1; isspace(z[i]) || z[i] == '`'; i++){}
starting at line 224 in tokenize.c
I know that this is a dirty enhancement but the structure of tokenize.c is rather unknown to me... |
|
588 |
new
|
active
|
2004 Jan
|
anonymous
|
|
2004 Jan
|
|
5
|
4
|
Please provide support for NULLS LAST in ORDER BY clauses.
|
edit |
Would be nice to be able to specify NULLS LAST in ORDER BY clauses to force nulls to end of sort order. (Oracle provides this feature) |
|
575 |
code
|
active
|
2004 Jan
|
anonymous
|
VDBE
|
2004 Mar
|
drh
|
3
|
3
|
pragma (default_)temp_store implementations seems incomplete
|
edit |
This problem is a conflict between documented behaviour and actual behaviour, and could fall in the 'Documentation' category as well.
There seems to be a problem with 'pragma default_temp_store'. In pragma.c code exists to handle it, and that code stores the provided value in Cookie 5 (as VDBE instruction argument; that is the sixth metadata integer, and would correspond to meta[6] in sqliteInitOne() in main.c).
However, the code loading a database (the aforementioned sqliteInitOne() in main.c) never looks at that value, and the setting is ignored. (Also, Vacuum doesn't seem to copy it.)
A related problem is that using the default_temp_store or temp_store pragma's doesn't work as advertised, at least not in the precompiled commandline tool sqlite.exe: you will always get the following error, even if you use the pragma at init time:
SQL error: The temporary database already exists - its location cannot now be changed
Trying to set the flag (the value at offset 0x50 in a database file) to 2 (attempting to force an in-memory database for temp tables) with a hex editor has only partial success: the handcrafted value is reported by pragma default_temp_store; but typing .databases still shows a file name for the temporary data base, and using the filemon tool (a windows file activity monitor, downloadable from www.sysinternals.com) shows that the temp file is actually accessed when giving a 'create temp table' command (not surprising, if there is no code to actually ever initialize the db->temp_store from the Cookie).
If for some reason it is infeasible to circumvent the issue that the temp table will always be open before executing the pragma, I suggest changing the semantics of pragma default_temp_store to only change the default (as stored in the file), but not change the current value. This would allow executing pragma default_temp_store even while a temp table is open (though its effect will only be visible when the database is opened again).
Note that this issue has a few documentation issues:
- lang.html suggests that pragma default_temp_store and pragma temp_store are currently working. At least in the commandline tool they aren't (I didn't make a dedicated test program to see if the problem already exists at the C-API level)
- fileformat.html doesn't document the location where the temp_store flag is stored. In fact, I consider the fact that the fifth meta value (meta[5] a.k.a. Cookie 4) is seemingly not used anywhere slightly suspicious.
- the number of metadata values is documented inconsistently in fileformat.html: in one place it mentions there are 6 values including the two leading values (which makes 4 metavalues), a bit later 9 metavalues are mentioned...
|
|
572 |
new
|
active
|
2004 Jan
|
anonymous
|
Unknown
|
2004 Jan
|
drh
|
3
|
3
|
sqlite 2.8.11 port to djgpp
|
edit |
hello friends
here is a patch to be applied to sqlite 2.8.11 to work with djgpp in a short file names environment.
it's a very small piece of code patches, but i will explicitly stick to the sqlite copyright policy:
The author or authors of this code dedicate any and all copyright interest in this code to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights this code under copyright law.
please apply this patch to the mainstream sources, for the benefit of all dos djgpp users.
best regards,
alex |
|
566 |
new
|
active
|
2004 Jan
|
anonymous
|
Unknown
|
2004 Jan
|
|
4
|
4
|
[PATCH] Port of sqlite and lemon to an EBCDIC mainframe
|
edit |
I have ported sqlite (and lemon - to bootstrap sqlite) to a mainframe
which features a POSIX subsystem, but in which all files are stored in
EBCDIC, not in ASCII. Very few places in sqlite have codeset
dependencies, so the resulting patch is rather small.
I have not tested tcl (lacking a tcl-ebcdic port).
I tested with a 3MB database of german bank codes
and compared against a FreeBSD ASCII version.
The diffs for lemon are ~280 lines.
Martin Kraemer
|
The Attachment contains the complete patch to make 2.8.9...2.8.11
compile & run on our EBCDIC platform. |
|
563 |
new
|
active
|
2004 Jan
|
anonymous
|
Parser
|
2004 Jan
|
|
4
|
3
|
Support for autoincrement type "SERIAL" (from PostgreSQL)
|
edit |
I am porting my application from PostgreSQL to SQLite but I want to keep it backwards compatible. With PostgreSQL autoincrement fields are created with type SERIAL. For example:
CREATE TABLE t1(
a SERIAL PRIMARY KEY,
b INTEGER);
And statements like:
INSERT INTO t1 VALUES(default,123);
are used to create rows with automatically increased ids. |
|
560 |
warn
|
active
|
2004 Jan
|
anonymous
|
|
2004 Jan
|
|
4
|
4
|
Warnings on commpiling using Visual C++ 6.0
|
edit |
Hello,
I tried to create static library using Visual C++ to make SQLite internal library of my project. When I compile SQLite, I receive 44 warnings:
Compiling...
attach.c
auth.c
btree.c
btree_rb.c
C:\Work\projects\SQLite_lib\src\btree.c(1920) : warning C4761: integral size mismatch in argument; conversion supplied
C:\Work\projects\SQLite_lib\src\btree.c(1922) : warning C4761: integral size mismatch in argument; conversion supplied
C:\Work\projects\SQLite_lib\src\btree.c(537) : warning C4761: integral size mismatch in argument; conversion supplied
C:\Work\projects\SQLite_lib\src\btree.c(541) : warning C4761: integral size mismatch in argument; conversion supplied
C:\Work\projects\SQLite_lib\src\btree.c(559) : warning C4761: integral size mismatch in argument; conversion supplied
C:\Work\projects\SQLite_lib\src\btree.c(503) : warning C4761: integral size mismatch in argument; conversion supplied
C:\Work\projects\SQLite_lib\src\btree.c(504) : warning C4761: integral size mismatch in argument; conversion supplied
C:\Work\projects\SQLite_lib\src\btree.c(440) : warning C4761: integral size mismatch in argument; conversion supplied
C:\Work\projects\SQLite_lib\src\btree.c(451) : warning C4761: integral size mismatch in argument; conversion supplied
build.c
copy.c
date.c
C:\Work\projects\SQLite_lib\src\date.c(234) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(235) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(339) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(340) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(343) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(344) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(345) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(346) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(359) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(360) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(362) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(390) : warning C4244: 'initializing' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(396) : warning C4244: '=' : conversion from 'double ' to 'long ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(503) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(510) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(584) : warning C4244: '+=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(590) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(596) : warning C4244: '+=' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(772) : warning C4244: 'initializing' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(773) : warning C4244: 'initializing' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\date.c(787) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
delete.c
expr.c
func.c
hash.c
insert.c
main.c
opcodes.c
os.c
C:\Work\projects\SQLite_lib\src\os.c(925) : warning C4244: 'initializing' : conversion from '__int64 ' to 'long ', possible loss of data
C:\Work\projects\SQLite_lib\src\os.c(926) : warning C4244: 'initializing' : conversion from '__int64 ' to 'long ', possible loss of data
C:\Work\projects\SQLite_lib\src\os.c(1017) : warning C4244: 'initializing' : conversion from '__int64 ' to 'long ', possible loss of data
C:\Work\projects\SQLite_lib\src\os.c(1018) : warning C4244: 'function' : conversion from '__int64 ' to 'long ', possible loss of data
pager.c
C:\Work\projects\SQLite_lib\src\os.c(1018) : warning C4761: integral size mismatch in argument; conversion supplied
C:\Work\projects\SQLite_lib\src\pager.c(602) : warning C4244: '=' : conversion from '__int64 ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\pager.c(605) : warning C4244: '=' : conversion from '__int64 ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\pager.c(720) : warning C4244: '=' : conversion from '__int64 ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\pager.c(928) : warning C4244: '=' : conversion from '__int64 ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\pager.c(930) : warning C4244: 'return' : conversion from '__int64 ' to 'int ', possible loss of data
parse.c
pragma.c
parse.c(3985) : warning C4761: integral size mismatch in argument; conversion supplied
parse.c(3996) : warning C4761: integral size mismatch in argument; conversion supplied
printf.c
random.c
select.c
C:\Work\projects\SQLite_lib\src\select.c(102) : warning C4018: '==' : signed/unsigned mismatch
shell.c
table.c
tclsqlite.c
tokenize.c
trigger.c
update.c
util.c
vacuum.c
vdbe.c
C:\Work\projects\SQLite_lib\src\vdbe.c(1295) : warning C4244: 'initializing' : conversion from 'double ' to 'int ', possible loss of data
C:\Work\projects\SQLite_lib\src\vdbe.c(1310) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
vdbeaux.c
where.c
Creating library...
|
2004-Jul-22 06:42:15 by anonymous:
Anything happening here ? I actually try to convince my boss to
evaluate SQLite for our project but as long as there are so many
warnings I have no chance. I think it's quite crucial to get a clean
compile, especially those "possible loss of data" warnings are quite
horrible for a database ;-) |
|
558 |
build
|
active
|
2004 Jan
|
anonymous
|
|
2007 Dec
|
|
4
|
4
|
Makefile.in should honor libdir and bindir
|
edit |
Please support non-standard installation layouts by honoring configure's --libdir and --bindir flags rather than hard-coding $(exec_prefix)/lib and $(exec_prefix)/bin. (For instance, the layout we often use on Solaris has parallel "lib" and "lib64" directories under a common prefix.) |
2007-Dec-18 17:29:26 by anonymous:
Why is this ticket not solved? The patch is trivial and solves a real problem.
Thank you.
2007-Dec-18 17:54:46 by drh:
The patch does not apply to the current makefile. And I do not
understand what the -libdir or -bindir options are for or what
they are suppose to do so I do not know how to fix it. |
|
550 |
new
|
active
|
2004 Jan
|
anonymous
|
Unknown
|
2004 Jan
|
anonymous
|
1
|
1
|
change of MASTER_NAME and TEMP_MASTER_NAME definition error
|
edit |
sqlite_master and sqlite_temp_master table name are directly use in main.c, shell.c and vacuum.c so when i try to change MASTER_NAME and TEMP_MASTER_NAME definition in the sqliteInt.h file it returns some errors.
so i replace sqlite_master and sqlite_master_table by "MASTER_NAME" and "TEMP_MASTER_NAME" to solve my problem in
main.c
- at line 195 in static char master_schema[] (in sqliteInitOne)
- at line 203 in static char temp_master_schema[] (in sqliteInitOne)
- at lines 228,230 in static char init_script[] (in sqliteInitOne)
- at lines 232,234,237 in static char older_init_script[] (in sqliteInitOne)
- at line 344 in sqliteInitOne
- at line 492 in sqlite_open
vacuum.c
- at line 293 in int sqliteRunVacuum
- at line 296 in int sqliteRunVacuum
shell.c
- at line 584 in static int do_meta_command
- at line 293 in static int do_meta_command
- at lines 793,795,831,832,872,875,882,885 in static int do_meta_command
|
|
544 |
new
|
active
|
2004 Jan
|
anonymous
|
|
2004 Jan
|
|
5
|
4
|
Feature Request: Indicate UNIQUE columns in table_info.
|
edit |
I goofed with ticket #543. I meant that I thought it would be neat if we had a new column in table_info indicating which columns were UNIQUE. Sorry about that. |
|
540 |
event
|
active
|
2003 Dec
|
drh
|
|
2003 Dec
|
|
1
|
5
|
Database corruption observed
|
edit |
The CVSTrac database for SQLite become corrupt sometime between
2003-12-23 and 2003-12-31. The corruption is visible using
PRAGMA integrity_check;
Note that the EXT3 filesystem on which the database file resided
was corrupted by a power outage during this same time interval.
The EXT3 errors were (allegedly) fixed by fsck. The EXT3 errors
may have been (or was likely) the origin of the database corruption.
The database errors were fixed using
sqlite sqlite.db .dump | sqlite sqlite.db.new
mv sqlite.db.new sqlite.db
The old corrupt database has been saved for analysis.
Unless additional corruption reports come in, we will assume this
was an EXT3 problem, not an SQLite problem. But we want to have
a record of the problem just in case... |
|
539 |
new
|
active
|
2003 Dec
|
anonymous
|
VDBE
|
2003 Dec
|
|
5
|
4
|
Addition of engine 'Suspension' interface
|
edit |
For my use of SQLite I require that the engine be suspended temporarily such that other tasks can be performed. At present SQLite has the ability to be interrupted - stopping the current VM in its tracks and aborting whatever it was doing. This isn't what I required - I just need it to stop doing what it was doing and return to me.
As the system is implemented as a Virtual Machine and is already capable of being suspended by in order to return its results, the suspension of the engine is relatively simple.
The implementation I have used will return the code 'SQLITE_SUSPEND' from an sqlite_step() call if the operation has been suspended. The function sqlite_suspend(sqlite_vm *) is provided to set a flag which will cause the suspend to take effect.
The intended use is within an environment where a co-operative environment where SQLite can run for a period before and interrupt triggers the sqlite_suspend() function. Thus the caller can know that the operation is progressing but no results have been returned before the timeout.
I can create diffs, or supply other information about the information if necessary. Sadly I've only tried this with the sqlite_step() interface, because that's all I've needed it with. My examination of the code implies that it is safe to perform this suspension in this manner, and it has worked very well within my application.
I don't know if it would be of use to others, but I can at least offer it back to anyone who might find a use for it. |
|
538 |
new
|
active
|
2003 Dec
|
anonymous
|
|
2003 Dec
|
|
4
|
3
|
Different warnings in windows
|
edit |
If you want the file, please contact me & I'm happy to send it through
[c:\]diff -up "C:\C++ Programs\DELISprint\SQLite" "sqlite_source_windows" > "new SQLite.txt"
------------------------------------------------diff code
diff -up C:\C++ Programs\DELISprint\SQLite/btree.c sqlite_source_windows/btree.c
--- C:\C++ Programs\DELISprint\SQLite/btree.c Tue Dec 30 22:58:12 2003
+++ sqlite_source_windows/btree.c Wed Dec 17 19:37:30 2003
@@ -65,7 +65,7 @@ static BtCursorOps sqliteBtreeCursorOps;
** X is an unsigned integer. SWAB16 byte swaps a 16-bit integer.
** SWAB32 byteswaps a 32-bit integer.
*/
-#define SWAB16(B,X) ((B)->needSwab? swab16((u16)(X)) : (u16)(X))
+#define SWAB16(B,X) ((B)->needSwab? swab16((u16)X) : ((u16)X))
#define SWAB32(B,X) ((B)->needSwab? swab32(X) : (X))
#define SWAB_ADD(B,X,A) \
if((B)->needSwab){ X=swab32(swab32(X)+A); }else{ X += (A); }
@@ -538,7 +538,7 @@ static void freeSpace(Btree *pBt, MemPag
if( idx + iSize + size == SWAB16(pBt, pFBlk->iNext) ){
pNext = (FreeBlk*)&pPage->u.aDisk[idx + iSize + size];
if( pBt->needSwab ){
- pFBlk->iSize = swab16((u16)(swab16(pNext->iSize)+iSize+size));
+ pFBlk->iSize = swab16((u16)swab16(pNext->iSize)+iSize+size);
}else{
pFBlk->iSize += pNext->iSize;
}
diff -up C:\C++ Programs\DELISprint\SQLite/date.c sqlite_source_windows/date.c
--- C:\C++ Programs\DELISprint\SQLite/date.c Tue Dec 30 22:53:08 2003
+++ sqlite_source_windows/date.c Wed Dec 17 19:37:30 2003
@@ -230,8 +230,8 @@ static void computeJD(DateTime *p){
}
A = Y/100;
B = 2 - A + (A/4);
- X1 = (int)(365.25*(Y+4716));
- X2 = (int)(30.6001*(M+1));
+ X1 = 365.25*(Y+4716);
+ X2 = 30.6001*(M+1);
p->rJD = X1 + X2 + D + B - 1524.5;
p->validJD = 1;
p->validYMD = 0;
@@ -335,14 +335,14 @@ static int parseDateOrTime(const char *z
static void computeYMD(DateTime *p){
int Z, A, B, C, D, E, X1;
if( p->validYMD ) return;
- Z = (int)(p->rJD + 0.5);
- A = (int)((Z - 1867216.25)/36524.25);
+ Z = p->rJD + 0.5;
+ A = (Z - 1867216.25)/36524.25;
A = Z + 1 + A - (A/4);
B = A + 1524;
- C = (int)((B - 122.1)/365.25);
- D = (int)(365.25*C);
- E = (int)((B-D)/30.6001);
- X1 = (int)(30.6001*E);
+ C = (B - 122.1)/365.25;
+ D = 365.25*C;
+ E = (B-D)/30.6001;
+ X1 = 30.6001*E;
p->D = B - D - X1;
p->M = E<14 ? E-1 : E-13;
p->Y = p->M>2 ? C - 4716 : C - 4715;
@@ -355,10 +355,10 @@ static void computeYMD(DateTime *p){
static void computeHMS(DateTime *p){
int Z, s;
if( p->validHMS ) return;
- Z = (int)(p->rJD + 0.5);
- s = (int)((p->rJD + 0.5 - Z)*86400000.0 + 0.5);
+ Z = p->rJD + 0.5;
+ s = (p->rJD + 0.5 - Z)*86400000.0 + 0.5;
p->s = 0.001*s;
- s = (int)(p->s);
+ s = p->s;
p->s -= s;
p->h = s/3600;
s -= p->h*3600;
@@ -422,14 +422,14 @@ static int parseModifier(const char *zMo
** to "start of day".
*/
if( strncmp(z, "weekday ", 8)==0 && getValue(&z[8],&r)>0
- && (n=(int)(r))==r && n>=0 && r<7 ){
+ && (n=r)==r && n>=0 && r<7 ){
int Z;
computeYMD(p);
p->validHMS = 0;
p->validTZ = 0;
p->validJD = 0;
computeJD(p);
- Z = (int)(p->rJD + 1.5);
+ Z = p->rJD + 1.5;
Z %= 7;
if( Z>n ) Z -= 7;
p->rJD += n - Z;
@@ -503,19 +503,19 @@ static int parseModifier(const char *zMo
}else if( n==5 && strcmp(z,"month")==0 ){
int x, y;
computeYMD(p);
- p->M += (int)(r);
+ p->M += r;
x = p->M>0 ? (p->M-1)/12 : (p->M-12)/12;
p->Y += x;
p->M -= x*12;
p->validJD = 0;
computeJD(p);
- y = (int)(r);
+ y = r;
if( y!=r ){
p->rJD += (r - y)*30.0;
}
}else if( n==4 && strcmp(z,"year")==0 ){
computeYMD(p);
- p->Y += (int)(r);
+ p->Y += r;
p->validJD = 0;
computeJD(p);
}else{
@@ -691,8 +691,8 @@ static void strftimeFunc(sqlite_func *co
switch( zFmt[i] ){
case 'd': sprintf(&z[j],"%02d",x.D); j+=2; break;
case 'f': {
- int s = (int)(x.s);
- int ms = (int)((x.s - s)*1000.0);
+ int s = x.s;
+ int ms = (x.s - s)*1000.0;
sprintf(&z[j],"%02d.%03d",s,ms);
j += strlen(&z[j]);
break;
@@ -706,7 +706,7 @@ static void strftimeFunc(sqlite_func *co
y.M = 1;
y.D = 1;
computeJD(&y);
- n = (int)(x.rJD - y.rJD + 1);
+ n = x.rJD - y.rJD + 1;
if( zFmt[i]=='W' ){
sprintf(&z[j],"%02d",(n+6)/7);
j += 2;
diff -up C:\C++ Programs\DELISprint\SQLite/os.c sqlite_source_windows/os.c
--- C:\C++ Programs\DELISprint\SQLite/os.c Tue Dec 30 22:42:48 2003
+++ sqlite_source_windows/os.c Wed Dec 17 19:37:30 2003
@@ -258,7 +258,7 @@ int sqliteOsDelete(const char *zFilename
unlink(zFilename);
#endif
#if OS_WIN
- DeleteFileA(zFilename);
+ DeleteFile(zFilename);
#endif
#if OS_MAC
unlink(zFilename);
@@ -274,7 +274,7 @@ int sqliteOsFileExists(const char *zFile
return access(zFilename, 0)==0;
#endif
#if OS_WIN
- return GetFileAttributesA(zFilename) != 0xffffffff;
+ return GetFileAttributes(zFilename) != 0xffffffff;
#endif
#if OS_MAC
return access(zFilename, 0)==0;
@@ -350,7 +350,7 @@ int sqliteOsOpenReadWrite(
return SQLITE_OK;
#endif
#if OS_WIN
- HANDLE h = CreateFileA(zFilename,
+ HANDLE h = CreateFile(zFilename,
GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
@@ -359,7 +359,7 @@ int sqliteOsOpenReadWrite(
NULL
);
if( h==INVALID_HANDLE_VALUE ){
- h = CreateFileA(zFilename,
+ h = CreateFile(zFilename,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
@@ -482,7 +482,7 @@ int sqliteOsOpenExclusive(const char *zF
}else{
fileflags = FILE_FLAG_RANDOM_ACCESS;
}
- h = CreateFileA(zFilename,
+ h = CreateFile(zFilename,
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
@@ -556,7 +556,7 @@ int sqliteOsOpenReadOnly(const char *zFi
return SQLITE_OK;
#endif
#if OS_WIN
- HANDLE h = CreateFileA(zFilename,
+ HANDLE h = CreateFile(zFilename,
GENERIC_READ,
0,
NULL,
@@ -679,7 +679,7 @@ int sqliteOsTempFileName(char *zBuf){
"0123456789";
int i, j;
char zTempPath[SQLITE_TEMPNAME_SIZE];
- GetTempPathA(SQLITE_TEMPNAME_SIZE-30, zTempPath);
+ GetTempPath(SQLITE_TEMPNAME_SIZE-30, zTempPath);
for(i=strlen(zTempPath); i>0 && zTempPath[i-1]=='\\'; i--){}
zTempPath[i] = 0;
for(;;){
@@ -899,8 +899,8 @@ int sqliteOsSeek(OsFile *id, off_t offse
#endif
#if OS_WIN
{
- LONG upperBits = (LONG) (offset>>32);
- LONG lowerBits = (LONG) (offset & 0xffffffff);
+ LONG upperBits = offset>>32;
+ LONG lowerBits = offset & 0xffffffff;
DWORD rc;
rc = SetFilePointer(id->h, lowerBits, &upperBits, FILE_BEGIN);
/* TRACE3("SEEK rc=0x%x upper=0x%x\n", rc, upperBits); */
@@ -991,8 +991,8 @@ int sqliteOsTruncate(OsFile *id, off_t n
#endif
#if OS_WIN
{
- LONG upperBits = (LONG) (nByte>>32);
- SetFilePointer(id->h, (LONG) (nByte), &upperBits, FILE_BEGIN);
+ LONG upperBits = nByte>>32;
+ SetFilePointer(id->h, nByte, &upperBits, FILE_BEGIN);
SetEndOfFile(id->h);
}
return SQLITE_OK;
@@ -1576,10 +1576,10 @@ char *sqliteOsFullPathname(const char *z
char *zNotUsed;
char *zFull;
int nByte;
- nByte = GetFullPathNameA(zRelative, 0, 0, &zNotUsed) + 1;
+ nByte = GetFullPathName(zRelative, 0, 0, &zNotUsed) + 1;
zFull = sqliteMalloc( nByte );
if( zFull==0 ) return 0;
- GetFullPathNameA(zRelative, nByte, zFull, &zNotUsed);
+ GetFullPathName(zRelative, nByte, zFull, &zNotUsed);
return zFull;
#endif
#if OS_MAC
diff -up C:\C++ Programs\DELISprint\SQLite/pager.c sqlite_source_windows/pager.c
--- C:\C++ Programs\DELISprint\SQLite/pager.c Tue Dec 30 22:45:48 2003
+++ sqlite_source_windows/pager.c Wed Dec 17 19:37:30 2003
@@ -599,17 +599,17 @@ static int pager_playback(Pager *pPager,
rc = read32bits(format, &pPager->jfd, &pPager->cksumInit);
if( rc ) goto end_playback;
if( nRec==0xffffffff || useJournalSize ){
- nRec = (int) ((szJ - JOURNAL_HDR_SZ(3))/JOURNAL_PG_SZ(3));
+ nRec = (szJ - JOURNAL_HDR_SZ(3))/JOURNAL_PG_SZ(3);
}
}else{
- nRec = (int) ((szJ - JOURNAL_HDR_SZ(2))/JOURNAL_PG_SZ(2));
+ nRec = (szJ - JOURNAL_HDR_SZ(2))/JOURNAL_PG_SZ(2);
assert( nRec*JOURNAL_PG_SZ(2)+JOURNAL_HDR_SZ(2)==szJ );
}
rc = read32bits(format, &pPager->jfd, &mxPg);
if( rc!=SQLITE_OK ){
goto end_playback;
}
- assert( pPager->origDbSize==0 || pPager->origDbSize==(int)(mxPg) );
+ assert( pPager->origDbSize==0 || pPager->origDbSize==mxPg );
rc = sqliteOsTruncate(&pPager->fd, SQLITE_PAGE_SIZE*(off_t)mxPg);
if( rc!=SQLITE_OK ){
goto end_playback;
@@ -717,7 +717,7 @@ static int pager_ckpt_playback(Pager *pP
if( rc!=SQLITE_OK ){
goto end_ckpt_playback;
}
- nRec = (int)((szJ - pPager->ckptJSize)/JOURNAL_PG_SZ(journal_format));
+ nRec = (szJ - pPager->ckptJSize)/JOURNAL_PG_SZ(journal_format);
for(i=nRec-1; i>=0; i--){
rc = pager_playback_one_page(pPager, &pPager->jfd, journal_format);
if( rc!=SQLITE_OK ){
@@ -925,9 +925,9 @@ int sqlitepager_pagecount(Pager *pPager)
}
n /= SQLITE_PAGE_SIZE;
if( pPager->state!=SQLITE_UNLOCK ){
- pPager->dbSize = (int)(n);
+ pPager->dbSize = n;
}
- return (int)(n);
+ return n;
}
/*
diff -up C:\C++ Programs\DELISprint\SQLite/parse.c sqlite_source_windows/parse.c
--- C:\C++ Programs\DELISprint\SQLite/parse.c Tue Dec 30 23:00:24 2003
+++ sqlite_source_windows/parse.c Wed Dec 17 19:37:30 2003
@@ -3982,7 +3982,7 @@ void sqliteParser(
yyTracePrompt,yyTokenName[yymajor]);
}
#endif
- yy_destructor((YYCODETYPE)(yymajor),&yyminorunion);
+ yy_destructor(yymajor,&yyminorunion);
yymajor = YYNOCODE;
}else{
while(
@@ -3993,7 +3993,7 @@ void sqliteParser(
yy_pop_parser_stack(yypParser);
}
if( yypParser->yyidx < 0 || yymajor==0 ){
- yy_destructor((YYCODETYPE)(yymajor),&yyminorunion);
+ yy_destructor(yymajor,&yyminorunion);
yy_parse_failed(yypParser);
yymajor = YYNOCODE;
}else if( yypParser->yytop->major!=YYERRORSYMBOL ){
diff -up C:\C++ Programs\DELISprint\SQLite/select.c sqlite_source_windows/select.c
--- C:\C++ Programs\DELISprint\SQLite/select.c Tue Dec 30 22:46:48 2003
+++ sqlite_source_windows/select.c Wed Dec 17 19:37:30 2003
@@ -98,7 +98,7 @@ int sqliteJoinType(Parse *pParse, Token
for(i=0; i<3 && apAll[i]; i++){
p = apAll[i];
for(j=0; j<sizeof(keywords)/sizeof(keywords[0]); j++){
- if( (int)(p->n)==keywords[j].nChar
+ if( p->n==keywords[j].nChar
&& sqliteStrNICmp(p->z, keywords[j].zKeyword, p->n)==0 ){
jointype |= keywords[j].code;
break;
diff -up C:\C++ Programs\DELISprint\SQLite/vdbe.c sqlite_source_windows/vdbe.c
--- C:\C++ Programs\DELISprint\SQLite/vdbe.c Tue Dec 30 22:53:08 2003
+++ sqlite_source_windows/vdbe.c Wed Dec 17 19:37:30 2003
@@ -1292,7 +1292,7 @@ case OP_MustBeInt: {
if( aStack[tos].flags & STK_Int ){
/* Do nothing */
}else if( aStack[tos].flags & STK_Real ){
- int i = (int)(aStack[tos].r);
+ int i = aStack[tos].r;
double r = (double)i;
if( r!=aStack[tos].r ){
goto mismatch;
@@ -1307,7 +1307,7 @@ case OP_MustBeInt: {
}
Realify(p, tos);
assert( (aStack[tos].flags & STK_Real)!=0 );
- v = (int)(aStack[tos].r);
+ v = aStack[tos].r;
r = (double)v;
if( r!=aStack[tos].r ){
goto mismatch;
------------------------------------------------diff code |
|
525 |
new
|
active
|
2003 Dec
|
anonymous
|
|
2003 Dec
|
|
4
|
4
|
DB testing
|
edit |
Hello,
I have a user wich finds it annoying that non-sqlite db files can be opened (or seems to be).
Would be nice to have an option like create always and open existing etc.. similar to createfile() api
Thanks,
Edwin Knoppert |
|
524 |
new
|
active
|
2003 Dec
|
anonymous
|
Unknown
|
2003 Dec
|
|
2
|
1
|
port of sqlite to dos with short file names
|
edit |
i'm just appending a patch i made to work with sqlite on dos with djgpp. see the wiki for backgrounds.
i hereby dedicate any and all copyright interest in this code to the public domain. i make this dedication for the benefit of the public at large and to the detriment of my heirs and successors. i intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights this code under copyright law. |
|
518 |
code
|
active
|
2003 Dec
|
anonymous
|
Unknown
|
2006 Aug
|
|
3
|
4
|
PRIMARY KEY does not imply UNIQUE and NOT NULL
|
edit |
According to SQL92 and Dr. Hipp, PRIMARY KEY should imply both NOT NULL and UNIQUE. It does not. The following statements exhibit the problem:
CREATE TABLE User ( Name VARCHAR (40),
UID INTEGER,
DeviceID VARCHAR (64),
PRIMARY KEY (Name, UID, DeviceID) );
INSERT INTO User (Name,DeviceID) VALUES ('Michael','Test');
INSERT INTO User (Name,DeviceID) VALUES ('Michael','Test');
Gets me two rows with ('Michael',NULL,'Test'). |
2005-Jan-03 01:46:01 by drh:
See http://www.sqlite.org/nulls.html.
SQLite considers NULLs to be distinct.
PostgreSQL, Oracle, MySQL, and Firebird all work this way.
Informix and MS-SQL work differently.
Works as designed.
2006-Aug-26 07:29:58 by anonymous:
as far as I can see, the closing remark applies to the UNIQUEness of NULL values, not the NOT NULLness of PRIMARY KEYs (or part of that).
let's see what some engines do:
PostgreSQL:
biblioteca=> CREATE TABLE test (
Name VARCHAR (40),
UID INTEGER,
DeviceID VARCHAR (64),
PRIMARY KEY (Name, UID, DeviceID) );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "test_pkey" for table "test"
CREATE TABLE
biblioteca=> insert into test(Name, DeviceID) values ('Michael', 'test');
ERROR: null value in column "uid" violates not-null constraint
MySQL:
mysql> CREATE TABLE test (
Name VARCHAR (40),
UID INTEGER,
DeviceID VARCHAR (64),
PRIMARY KEY (Name, UID, DeviceID) );
Query OK, 0 rows affected (0.07 sec)
mysql> insert into test(Name, DeviceID) values ('Michael', 'test');
Query OK, 1 row affected (0.11 sec)
mysql> insert into test(Name, DeviceID) values ('Michael', 'test');
ERROR 1062 (23000): Duplicate entry 'Michael-0-test' for key 1
that is: it MySQL is also not allowing NULL primary keys and is silently replacing NULL values with 0.
Oracle:
CREATE TABLE test (
Name VARCHAR (40),
UniqueID INTEGER,
DeviceID VARCHAR (64),
PRIMARY KEY (Name, UniqueID, DeviceID) );
insert into test(Name, DeviceID) values ('Michael', 'test');
ORA-01400: impossibile inserire NULL in ("IBOTEST"."TEST"."UNIQUEID")
I hope no-one will disagree if I reopen the ticket.
2006-Aug-29 11:51:00 by anonymous:
behaviour with the patch:
sqlite> CREATE TABLE User ( Name VARCHAR (40),
...> UID INTEGER,
...> DeviceID VARCHAR (64),
...> PRIMARY KEY (Name, UID, DeviceID) );
sqlite> INSERT INTO User (Name,DeviceID) VALUES ('Michael','Test');
SQL error: User.UID may not be NULL
sqlite> INSERT INTO User (Name,DeviceID) VALUES ('Michael','Test');
SQL error: User.UID may not be NULL
2006-Aug-29 13:10:37 by drh:
To my great surprise, I discovered that SQLite has allowed NULL
values in PRIMARY KEY columns for a very long time. This is a bug.
But the bug has been in the code for so long, that we fear fixing
it might break legacy applications. So for now we have chosen to
merely document the fact that the bug exists and to warn developers
not to depend on it since it might be fixed at some unspecified
point in the future.
2006-Aug-29 19:54:12 by anonymous:
Can you put a SQLITE_ENABLE_NOTNULL_PRIMARYKEYS #ifdef and apply this patch to the official tree? This may solve the problems with legacy code and solve the SQL issue |
|
517 |
new
|
active
|
2003 Dec
|
anonymous
|
Parser
|
2003 Dec
|
drh
|
1
|
1
|
\' sequence unrecognized token error enhancement request
|
edit |
per an email exchange with Richard on 12/6/03, am requesting an enhancement to handle a situation where a sequence of \' in a SQL INSERT INTO data stream causes an unrecognized token error. This occurs when attempting to reload data that has been dumped with the phpMyAdmin application.
There are a number of allowed escape sequences in MySQL namely:
\0 => NUL (ASCII 0)
\'
\"
\b
\n
\r
\t
\\
\z |
|
510 |
new
|
active
|
2003 Nov
|
anonymous
|
Unknown
|
2003 Nov
|
|
5
|
2
|
trigger: addition of create ability
|
edit |
this code COULD be implemented outside the .sql script, but if this were possible it would cut that code by about 70-80%! not to mention makes it 10x easier to handle the db.
this is only a chunk:
/* create group info table on addtion to master group list /*
create trigger group_make_new after insert on group_list
begin
/* make table of users for group /*
create table group_[new.groupID] (
userID unique,
userlevel
);
/* insert owner as a member /*
insert into group_[new.groupID] values (new.owner,3);
end;
note: you'll have to fix the comments cause of this posting format.... |
|
509 |
event
|
active
|
2003 Nov
|
anonymous
|
|
2003 Nov
|
|
5
|
3
|
SQLite on Pocket PC - question - how to do that step by step?
|
edit |
Hi!
First of all I really appreciate work you guys did with SQLite.
My question is; can anyone tell me how can I create the SQLite version working with Unicode (_UNICODE defined on Win32) on Pocket PC platform. The case is I am creating application for pocket PC to cooperate with PC computer, and while I create and access database on the PC, I cant open or even create new database on Pocket PC. I was succesfull in compiling SQLite as it is ported to CE but always I get the error that the database disk image is malformed, even if I am creating new database.
Does any one was successful in creating and accessing database on Pocket PC and then in copying it to PC and accessing it on PC? I will not stick to Unicode since I am converting the wide char to char but this is not helping in avoiding the malformed error while creating or accessing database.
I would appreciate any help, I am quit new bee for database sources and SQLite looks for me quite complex to get into it.
Artur |
2004-Aug-20 09:14:36 by anonymous:
I have the same problem. I create a little parser using scripts for traslating a MySQL database to SQLite database. I pass the db file with ActiveSync. I open the file correctly with a XML generator that I create with Visual Studio, but I'm trying to do the same project with eMbedded Visual C++ 4.0 and I have a lot of errors.
Can anybody help me?
Thanks a lot.
aaronpl@ya.com
2005-May-11 14:30:47 by anonymous:
Am also trying to port sqlite3.2.1 to WinCE, and have many errors in eMbeddedVC++ Version 4 sp4, mainly
btree.c(549) : error C2059: syntax error : 'type'
Error in line assert( iCell<int(get2byte(&data[pPage->hdrOffset+3])) );
btree.c(601) : warning C4244: '+=' : conversion from '__int64 ' to 'unsigned int ', possible loss of data
Many errors of this form, this line nPayload += pInfo->nKey;
os_win.c(394) : error C2065: 'LOCKFILE_FAIL_IMMEDIATELY' : undeclared identifier
Error in line res = LockFileEx(id->h, LOCKFILE_FAIL_IMMEDIATELY, 0, SHARED_SIZE,0,&ovlp);
|
|
508 |
doc
|
active
|
2003 Nov
|
anonymous
|
|
2003 Nov
|
|
4
|
4
|
Build instructions on home page needs link to page with platform help
|
edit |
I just ran across SQLite and wanted to try to build it for Mac OS X. It seemed to build but kept failing the "make test" step. I dug around your site, then started googling trying to find information on building SQLite for Mac OS X. After quite a bit of searching, I finally found a link to a wiki page for cvstrac that told me exactly what I needed to know.
It would be handy for other folks in the future if the following link was included in the "Building From Source" section on the main page.
http://www.sqlite.org/cvstrac/wiki?p=HowToCompile |
|
503 |
warn
|
active
|
2003 Nov
|
anonymous
|
Unknown
|
2003 Dec
|
anonymous
|
5
|
2
|
Include sqlite source in Visual C++ 6.0 SP5
|
edit |
when I try to use sqlite source in my VC6 project,there a lot of errors with compile,then I change the precompiled header setting to NONE,now no errors,but there so many warning about type,I suggest forced convertion type should be used then it will look more official,and there a "( )" should be inside the MACRO defination for SWAB16(?). |
|
501 |
doc
|
active
|
2003 Nov
|
anonymous
|
Unknown
|
2003 Nov
|
anonymous
|
4
|
4
|
missing sqlite_encode_binary
|
edit |
The FAQ discusses a pair of functions for binary<-->ASCII encoding in "encode.c". I grabbed the windows "pre-processed" c files and there is no such file. Nor do I see any mention of those functions (sqlite_encode_binary) in the C/C++ documentation on the website. Was this removed for some reason? Either the FAQ needs updating or the code/docs do. |
|
500 |
doc
|
active
|
2003 Nov
|
anonymous
|
Unknown
|
2003 Nov
|
|
4
|
4
|
Discrepancies in comments in encode.c
|
edit |
The explanation for how the encoder works in src/encode.c says that the offset is added on encoding and subtracted on decoding. However, in the actual source code the reverse is true (i.e., the offset is subtracted in sqlite_encode_binary() and added in sqlite_decode_binary()). Presumably the source is correct, so the comments should be corrected to reflect this. |
|
498 |
new
|
active
|
2003 Nov
|
anonymous
|
Unknown
|
2003 Nov
|
|
4
|
4
|
Suggestion: Allow named parameters.
|
edit |
The ability to add parameters using "?" is great. However, it would be even better if you could add a meaningful names to the parameters. This would be just for human purposes, as the parser could just ignore the names.
For example:
"insert into mytable values (?, ?, ?)"
could be written like
"insert into mytable values (?Day, ?Month, ?Year)" |
Named parameters could also be used to allow a parameter to appear multiple times in a single query, and yet only require a single call to sqlite_bind to set its value. For example
SELECT quantity FROM Inventory WHERE :price < 10 OR :price > 100;
would only require a single call to sqlite_bind to set the value of the :price parameter. This feature becomes more valuable with complex queries where multiple sub-selects may require the same parameter.
Implementing this feature outside SQLite would require parsing the SQL statments to locate the named parameters, substituting the positional parameters, then using the existing API to set the value of the positional parameters. This seems wasteful since SQLite will have to parse the same SQL statement again to extract the positional parameters.
The colon, ":", is used by SQL:1999 as the standard prefix to denote parameter names, and should probably be adopted by SQLite as well if named parameters are implemented. |
|
496 |
build
|
active
|
2003 Nov
|
anonymous
|
|
2003 Nov
|
|
1
|
1
|
SQLite Ignores Autoconf Options
|
edit |
When I entered the following command to configure SQLite before
installation:
./configure \
--prefix=/home/adam02/bx3-in/xplc/miscres \
--bindir=/home/adam02/bx3-in/basics/bin \
--libexecdir=/home/adam02/bx3-in/bin-tools \
--libdir=/home/adam02/bx3-in/basics/library-directory \
--mandir=/home/adam02/bx3-docs/man
it seems as though all the options that I entered, with the
exception of "--prefix", were ignored.
This is a serious problem that completely prevents any
system of customized installation from working. |
|
495 |
build
|
active
|
2003 Nov
|
anonymous
|
|
2003 Nov
|
|
1
|
1
|
Makefile syntax errors
|
edit |
When I run make I get this:
"Makefile", line 72: Missing dependency operator
"Makefile", line 74: Need an operator
"Makefile", line 89: Missing dependency operator
"Makefile", line 91: Need an operator
make: fatal errors encountered -- cannot continue
|
What operating system?
What steps did you follow to get to this point? |
|
493 |
event
|
active
|
2003 Nov
|
anonymous
|
Unknown
|
2003 Nov
|
|
3
|
3
|
Problem compiling sqlite
|
edit |
# gmake
./libtool gcc -s -O3 -march=i686 -DOS_UNIX=1 -DOS_WIN=0 -DHAVE_USLEEP=1 -I. -I./src -DHAVE_READLINE=1 -I/usr/local/include/readline -o sqlite ./src/shell.c \
libsqlite.la -lreadline -rpath /usr/local/lib
gcc -s -O3 -march=i686 -DOS_UNIX=1 -DOS_WIN=0 -DHAVE_USLEEP=1 -I. -I./src -DHAVE_READLINE=1 -I/usr/local/include/readline -o .libs/sqlite ./src/shell.c ./.libs/libsqlite.so -lreadline -Wl,--rpath -Wl,/usr/local/lib
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../../libreadline.so: undefined reference to `tgetnum'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../../libreadline.so: undefined reference to `tgoto'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../../libreadline.so: undefined reference to `tgetflag'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../../libreadline.so: undefined reference to `BC'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../../libreadline.so: undefined reference to `tputs'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../../libreadline.so: undefined reference to `PC'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../../libreadline.so: undefined reference to `tgetent'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../../libreadline.so: undefined reference to `UP'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../../libreadline.so: undefined reference to `tgetstr'
collect2: ld returned 1 exit status
gmake: *** [sqlite] Error 1
|
|
491 |
new
|
active
|
2003 Nov
|
anonymous
|
|
2003 Nov
|
|
4
|
4
|
Want to use SET col = 'val' with INSERT statement
|
edit |
It would be nice if the an additional INSERT syntax is supported because:
1) This makes migrating from MySQL to SQLite easier.
2) The body of UPDATE and INSERT statements are the same using this syntax which makes developing faster and easier.
The exact syntax:
INSERT [INTO] tbl_name
SET col_name=(expression | DEFAULT), ...
(From: http://www.mysql.com/doc/en/INSERT.html) |
2004-Mar-14 22:29:54 by anonymous:
I'd like to second this item. From my readings, this is a documented feature of SQL92, and from my own use of SQL in programming languages, it's far easier to use the SET syntax over the VALUES syntax for manipulation queries.
2004-May-10 10:20:25 by anonymous:
My vote on this one too! When this is implemented, we can finally switch with our entire product range to sqlite :). |
|
490 |
new
|
active
|
2003 Nov
|
anonymous
|
VDBE
|
2003 Nov
|
xdong
|
4
|
3
|
a few api improvements for recordset operations
|
edit |
hi friends,
i'm working on a visual user interface for sqlite under dos. sqlite works great and i will post a patch for short file name support. there are a few api enhancements needed for automatic synchronization of data in a recordset with the database.
1. please add a new format in printf (like %k) to convert a string to a valid sql identifier. (like rename field "from" to "[from]").
2. additional information on a selection result will be great also: add the source table name for each column, and the rowid of each field coming from a table. a timestamp for each such field will also be of great importance, though i understand it is not present in the current code. this information will be repeated of course when there are several fields of the same table, and other way to have this information will be welcome too (such like querying the vdbe for each column of interest, every row).
3. please provide a structured way to query the fields information for a table, index, view or view order part.
4. the database dump facility should be provided as an atomic routine in the utils library.
best regards,
alex |
|
489 |
new
|
active
|
2003 Nov
|
anonymous
|
|
2008 Jan
|
|
4
|
4
|
DLL exports suggestion
|
edit |
Just a suggestion:
I'm building SQLite using MS C++, and an easily maintained alternative to a .def file for the DLL exports is to incorporate the following into the sqlite.h header...
#ifdef _MSC_VER
#ifdef SQLITE_EXPORTS
#define SQLITE_API __declspec(dllexport)
#else
#define SQLITE_API __declspec(dllimport)
#endif
#else
#define SQLITE_API
#endif
// example function declaration
SQLITE_API void sqlite_close(sqlite *);
SQLITE_EXPORTS is defined when building the library, but not when building client applications.
I don't know if other compilers have similar methods of defining library exports, but if so, this could possibly be extended to support them. |
2008-Jan-11 01:58:27 by anonymous:
There is a good reason for adding this feature in some form other than merely avoiding the manual import library creation step.
When __declspec(dllimport) is used, it is a hint to MSVC++ to produce more efficient code. This allows the function in the DLL to be called in a single call. Otherwise there is an extra jmp (2 in Debug mode). So those that want maximum performance out of C and DLL combo should take note. I patched this into my copy of the source.
But the code given in the ticket assumes that the library is used as a DLL and not statically linked in which case dllimport shouldn't be used.
-- Bz
2008-Jan-11 13:28:27 by drh:
The prefix SQLITE_API appears in front of all interfaces in the
amalgamation. So it seems
like this problem could be solved by adding
-DSQLITE_API=__declspec(dllexport)
to the compiler command line. No?
2008-Jan-12 07:16:44 by anonymous:
Yes -DSQLITE_API will do, and also it is necessary to define SQLITE_EXTERN because some data symbols:
sqlite3_version[]
sqlite3_temp_directory
sqlite3_io_trace
are forward declared with SQLITE_EXTERN but defined with SQLITE_API and these must match.
But like I mentioned, this is only half of the issue. The other half is the small performance boost from __declspec(dllimport). It would be nice to have SQLITE_API prefixes in sqlite3.h for users of the DLL. It's low priority, but I thought I would point this out.
Another thing to note is that using __declspec(dllexport) instead of DEF file along with the (non default) stdcall convention (callee cleans up the stack) will result in function names in DLL export table being mangled with numeric suffixes. If one links through the auto generated import lib file, this isn't an issue, but it affects looking up a function name with GetProcAddress(). So the DEF file (the original intent of the ticket before I hijacked it) has a benefit in this case. But to use the stdcall convention properly there would have to be yet another prefix for the benefit of clients using the default cdecl convention:
#define SQLITE_CALL
#define SQLITE_CALL __stdcall
SQLITE_API int SQLITE_CALL sqlite3_open(
const char *filename,
sqlite3 **ppDb
);
The 2 prefixes is what MS does with their API functions. I assume there is some small performance boost from __stdcall.
-- Bz
2008-Jan-13 02:02:38 by sdwilsh:
See also Ticket #2448 |
|
486 |
new
|
active
|
2003 Oct
|
anonymous
|
VDBE
|
2003 Oct
|
|
5
|
4
|
index on expressions (general solution to case-insensitive problem)
|
edit |
Hi.
Just wanted to throw a suggestion for this very useful database:
It would be very useful to be able to have indexes that use expressions rather than column names (and have the query optimizer be able to use them when it sees those expressions) Oracle has this capability and it's surprisingly general-purpose and useful for a variety of problems, so I'd like to ask that this be considered for a sqlite wish-list (not that I want to try to make sqlite into oracle or use 'oracle has this' as a justification for any feature:-).
For example, a frequent request or requirement is to search fields case-insensitively. However, most such requirements also require that the field be displayed in the original case.
CREATE INDEX
upper_ix
ON
employees (UPPER(last_name));
makes for an easy solution (though one might want a FOLD() function to correctly deal with internationalization, but that's another subject)
Thanks.
Mark. |
|
485 |
new
|
active
|
2003 Oct
|
anonymous
|
BTree
|
2003 Oct
|
|
5
|
4
|
Comparing strings: user defined callback, strcoll?
|
edit |
I think it would be useful to specify the "C" locale character set (like strcoll), at database level, so strings are compared based on that locale. Or at least some callback routine so one could perform those string comparisons. |
|
484 |
build
|
active
|
2003 Oct
|
anonymous
|
|
2003 Nov
|
|
5
|
4
|
make clean cleans doc/ completely
|
edit |
Hi,
when doing a "make clean", the Makefile.in does this:
rm -rf doc/
Wouldn't it be better to do
if test -d doc/; then cd doc/; rm -f $(DOC); cd ..; fi
?
Best regards,
Ulrik Petersen, Denmark |
|
483 |
build
|
active
|
2003 Oct
|
anonymous
|
Shell
|
2003 Nov
|
|
2
|
3
|
history.h from readline library not checked for
|
edit |
Hi,
I have a system with a really old readline lying around in /usr/local/include/readline. This readline has no history.h, but src/shell.c looks for <readline/history.h>.
What I am suggesting is that the configure.ac script be extended so that it checks for history.h as well as readline.h. A patch appears below.
Best regards,
Ulrik Petersen
diff sqlite/configure.ac sqlite-2.8.6-up-2/configure.ac
494a495,497
> if test "$found" = "yes"; then
> AC_CHECK_HEADER(history.h, [found=yes], [found=no])
> fi
500,501c503,507
< TARGET_READLINE_INC="-I$dir/include"
< break
---
> AC_CHECK_FILE($dir/include/history.h, found=yes, found=no)
> if test "$found" = "yes"; then
> TARGET_READLINE_INC="-I$dir/include"
> break
> fi
505,506c511,515
< TARGET_READLINE_INC="-I$dir/include/readline"
< break
---
> AC_CHECK_FILE($dir/include/readline/history.h, found=yes, found=no)
> if test "$found" = "yes"; then
> TARGET_READLINE_INC="-I$dir/include/readline"
> break
> fi
|
|
479 |
new
|
active
|
2003 Oct
|
anonymous
|
Parser
|
2003 Oct
|
drh
|
4
|
3
|
Sequences
|
edit |
Adding sequences to sqlite would be very useful... allowing to do several things that are not possible today. But I'm not sure if default column values must be implemented to take full use of sequences. |
2004-Mar-03 13:14:00 by anonymous:
Any plans to add sequences? |
|
478 |
new
|
active
|
2003 Oct
|
anonymous
|
Parser
|
2003 Nov
|
drh
|
1
|
3
|
select into is lacking
|
edit |
hi,
thanks for sqlite. i accidentally tryed a "select into" statement and found it is not parsed by sqlite.
best regards,
alex |
|
477 |
new
|
active
|
2003 Oct
|
anonymous
|
|
2003 Dec
|
anonymous
|
4
|
4
|
Are there any plans to enchance SQLite to support Unicode
|
edit |
Hi,
Are there any plans to enchance SQLite to support UNICODE. Did anyone try and had any problems.
I would like to use SQLite in my embedded device. I might have to modify SQLite to support UNICODE. If anyone has any points please let me know.
Thanks, |
Use UTF8 encoding, which doesn't require 0 values, and is especially efficient for encoding ASCII text.
But sqlite_exec takes a char* for SQL statement. Do I need to change this peace of code or is anything simple that can be done so that I can pass unicode information
UTF8 encoding looks like a normal ASCIIZ string; the NUL byte is not valid UTF8 encoding, and therefore any UTF8 string can be given to SQLite, which only cares that the data be an ASCIIZ string.
Will SELCT lower(text), upper(text) works ? I suppouse NO... Support of unicode in some form is needed. There is no hack way to do this my client side. |
|
473 |
build
|
active
|
2003 Oct
|
anonymous
|
|
2003 Nov
|
drh
|
3
|
3
|
makefile's target_source fails to create opcodes.c
|
edit |
Configure on MinGW, run "make target_source", opcodes.c is not created. Don't know if this happens on other platforms.
Changing this line in Makefile.in...
opcodes.h: $(TOP)/src/vdbe.h
to...
opcodes.h: $(TOP)/src/vdbe.h opcodes.c
solves the problem, but I don't know if this is the desired fix. |
|
472 |
new
|
active
|
2003 Oct
|
anonymous
|
VDBE
|
2003 Nov
|
|
5
|
5
|
[Patch] Using localtime instead UTC time to 'now'
|
edit |
--- os.c.orig Mon Oct 6 09:23:03 2003
+++ os.c Mon Oct 6 09:29:16 2003
@@ -1605,20 +1605,35 @@
*/
int sqliteOsCurrentTime(double *prNow){
#if OS_UNIX
- time_t t;
+ time_t t, lot;
+ struct tm ltm;
+ int ltmsec;
time(&t);
- *prNow = t/86400.0 + 2440587.5;
+ /*
+ * to use localtime, I used localtime - gmtime.
+ * localtime_r, gmtime_r are thread safe.
+ * by iosephATuriDATsarangDATnet
+ */
+ localtime_r(&t,<m);
+ lot = mktime(<m);
+ gmtime_r(&t, <m);
+ ltmsec = lot - mktime(<m);
+ *prNow = (t + ltmsec)/86400.0 + 2440587.5;
return 0;
#endif
#if OS_WIN
- FILETIME ft;
+ FILETIME ft,ft2;
/* FILETIME structure is a 64-bit value representing the number of
100-nanosecond intervals since January 1, 1601 (= JD 2305813.5).
*/
double now;
GetSystemTimeAsFileTime( &ft );
- now = ((double)ft.dwHighDateTime) * 4294967296.0;
- *prNow = (now + ft.dwLowDateTime)/864000000000.0 + 2305813.5;
+ /* to use localtime, I used this API.
+ * by iosephATuriDATsarangDATnet
+ */
+ FileTimeToLocalFileTime(&ft, &ft2);
+ now = ((double)ft2.dwHighDateTime) * 4294967296.0;
+ *prNow = (now + ft2.dwLowDateTime)/864000000000.0 + 2305813.5;
#endif
return 0;
-- EOF --
This patch is local patch.
I patched both OS_UNIX and OS_WIN to be thread safe. |
|
465 |
new
|
active
|
2003 Sep
|
anonymous
|
|
2003 Sep
|
|
4
|
3
|
data types should be implemented as formated strings
|
edit |
a real improvement of sqlite would be operating on numeric and date, time fields in a sortable string format, for example:
* date as YYYYDDMM,
* time as HHMMSSmmm,
* integer as hexadecimal string without "0x",
* float as WWWWWWWWDDDDDDDDDDDDDEEEEEEE (wholes, decimals, exponent)
this way, there would be no need for the special integer keys and indexes, and code will be more feature oriented and less feature evading.
hexadecimal values will compress decimals and improve sortability. all numbers should be 0-padded, prefixed by their sign, with null strings for null values.
the developing effort required would be to:
* make a library of basic mathematical functions for string values.
* parse numeric, date, and time literals in queries without quotation marks.
* match the right function for the specified type.
* it would be very nice to support all the types of c variables. |
|
463 |
event
|
active
|
2003 Sep
|
anonymous
|
|
2003 Sep
|
|
2
|
1
|
list index out of bounds(1)
|
edit |
I am using the sqlite.dll with "sqlitedbu.pas" package in Delphi 7.
Database has only one table called "baza".
'create table baza(filename string, bin blob)';
There is no problem when i am inserting mime encoded files into table.
problem is when i have more than 200 records. Delphi gives me explanation :
"list index out of bounds(1)".
Same query in sqlite console works with no problems.
same problem happens if i index table or when i create unique fields.
query I've used is:
_select filename from baza where filename like "%" order by filename;_
*Delphi code:*
procedure TForm1.Edit1Change(Sender: TObject);
var t:string;
baza:TSQLiteDB;
i:integer;
begin
t:=edit1.Text;
ListBox1.Clear;
if (DataBaseName<>'') then begin
baza:=TSQLiteDB.Create(nil,DataBaseName);
baza.sql:='select filename from baza where filename like "'+t+'%" order by filename';
baza.ExecSQL;
baza.Open;
if baza.RecordCount>0 then begin
baza.First;
while not baza.EOF do begin
ListBox1.Items.Add(baza.Fields['filename']);
baza.Next;
end;
end;
baza.Close;
FreeAndNil(baza);FreeAndNil(i);
end;
end;
|
|
462 |
event
|
active
|
2003 Sep
|
anonymous
|
|
2003 Sep
|
|
2
|
1
|
list index out of bounds(1)
|
edit |
I am using the sqlite.dll with "sqlitedbu.pas" package in Delphi 7.
Database has only one table called "baza".
'create table baza(filename string, bin blob)';
There is no problem when i am inserting mime encoded files into table.
problem is when i have more than 200 records. Delphi gives me explanation :
"list index out of bounds(1)".
Same query in sqlite console works with no problems.
same problem happens if i index table or when i create unique fields.
please help me to resolve this. |
|
457 |
new
|
active
|
2003 Sep
|
anonymous
|
|
2003 Sep
|
|
1
|
1
|
Ported to NetWare
|
edit |
I've ported SQLite to work on NetWare 5.1 and 6.x. The database file location must be an NSS volume. |
|
456 |
build
|
active
|
2003 Sep
|
anonymous
|
|
2003 Nov
|
anonymous
|
1
|
1
|
compilation problem under winnt 4 using Lcc-win32
|
edit |
I was trying to compile a small C-programm which I copied from the document "quickstart.html". The linker says:"sqlite.dll:unknown file type". I took the binaries from your site without recompiling. I'm using the Lcc-Win32 compiler under Windows NT 4 (with Service Pack 5).
Is anything wrong with the file sqlite.dll? |
|
454 |
new
|
active
|
2003 Sep
|
anonymous
|
|
2003 Sep
|
|
4
|
4
|
schema column types with parenthesis to automatically invoke functions
|
edit |
having a table such as:
CREATE TABLE foo (amount NUMERIC(10,2));
and having a function (NUMERIC) that accepts three parameters, it would be nice if:
INSERT INTO TABLE foo (10.50);
would call:
NUMERIC(10.50,10,2);
and use its result as the insert.
Since this could break compatability, I recommend the use of a PRAGMA that would enable this mode.
I am aware that TRIGGERS make it possible to do this, however this would require application-level setup that is too specific for some of the applications I work with; A pragma is not an unrealistic setup for my application, but setting up special INSERT/UPDATE triggers is.
As a temporary workaround, my application downloads the sqlite_master table, parses out the columns, and creates the triggers accordingly. This code is somewhat complex, and thus represents an annoyance. |
|
451 |
build
|
active
|
2003 Sep
|
anonymous
|
|
2004 Feb
|
|
1
|
1
|
Makefile fails on FreeBSD
|
edit |
Unless I am mistaken, I have previously built SQLite on FreeBSD.
However, I now try to build version 2.8.4 and 2.8.6 on FreeBSD 5.0
and discover that the <B style="color:black;background-color:#ffff66">Makefile</B> apparently depends on the GNU make
rather than a standard Unix make:
"<B style="color:black;background-color:#ffff66">Makefile</B>", <B style="color:black;background-color:#99ff99">line</B> 72: Missing dependency operator
"<B style="color:black;background-color:#ffff66">Makefile</B>", <B style="color:black;background-color:#99ff99">line </B><B style="color:black;background-color:#ff9999">74</B>: Need an operator
"<B style="color:black;background-color:#ffff66">Makefile</B>", <B style="color:black;background-color:#99ff99">line</B> 89: Missing dependency operator
"<B style="color:black;background-color:#ffff66">Makefile</B>", <B style="color:black;background-color:#99ff99">line</B> 91: Need an operator
make: fatal errors encountered -- cannot continue
Isn't it possible to stick with a Unix make that way
SQLite is more portable. |
use gmake |
|
450 |
new
|
active
|
2003 Sep
|
anonymous
|
Shell
|
2003 Sep
|
|
5
|
4
|
Make HTML Output XHTML compliant
|
edit |
According to the website documentation, sqlite already does this but the latest version I downloaded doesn't. XHTML states that tags should all be lowercase (<td> as opposed to <TD>). Instead of fixing the website, it would be easier to patch sqlite.
There follows a patch to do this and also a patch to change the documentation on the site as it says XHTML compliance but lists non XHTML compliant tags. |
D'oh - just saw Attach link.
Sorry
2005-Sep-08 01:02:45 by anonymous:
Still an issue in v3.2.5 |
|
448 |
new
|
active
|
2003 Sep
|
anonymous
|
|
2003 Sep
|
drh
|
3
|
3
|
a general bug-fix and dos support without lfn
|
edit |
there are 2 issues in the included diff:
1. fixed support for djgpp without long file names. djgpp gives brute force to dos in terms of 32bit and 4gb memory, but it still remains a mainly one process at a time os, where programs are being enhanced mainly through libraries. that's why sqlite makes such a big difference to dos users, allowing them to directly use databases.
2. a minor bug in the code if readline isn't on:
#if !HAVE_READLINE
# define macro1(arg)
# define macro2(arg)
#endif
if (a)
macro1(1)
if (b)
macro2(2)
if (c)
return;
will be preprocessed to contain:
if (a)
if (b)
if (c)
return;
which is equivalent to:
if (a && b && c)
return;
as i understand, you meant to write:
if (a)
/*do nothing*/
if (b)
/*do nothing*/
if (c)
return;
thus, i've changed the code to:
#if !HAVE_READLINE
# define macro1(arg) {}
# define macro2(arg) {}
#endif
feel free to correct me if i'm wrong.
best regards and thank you for sqlite,
alex |
please also rename the only non short file names : sqliteInt.h, tclsqlite.c to some 8.3 compliant names.
thanks,
alex |
|
446 |
doc
|
active
|
2003 Sep
|
anonymous
|
|
2003 Sep
|
drh
|
3
|
3
|
sqlite_compile can return no virtual machine with code SQLITE_OK
|
edit |
Hello,
Hope you are fine today!
Here is what can be found in the documentation of the C/C++ interface:
"A pointer to the virtual machine is stored in a pointer which is passed in as the 4th parameter. Space to hold the virtual machine is dynamically allocated. To avoid a memory leak, the calling function must invoke sqlite_finalize on the virtual machine after it has finished with it. The 4th parameter may be set to NULL if an error is encountered during compilation."
Just pay attention to the last line:
"The 4th parameter may be set to NULL if an error is encountered during compilation."
If you try to compile an empty query i.e. "" or ";" then SQLITE_OK is returned BUT no virtual machine.
I don't consider this as a bug because nothing has to be done for those empty queries. I just think it should be documented.
Example of documentation:
"The 4th parameter may be set to NULL if an error is encountered during compilation. It can also be NULL without error when one try to compile an empty query."
Kind regards
Valere Monseur
aka Dobedo |
|
445 |
build
|
active
|
2003 Sep
|
anonymous
|
Unknown
|
2003 Dec
|
anonymous
|
3
|
1
|
Compilation problem on MinGW
|
edit |
dejan@KLEENE ~/src/sqlite$ make; head config.log; gcc -v
./libtool gcc -g -O2 -DOS_UNIX=1 -DOS_WIN=0 -I. -I./src -c ./src/os.c
rm -f .libs/os.lo
gcc -g -O2 -DOS_UNIX=1 -DOS_WIN=0 -I. -I./src -c ./src/os.c -DDLL_EXPORT -DPIC -o .libs/os.lo
src/os.c: In function `sqliteOsReadLock':
src/os.c:1142: storage size of `lock' isn't known
src/os.c:1144: `F_RDLCK' undeclared (first use in this function)
src/os.c:1144: (Each undeclared identifier is reported only once
src/os.c:1144: for each function it appears in.)
src/os.c:1147: `F_SETLK' undeclared (first use in this function)
src/os.c: In function `sqliteOsWriteLock':
src/os.c:1246: storage size of `lock' isn't known
src/os.c:1248: `F_WRLCK' undeclared (first use in this function)
src/os.c:1251: `F_SETLK' undeclared (first use in this function)
src/os.c: In function `sqliteOsUnlock':
src/os.c:1358: storage size of `lock' isn't known
src/os.c:1360: `F_UNLCK' undeclared (first use in this function)
src/os.c:1363: `F_SETLK' undeclared (first use in this function)
make: *** [os.lo] Error 1
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure, which was
generated by GNU Autoconf 2.57. Invocation command line was
$ ./configure --enable-utf8 --prefix=/usr/local
## --------- ##
## Platform. ##
Reading specs from C:/GNU/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c++,f77,objc --disable-win32-registry --disable-shared --enable-sjlj-exceptions
Thread model: win32
gcc version 3.2.3 (mingw special 20030504-1) |
See Ticket #433.
e |
|
442 |
new
|
active
|
2003 Sep
|
anonymous
|
|
2003 Sep
|
|
5
|
2
|
[PATCH] sqlite: allow configure --enable-threadsafe
|
edit |
attached is a patch against cvs head for incorporating the
thread-safety aspect to the sqlite lib.
http://cygwin.dev.wapme.net/sqlite/
Please try and comment. This is intended to be included to cvs head. |
|
428 |
new
|
active
|
2003 Aug
|
anonymous
|
TclLib
|
2003 Aug
|
drh
|
5
|
5
|
missing prepare/fetch functions to be compatible with other DBs
|
edit |
To have a compatible behaviour to other database engines when fetching single rows from a database table, it would be nice to be able to have a single fetch function instead of the standard "db eval ..." ability using a callback code. I've found three functions in the file test1.c which comes with the source files and implemented them into the TCL interface (file tclsqlite.c proc DbObjCmd).
oops deleted attach. please post it again. |
|
425 |
new
|
active
|
2003 Aug
|
anonymous
|
VDBE
|
2003 Aug
|
|
5
|
3
|
Datetime enhancements: fractional seconds, addmonth
|
edit |
This code adds support for fractional seconds in the datetime functions. From 0 to 6 digits are supported on creation of timestamp or time strings; up to 12 digits are read from them.
YYYY-MM-DD HH:MM:SS.SSSSSSS
HH:MM:SS.SSSSSSS
The functions TIMESTAMP TIME and SECOND have been modified to accept an optional second argument to specify the number of fractional digits to be produced in the string result. The JD is rounded for the specified precision.
A new function ADDMONTHS is also included. It takes a datetime and an integer, and increments the datetime by the number of months specified. The number can be negative, and can be greater than 12. To add years, do ADDMONTHS(<jd>,<years>*12).
e |
|
424 |
new
|
active
|
2003 Aug
|
anonymous
|
Shell
|
2003 Aug
|
|
4
|
3
|
Provide access to internal function _all_whitespace()
|
edit |
Can the function _all_whitespace() in shell.c be made available as part of the SQLite API, perhaps with the more appropriate name sqlite_empty(). This function could then be used along with sqlite_complete() when splitting files contain SQL scripts into individual statements that can be executed by SQLite.
The problem occurs because sqlite_complete() returns true for an empty statment, but some applications (Borlands dbExpress for example) don't consider an empty statment to be valid SQL and throw an exception when they are executed. So the user must ensure that the statement accepted by sqlite_compltet() is not empty using the sqlite_empty() function before trying to execute it.
The name _all_whitespace() is not really appropriate since it also accepts comments which are not "whitespace" characters.
I am currently using a modified version of shell.c to build a custom DLL, but changing the SQLite source would be a lot cleaner. |
|
420 |
new
|
active
|
2003 Jul
|
anonymous
|
VDBE
|
2003 Jul
|
|
3
|
3
|
Not abort transaction when callback is cancelled
|
edit |
When a callback is cancelled (non-zero return value) in a transaction, the changes are undone, but the transaction is not rolled back.
This presents a problem as my sqlite wrapper sometimes legitimately cancels a callback in the middle of a transaction and wants to commit the changes made before/after the callback cancel.
The way I understand it, a callback is only invoked when a query is being executed (data retrieval) which doesn't impact a transaction anyway. If I am wrong in this assumption, then perhaps this will require more changes to accomplish.
[This code works on my box with the limited number of tests I have accomplished. I'm not a linux developer and I don't have tcl on my system so I can't run the full test suite. If someone could do that with these proposed changes I would be very appreciative]
My proposed changes are (quite simple):
1) create a new PRAGMA: PRAGMA callback_cancel_no_abort with a default of FALSE (to keep the current behaviour as default)
2) if a callback is ABORTed and this pragma is true, then don't return SQLITE_ERROR from sqlite_vbde_exec, but rather SQLITE_DONE
The code changes for these proposed changes are (to the official 2.8.5 release):
In sqliteInt.h: INSERT this line at line 351:
#define SQLITE_CallBackNoAbort 0x00000400 /* Don't abort on callback cancel */
In pragma.c: INSERT this code at line 336:
if( sqliteStrICmp(zLeft, "callback_cancel_no_abort")==0 ){
if( getBoolean(zRight) ){
db->flags |= SQLITE_CallBackNoAbort;
}else{
db->flags &= ~SQLITE_CallBackNoAbort;
}
}else
In vbde.c: CHANGE line 5751: from
if( rc ){
TO
if( rc && ( !(db->flags & SQLITE_CallBackNoAbort) || rc != SQLITE_ABORT) ){
I don't believe these changes will conflict with existing callback abort responses, however I am not completely familiar with all parts of sqlite, therefore I would like to hear the thoughts of DRH and the sqlite community. |
|
414 |
code
|
active
|
2003 Jul
|
anonymous
|
VDBE
|
2003 Nov
|
|
3
|
4
|
sqlite_compile() and database schema changes
|
edit |
If you compile a query using sqlite_compile(), and then change the database schema using the same db handle, SQLite doesn't detect this. The following program demonstrates:
void corrupt_query(char * filename)
{
sqlite *db;
sqlite_vm *vm;
int rc;
db = sqlite_open(filename, 0, 0);
assert(db);
sqlite_exec(db, "DROP TABLE tbl;", 0, 0, 0);
sqlite_exec(db, "CREATE TABLE tbl(a, b);", 0, 0, 0);
sqlite_compile(db, "SELECT * FROM tbl;", 0, &vm, 0);
sqlite_exec(db, "DROP TABLE tbl;", 0, 0, 0);
/* This next line causes an assert() in the memory db or an SQLITE_CORRUPT
* with the real db. This is because the program stored in vm tries to
* open a cursor to a table that no longer exists.
*/
rc = sqlite_step(vm, 0, 0, 0);
printf("sqlite_step returned %d, \"%s\"\n", rc, sqlite_error_string(rc));
sqlite_close(db);
}
int main( int argc, char ** argv )
{
corrupt_query("cookie_test.db");
corrupt_query(":memory:");
return 0;
}
It seems unlikely to happen in practice, but I imagine there is a series of operations you could perform using this loophole that would corrupt the database file. |
äääüüüü""&5 |
|
413 |
new
|
active
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
|
5
|
1
|
SQL_CALC_FOUND_ROWS & FOUND_ROWS() not supported
|
edit |
for speedup & code compatibility with mysql |
|
412 |
new
|
active
|
2003 Jul
|
anonymous
|
Unknown
|
2003 Jul
|
drh
|
1
|
1
|
sign function: quick hack for func.c (hope this helps)
|
edit |
Here's a quick hack to create the sign function in /src/func.c
/*
** Implementation of the sign() function
*/
static void signFunc(sqlite_func *context, int argc, const char **argv){
double r;
char zBuf[3];
assert( argc==1 );
r = atof( argv[0] );
if ( r < 0 )
{ zBuf[0]='-';
zBuf[1]='1';
zBuf[2]='\0';
sqlite_set_result_string(context, zBuf, -1);
return;
}
if ( r == 0 )
{ zBuf[0]='0';
zBuf[1]='\0';
sqlite_set_result_string(context, zBuf, -1);
return;
}
if ( r > 0 )
{ zBuf[0]='1';
zBuf[1]='\0';
sqlite_set_result_string(context, zBuf, -1);
return;
}
}
Also note the following change in sqliteRegister where sign is added.
** This function registered all of the above C functions as SQL
** functions. This should be the only routine in this file with
** external linkage.
*/
void sqliteRegisterBuiltinFunctions(sqlite *db){
static struct {
char *zName;
int nArg;
int dataType;
void (*xFunc)(sqlite_func*,int,const char**);
} aFuncs[] = {
{ "min", -1, SQLITE_ARGS, minFunc },
{ "min", 0, 0, 0 },
{ "max", -1, SQLITE_ARGS, maxFunc },
{ "max", 0, 0, 0 },
{ "length", 1, SQLITE_NUMERIC, lengthFunc },
{ "substr", 3, SQLITE_TEXT, substrFunc },
{ "abs", 1, SQLITE_NUMERIC, absFunc },
{ "sign", 1, SQLITE_NUMERIC, signFunc },
....
The above is a quick hack; but, it allows the
users of sqlite to create pivot table as follows:
CREATE TABLE exams (
pkey int(11) ,
name varchar(15),
exam int,
score int,
PRIMARY KEY (pkey)
);
insert into exams (name,exam,score) values ('Bob',1,75);
insert into exams (name,exam,score) values ('Bob',2,77);
insert into exams (name,exam,score) values ('Bob',3,78);
insert into exams (name,exam,score) values ('Bob',4,80);
insert into exams (name,exam,score) values ('Sue',1,90);
insert into exams (name,exam,score) values ('Sue',2,97);
insert into exams (name,exam,score) values ('Sue',3,98);
insert into exams (name,exam,score) values ('Sue',4,99);
sqlite> select name,
sum(score*(1-abs(sign(exam-1)))) as exam1,
sum(score*(1-abs(sign(exam-2)))) as exam2,
sum(score*(1-abs(sign(exam-3)))) as exam3,
sum(score*(1-abs(sign(exam-4)))) as exam4
from exams group by name;
Sue|90|97|98|99
Bob|75|77|78|80
ref http://sqlchar.sourceforge.net/index.php
Hope this helps,
Mike Chirico
http://vc2000-08.med.upenn.edu/chirico/
|
|
411 |
todo
|
active
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
drh
|
1
|
1
|
support for sign function in select
|
edit |
Adding the sign function to the select statement would
greatly enhance sqlite. Specifically, it would allow
the use of characteristic functions, which I believe
falls under the SQL92 standard. These characteristic
functions are very handy for creating pivot tables.
Consider the following example which works in MySQL:
CREATE TABLE exams (
pkey int(11) ,
name varchar(15),
exam int,
score int,
PRIMARY KEY (pkey)
);
insert into exams (name,exam,score) values ('Bob',1,75);
insert into exams (name,exam,score) values ('Bob',2,77);
insert into exams (name,exam,score) values ('Bob',3,78);
insert into exams (name,exam,score) values ('Bob',4,80);
insert into exams (name,exam,score) values ('Sue',1,90);
insert into exams (name,exam,score) values ('Sue',2,97);
insert into exams (name,exam,score) values ('Sue',3,98);
insert into exams (name,exam,score) values ('Sue',4,99);
select * from exams;
+------+------+------+-------+
| pkey | name | exam | score |
+------+------+------+-------+
| 1 | Bob | 1 | 75 |
| 2 | Bob | 2 | 77 |
| 3 | Bob | 3 | 78 |
| 4 | Bob | 4 | 80 |
| 5 | Sue | 1 | 90 |
| 6 | Sue | 2 | 97 |
| 7 | Sue | 3 | 98 |
| 8 | Sue | 4 | 99 |
+------+------+------+-------+
8 rows in set (0.00 sec)
select name,
sum(score*(1-abs(sign(exam-1)))) as exam1,
sum(score*(1-abs(sign(exam-2)))) as exam2,
sum(score*(1-abs(sign(exam-3)))) as exam3,
sum(score*(1-abs(sign(exam-4)))) as exam4
from exams group by name;
+------+-------+-------+-------+-------+
| name | exam1 | exam2 | exam3 | exam4 |
+------+-------+-------+-------+-------+
| Bob | 75 | 77 | 78 | 80 |
| Sue | 90 | 97 | 98 | 99 |
+------+-------+-------+-------+-------+
2 rows in set (0.00 sec)
Note the last select statements pivots the select entries.
More examples can be found at http://sqlchar.sourceforge.net/index.php
It would be wonderful to have this feature available in sqlite.
Regards,
Mike
Mike Chirico (mchirico@med.upenn.edu)
|
|
409 |
event
|
active
|
2003 Jul
|
anonymous
|
Unknown
|
2003 Dec
|
anonymous
|
3
|
1
|
sqlite_open will cause segfault when using Rational PurifyPlus/Linux
|
edit |
Note: I'm not certain if this is a sqlite or purifyplus problem
While trying to troubleshoot some minor memory leaks in my application, I noticed that when using PurifyPlus the appliation will segfault when calling sqlite_open. I encountered the same problem when profiling src/threadtest.c.
1 - thread
11 - (thread)
Run @ Sat Jul 19 23:58:54 2003
SIG (Signal 11 Handled: Segmentation fault)
It occurs near after:
worker_bee [/scratch/hsiab_c/hsiabd/t/sql/sqlite/src/threadtest.c] line 207
main [/scratch/hsiab_c/hsiabd/t/sql/sqlite/src/threadtest.c] line 265
Program exit code: 11
No Memory Leak detected
The same problem happens when testing with an incredibly simple program:
#include <stdio.h>
#include <stdlib.h>
#include <sqlite.h>
#ifdef MTRACE
#include <mcheck.h>
#endif
int main() {
sqlite *db;
char *azErr;
#ifdef MTRACE
mtrace();
#endif
db = sqlite_open("/tmp/testdb", 0, &azErr);
if (db == 0) {
printf("Couldn't open db file!\n");
free(azErr);
exit(0);
}
sqlite_close(db);
}
Oddly enough, when I mtrace this program is complains with:
Memory not freed:
Address Size Caller
0x08049bd0 0x40 at 0x4004a3ac
I'm not sure if this is even related. Any ideas? |
This problem is occuring on Redhat 7.2 with sqlite 2.8.5 and purifyplus 2003.06.00. |
|
407 |
new
|
active
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
|
4
|
4
|
sqlite_compile etc. and pragma empty_result_callbacks.
|
edit |
Maybe if EMPTY_RESULT_CALLBACKS is set and you use sqlite_compile, sqlite_step etc. with a SELECT query that returns no rows the first invocation of sqlite_step() should return SQLITE_ROW with just columns data. |
|
404 |
new
|
active
|
2003 Jul
|
anonymous
|
|
2003 Dec
|
|
3
|
3
|
new C API: sqlite_get_table_with_types with type information
|
edit |
Patches for a new C API function:
sqlite_get_table_with_types, which is like sqlite_get_table but also adds type information in the return data which apepars right after the column names.
Implementation (patch is against 2.8.3) is almost zero overhead and only needs an extra few lines:
--- table.c.old Sun Jul 13 11:59:18 2003
+++ table.c Sun Jul 13 14:54:13 2003
@@ -33,6 +33,7 @@
int nColumn;
int nData;
int rc;
+ int headHasType;
} TabResult;
/*
@@ -50,7 +51,7 @@
** we need to remember from this invocation of the callback.
*/
if( p->nRow==0 && argv!=0 ){
- need = nCol*2;
+ need = nCol * (p->headHasType ? 3 : 2);
}else{
need = nCol;
}
@@ -69,8 +70,9 @@
** the names of all columns.
*/
if( p->nRow==0 ){
+ int cols_top = (p->headHasType ? nCol * 2 : nCol);
p->nColumn = nCol;
- for(i=0; i<nCol; i++){
+ for(i=0; i<cols_top; i++){
if( colv[i]==0 ){
z = 0;
}else{
@@ -121,13 +123,14 @@
** Instead, the entire table should be passed to sqlite_free_table() when
** the calling procedure is finished using it.
*/
-int sqlite_get_table(
+static int sqlite_get_table_common(
sqlite *db, /* The database on which the SQL executes */
const char *zSql, /* The SQL to be executed */
char ***pazResult, /* Write the result table here */
int *pnRow, /* Write the number of rows in the result here */
int *pnColumn, /* Write the number of columns of result here */
- char **pzErrMsg /* Write error messages here */
+ char **pzErrMsg, /* Write error messages here */
+ int headerHasTypes /* set to 1 to return types after col names; else set to 0 */
){
int rc;
TabResult res;
@@ -141,6 +144,7 @@
res.nColumn = 0;
res.nData = 1;
res.nAlloc = 20;
+ res.headHasType = headerHasTypes;
res.rc = SQLITE_OK;
res.azResult = malloc( sizeof(char*)*res.nAlloc );
if( res.azResult==0 ){
@@ -199,4 +203,26 @@
for(i=1; i<n; i++){ if( azResult[i] ) free(azResult[i]); }
free(azResult);
}
+}
+
+int sqlite_get_table(
+ sqlite *db, /* The database on which the SQL executes */
+ const char *zSql, /* The SQL to be executed */
+ char ***pazResult, /* Write the result table here */
+ int *pnRow, /* Write the number of rows in the result here */
+ int *pnColumn, /* Write the number of columns of result here */
+ char **pzErrMsg /* Write error messages here */
+){
+ return sqlite_get_table_common(db, zSql, pazResult, pnRow, pnColumn, pzErrMsg, 0);
+}
+
+int sqlite_get_table_with_types(
+ sqlite *db, /* The database on which the SQL executes */
+ const char *zSql, /* The SQL to be executed */
+ char ***pazResult, /* Write the result table here */
+ int *pnRow, /* Write the number of rows in the result here */
+ int *pnColumn, /* Write the number of columns of result here */
+ char **pzErrMsg /* Write error messages here */
+){
+ return sqlite_get_table_common(db, zSql, pazResult, pnRow, pnColumn, pzErrMsg, 1);
}
--- sqlite.h.old Thu Jun 05 02:14:02 2003
+++ sqlite.h Sun Jul 13 12:28:30 2003
@@ -314,6 +314,18 @@
);
/*
+** Same as above but also returns column types after column names and before data
+ */
+int sqlite_get_table_with_types(
+ sqlite*, /* An open database */
+ const char *sql, /* SQL to be executed */
+ char ***resultp, /* Result written to a char *[] that this points to */
+ int *nrow, /* Number of result rows written here */
+ int *ncolumn, /* Number of result columns written here */
+ char **errmsg /* Error msg written here */
+);
+
+/*
** Call this routine to free the memory that sqlite_get_table() allocated.
*/
void sqlite_free_table(char **result);
|
|
403 |
code
|
active
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
|
4
|
4
|
Two small fixes in .spec file for RPMS
|
edit |
1. The sqlite.pc isn't packaged in the sqlite-devel package.
Simply add in the package %files section:
%{_libdir}/pkgconfig/*.pc
2. There is not %post and %postun:
Need to run /sbin/ldconfig in both sections. |
|
398 |
build
|
active
|
2003 Jul
|
anonymous
|
Unknown
|
2003 Nov
|
|
3
|
3
|
configure.ac is wrong for Windows Mingw/Msys
|
edit |
On Windows Mingw/Msys, the 2.8.4 configure script produces a Makefile with
TCC = gcc -g -O2 -DOS_UNIX=1 -DOS_WIN=0 -I. -I${TOP}/src
which I've traced to configure.ac
if test "$TARGET_EXEEXT" = ".exe"; then
OS_UNIX=0
OS_WIN=1
tclsubdir=win
else
OS_UNIX=1
OS_WIN=0
tclsubdir=unix
fi
TARGET_CFLAGS="$TARGET_CFLAGS -DOS_UNIX=$OS_UNIX -DOS_WIN=$OS_WIN"
Now, os.h, when OS_UNIX is defined, and regardless of its value, ignores OS_WIN and redefines it to 0. So, there are two problems here: -DOS_UNIX=$OS_UNIX -DOS_WIN=$OS_WIN should not both appear in TARGET_CFLAGS, and for Windows -DOS_WIN=1.
The line that configure should produce is
TCC = gcc -g -O2 -DOS_WIN=1 -I. -I${TOP}/src
Note that this would obviate the need for the workaround described on HowToCompile in step 6 of section "Win32 recompile with mingw32/msys." |
|
395 |
code
|
active
|
2003 Jul
|
anonymous
|
Unknown
|
2003 Jul
|
|
4
|
4
|
Error opening db on Mac OS X not reported correctly
|
edit |
When sqlite is passed a directory as the database to open on Mac OS X it doesn't report an immediate error, only when you run any command does it fail.
e.g..
$ mkdir 1
$ sqlite 1
SQLite version 2.8.4
Enter ".help" for instructions
sqlite> .schema
Error: database is locked
sqlite>
where on Linux it reports as I expect the code intends with:
Unable to open database "contrib": disk I/O error
I've tracked it down as far as I can into sqlite_open at line 162 where it calls sqliteInit - sorry my C knowhow runs out at this point.
I'm more than happy to test any patches that you would like.
Also I have a feeling this is related to ticket #304 that you weren't able to reproduce - presumably its a Mac OS X only problem too.
Regards, PeterW. |
I've done some more poking about with this and it looks like the problem boils down to the line "s = fcntl(id->fd, F_SETLK, &lock);" in sqliteOsReadLock in os.c.
On Mac OS X fcntl returns EISDIR when the file to lock is a directory rather than EINVAL so that the check a line or so down returns SQLITE_BUSY. On Linux this returns SQLITE_OK which causes the pager to try and find a page and causes an error when it tries to read from the directory which ends up failing with a disk I/O error.
If I change the check to be:
rc = (errno==EINVAL || errno==EISDIR) ? SQLITE_NOLFS : SQLITE_BUSY;
then passing a directory name to open fails with the predictable error of no large file support which certainly doesn't seem like the right thing to do in this instance.
Does it make to have a check right at the beginning of sqlite_open to see if the file to open is a regular file and so stop this much earlier if something other than a regular file is passed in? |
|
391 |
warn
|
active
|
2003 Jul
|
anonymous
|
|
2003 Dec
|
|
4
|
3
|
signed/unsiged compiler warnings from Borland C++6
|
edit |
When I compile the 2.8.4 source code (as of 2003-07-14) with Borland's C++ Builder 6 compiler I get warnings about signed-unsigned comparisons and suspicious pointer conversions (int * vs unsigned *) in two files.
pager.c produces the following messages:
[C++ Warning] pager.c(598): W8075 Suspicious pointer conversion
[C++ Warning] pager.c(613): W8012 Comparing signed and unsigned values
select.c produces the following message:
[C++ Warning] select.c(99): W8012 Comparing signed and unsigned values
These warnings can be eliminated by the small changes detailed in the attached diff files. |
|
386 |
new
|
active
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
|
5
|
1
|
compile on WinCE ?
|
edit |
hi,
since wince is supported by pythonCE and pysqlite is a wrapper it might be usefull to compile SQLITE on WinCE ( I use winCE 2.1 on ARM (iPAQ) ).
.klemens |
|
381 |
new
|
active
|
2003 Jul
|
anonymous
|
|
2003 Jul
|
|
1
|
3
|
Support for DJGPP and DOS
|
edit |
I would like to use SQLite in a pure DOS (MS-DOS, DR-DOS, FreeDOS) environment. Thankfully DJGPP provides many of the Unix APIs and tools. But the file name limit has been a prolem. DOS filenames must be 8.3, that is 8 characters plus a 3 character extension. I found 3 places where this is violated.
1) A file named "sqlite.h.in" is included with the source distribution. This unzips to "sqlite.h" since there may be only 1 extension. Since "sqlite.h" is supposed to be generated from the ".in", this causes problems. If I rename the file to "sqlite.hin" and modify the makefile main.mk, all works fine.
2) The temporary files created violate 8.3. The default pattern is "sqlite_XXXXXXXXXXXXXXXX". I modified the pattern to be "sqXXXXXX" so it is 8 characters long. Another possible (better?) solution would be to use mkstemp(), or even tmpnam().
3) The journal files created violate 8.3 The default is to append "-journal" to the end of the database or temp file name. For database file names like "mydb.sld", this results in "mydb.sld-journal". Since the extension may only be 3 characters, it ends up writing to "mydb.sld". This is really bad since now the journal and DB are the same file. Instead of "-journal", I used ".jnl". This works if the database filename does not already have an extension. A better fix would be to change the extension, if there is one. |
2005-Feb-09 03:32:44 by anonymous:
Use ROM-DOS 7.1(from datalight) |
|
369 |
code
|
active
|
2003 Jun
|
anonymous
|
|
2004 Jan
|
|
3
|
2
|
Testsuite fails on btree-1.1.1 (Mac OS X, SQLite 2.8.4)
|
edit |
On Mac OS X the testsuite fails:
btree-1.1.1..../src/btree.c:2687: failed assertion `pPage->isInit'
make: *** [test] Abort trap
SQLite version: 2.8.4, OS Version: 10.2.6 |
Obtained same result. Mac OS X 10.2.6, Developer Tools Dec 2002, SQLite 2.8.5.
Shared libraries are busted on Macs. As far as I can tell, this
appears to be Apple's fault. Until a workaround is devised, do
not attempt to compile using shared libraries. Add the
--disable-shared option to the configure script:
../sqlite/configure --disable-shared
On 2.8.5+, this shows up on 2689. Also, configure does not allow the use of --disable-shared (probably requries a fix in the configure scripts). On a G5 in 10.3.2, this error shows up as a Bus Error. Builds work fine otherwise. This issue may be related to the warnings received in src/test1.c thru src/test4.c and in src/tclsqlite.c regarding Tcl_SetVar, Tcl_GetInt, Tcl_GetBoolean, Tcl_GetIndexFromObj. All warnings are regarding promotion of arguments to pointers of invalid type.
oso2k/Louis
2004-Feb-11 22:57:17 by anonymous:
I did some quick testing of 2.8.12 on the machines I
have available to me. In general, there seems to be
more warnings than I remember (I believe I was testing
2.8.9 from cvs before it went live).
- G3 700MHz/640MB iBook 10.2.8
Same results as we last spoke. Fails make test at:
btree-1.1.1
- Dual G4 800MHz/1.25GB 10.2.8
Same results as we last spoke. Fails make test at:
btree-1.1.1
- G5 1.6GHz/1.25GB 10.3.2
Something really weird happens here. There is no
longer a bus error. Right after make test gets past
bigfile-1.1, the machine seems to enter an infinite
loop or something.
|
|
368 |
code
|
active
|
2003 Jun
|
anonymous
|
|
2007 Dec
|
|
3
|
4
|
UPDATE trigger doesn't fire on INSERT OR REPLACE
|
edit |
After executing the following SQL, there will be nothing in table T2. I expect to see '1' there:
CREATE TABLE T1 ( id, name );
CREATE TABLE T2 ( id );
CREATE TRIGGER T1A AFTER UPDATE ON T1
BEGIN
INSERT INTO T2 VALUES( new.id );
END;
INSERT INTO T1 VALUES (1, 'Hi');
INSERT INTO T1 VALUES (2, 'There');
INSERT OR REPLACE INTO T1 VALUES (1,'Me');
|
An INSERT trigger does fire on INSERT OR REPLACE if the item exists already -- I would expect an UPDATE trigger.
2004-Sep-21 17:15:37 by anonymous:
Still repros in 3.0.7 :-(
2007-Dec-17 21:45:03 by anonymous:
I would say that ON DELETE and ON INSERT better describes what really happens (and not ON UPDATE), because if there would be another columns in the '1' row, their values would not be preserved after INSERT OR REPLACE takes place, as the documentation of the ON REPLACE algorithm states: "When a UNIQUE constraint violation occurs, the pre-existing rows that are causing the constraint violation are removed prior to inserting or updating the current row". However, neither ON UPDATE nor ON DELETE trigger occurs, which still is a bug. Thank you. |
|
366 |
new
|
active
|
2003 Jun
|
anonymous
|
Unknown
|
2003 Jun
|
drh
|
4
|
3
|
Functions sqlite_(en/de)code_binary() not in sqlite.h
|
edit |
The handy utility functions sqlite_encode_binary() and sqlite_decode_binary() from encode.c don't have any declarations in sqlite.h |
|
363 |
new
|
active
|
2003 Jun
|
anonymous
|
VDBE
|
2003 Jun
|
jadams
|
5
|
5
|
sqlite support domain as user defined type
|
edit |
sqlite support domain as user defined type |
|
362 |
event
|
active
|
2003 Jun
|
anonymous
|
Shell
|
2003 Jun
|
jadams
|
4
|
2
|
Problem with select count
|
edit |
select count() nonetable;
select count without FROM always return 1,
not return error message :-) |
|
356 |
new
|
active
|
2003 Jun
|
anonymous
|
VDBE
|
2003 Jun
|
|
5
|
2
|
Returns real error codes
|
edit |
Hello,
I use succesfully sqlite with the php extension and some C application. While writes drivers for different backends I use, it is a real pain to know what really happen on error.
The output message is well down and usefull for a human ;). Once you switch to manager error programmatically, it's quit impossible to know exactly the error code. As you change it to a string output, 'SQL error' or others "useless" message.
Is there a chance to get an additionnal argument for the error code? I mean if you can populate the error code?
hth
pierre |
The problem is that the returned by reference error message is very descriptive but that the error codes are too coarsely grained to be useful for programmatic decision making.
Eg: "select * from foo"
when the table foo does not exist provides a nice textual description of the error, but the error code is a generic code that does not distinguish between a missing database, missing table, syntax error etc.
2004-May-19 13:44:28 by anonymous:
Yup this issue is very severe if you want to do any sort of error handling in your code. Actually a work around is parsing the error messages returned from the initial API call that failed and mapping them to your own error code table. Very klunky and bound to break often too. |
|
348 |
warn
|
active
|
2003 Jun
|
anonymous
|
Unknown
|
2003 Dec
|
drh
|
4
|
3
|
SQLite and GCC using enhanced warning levels
|
edit |
SQLite doesn't compile cleanly if you enable the following GCC compiler warnings:
-Wcast-qual
-Wmissing-declarations
-Wnested-externs
-Wuninitialized
-Wwrite-strings
Most of these can be fixed by changing "char *" to "char const *" in a few judicious places. |
|
339 |
build
|
active
|
2003 Jun
|
anonymous
|
Shell
|
2003 Nov
|
|
2
|
3
|
readline headers not found (because of readline/ prefix)
|
edit |
Hi,
I have GNU readline in /usr/local/include/readline :
$ ls -l /usr/local/include/readline/{linebreak}
total 32
-rw-r--r-- 1 root bin 1846 Mar 6 1996 chardefs.h
-rw-r--r-- 1 root bin 3200 Mar 6 1996 keymaps.h
-rw-r--r-- 1 root bin 9952 Mar 6 1996 readline.h
The shell program references the readline header-files as
# include <readline/readline.h>
# include <readline/history.h>
I believe that this is not the proper way to do it. readline.h and history.h may not be in a readline/ subdirectory. The configure script sets TARGET_READLINE_INC properly, namely to the directory where readline.h can be found (including on my machine, namely to /usr/local/include/readline). But since shell.c has the prefix readline/, it is not found.
Regards,
Ulrik Petersen, Denmark |
Here is a patch against 2.8.6:
$ diff sqlite/src/shell.c sqlite-2.8.6-up-2/src/shell.c
40,41c40,41
< # include <readline/readline.h>
< # include <readline/history.h>
---
> # include <readline.h>
> # include <history.h>
Best regards,
Ulrik Petersen |
|
338 |
new
|
active
|
2003 Jun
|
anonymous
|
Unknown
|
2003 Nov
|
|
5
|
1
|
lowerFunc and upperFunc Fail on foreign characters
|
edit |
This seems to work better
static void upperFunc(sqlite_func *context, int argc, const char **argv){
char *z;
int i;
if( argc<1 || argv[0]==0 ) return;
z = sqlite_set_result_string(context, argv[0], -1);
if( z==0 ) return;
for(i=0; z[i]; i++){
if ( ( z[i] >= 'a' && z[i] <= 'z' ) ||
( z[i] >= '�' && z[i] <= '�' ) ||
( z[i] >= '�' && z[i] <= '�' ) )
z[i] = toupper(z[i]);
}
}
static void lowerFunc(sqlite_func *context, int argc, const char **argv){
char *z;
int i;
if( argc<1 || argv[0]==0 ) return;
z = sqlite_set_result_string(context, argv[0], -1);
if( z==0 ) return;
for(i=0; z[i]; i++){
if ( ( z[i] >= 'A' && z[i] <= 'Z' ) ||
( z[i] >= '�' && z[i] <= '�' ) ||
( z[i] >= '�' && z[i] <= '�' ) )
z[i] = tolower(z[i]);
}
}
|
|
335 |
event
|
active
|
2003 Jun
|
anonymous
|
Unknown
|
2003 Jun
|
drh
|
2
|
2
|
ChangeCount still failing
|
edit |
Ah, I've traced deeper in my code instead of concluding that the workaround I've implemented in version 2.8.0 is still needed.
Perhaps the problem lies a bit deeper. Here's what's happening in the driver:
- SQLite_Compile 'update Simpsons set Firstname = "Homer." where Lastname = "Simpson" and Firstname = "Homer" '
- SQLite_Step which returns ok
- SQLiteChanges which returns 1
Now the weird thing kicks in (See also my ticket #261):
- SQLite_Finalize fails with "call is out of sequence"
If I perform the following ticket #335 is relevant
- SQLite_Step until EOF
- Don't call SQLite_Finalize (reource leaking?)
Any next virtual machine will increment the SQLiteChanges with the previous SQLiteChanges, again and again.
Perhaps #335 is non relevant if #261 is fixed with the procedure described above.
Below are snippets of log from my sqlite dbexpress driver. Every execute line is using a different virtual machine. The first time everything is ok, the second virtual machine however doesn't seem to have reset the changecount, because it returns two changes. This increments to three, four etc...
Execute: update Simpsons set
Firstname = "Homer."
where
Lastname = "Simpson" and
Firstname = "Homer"
Rows affected: 1
Execute: update Simpsons set
Firstname = "Barney."
where
Lastname = "Gumbles" and
Firstname = "Barney"
Rows affected: 2
etcetera |
I am unable to reproduce this with SQLite. Can you provide
a pure SQL script that generates this behavior? Are you
certain the problem is in SQLite and not in the DBExpress driver? |
|
331 |
new
|
active
|
2003 May
|
anonymous
|
Unknown
|
2003 Jun
|
mike
|
5
|
5
|
Went to compile Win32 project and found a missing header reference
|
edit |
I created a project in VS.NET 2003, specifically a Windows Dll project. I included all of the *.c files from your windows source distribution. The build went ok with a bunch of warnings until I go to the tcl.h file inclusion. The build barfed. |
The header "tcl.h" is only required when building the tcl-enabled version of SQLite used for testing. To compile a normal (non-testing) version, omit the file "tclsqlite.c". If you are building using the tarball, omit the files "md5.c", "test1.c", "test2.c", "test3.c" as well.
This is covered in the wiki pages HowToCompile, HowToCompileWithVsNet.
The tcl version can be built under Windows if the tcl development tools are installed.
Perhaps this should be converted to a "request for enhancement" for a MSVC project file or at least a readme.txt file to be placed in the Windows download. |
|
330 |
code
|
active
|
2003 May
|
anonymous
|
VDBE
|
2003 May
|
|
3
|
4
|
Aggregator's error are ignored
|
edit |
Any error set by aggregator functions using sqlite_set_result_error()
is ignored and returned as the aggregator's result.
In vdbe.c, the AggNext and AggReset operators implementation do
not check the context's isError attribute after the xFinalize function
is called. Errors reported by normal functions works fine. |
Additional note on errors from aggregates: there is an requirement (and corresponding assert in the code) that sqlite_set_result_error will never be called from xStep callback. So it is required to wait for the first xFinalize call, this leads to allocation of extra memory to remember that an error is occured.
Can it be allowed to call this function from xStep callback ? |
|
326 |
new
|
active
|
2003 May
|
anonymous
|
|
2003 May
|
|
4
|
4
|
Request for additional callback for various functions
|
edit |
There are several functions of sqlite which take callbacks as a parameter. Two of them are sqlite_create_function and sqlite_create_aggregate.
I'm interfacing the sqlite with the ocaml language and it is required to do some work when the function is about to be "unregisttered", i.e. free some memory, tell the garbage collector to feel free with destroying some data and not to look for something anymore, etc.
It is relatively easy to track this with auth/trace callbacks and busy handler, but for functions and aggregates I have to keep track of all registered functions ang aggregates, so the information is stored twice in a very similar structures - once inside the sqlite, once in my code.
It would be easier if sqlite_create_function sqlite_create_aggregate will take one "cleanup" function as a parameter which (if not null) will be called at the time when registered function/aggregate is about to be replaced or disabled, or when sqlite structure is destroyed.
This can be extended further with registering optional cleanup functions for auth/busy/trace callbacks (with calling them all when closing the database, when disabling, and when replacing), but there are workarounds for it; the real pain is only with functions and aggregates.
Mikhail |
|
321 |
new
|
active
|
2003 May
|
anonymous
|
|
2003 May
|
|
4
|
3
|
Make SQLITE_ISO8859 and SQLITE_UTF8 overridable by compiler define
|
edit |
For those of us who use the preprocessed sqlite_source.zip: it would be nice if we could override the character encoding with a compiler #define. That way I wouldn't have to manually edit sqlite.h.
You could put an #ifndef in sqlite.h:
#ifndef SQLITE_UTF8
# define SQLITE_ISO8859 1
#endif
The other #defines I use (THREADSAFE, TEMP_FILE_PREFIX) etc. are overridable. Only the encoding is not. |
|
312 |
build
|
active
|
2003 May
|
anonymous
|
Shell
|
2003 Dec
|
|
1
|
3
|
libreadline.so.0.0 causes unidentified token error
|
edit |
I am running OpenBSD 3.2.
SQLite configures and builds just fine, but when I try to "sqlite test.db" I get "ld.so: unidentified symbol '_tgetent' in sqlite:/usr/lib/libreadline.so.0.0", and SQLite refuses to run. I grepped the source and couldn't find tgetent anywhere, then I tried man tgetent and found that it was part of the curses library. I'm not sure why this is happening, and thus I cannot give you details on how to reproduce the bug.
thanks,
will |
|
307 |
event
|
active
|
2003 May
|
anonymous
|
Shell
|
2003 Dec
|
anonymous
|
1
|
1
|
fail to rpm install on redhat 9
|
edit |
OS: Redhat 9.0
Kernel: 2.4.20-8
rpm: 4.2
package: sqlite-2.8.0-1.i386.rpm
Error: headerRead failed: region trailer: BAD, tag 2053730304
type 956301312 offset -4128768 count 524287 |
|
303 |
build
|
active
|
2003 May
|
anonymous
|
Unknown
|
2003 Nov
|
a.rottmann
|
4
|
4
|
Makefile issues
|
edit |
I pulled down an intermediate to test the fix for #284 and had a bit more trouble with the makefile than previously. Here are the versions from CVS/Entries:
/config.guess/1.2/Mon Mar 24 09:40:35 2003//
/config.sub/1.2/Mon Mar 24 09:40:35 2003//
/configure/1.16/Tue Apr 22 08:04:49 2003//
/configure.ac/1.5/Tue Apr 22 08:04:50 2003//
And I'll attache the diff between the generated Makefile and the one I ended up with, and the configure params I used.
I'm okay if you want to write off the TCL include & lib problems as due to my weird setup, and I know the double slash has been reported before, but the readline issue is probably fair game.
Lastly, it's useful to note that the generated Makefile is no longer compatible with SunWorkshop make - it really requires GNU make now. |
2004-Feb-26 14:50:53 by anonymous:
There are several config_ variables that can be passed to the configure script; for example, the Debian package uses (from a Makefile):
./configure config_TARGET_TCL_INC="-I/usr/include/tcl8.4" config_BUILD_CFLAGS="$(CFLAGS) -DTHREADSAFE=1"
Do a grep for config_ on configure.ac to see what other variables are available for tweaking.
2004-Mar-09 12:46:40 by a.rottmann:
I should really switch the stuff to use automake, plus using the conventional --with-foo-includes flags instead of config_ environment variables. |
|
301 |
code
|
active
|
2003 Apr
|
anonymous
|
Unknown
|
2003 Apr
|
|
2
|
3
|
Can't acquire lock for database on Mac OS X AppleShare volume
|
edit |
I'm using SQLite on Mac OS X 10.2.5. If I try to do a SELECT from a database that resides on an AppleShare volume (from my code or from sqlite), SQLite says that it's locked, even if no other process is using it. It appears that sqliteOsReadLock always returns SQLITE_BUSY for files on AppleShare volumes. I've temporarily solved the problem here by disabling SQLite's locking code and implementing higher-level protections in my application.
You may find this link helpful: http://developer.apple.com/technotes/tn/tn2037.html |
2004-Mar-22 11:21:56 by anonymous:
under OSX fcntl returns ENOTSUP (45) = Operation Not Supported when trying to open a DB on AFP or SMB. Local HD is fine (HFS) as well as on USB devices HFS and UFS. Even with the recommendations from Apple's technote tn2037 the problem persists. |
|
294 |
new
|
active
|
2003 Apr
|
anonymous
|
Shell
|
2003 Apr
|
a.rottmann
|
1
|
4
|
Diff for OpenBSD
|
edit |
In order to build on OpenBSD, the following diff must be applied, as per Wild Karl-Heinz <kh.wild@wicom.li>. This is on an OpenBSD 3.2 -current build.
diff Makefile.in Makefile.in~
52c52
< LIBREADLINE = @TARGET_READLINE_LIBS@ -lcurses
---
> LIBREADLINE = @TARGET_READLINE_LIBS@
Once that change is made to the Makefile.in, sqlite compiles and runs without problem. Otherwise, sqlite dies on '/usr/libexec/ld.so: Undefined symbol "_tgetent" called from sqlite:/usr/lib/libreadline.so.1.0 at 0x40083940'. |
2004-Mar-09 12:48:12 by a.rottmann:
See #303; the build system should have an overhaul. |
|
286 |
doc
|
active
|
2003 Apr
|
anonymous
|
|
2003 Apr
|
|
3
|
3
|
Tcl command documentation does not explain (minus) options.
|
edit |
The -options of the sqlite tcl command are not documented.
-version : returns versions of sqlite
-encoding : returns default encoding
-tcl-uses-utf : returns whether tcl can handle utf strings |
|
285 |
build
|
active
|
2003 Apr
|
anonymous
|
Unknown
|
2007 Nov
|
|
2
|
2
|
Configure doesn't honour LDFLAGS during build
|
edit |
Right now the configure script in the 2.8.0 tar.gz and CVS can't quite
build a working SQLite when Fink is installed - it gets confused with
finding readline.
(I've not been able to find the right places to add these changes).
* if LDFLAGS is set it is used during the check phase of configure but
it isn't used during the build, ie. LDFLAGS doesn't get into the
Makefile, this leads to the readline support being turned on but the
libraries not being available at link time
* paths searched for readline.h should include /sw |
|
279 |
new
|
active
|
2003 Apr
|
anonymous
|
|
2003 May
|
|
3
|
3
|
WinCE port of CVS version as of 02 Apr 2003
|
edit |
I've re-ported http://cvs.hwaci.com:2080/sqlite/tktview?tn=169 sqlite to Windows CE. Currently only supports MIPS CPU's and x86 but ading a CPU is a 2 liner. Code and diffs attached.
The new files (contain _wince in the filename) in my build system are in a sub dir called WinCE_src and are in the include path before the sqlite src dir. The assert_wince.h is actually called assert.h. Same for config.h.
The diffs look bigger than they really are as I've re-indented the original Windows code to match the new #IFDEF's. I've include os.h, os.c and tokenize.c for clarity.
If you just want the src to build with evc, here is a complete zip ball http://www.geocities.com/clach04/src/sqlite/wince_sqlite_CVS_2003_04_02_src.zip
Chris |
It should be considered that Windows CE doesn't support the FILE_FLAG_DELETE_ON_CLOSE option. This may cause a lot of problems with SQLite temporary files. |
|
278 |
doc
|
active
|
2003 Apr
|
anonymous
|
Unknown
|
2003 Apr
|
anonymous
|
3
|
3
|
Possible documentation bug in "expression" section.
|
edit |
The documentation for expressions shows this:
expr ::=
...
( select-statement ) |
CASE [expr] ( WHEN expr THEN expr )+ [ELSE expr] END
I think this ought to be:
expr ::=
...
( select-statement ) |
SELECT CASE [expr] ( WHEN expr THEN expr )+ [ELSE expr] END
The "SELECT CASE" form seems to be needed, at least in triggers (although, I don't recall if I tried simply "CASE ..." or not). |
|
273 |
new
|
active
|
2003 Mar
|
drh
|
CodeGen
|
2003 Mar
|
drh
|
1
|
1
|
Make NULL_ALWAYS_DISTINCT a pragma rather than a compile-time option
|
edit |
NULL_ALWAYS_DISTINCT is a #define currently set to 0. If set to 1,
then SQLite will treat NULLs a distinct in SELECT DISTINCT statements
and in UNION operators. This is what the SQL standard calls for.
But no database (other than Ocelot) works this way, so SQLite leaves
NULL_ALWAYS_DISTINCT set to 0 to enhance compatibility.
See http://www.sqlite.org/nulls.html for additional information.
This compile-time options should become a run-time option. It should
still be off by default, but a pragma should be available to turn it
on for those who want it. |
|
271 |
event
|
active
|
2003 Mar
|
anonymous
|
Unknown
|
2003 Mar
|
drh
|
3
|
2
|
'make test' fails on MacOS X
|
edit |
As per a message from drh, adding -DSQLITE_TEST=1 to the make file may fix the problem. Unfortunately adding -DSQLITE_TEST=1 to the makefile broke the sqlite build (not test) with the linker errors below. Adding -DSQLITE_TEST=1 just for the 'make test' did not fix the problem with the tests.
---- from 'make test' with or without -DSQLITE_TEST=1
trans-9.1...
Error: no such function: randstr
trans-9.2.1-0...
Error: cannot start a transaction within a transaction
trans-9.2.2-0...
Error: cannot start a transaction within a transaction
trans-9.2.9-0...
Error: no such function: randstr
trans-9.3.1-0...
Error: cannot start a transaction within a transaction
trans-9.3.2-0...
Error: cannot start a transaction within a transaction
trans-9.3.9-0...
Error: no such function: randstr
trans-9.4.1-0...
Error: cannot start a transaction within a transaction
trans-9.4.2-0...
Error: cannot start a transaction within a transaction
trans-9.4.9-0...
Error: no such function: randstr
trans-9.5.1-0...
Error: cannot start a transaction within a transaction
*** Giving up...
11 errors out of 13684 tests
Failures on these tests: trans-9.1 trans-9.2.1-0 trans-9.2.2-0
trans-9.2.9-0 trans-9.3.1-0 trans-9.3.2-0 trans-9.3.9-0 trans-9.4.1-0
trans-9.4.2-0 trans-9.4.9-0 trans-9.5.1-0
make: *** [test] Error 1
---- from 'make':
ld: multiple definitions of symbol _btree_native_byte_order
auth.lo definition of _btree_native_byte_order in section (__DATA,__common)
btree.lo definition of _btree_native_byte_order in section (__DATA,__data)
build.lo definition of _btree_native_byte_order in section (__DATA,__common)
delete.lo definition of _btree_native_byte_order in section (__DATA,__common)
expr.lo definition of _btree_native_byte_order in section (__DATA,__common)
func.lo definition of _btree_native_byte_order in section (__DATA,__common)
hash.lo definition of _btree_native_byte_order in section (__DATA,__common)
insert.lo definition of _btree_native_byte_order in section (__DATA,__common)
main.lo definition of _btree_native_byte_order in section (__DATA,__common)
os.lo definition of _btree_native_byte_order in section (__DATA,__common)
pager.lo definition of _btree_native_byte_order in section (__DATA,__common)
ld: multiple definitions of symbol _journal_format
btree.lo definition of _journal_format in section (__DATA,__common)
pager.lo definition of _journal_format in section (__DATA,__data)
ld: multiple definitions of symbol _pager_refinfo_enable
btree.lo definition of _pager_refinfo_enable in section (__DATA,__common)
pager.lo definition of _pager_refinfo_enable in section (__DATA,__data)
parse.lo definition of _btree_native_byte_order in section (__DATA,__common)
printf.lo definition of _btree_native_byte_order in section (__DATA,__common)
random.lo definition of _btree_native_byte_order in section (__DATA,__common)
select.lo definition of _btree_native_byte_order in section (__DATA,__common)
table.lo definition of _btree_native_byte_order in section (__DATA,__common)
tokenize.lo definition of _btree_native_byte_order in section (__DATA,__common)
update.lo definition of _btree_native_byte_order in section (__DATA,__common)
util.lo definition of _btree_native_byte_order in section (__DATA,__common)
vdbe.lo definition of _btree_native_byte_order in section (__DATA,__common)
where.lo definition of _btree_native_byte_order in section (__DATA,__common)
trigger.lo definition of _btree_native_byte_order in section (__DATA,__common)
make: *** [libsqlite.la] Error 1 |
2004-Aug-14 00:40:23 by anonymous:
On Mac OSX 10.3.5 with sqlite 3.0.4, "make test" resulted in:
0 errors out of 22420 tests
I suggest this bug be closed.
2004-Nov-09 20:48:41 by anonymous:
Server compiled fine here on Mac OS X 10.3.6, none of the tests fail. |
|
268 |
new
|
active
|
2003 Mar
|
anonymous
|
Parser
|
2003 Nov
|
|
1
|
3
|
columns of subselects containing joins are not recognized
|
edit |
The following is a transcript of a minimal sqlite session exhibiting the problem:
SQLite version 2.8.0
Enter ".help" for instructions
sqlite> create table A(x);
sqlite> create table B(y);
sqlite> select * from (select * from A,B) where x = 0;
SQL error: no such column: x
The problem does not appear to be with the statement select * from (select * from A,B) itself, because that produces the correct results, but with the parser being unable to resolve the column name. Using an alias does not help:
sqlite> select * from (select * from A,B) as t1 where t1.x = 0;
SQL error: no such column: t1.x
Obviously the simpler select * from A,B where x = 0 would work, but that's not a workaround in this case - I ran into this because I'm working with a relational algebra to SQL translator, that doesn't know how to simplify the expressions to more idiomatic SQL. |
|
263 |
new
|
active
|
2003 Mar
|
anonymous
|
CodeGen
|
2003 Mar
|
|
1
|
4
|
sqlite locking strategy can lead to deadlock
|
edit |
G'day,
I'm currently on a customer site, and as one does when a big upgrade is coming up the next day I was thinking about problems I've encountered over the last few weeks. I realise now that a problem I'd considered not very imporant really should be reported to you:
The locking strategy of sqlite when doing operations that modify the database is to set a read lock while data is being analysed, then upgrade that read lock to a write lock when it comes time to modify the data. This strategy can cause deadlock on a UNIX-based system if two processes are executing sql code to modify data simultaneously. The following interleaving results in deadlock:
Process 1: Lock file for read (ok)
Process 2: Lock file for read (ok)
Process 1: Upgrade lock to write lock (go into wait state for process 2 to release read lock)
Process 2: Upgrade lock to write lock (deadlock waiting for process 1 to release read lock: fail)
I have a slightly modified version of sqlite that uses blocking locks instead of your usual non-blocking lock with delay backoff strategy. I have seen this bug in operation in my build, and although I think it is more likely to occur in my version it is still possible in the vanilla sqlite version.
Since most sql statements that can modify data probably do eventually end up modifying data, my suggested fix to the locking strategy is to decide based on the kind of overall statement whether to set a read lock or a write lock. In that scenario there is no interleaving which can cause a problem because every time a lock is obtained the relevant sqlite process is guaranteed to complete it's operation and then release the lock before trying to obtain another lock (unless the user application is trying to do something tricky, say run sqlite statements from two sqlite instances at the same time and in the same thread).
For the BEGIN TRANSACTION command's lock I would also recommend a write lock be obtained, since most use of this statement would involve non-const operations during the transaction (otherwise the transaction would have no value!).
Benjamin. |
The scenario described above is not a problem for the standard
SQLite build since locks are non-blocking there. But I will consider
how locking might be changed to better accomodate blocking locks.
This is
not a high priority, however. And since the problem described above
does not occur for the standard SQLite build with non-blocking locks,
I'm changing this ticket to an enhancement request.
Further remarks by bug reporter:
The locking strategy can have implications for the non-blocking sqlite version as well. Consider the following interleaving:
Process 1: Obtain read lock (ok)
Process 2: Obtain read lock (ok)
Process 1: Upgrade read lock to write lock (failed, read lock is active)
This means that even though Process 1 obtained a lock before process 2 the operation fails. If a write lock had been obtained instead of a read lock then it would have been Process 2 that had it's operation fail. This would unfairly balance the contention between a reader and a writer process in favour of the reader in very tightly contentious environments.
On the other hand, the non-blocking mechanism is not one that deals with high contention between readers and writers very well anyway ;) That's why I ended up making the locks blocking in the first place for my version.
Benjamin. |
|
259 |
new
|
active
|
2003 Mar
|
anonymous
|
CodeGen
|
2003 Nov
|
|
1
|
2
|
ORDER BY queries including an integer primary key don't use index
|
edit |
G'day,
I have a table and index with the following specification:
CREATE TABLE Disturbance (Entry INTEGER PRIMARY KEY,Input,Value,Time,HmiQuality,Quality);
CREATE INDEX DisturbanceIndex ON Disturbance ( Input, Time, Entry );
When I do a query where the order by includes Input and Time, but not Entry no sorting is required as sqlite uses the index. When I include Entry at the end of the order by the index is not used for sorting.
I've traced this to the findSortingIndex() function in where.c. The first two order-by entries pass the appropriate tests in the part of the function beginning at pMatch = 0. The third colum fails the test.
On the line
if( pOrderBy->a[i+j].pExpr->iColumn!=pIdx->aiColumn[i+nEqCol] ) break;
the break is triggered because
pOrderBy->a[i+j].pExpr->iColumn = -1, but
pIdx->aiColumn[i+nEqCol] = 0.
It looks to me like it's the order by version that's wrong, but I didn't want to delve any deeper than this, because there's probably a reason why the value is -1, and not 0 :) I'll leave it for more experienced hands to look at from this point onwards. Any work-around suggestions would also be appreciated as this is software that will be going to a customer in a week :)
Benjamin. |
Yes, the query optimizer, and especially the code that tries to
avoid sorting by using an index, needs some work. That has been
on the to-do list for some time.
Here is a temporary work-around: In the schema you define above,
"ORDER BY Input, Time, Entry" and "ORDER BY Input, Time" will always
generate the same order. So you should use the second ORDER BY form.
Or, consider making Entry an "INT PRIMARY KEY" instead of "INTEGER
PRIMARY KEY" to avoid invoking the primary key magic of SQLite.
BTW, a value of -1 for a column number means that the column
is the key of the record. |
|
255 |
event
|
active
|
2003 Feb
|
anonymous
|
|
2003 Feb
|
|
1
|
1
|
Database locked on HP64 (B11.11)
|
edit |
When using %sqlite foo
on HP64 (HPUX B11.11, gcc 3.2)
and trying to create Table
An error message said that the database is locked |
|
254 |
event
|
active
|
2003 Feb
|
anonymous
|
|
2003 Feb
|
|
1
|
1
|
make test does not work on HP64 (B11.11)
|
edit |
make test does not work on HP64 (B11.11) |
|
253 |
event
|
active
|
2003 Feb
|
anonymous
|
|
2003 Feb
|
|
1
|
1
|
make install does not work with install-sh script
|
edit |
On HP64bits,B11.11
After ./configure and make
% make install
does not work because
install-sh does not have execution rights
need to do a chmod +x |
|
252 |
new
|
active
|
2003 Feb
|
anonymous
|
|
2003 Feb
|
|
4
|
1
|
Add optional regex matching similar to what Postgres & Oracle have
|
edit |
It would be really nice if one could use the ~ operator for regular expression matches. Postgres does this very nicely.
This one feature is a limiting factor in moving more completely to sqlite over ascii flatfiles. Using perl to slice thru stuff with regex is the only thing I miss. If I had regex matching I would be in heaven.
If you are looking for a regular expression engine, I might recommend http://www.pcre.org/ |
2004-May-03 15:33:30 by anonymous:
I second this request. I am in charge of the Gentoo Linux Tools project, and we are developing various searching tools which we wish to have a proper database backend for.
Currently, we're looking at using SQLite for this, but any speed and size advantage SQLite has over flat files for our purposes is easily removed by its inability to do regex SELECTs.
I have seen that Brad Campbell has written a patch for this, but it does not appear to have shown up by SQLite release 2.8.11, nor can I find any mention of it in the change log for the past 130 days. |
|
244 |
new
|
active
|
2003 Feb
|
anonymous
|
Unknown
|
2003 Feb
|
drh
|
5
|
4
|
Combining CREATE TABLE with its populating from some flat file
|
edit |
Michael Ovcharenko wrote:
Hi, Richard,
SQLite is a brilliant tool which can be used for
numerous purposes. It, however, can be especially
useful when it comes to producing some information on
the base of the data derived from multiple
heterogeneous data sources to suck them up onto the
SQLite tables, use these for some sophisticated
analysis, produce the necessary information, and then
drop the unnecessary tables. The whole process can be
reproduced at any time, e.g., by running a single
script with SQLite. And SQLite is very good and fast
here with its ".COPY table-name FROM file-name ..."
command. Still, the table should have been created
before this operation.
Don't you think it could be useful for SQLite to
combine both (create table and populate it with the
data) in one command (which can be considered as an
extension of ".COPY..." command - it does not comply
with SQL92 anyway) provided that the first row of the
source data file contains column names. It seems to be
especially reasonable as SQLite is typeless and could
potentially "suck up" a source file representing any
number and types of columns. In many cases the source
data can represent some spreadsheet exported, e.g., in
CSV format, so these files usually contain column
headers anyway. In an extreme case, table name and
column names (when missing) could be generated in
according to some convention.
RH: Good idea. I suggest syntax like this:
CREATE TABLE <name> AS COPY FROM <file>.
Or perhaps just
CREATE TABLE <name> FROM <file>.
Can you write this up as an enhancement ticket on
CVSTrac so that I don't forget?
http://cvs.hwaci.com:2080/sqlite/tktnew
MO: Another opportunity is to extend .COPY command so that it will be able to implicitly create table in case it does not exist yet. Its parameters may establish certain pattern on default names for its columns if (in an extreme case) the first line of the source file does not contain any column names, e.g. something like DEFAULT COLNAME AS 'EMP_COL' (plus its sequential number like EMP_COL1, EMP_COL2, etc.). When created implicitly, the name of the table can be defaulted from "table-name" clause of .COPY command.
I think, it could be useful to consider employing ON CONFLICT clause for this case (can it be extednded with something like CREATE TABLE?).
Best regards,
Michael Ovcharenko. |
|
243 |
new
|
active
|
2003 Feb
|
anonymous
|
Unknown
|
2003 Oct
|
anonymous
|
3
|
4
|
Performance problem with MSVC precompiled DLL
|
edit |
After a while the time for queries increase from e.g. 0.46 sec to 1.5 sec or even over 2 sec. The interesting thing is, that time for sqlite_free_table also increase.
I recompiled the library with Borland C++ Builder 5 with the effect, that it runs 2 times faster (about 0.25 s for the same query) and produces constant times for queries.
Another advantage of this library is : no need for msvcrt.dll.
The only dependences are : kernel32.dll and user32.dll
For details mail me at : sascha_7777@onlinehome.de and i will send you this version of library. |
My guess that this is entirely the fault of particularly poor
malloc() that comes by default on Windows. Borland C++ Builder 5
is probably tossing in its own (better) malloc() implementation.
---
Pablo 10/16/2003
I have confirmed this as well with 2.8.6. I was seeing the behavior reported here and after rebuilding the DLL with BCB 5.5 (which is free now) the memory usage is down and the query times are constant.
With the downloaded DLL, I would see the following results (times in seconds):
took 0.0400 for 1 rows and 2 columns
took 0.0700 for 681 rows and 17 columns
took 0.0000 for 8 rows and 2 columns
took 0.6010 for 1 rows and 2 columns
took 0.0700 for 681 rows and 17 columns
took 0.0000 for 8 rows and 2 columns
took 0.5210 for 1 rows and 2 columns
took 0.0800 for 681 rows and 17 columns
took 0.0000 for 8 rows and 2 columns
It simply runs the same 3 select statements 3 times. The first time, it is fast because (presumably) the heap is clean.
After rebuilding the DLL with BCB 5.5, the results are as follows:
took 0.0100 for 1 rows and 2 columns
took 0.0300 for 681 rows and 17 columns
took 0.0100 for 8 rows and 2 columns
took 0.0100 for 1 rows and 2 columns
took 0.0300 for 681 rows and 17 columns
took 0.0000 for 8 rows and 2 columns
took 0.0100 for 1 rows and 2 columns
took 0.0300 for 681 rows and 17 columns
took 0.0000 for 8 rows and 2 columns |
|
241 |
new
|
active
|
2003 Feb
|
anonymous
|
|
2005 Jun
|
anonymous
|
5
|
5
|
lack of alter table statement
|
edit |
Have you any plans for the alter table statement? |
|
239 |
new
|
active
|
2003 Feb
|
anonymous
|
Unknown
|
2004 Jul
|
|
4
|
2
|
ANSI/Unicode(Wide) version file-handling functions for Win32
|
edit |
As I reported in the ML, since SQLite os.c file-operation functions accept only const char *zFilename, when you build a project with SQLite source
code under _UNICODE defined on Win32, their internal expectation of
ANSI version function fails. For example,
int sqliteOsDelete(const char *zFilename){
#if OS_UNIX
unlink(zFilename);
#endif
#if OS_WIN
DeleteFile(zFilename);
#endif
#if OS_MAC
unlink(zFilename);
#endif
return SQLITE_OK;
}
DeleteFile in this function is replaced with DeleteFileW, the unicode
version of DeleteFile, which takes Unicode string(wide characters) as
an argument.
To compile SQLite in Unicode application, you must change those
functions to its ANSI version. For DeleteFile, it's DeleteFileA.
The functions that should be presented in os.c as their explicit
ANSI version are:
DeleteFile -> DeleteFileA
GetFileAttributes -> GetFileAttributesA
CreateFile -> CreateFileA
GetFullPathName -> GetFullPathNameA
GetTempPath -> GetTempPathA
Namely, all file-handling Win32 APIs that take a path name as its argument, not a handle. |
The 'vanilla' versions of functions like GetFile() aren't functions, but symbols defined in "winbase.h". For example, GetFile() expands to:
#ifdef UNICODE
#define DeleteFile DeleteFileW
#else
#define DeleteFile DeleteFileA
#endif // !UNICODE
So when someone compiles SQLite under Windows, they need to #define _UNICODE (or not), as desired. Unless I completely misunderstand this, there is no reason to change the SQLite code, and doing so would make it less flexible.
Additionally, The unicode versions of the functions will handle ASCII strings, which are legal UTF8 strings. So the only real consideration left is the 'offical' SQLite Windows DLL. Because older systems (95, 98) lack built-in support for the Unicode versions of most functions, the DLL should probably be built without the Unicode versions.
We might want to force the definition of UNICODE when SQLITE_UTF8 is defined, so that the DLL can be queried to see what kind of strings it expects, but then, someone (me) may reasonably want to compile the app to use unicode strings for file handling, but iso8859 strings for data. So at most I would suggest a #pragma message when the two symbols disagree. This is compiler dependent, but one for MSVC, Borland, and gcc would probably catch most current users.
Jim Lyon
(by reporter)
In C++ context compiler issues error because const char* of os.c functions doesn't match DeleteFileW signature under _UNICODE defined and this is not convenient in simply adding SQLite source files in UNICODE-defined host app project.
Anyway, if os.c Windows-version functions take LPCTSTR zFilename that is translated into const char* in ANSI(MBCS) and const wchar* in _UNICODE in compile-time, you don't have to use explicit ANSI version API. If explicit use of ANSI version API makes SQLite "less flexible", I'd like to propose changing const char* zFilename to LPCTSTR in os.c.
Another way is, add to SQLite its own ANSI/Unicode(UCS-2) version APIs as Windows does, in Windows SQLite build. For example "open" is translated in sqlite.h to openA/openW which exists in dll. Fortunately SQLite has os.c as abstraction filter for its body, several changes in os.c will be sufficient.
(by reporter)
It's fixed in between 3.0.0 and 3.0.2 by adding 'A' suffix to those file-handling APIs. Can someone verify and close this ticket?
2004-Jul-22 23:19:23 by anonymous:
SQLite 2.8.15 os.c is not fixed as of now. I think there's no reason not to apply the same replacement that favors ASCII APIs. |
|
236 |
new
|
active
|
2003 Jan
|
anonymous
|
|
2003 Feb
|
|
3
|
3
|
Add RENAME TABLE - will be easier to work around missing ALTER TABLE
|
edit |
Currently the recommended method to ALTER TABLE is:
- Create a temporary table.
- Copy all data from original table to temporary table.
- Drop the original table.
- Create a new table.
- Copy all data from the temporary table to the new table.
This means that most of the data is copied twice - with a big database this may take quite some time.
I suggest adding a RENAME TABLE command, which will cut 50% of the overhead (copy the data only once instead of twice):
- Rename the original table to a temporary name.
- Create a new table.
- Copy data from the temporary/original table to the new table.
- Drop the temporary/original table.
A further enhancement would be to make the RENAME TABLE an internal command (not exposed to the SQL interface), and use it internally in order to implement an ALTER TABLE feature.
This may not be the most efficient ALTER TABLE out there, but at least will make SQLite much more compatible with standard SQL commands. It will certainly make life easier during development, when tables need to be altered all the time. |
This suggestion isn't as easy to implement as it sounds. Because VIEWs, TRIGGERs, FOREIGN KEYs,... can reference a table by name, renaming a table means modifying their schemas to do the renaming, and handling all kinds of cases.
One trick might be to have the parser modify the SQL used to create all SQLite TABLES, VIEWS,... by inserting special C-style comments into the SQL following every table name, which would allow you to find and replace them. For example:
CREATE TABLE t1 (...);
becomes
CREATE TABLE t1 /*SQLITE-TABLE-NAME:t1*/ (...);
Another way would be to create the temp table with a new name, and then have a SWAP TABLE pragma which ends up swapping the pointers to the tables. Afterwards you have to re-check constraints on both tables. Then you can drop the old table.
Jim Lyon
---
I agree that just renaming a table can have adverse side-effects as you describe. However, I suggest RENAME TABLE only as an intermediate solution for the missing ALTER TABLE.
If used only in the way I suggest, then RENAME TABLE will not have any side effects, as it will just be part of a procedure that results in no change to the original table name:
- Rename original table to temp name.
- Create new table with ORIGINAL name.
- Move data from previous to new table.
- Drop previous table.
As you can see in step 2, the "new" table retains the original name, so any references from other tables should be retained. I think that the SWAP TABLE you suggest is very similar.
Of course, references to specific fields may be affected (if the new table structure drops some fields), but this is anyway the case with ALTER TABLE.
Eyal Zvi. |
|
235 |
new
|
active
|
2003 Jan
|
anonymous
|
Unknown
|
2003 Nov
|
chw
|
5
|
1
|
Local language do not support!
|
edit |
We are from Russia! We need support for local language! I think, this make faster, if you add the WinAPI functions for compare ansi string, or other way. |
To fix this you can add one small function to the sqlite sources.
Note, I don't know about possible damages.
--- sqlite/src/util.c.locale Sat Aug 31 20:14:35 2002
+++ sqlite/src/util.c Fri Sep 27 14:06:56 2002
@@ -415,6 +415,23 @@
};
/*
+** Compile with SQLITE_ISO8859=1 and call this function on startup.
+**
+** Usage:
+**
+** setlocale(LC_CTYPE, "");
+** sqliteSetUpperToLower();
+**
+*/
+void sqliteSetUpperToLower(){
+ /*extern int tolower (int c);*/
+ int i;
+ for (i = 0; i <= 255; i++) {
+ UpperToLower[i] = (unsigned char)tolower(i);
+ }
+}
+
+/*
** This function computes a hash on the name of a keyword.
** Case is not significant.
*/
|
|
233 |
event
|
active
|
2003 Jan
|
anonymous
|
Unknown
|
2003 Jan
|
|
1
|
4
|
test bigfile-1.1 dumps core on Tru64 platform
|
edit |
I'm trying to get cvstrac (which uses sqlite) up and running on a Tru64 machine (uname -a follows):
OSF1 calypso.umc.com.ua V5.1 732 alpha
However, cvstrac coredumps constantly. In attempt to track the reason of bug I tried to run 'make test' for sqlite and got:
bigfile-1.1...make: Segmentation fault (core dumped)
I tried to compile with either gcc-3.0.3 or supplied cc (dont know how to get version of cc, though) - it doesnt matter, coredump doesnt go.
If I try to run testfixture under gdb, SIGSEGV kills gdb as well, so I tried to use truss to get a backtrace and got:
[lots of open("/var/tmp/sqlite_59JacTYbQOLAC2h")/write/close skipped - they all were succefull ]
185527: fcntl(9, F_SETLK, 0x000000011FFF9000) = 0
185527: fstat(9, 0x000000011FFF8F70) = 0
185527: fcntl(9, F_SETLK, 0x000000011FFF9090) = 0
185527: write(7, "\0\0\003\0\0\0\0\b\0 803".., 1028) = 1028
185527: Incurred fault #32, FLTBOUNDS %pc = 0x0000000120007130 addr = 0x000000011FFF6EA0
185527: Received signal #11, SIGSEGV [default]
185527: siginfo: SIGSEGV SEGV_MAPERR addr=0x000000001FFF7369
Err#139 Error 139 occurred.
185527: *** process killed ***
Seems like "write out of page bounds to me". Where can I get a closer look at in attempt to resolve the problem? |
|
230 |
event
|
active
|
2003 Jan
|
anonymous
|
Shell
|
2003 Jan
|
anonymous
|
4
|
5
|
Problems compiling on AIX 4.3.3
|
edit |
Probably not really a bug, but a problem compiling on AIX 4.3.3 that I fixed and thought you might like to know about...
During make, I got the output below. The problem turned out to be the AIX nm command itself. I used nm from gnu's bintools and it made fine. Thought you might like to know.
FYI, the relevant output from make was:
/usr/bin/nm -B .libs/btree.o .libs/build.o .libs/delete.o .libs/expr.o (etc, etc)
nm: .libs/main.o: 0654-206 Cannot process the symbol table.
...
gcc -g -O2 -DOS_UNIX=1 -DOS_WIN=0 -DHAVE_USLEEP=1 -I. -I../src -DHAVE_READLINE=0 -o .libs/sqlite (etc, etc)
ld: 0711-317 ERROR: Undefined symbol: .sqlite_interrupt
ld: 0711-317 ERROR: Undefined symbol: .sqlite_exec
ld: 0711-317 ERROR: Undefined symbol: .sqlite_open_aux_file
ld: 0711-317 ERROR: Undefined symbol: .sqlite_close
ld: 0711-317 ERROR: Undefined symbol: .sqlite_busy_timeout
ld: 0711-317 ERROR: Undefined symbol: .sqlite_complete
ld: 0711-317 ERROR: Undefined symbol: .sqlite_error_string
ld: 0711-317 ERROR: Undefined symbol: .sqlite_open
ld: 0711-317 ERROR: Undefined symbol: sqlite_version
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status
make: 1254-004 The error code from the last command is 1.
Stop. |
|
229 |
new
|
active
|
2003 Jan
|
anonymous
|
Parser
|
2005 Sep
|
|
5
|
4
|
DECLARE ... CURSOR FOR ... would be really nice
|
edit |
Cursors can be a tremendous performance aid in GUI-driven applications with large data sets, and it's pretty hard to emulate them if your application is written with the concept in mind.
I would really be thrilled if cursors found their way into SQLite!
Thanks,
b.g. |
OK, this is now Jan 2005 and "cursors" are not there yet. Any plans? what would be an easy work around.
2005-Sep-14 06:31:57 by anonymous:
Yes Cursor would be a added advantage so that we dont have to move to and for from application to sqlite for smiple calculation
2005-Sep-14 20:03:40 by anonymous:
SQLite3's cursors are called sqlite3_prepare(), sqlite3_step(), sqlite3_reset() and sqlite3_finalize()
Seriously, the purpose of a cursor is to leave the data on the database server and retrieve only the data and columns you need from a resultset managed by the server. SQLite is an embedded file-based database engine, not a database server -- therefore cursors make no sense.
Asking for cursors in sqlite is akin to asking the filesystem to give you a cursor on a textfile so you can only read one line at a time -- when the reality is, you just open the file and read the lines yourself. sqlite3_step() is your cursor, it is reading the row from the file, one row at a time. |
|
219 |
new
|
active
|
2003 Jan
|
anonymous
|
|
2003 Jan
|
|
5
|
5
|
MySQL style enums
|
edit |
I would be really cool if SQLite supported enum like MySQL does:
http://www.mysql.com/doc/en/ENUM.html |
|
216 |
new
|
active
|
2003 Jan
|
anonymous
|
|
2003 Jan
|
|
1
|
1
|
Add "DISTINCT ON()" clause to specify the fields to apply the unicity
|
edit |
Like postgresql is a good enhancement to the distinct clause allow to specify wich fields to use when decide that a row match the distinct clause. |
Looking in a way to achieve the above functionality I've discovered that sqlite permit us to have columns in a "select" with "group by" that aren't present in the "group by" clause or in an agregate function.
With that functionality ("Bug" a nice one) we can get the same result of "DISTINCT ON()".
create table test(pk integer, name text);
insert into test(1,'carl');
insert into test(2,'pal');
insert into test(3,'carl');
select distinct on(name) name, pk from test; -- impossible in most databases
-- return the same result as
select name, pk from test group by name; -- as well impossible in all databases I know except SQLITE
Please leave the "group by" functionality ("bug") there allways.
2004-Mar-10 01:45:44 by anonymous:
That's a good workaround, except it's seemingly impossible to apply ordering first. E.g. I want to select the latest submission for each document in a table like the following:
create table submissions (
s_id integer primary key,
doc_id integer references documents,
entry_time datetime);
I do this in postgresql:
select distinct on (doc_id) s_id from submissions order by doc_id, entry_time desc;
By doing so, I get the s_id for the latest submission of each document.
Using the group by workaround in sqlite will not apply the sort before choosing the row, so it does not choose latest submission, but rather some arbitrary one.
2006-Feb-11 13:45:11 by anonymous:
What is the current status? I have found http://article.gmane.org/gmane.comp.db.sqlite.general/703 and I would like to know if it is now a supported feature instead of a "consequence". I would also like to know if running
SELECT a, min(b) FROM t1 GROUP BY a;
1, 2
2, 4
is the proper way to select all rows with distinct a's and the smallest b. Is this equivalent to saying:
SELECT a as aa, b FROM t1 where b = (select min(b) from t1 where a = aa) GROUP BY a;
It gives the same result with 3.2.8 but the 'explain' output looks longer for the second version... |
|
209 |
new
|
active
|
2002 Dec
|
anonymous
|
BTree
|
2003 Nov
|
|
1
|
1
|
update libtool
|
edit |
The version of libtool shipped with sqlite is very out of date (well over a year old). It does not properly detect the ability to build shared libraries on darwin, for example, which is bad. You need to update to the latest version of gnu libtool. |
|
207 |
event
|
active
|
2002 Dec
|
anonymous
|
Shell
|
2003 Dec
|
|
2
|
1
|
After installation cannot create any databases
|
edit |
After installation of sqlite 2.7.4, use of the commandline to create a database always ends with a SQL error: database locked. The file of the database is created. |
I've been experiencing the same issue with 2.8.0, compiled for the Cygwin environment in Windows 95. The issue is not present if I instead compile for the MinGW environment.
For my case, I've tracked it down to an issue with the behaviour of advisory locking in Cygwin (based on the fcntl POSIX function). I've patched my copy to work around the issue by clearing any existing locks on a file before attempting to acquire a new one, though I'm not too sure this is the best solution.
Russell Reed (rreed@cei.net)
Same for me with sqlite 2.8.6. Here's my environment:
$ dmesg |head
Linux version 2.2.25 (root@sbgpcs22) (gcc version 2.95.4 20011002 (Debian prerelease)) \#1 SMP Mon Mar 31 19:10:06 CEST 2003
BIOS-provided physical RAM map:
BIOS-e820: 0009f000 @ 00000000 (usable)
BIOS-e820: terface adding patch-sets, bug tracking, and Wiki
to CVS. http://www.hwaci.com/sw/cvstrac/.
|
|
204 |
event
|
active
|
2002 Dec
|
anonymous
|
Unknown
|
2002 Dec
|
anonymous
|
1
|
1
|
Select statement takes hours (or more!)
|
edit |
On Win32, I have a 500> MB db with 13 tables. The schema for each table is:
CREATE TABLE XX
(Year integer,Month integer,
ProvOD integer,PaisOD integer,Posicion char(10),IOD char(1),
PesoI float,UnidadesI float,ValorEstI float,
PesoE float,UnidadesE float,ValorEstE float);
create index tmpidx on tmp (provod,paisod,posicion,iod);
One the the tables is called tmp and it has more than 2.000.000 records.
Issuing the statement:
select 1994 AS Year,-1 AS Month,ProvOD,PaisOD,Posicion,IOD,
SUM(PesoI) AS PesoI,SUM(UnidadesI) AS UnidadesI,SUM(ValorEstI) AS ValorEstI,
SUM(PesoE) AS PesoE,SUM(UnidadesE) AS UnidadesE,SUM(ValorEstE) AS ValorEstE
FROM tmp GROUP BY
ProvOD,PaisOD,Posicion,IOD;
takes forever (at least several hours - Pentium III 800Mhz), the I stopped with ^C.
Also it "eats" more than 200 Mb of RAM while executin (through the sqlite command line).
If I get ride of the "Position" field in the group by it takes 50 seconds.
Is it normal? Is there anyway to speed that up? Am I taking sqlite to its limits? Comments? |
|
203 |
new
|
active
|
2002 Dec
|
anonymous
|
Unknown
|
2002 Dec
|
anonymous
|
2
|
1
|
Missing Win32 open flag if shared database
|
edit |
In Win32, network and/or shared files should be opened with the FILE_FLAG_WRITE_THROUGH flag in the os.c file.
There could be a flag when opening a database that informs the file is to be opened as shared or exclusive, and avoid locking if exclusive. I think this would improve speed considerably in "local" or exclusive databases. |
|
192 |
doc
|
active
|
2002 Nov
|
anonymous
|
Unknown
|
2002 Nov
|
anonymous
|
4
|
4
|
Finishing build on MacOS 10.x (and other *nix's, likely)
|
edit |
Platform: MacOS 10.x (10.2.2)
Problem: "Make" of SQLite source goes fine, but using the libsqlite.a archive in an application build fails (eg., demo in Blackhole Media's ObjC wrappers, or in building Neo [http://expert.cc.purdue.edu/~mthole/neo/index.html] from source).
Errmsg: "table of contents for archive: libsqlite.a is out of date; rerun ranlib(1) (can't load from it)".
Solution: Run "ranlib libsqlite.a" in terminal.
Explanation: (From the "ranlib" manual:) "Ranlib adds or updates the table of contents to each archive so it can be linked by the link editor, ld. The table of contents is an archive member at the beginning of the archive that indicates which symbols are defined in which library members.... Ranlib takes all correct forms of libraries (fat files containing archives, and simple archives) and updates the table of contents for all archives in the file." |
|
186 |
new
|
active
|
2002 Nov
|
anonymous
|
Shell
|
2002 Nov
|
|
5
|
4
|
./configure --enable-threads-safe ?
|
edit |
It would be nice to have a ./configure --enable-threads-safe feature instead of using the template Makefile to compile libsqlite with this option turned on. |
|
184 |
new
|
active
|
2002 Oct
|
mike
|
|
2003 Jul
|
drh
|
5
|
3
|
auto update mechanism for CVS
|
edit |
is it possible to set up CVS in such a way that we are notified of activities on tickets, and check-ins? |
|
180 |
event
|
active
|
2002 Oct
|
anonymous
|
|
2003 Dec
|
anonymous
|
1
|
1
|
on WIN32 - multithreaded process causes crash on assert(mutext)
|
edit |
I'm testing how the sqlite is handling load with multiple threads and processes writing to the same table in the same db.
the attached program instantiates 3 threads that are sequentially updating a table.
each thread has its own db connection (sqlite * psqlite).
I tried running 2 instances of this program simultaneously and the following happens:
many times i get "Disk I/O Error" - but then i close an re-open the db and it works (is that the way to handle this problem?)
some times i get the error " Error db no such table: ac" (that's a strange one - i also re-open the db to recover)
but after a while the program constantly crashes on the following line:
line 889 in os.c ( assert( !inMutex );)
I'm currently testing it under windows 2000 - but this program should also run on linux.
i'm attaching the code and a database (AWDB) on which i tested it. |
I'm also experiencing this in linux doing multithreaded load tests with 2 threads updateing and 3 threads selecting.
Nevermind! This was due to THREADSAFE not being defined at build time. It might be nice to have this defined by default. |
|
175 |
new
|
active
|
2002 Oct
|
anonymous
|
Pager
|
2002 Oct
|
|
5
|
3
|
journal file should be kept open
|
edit |
In windows at least, the journal file used to manage transactions is being created and deleted for every transaction. this makes transactions slow in the following case: if a virus scanner is active, it will attempt to scan the file being created every time , and it will add 50-100 ms to each transaction. While starting an explicit transaction makes the problem smaller, in an environment where many atomic transactions with a single INSERT or UPDATE must be executed, this slows things down quite a lot. I understand that the peculiarity of the virus scanner actually creates the problem, but , is it a good design decision to keep creating and droping the file ?
of course, there is the issue of multiple process accessing the same database, in which case multiple journals would exist, but this should/would be resolved by the locking mechanism anyway... |
|
169 |
new
|
active
|
2002 Oct
|
anonymous
|
Unknown
|
2004 Apr
|
anonymous
|
5
|
5
|
CE version
|
edit |
I've successfully ported sqlite to windows CE 3.0 using eVC3.5maybe it was already done ?)
I have only modified os.c to take into account the unicode interface.
I attach my modified file.
Best regards
Noel Frankinet |
Can you attach the full modified source code for me ? (.zip)
My personal e-mail is hensel@al.furb.br
Thanks ...
Andri |
|
164 |
event
|
active
|
2002 Oct
|
anonymous
|
CodeGen
|
2002 Oct
|
anonymous
|
3
|
4
|
Compiler warnings with MS Visual C++ 6.0
|
edit |
Hi,
when I incorporated the "sqlite_source.zip" source code into a Microsoft Visual C++6.0 sample application, I got 24 warnings, mostly due to some signed/unsigned mismatch. It looks as it still works fine (no difference as when I used the DLL), but you never know if this holds true alltimes. Not showing up warnings would improve convidence into the product.
Regards, Louis Schneider
Deleting intermediate files and output files for project 'GENERIC - Win32 Release'.
--------------------Configuration: GENERIC - Win32 Release--------------------
Compiling resources...
Compiling...
GENERIC.C
where.c
build.c
delete.c
expr.c
C:\samples\techart\tech\win32\generic3\expr.c(1461) : warning C4018: '!=' : signed/unsigned mismatch
func.c
hash.c
insert.c
main.c
opcodes.c
os.c
C:\samples\techart\tech\win32\generic3\os.c(495) : warning C4018: '==' : signed/unsigned mismatch
pager.c
C:\samples\techart\tech\win32\generic3\pager.c(346) : warning C4018: '>' : signed/unsigned mismatch
C:\samples\techart\tech\win32\generic3\pager.c(1008) : warning C4018: '>=' : signed/unsigned mismatch
parse.c
printf.c
random.c
select.c
C:\samples\techart\tech\win32\generic3\select.c(99) : warning C4018: '==' : signed/unsigned mismatch
shell.c
table.c
tokenize.c
trigger.c
Generating Code...
parse.c(6771) : warning C4761: integral size mismatch in argument; conversion supplied
parse.c(6782) : warning C4761: integral size mismatch in argument; conversion supplied
Compiling...
update.c
util.c
vdbe.c
C:\samples\techart\tech\win32\generic3\vdbe.c(2069) : warning C4244: 'initializing' : conversion from 'double ' to 'int ', possible loss of data
btree.c
C:\samples\techart\tech\win32\generic3\btree.c(2306) : warning C4018: '<' : signed/unsigned mismatch
Generating Code...
C:\samples\techart\tech\win32\generic3\btree.c(629) : warning C4761: integral size mismatch in argument; conversion supplied
C:\samples\techart\tech\win32\generic3\btree.c(1762) : warning C4761: integral size mismatch in argument; conversion supplied
C:\samples\techart\tech\win32\generic3\btree.c(1764) : warning C4761: integral size mismatch in argument; conversion supplied
C:\samples\techart\tech\win32\generic3\btree.c(516) : warning C4761: integral size mismatch in argument; conversion supplied
C:\samples\techart\tech\win32\generic3\btree.c(520) : warning C4761: integral size mismatch in argument; conversion supplied
C:\samples\techart\tech\win32\generic3\btree.c(534) : warning C4761: integral size mismatch in argument; conversion supplied
C:\samples\techart\tech\win32\generic3\btree.c(538) : warning C4761: integral size mismatch in argument; conversion supplied
C:\samples\techart\tech\win32\generic3\btree.c(541) : warning C4761: integral size mismatch in argument; conversion supplied
C:\samples\techart\tech\win32\generic3\btree.c(482) : warning C4761: integral size mismatch in argument; conversion supplied
C:\samples\techart\tech\win32\generic3\btree.c(483) : warning C4761: integral size mismatch in argument; conversion supplied
C:\samples\techart\tech\win32\generic3\btree.c(410) : warning C4761: integral size mismatch in argument; conversion supplied
C:\samples\techart\tech\win32\generic3\btree.c(421) : warning C4761: integral size mismatch in argument; conversion supplied
C:\samples\techart\tech\win32\generic3\btree.c(432) : warning C4761: integral size mismatch in argument; conversion supplied
C:\samples\techart\tech\win32\generic3\btree.c(434) : warning C4761: integral size mismatch in argument; conversion supplied
C:\samples\techart\tech\win32\generic3\btree.c(1924) : warning C4761: integral size mismatch in argument; conversion supplied
Linking...
Creating library GENERIC.lib and object GENERIC.exp
GENERIC.exe - 0 error(s), 24 warning(s) |
|
154 |
code
|
active
|
2002 Sep
|
drh
|
Pager
|
2007 Jun
|
drh
|
3
|
3
|
Prohibit links on database files.
|
edit |
If a database file is aliased using either hard or symbolic links,
it can happen that an aborted transaction will not roll back
correctly.
Consider this scenario. The database file is named both a.db and
a.db. Application one opens a.db and starts to make a change.
This creates a journal file a.db-journal. But application one
crashes without completing the transaction. Later, application
two attempts to open the database as b.db. App two looks for a
journal file to rollback, but it thinks the journal should be
named b.db-journal. So it fails to see the a.db-journal that
app one left and fails to rollback the transaction.
The only way I can think of to prevent this kind of thing it to
refuse to open any database file that contains two or more
hard links and to refuse to open a file through a symbolic link. |
2004-Mar-16 20:46:17 by anonymous:
What if the journal file name wasn't based on the database name, but instead was based on the starting inode of the database file? For instance, "journal-10293" would be used if the starting inode for the associated database file was 10293.
2004-Mar-20 17:17:41 by anonymous:
Using Inode-numbers to solve this problem is a dangerous proposition, as disk defragmenters can alter the inode the db starts at in between a crash and a subsequent roll-back attempt.
2007-Jun-05 03:57:17 by anonymous:
On unix, you can use ftok() to solve this problem. It guarantees to return the same key for all paths to the same file, including symbolic and hard links.
I have to experience programming in Windows, but have no doubt a similar function call exists in that API. |
|
151 |
new
|
active
|
2002 Sep
|
anonymous
|
|
2007 Mar
|
|
5
|
5
|
Add 'configure' options for locating readline headers and library
|
edit |
Just a feature request on the build system. If 'configure' offered compile-time options for specifying the location for readline's includes and headers, that would make it easier to link in readline support on systems where readline isn't installed in /usr/local.
It is common to see '--with-readline-includes' and '--with-readline-libs' as config options in other software distributions that use readline. |
2007-Mar-20 23:11:10 by anonymous:
In the meantime, if you want to link against a readline in an unusual location, configure (it will configure without readline), then edit the resultant Makefile:
# Compiler options needed for programs that use the readline() library.
#
READLINE_FLAGS = -DHAVE_READLINE=1 -I/home/mjs/local/include
# The library that programs using readline() must link against.
#
LIBREADLINE = -L/home/mjs/local-linux/lib -lreadline -lncurses
|
|
139 |
new
|
active
|
2002 Aug
|
anonymous
|
Pager
|
2002 Aug
|
|
3
|
3
|
Named transactions are misleading as documented
|
edit |
As documented it appears as though you can assign meaningful names to transactions, but in practice the names are just a throwaway for SQL92 compatibility. Nested transactions could be implemented if names were used -- perhaps by using markers in the journal file. This method would work well and provide for unlimited nesting of transactions given that sqlite does not support concurrent transactions.
Example nested transaction:
begin transaction t1;
-- creates journal: mydb-journal
...
inserts, updates, deletes, etc...
...
begin transaction t1a;
-- adds a marker (e.g. 'begin t1a') to the journal
...
inserts, updates, deletes, etc...
...
commit transaction t1a;
-- adds a marker (e.g. 'commit t1a') to the journal
...
begin transaction t1b;
-- adds a marker (e.g. 'begin t1b') to the journal
...
...
begin transaction t1b1;
-- adds a marker (e.g. 'begin t1b1') to the journal
...
commit transaction t1b1;
...
rollback transaction t1b;
-- rolls back the database to journal marker 'begin t1b'
rollback transaction t1;
-- rolls back to the beginning of the journal, undoing
-- the commit performed in transaction t1a.
|
|
129 |
event
|
active
|
2002 Jul
|
anonymous
|
Unknown
|
2002 Jul
|
|
4
|
4
|
tcl-2.2 test fails
|
edit |
Mac OS X 10.1.5/Tcl8.4b4
When sqlite is compiled with UTF-8 encoding, -DSQLITE_TEST and no memory debugging activated, the tcl-2.2 test fails in the context of running the quick test suite.
tcl-2.2...
Error: can't read "result(*)": variable isn't array
When the tclsqlite.test suite is run individually, all tests pass. I worked around this by modifying the test case to unset the variable 'result' at the top of the test.
do_test tcl-2.2 {
catch { unset result }
execsql "INSERT INTO t\u0123x VALUES(1,2.3)"
db eval "SELECT * FROM t\u0123x" result break
set result(*)
} "a b\u1235"
|
This problem does not appear under Linux or Win2k.
It may be an issue with OS X or with the new Tcl.
See also tickets #126, #127, and #128. |
|
128 |
event
|
active
|
2002 Jul
|
anonymous
|
Unknown
|
2003 Oct
|
|
4
|
4
|
Workaround for problem reported in ticket 127-
|
edit |
Replacing the misuse-5.3 test case with the following enables testfixture to continue running the quick test suite without bus error on Mac OS X 10.1.5/Tcl 8.4b4.
do_test misuse-5.3 {
db close
catch { sqlite_exec_printf $::DB {SELECT * FROM t1} {} } result
set result
} {21 {library routine called out of sequence}}
|
This problem does not appear under Linux or Win2K.
It may be an issue with OS X or with the new Tcl.
See also tickets #126, #127, and #129. |
|
126 |
event
|
active
|
2002 Jul
|
anonymous
|
VDBE
|
2002 Jul
|
|
4
|
5
|
malloc-1.195 test aborts from assert in vdbe.c
|
edit |
Release 2.6.2 passes the quick.test suite with no errors. In further testing with the complete suite (all.test), the tests abort at malloc-1.195. The error message is given below.
malloc-1.194... Ok
malloc-1.195..../src/vdbe.c:5127: failed assertion `p->tos<pc'
Abort trap
I don't know how serious this is, given that the quick tests pass. I submit it just in case you're idly curious about this particular failing test.
My system is Mac OS X 10.1.5, 640 MB RAM. sqlite compiled against Tcl 8.4b4, with -DSQLITE_TEST and -DMEMORY_DEBUG.
Bill Garrison
garrison@standardorbit.com |
This problem does not appear on Linux or Win2K.
This may be an issue with OS X or with the new Tcl library.
See also tickets #127, #128, and #129. |
|
98 |
todo
|
active
|
2002 Jul
|
drh
|
|
2002 Jul
|
drh
|
1
|
1
|
Document and test TEMPORARY views
|
edit |
Add documentation and tests for TEMPORARY views. |
|
96 |
todo
|
active
|
2002 Jul
|
drh
|
|
2002 Jul
|
drh
|
1
|
1
|
Handle problems resulting from fork()
|
edit |
Update the documentation to explicitly state that SQLite database
connections should not be carried across a fork() under Unix.
Try to detect when this rule is broken and return SQLITE_MISUSE. |
The code is in place. We need to test it and add caveats to the
documentation telling the user not to keep SQLite connections
open across a fork().
2006-Nov-03 23:44:46 by anonymous:
Using pthread_atfork(3C) sqlite3 could re-open open files on fork(2). |
|
93 |
new
|
active
|
2002 Jul
|
anonymous
|
|
2004 Jan
|
|
3
|
3
|
Can't open database when TEMP environment variable is not defined well
|
edit |
This happened on WIN32 but is relevant to unix too.
When the TEMP variable is not configured well the GetTempPath returns it without any checking that the directory exists.
The error the database returns is something like "can't find table sqlite_temp_master" while the real error is that the temporary file couldn't be created.
For security reason, the best practice is to give the application to set the temp directory. Then as the application writter I know where all the relevant sqlite files will be created and have full control of it.
I will be happy to do the fix (If you find it suitable).
Thanks in advanced
Avner |
This happens always when using sqlite from a NT / Win2000 / XP service since they don't resolve the default TEMP directory var. |
|
82 |
new
|
active
|
2002 Jun
|
anonymous
|
|
2002 Jun
|
|
1
|
4
|
Add IsCacheable, IsNullable to sqlite_create_function
|
edit |
I did a first release of Ruby-SQLite interface and I've noticed that for some external functions it's not necessary to call then for each row wich will do a big difference in performance, probably adding another field to the sqlite_create_function let's call it "hints" that can tell SQLite that a function returns a constant value for the same entry or null if any of it's parameters are null, this is used in postgresql plpgsql.
Let's say that the new prototype of sqlite_create_function could be:
int sqlite_create_function(
sqlite *db,
const char *zName,
int nArg,
void (*xFunc)(sqlite_func*,int,const char**),
void *pUserData,
int hints
);
The hints field can be a bit field that can hold new future hints like this.
#define IS_CACHEABLE (1)
#define IS_NULLABLE (1 << 2)
#define IS_ANOTHER_HINT (1 << 3)
int hints = IS_CACHEABLE | IS_NULLABLE; |
|
68 |
new
|
active
|
2002 Jun
|
anonymous
|
|
2003 Jan
|
|
5
|
5
|
PRAGMA table_info(table-name) for queries
|
edit |
It would be nice to have a possibility to get columns information, something like from PRAGMA table_info(table-name), also for queries. Maybe It could be a one function which enables to get both information and data. |
Selecting something from a view which is created with the statement
"create view MyView as (select * from MyTable where ...)"
is returning invalid datatypes instead of the MyTable datatypes. |
|
55 |
new
|
active
|
2002 Jun
|
anonymous
|
|
2007 Oct
|
drh
|
5
|
3
|
instead of triggers for inserts (updates) on regular tablesxx
|
edit |
It would be very useful to be able to define a trigger
that only executes the trigger code and will prevent the
actual insert (or update) on regular tables (eg. specialised
autoincrement fields). This could be done by allowing the
same "instead of" syntax as used for views. Even better would be
the possibility of return codes in a before trigger that can
prevents the insert or raise an error. Ideally,
this return code could be given conditionally (implementing foreign
key and check like functionality). |
test
2007-Oct-01 23:37:44 by anonymous:
create trigger syntax :
A special SQL function RAISE() may be used within
a trigger-program, with the following syntax:
raise-function ::= RAISE ( ABORT, error-message ) |
RAISE ( FAIL, error-message ) |
RAISE ( ROLLBACK, error-message ) |
RAISE ( IGNORE )
|
|
48 |
doc
|
active
|
2002 May
|
anonymous
|
|
2004 Mar
|
drh
|
1
|
1
|
use sqlite from a tclsh.exe
|
edit |
Hi !
Maybe I am to stupid to understand, but I don't really
figure out how to use sqlite from a tclsh.exe333333
package require sqlite
does not work. And I did not find any simple introductory sample code.
greetings
tom |
2004-Sep-17 03:48:33 by anonymous:
This might help Tom:
http://www.sqlite.org/cvstrac/wiki?p=SqliteTclPackageWrapper |
|
43 |
event
|
active
|
2002 May
|
anonymous
|
|
2002 May
|
drh
|
1
|
1
|
sqlite compile without readline on linux slackware 8.0
|
edit |
./configure won't detect libreadline on Linux slackware 8.0 (tested on 3 computer)
Adding by hand
READLINE = -DHAVE_READLINE=1 -l/usr/include/redline
and
LIBREADLINE = -lreadline -lcurses
work well
best
claude |
I think this may be a Slackware bug to do with the way they compiled libreadline, I've had it occur with other packages too.
If you put:
export config_TARGET_READLINE_LIBS="-lreadline -lcurses"
in your .profile or similar, you workaround the problem for multiple packages. |