sqlite - Known Issues with descriptions

  $ 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...

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.

Thank you,

Tony Dellos Milwaukee WI

Tom

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).

/* 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;

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.

  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.

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?

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.

sqlite> select sum(seqval) from tbl; Bus Error(coredump)

it should be INT8_TYPE.

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.

  # 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

  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

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

  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

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.

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

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.

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.

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

.mode csv mixes up the charset IMHO

Example "f&#252;r" becomes "f\37777777703\37777777674r"

which makes the output file not usable

G&#252;ssing now is G\303\274ssing

hope it's ok to reopen the bug

.mode cvs still does not work,

.mode tab works fine now

I tried

1. field LIKE 'abc'
2. field LIKE quote('abc') and
3. field LIKE X'616263'

but nothing seems to return back the record that I am interested in.

Thanx Doriaqn Tessore

./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

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

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?

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

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.

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

This problem seams to have been fixed on the 3.2 branch but is still in the 2.8.16

  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.

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).

  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.

Is it the intended design?

Thanks, John

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

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.

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$

    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
    }

rc = sqlite3_prepare(pDb->db, zSql,0, &pStmt, 0);

should be

rc = sqlite3_prepare(pDb->db, zSql,-1, &pStmt, 0);

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.

  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.

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.

  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.

• 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?

• 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)?

  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.

  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.

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?

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

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

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

"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).

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?

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.

  #ifndef SQLITE_OMIT_TRIGGER

from around the

  sqlite3ExprCodeAndCache

function seems to fix it. Could you commit this?

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.

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

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);
  }

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.

...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.

1. 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.

2. 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.

  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!

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.

  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';

  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.

  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.

Is this a known issue in 3.3.3?

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

  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

  select name, ingredients from recipe where ingredients match '"broccoli cheese"';

Offsets() returns at least two matches for both individual words:

• broccoli
• cheese

  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.

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.

However, the problem with SQLITE_OMIT_SHARED_CACHE still persists.

/* ** 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;
}

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;

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.

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

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. :-)

  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

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.

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);
  }

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.

  #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);
  }

  void *zConverted = convertUtf8Filename(zFilename);
  if( zConverted==0 ){
    return SQLITE_NOMEM;
  }

#if OS_WINCE
  f.zDeleteOnClose = delFlag ? utf8ToUnicode(zFilename) : 0;
  f.hMutex = NULL;
#endif

the following patch correct those things:

int sqlite3WinOpenExclusive(const char *zFilename, OsFile **pId, int delFlag){
  winFile f;
  HANDLE h;
  DWORD fileflags;
  void *zConverted = convertUtf8Filename(zFilename);
  if( zConverted==0 ){
    return SQLITE_NOMEM;
  }
  assert( *pId == 0 );
  fileflags = FILE_FLAG_RANDOM_ACCESS;
#if !OS_WINCE
  if( delFlag ){
    fileflags |= FILE_ATTRIBUTE_TEMPORARY | FILE_FLAG_DELETE_ON_CLOSE;
  }
#endif
  if( isNT() ){
    int cnt = 0;
    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) );
  }else{
#if OS_WINCE
    return SQLITE_NOMEM;
#else
    int cnt = 0;
    do{
      h = CreateFileA((char*)zConverted,
        GENERIC_READ | GENERIC_WRITE,
        0,
        NULL,
        CREATE_ALWAYS,
        fileflags,
        NULL
      );
    }while( h==INVALID_HANDLE_VALUE && cnt++ < 2 && (Sleep(100), 1) );
#endif /* OS_WINCE */
  }
  if( h==INVALID_HANDLE_VALUE ){
    sqliteFree(zConverted);
    return SQLITE_CANTOPEN;
  }
  f.h = h;
#if OS_WINCE
  f.zDeleteOnClose = delFlag ? (WCHAR*) zConverted : 0;
  f.hMutex = NULL;
  if (!delFlag)
#endif
    sqliteFree(zConverted);
  TRACE3("OPEN EX %d \"%s\"\n", h, zFilename);
  return allocateWinFile(&f, pId);
}

  -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?

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

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.

• 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?

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}]

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.

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.

  #if 0
  extern "C" {
  #endif

  #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.

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.

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?

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.

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

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.

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;

  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

  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.

  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

  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.

I recommend to remove MODE_Column functionality from shell.c completely, as it never worked correctly.

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.

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...

Where can I get the latest CVS precompiled binary for windows platform ?

tamagawa

The problem can be easily reproduced by running the script below using the "testfixture" program that we use for testing SQLite.

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

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

   ===========
   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

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.

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.

To fix this had to change code page from CP_UTF8 to CP_ACP -- no idea why this works.

Original utf8ToUnicode()

  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;
}

  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;
}

Before:

  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;
}

  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;
}

Or using UTF-16 variants in windows ce should be the best case.

  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.

  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;
  }

I hope, it will result/return DATE, TIME. Please support to SQLITE_DATE and SQLITE_TIME. Thanks.

  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.

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';

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);

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

The best workaround is to put docid as INTEGER, then adding a PRIMARY KEY index for the docid column.

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

  CREATE VIRTUAL TABLE a USING fts2 (a);

Returns "vtable constructor failed: a.".

'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

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.

   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.

  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()

  ATTACH 'db' AS aux1;
  ATTACH 'db' AS aux2;
  CREATE TABLE aux1.abc(a, b, c);
  CREATE TABLE aux2.abc(a, b, c);

If application 1 runs as normal application, started by local user, this problem doesnt occur and both applications can open the db.

Anachronism? Service is just another word for daemon.

-knu-

1. 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.

2. 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.

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.

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.

flags = SQLITE_OPEN_READWRITE;

and when

  res = sqlite3_open_v2(sourcename, &conn, flags, NULL);

seems to leak 674 bytes per call

All calls to sqlite3_open_v2() need to be matched by a call to sqlite3_close(), even if an error occurs.

   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....

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!

Large blobs work for me with both release and debug builds (not msvc though, gcc/linux).

  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;
}

But even without those fixes, I cannot reproduce the problem on Linux.

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

Thank you for your time.

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".

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 ....

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.

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|

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.

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.

  ./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.

You have to run ext/fts3/mkfts3amal.tcl

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.

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."

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?

  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.

I therefore consider this issue fixed and I will now close this ticket.

If you do want details, please let me know (I'll recheck this ticket tomorrow I guess).

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.

  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;
    }
  }

maybe adding a small comment in there would clarify this issue

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.

   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.

thanks in advance.

You may find this link helpful: http://developer.apple.com/technotes/tn/tn2037.html

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.

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?

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.

...
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

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}

I'll rerun the exact scenario and try again.

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]

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.

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

        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.

- 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.

  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.

CREATE VIEW test1 AS SELECT * FROM tableA;
CREATE VIEW test AS SELECT COUNT(*) FROM test1;

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.

  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

  VIEWs are read-only so you can not INSERT into them.
  See: http://www.sqlite.org/omitted.html

  Regards,
  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

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.

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

Thanks,

Theory

Thanks,

Theory

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.

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?

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.

  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.

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).

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

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.

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.

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

  # 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.

But when I update some data with this column on uClinux,I can read the data right!

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.

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.

  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.

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?

  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?

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

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.

sqlite3 my_db
>.output my_file
>.dump table_with_blob
>.exit
del my_db

sqlite3 my_db
>.read my_file

Fails with "Incomplete SQL: ..." SQL break before 0x1a char

I'm on windows. Possibly solving with opening file as binary file.

Sorry for my English

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.

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.

    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")

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.

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.

  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.

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.

   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.

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;

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

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);
  }

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"
  }

  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

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.

Technically, POSIX requires that you only read errno if -1 is returned by the system call. QNX is picky about this sort of thing.

>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.

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.

got = write(id->h, pBuf, cnt);

#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

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 :-)

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.

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.

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).

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

    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.

41|X'D791D7A8D799D799D7A7D793D790D7A0D7A1'
42|X'D7A1D798D7A4D7A1'

  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?

  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>

  CREATE TABLE t1(a blob);
  INSERT INTO t1 VALUES(X'00000008090A0D0D0A00');
  .mode insert whatever
  select * from t1;

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

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>

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;
}

Fedor

	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

  .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.

  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

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.

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.

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.

--- 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 ){

    /* 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.

(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.

  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.

  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

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)

./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

1. If you run make install as root.
2. If you use ./configure --disable-tcl

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.

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)

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

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.

I have to experience programming in Windows, but have no doubt a similar function call exists in that API.

  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

    ../sqlite/configure --disable-shared

• 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.

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...

The attachment is an archive with a Makefile, a shell script and a program that reproduce the error.

  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;

  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

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

  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

  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...).

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

PKG_CHECK_MODULES(SQLITE, sqlite >= 3.0.3, AC_MSG_ERROR([$SQLITE_PKG_ERRORS]))

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.

  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

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 */

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)

  (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>

  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;

  select test2.b 
  from (select test1.a as a from test1 where a%2=0) as bb
       join test2 on bb.a=test2.a;

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

the word privé in the connectionstring becomes privé.db3 on the disk, which causes errors afterwards when opening the database

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

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.

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.

  shell.c(1705) : warning C4013: 'access' undefined; assuming extern returning int

Add this:

  #if defined(_WIN32) && defined(_MSC_VER)
  # include <io.h>
  #endif

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 */

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]

  $ 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

  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

  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?

  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

  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.

anyone?

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

For example, the German Umlaute or the &#232; 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&#180;ve set the priority wrong... It&#180;s obviously highest priority to me ;)

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

#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;

  --- 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;

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.

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.

  SELECT name_alt AS name, * FROM sort_table ORDER BY name;

Who knows - it is ambiguous.

   select a, b, c from foo order by d;

  SELECT name_alt AS name FROM sort_table ORDER BY name

  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.

Regards Stanislav Nikolov

(from http://www.unicode.org/reports/tr21/tr21-5.html#Introduction) Case is a normative property of characters in specific alphabets (Latin, Greek, Cyrillic, Armenian, and archaic Georgian) whereby characters are considered to be variants of a single letter. These variants, which may differ markedly in shape and size, are called the uppercase letter (also known as capital or majuscule) and the lower&#173;case letter (also known as small or minuscule). The uppercase letter is generally larger than the lowercase letter. Alphabets with case differences are called bicameral; those without are called unicameral.

Therefore, I don't think someone will need support for case-insensitive comparison for Japanese, Chinese or Korean characters and I guess that adding support for the remaining Armenian alphabet is a matter of minutes and will not add up to the complexity of the code. Of course, perhaps it is possible for every project and/or developer to design their own "collation schemes" but I don't find it very practical. I can't really see the reason behind rejecting the patch. Perhaps you could actually look at it ?

Regards, Stanislav Nikolov

I observer that as written it increases the size of the SQLite library by a little over 4KiB. That might not seem like much, but embedded device manufacturers (that is to say, most of my paying customers) are very sensitive to this kind of library size growth. I will look into reducing the size somewhat and getting it into a future release as a compile-time option.

Perhaps somebody with more experience in unicode case folding can comment.

Keep up the good work.

Anze

Thanks a lot.

   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...

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.

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...

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

  Select "Wow !!" from "Wow !!"
  :-)
  Maybe VIEWs could help ??

    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);

(and no I dont want the C API. I found that)

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

  ----- 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

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; */

  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]

  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]

  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;
  }

  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;

  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

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.

  /*
  ** 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]

  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.

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.

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.

  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.

"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.

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

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?

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.

    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?

    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>

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.

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;

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.

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.

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.

  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,

    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.

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.

http://www.mail-archive.com/sqlite-users%40sqlite.org/msg22143.html

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.

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.