bgcolor # Status Created By Subsys Due Date SCR Assigned Svr Pri Title _Description _Remarks #cfe8bd 2128 active 2006 Dec anonymous Pending 4 3 virtual table code doesn't verify type of rowid (calling xUpdate) The virtual tables code doesn't verify the type of rowid when calling update. For example I used the following query: UPDATE foo SET rowid='a string' WHERE 1 This results in a call to xUpdate with argv[0] equal the current rowid but argv[1] is 'a string'. While I'd be quite happy for rowids to be any SQLite type, the xRowid call only allows 64 bit integers. I believe SQLite should check the new rowid in a case like this is an integer and reject it, rather than calling xUpdate with the bad value. (I also just checked with rowid=3.4 and rowid=NULL and they get passed through as is as well) A workaround is to document that the xUpdate method must check the new rowid is an integer type. #f2dcdc 2508 active 2007 Jul anonymous Pending 1 1 utf8ToUnicode() does not work on some WinCE devices On some WinCE devices first call to =MultiByteToWideChar()= in =utf8ToUnicode()= always fails. Tried calling =GetLastError()= after it fails and it returns error code 87 -- =ERROR_INVALID_PARAMETER=. To fix this had to change code page from =CP_UTF8= to =CP_ACP= -- no idea why this works. Original =utf8ToUnicode()= ---- static WCHAR *utf8ToUnicode(const char *zFilename) { int nChar; WCHAR *zWideFilename; nChar = MultiByteToWideChar(CP_UTF8, 0, zFilename, -1, NULL, 0); zWideFilename = sqliteMalloc( nChar*sizeof(zWideFilename[0]) ); if( zWideFilename==0 ){ return 0; } nChar = MultiByteToWideChar(CP_UTF8, 0, zFilename, -1, zWideFilename, nChar); if( nChar==0 ){ sqliteFree(zWideFilename); zWideFilename = 0; } return zWideFilename; } ---- Fixed =utf8ToUnicode()= ---- static WCHAR *utf8ToUnicode(const char *zFilename) { int nChar; WCHAR *zWideFilename; nChar = MultiByteToWideChar(CP_ACP, 0, zFilename, -1, NULL, 0); if( nChar == 0 ) { DWORD dwError = GetLastError(); OSTRACE2("MultiByteToWideChar() failed, last error: %d\n", dwError); return 0; } zWideFilename = sqliteMalloc( nChar*sizeof(zWideFilename[0]) ); if( zWideFilename==0 ){ return 0; } nChar = MultiByteToWideChar(CP_ACP, 0, zFilename, -1, zWideFilename, nChar); if( nChar==0 ){ sqliteFree(zWideFilename); zWideFilename = 0; } return zWideFilename; } ---- _2007-Jul-17 23:56:10 by anonymous:_ {linebreak} =unicodeToUtf8()= needs to be fixed the same way. Before: ---- static char *unicodeToUtf8(const WCHAR *zWideFilename){ int nByte; char *zFilename; nByte = WideCharToMultiByte(CP_UTF8, 0, zWideFilename, -1, 0, 0, 0, 0); zFilename = sqliteMalloc( nByte ); if( zFilename==0 ){ return 0; } nByte = WideCharToMultiByte(CP_UTF8, 0, zWideFilename, -1, zFilename, nByte, 0, 0); if( nByte == 0 ){ sqliteFree(zFilename); zFilename = 0; } return zFilename; } ---- After: ---- static char *unicodeToUtf8(const WCHAR *zWideFilename){ int nByte; char *zFilename; nByte = WideCharToMultiByte(CP_ACP, 0, zWideFilename, -1, NULL, 0, NULL, NULL); if ( nByte == 0 ) { DWORD dwError = GetLastError(); OSTRACE2("WideCharToMultiByte() failed, last error = %d\n", dwError); return 0; } zFilename = sqliteMalloc( nByte ); if( zFilename==0 ){ return 0; } nByte = WideCharToMultiByte(CP_ACP, 0, zWideFilename, -1, zFilename, nByte, 0, 0); if( nByte == 0 ){ sqliteFree(zFilename); zFilename = 0; } return zFilename; } ---- Note that while original code with =CP_UTF8= works on Windows and SOME WinCE devices, this modified code works well and Windows and all WinCE devices I've tested so far. ---- _2007-Jul-18 16:01:21 by anonymous:_ {linebreak} Why not using the conversions from SQLite internals ? It can change a UTF-16 to UTF-8 and vice-versa. Or using UTF-16 variants in windows ce should be the best case. ---- _2007-Aug-09 20:47:04 by anonymous:_ Why not using the conversions from SQLite internals ? It can change a UTF-16 to UTF-8 and vice-versa. Or using UTF-16 variants in windows ce should be the best case. Not so simple. =unicodeToUtf8()= is used a lot internally regardless of what whether you use UTF-16 or UTF-8 yourself. For example, =unicodeToUtf8()= is used by =sqlite3WinTempFileName()= which is in turn used by =sqlite3PagerOpentemp()= -- I think you get the idea. ---- _2007-Dec-20 00:29:33 by anonymous:_ {linebreak} We've found that using CP_UTF8 fails on WinCE kernels that don't include SYSGEN_CORELOC (http://msdn2.microsoft.com/en-us/library/ms903883.aspx). To make the code handle any device it should be changed to: static WCHAR *utf8ToUnicode(const char *zFilename) { int nChar; WCHAR *zWideFilename; nChar = MultiByteToWideChar(CP_UTF8, 0, zFilename, -1, NULL, 0); if( nChar == 0 ) { nChar = MultiByteToWideChar(CP_ACP, 0, zFilename, -1, NULL, 0); if( nChar == 0 ) { DWORD dwError = GetLastError(); OSTRACE2("MultiByteToWideChar() failed, last error: %d\n", dwError); return 0; } } zWideFilename = sqliteMalloc( nChar*sizeof(zWideFilename[0]) ); if( zWideFilename==0 ) { return 0; } nChar = MultiByteToWideChar(CP_UTF8, 0, zFilename, -1, zWideFilename, nChar); if( nChar==0 ) { nChar = MultiByteToWideChar(CP_ACP, 0, zFilename, -1, zWideFilename, nChar); if( nChar==0 ) { sqliteFree(zWideFilename); zWideFilename = 0; } } return zWideFilename; } #cfe8bd 2297 active 2007 Apr anonymous Pending drh 3 3 uninitialized var (with patch) Warnings with amalgamation and NDEBUG. _2007-Apr-12 21:21:29 by drh:_ {linebreak} I looked at the suggested changes and I didn't find any cases where it really was possible to use an uninitialized variable, at least not in a harmful way. Did I overlook something, or is this ticket just a request to silence compiler warnings? ---- _2007-Apr-13 00:08:36 by anonymous:_ {linebreak} vdbe.c with n, n64, payloadSize and payloadSize64{linebreak} sqlite3BtreeKeySize,sqlite3BtreeLast return are not checked. You can not be sure the pointer passed as second argument will be init depending on the return of restoreOrClearCursorPosition (btree.c).{linebreak} page.c with ro{linebreak} Compiled with -DNDEBUG, the return of sqlite3OsOpenReadWrite is not checked before making a move with 'ro'. For sContext.zAuthContext in delete.c/update.c, you're the one. gcc (compiler in general) warnings are quite usefull, i don't think it's a good idea to ignore them and accumulate danger. Perhaps one day, one line in a subroutine will modify some tricky behavior and (re)raise a previous checked warning, making it completely normal and 'under control'. #cfe8bd 2012 active 2006 Oct anonymous New 4 3 trigger4.test aborts "make test" on Windows The failure to remove these files causes "make test" to abort without completing remaining tests: trigger4-99.9... Ok ./testfixture: error deleting "trigtest.db": permission denied while executing "file delete -force trigtest.db trigtest.db-journal" (file "test/trigger4.test" line 199) fix: Index: test/trigger4.test =================================================================== RCS file: /sqlite/sqlite/test/trigger4.test,v retrieving revision 1.9 diff -u -3 -p -r1.9 trigger4.test --- test/trigger4.test 4 Oct 2006 11:55:50 -0000 1.9 +++ test/trigger4.test 9 Oct 2006 14:09:07 -0000 @@ -195,6 +195,6 @@ do_test trigger4-7.2 { integrity_check trigger4-99.9 -file delete -force trigtest.db trigtest.db-journal +catch {file delete -force trigtest.db trigtest.db-journal} finish_test Not sure why this ticket was set to Fixed_in_3.0, but I can reproduce the "make test" abort on Windows. ---- _2006-Oct-11 00:27:16 by drh:_ {linebreak} I do not know why the resolution was set to "Fixed_In_3.0" either. It seems to have been set that why by the original submitter. I will fix this eventually, but since it does not represent a real malfunction, it has a lower priority. #cfe8bd 2755 active 2007 Nov anonymous Pending 3 3 trace interfere with transaction Tcl interface When using the transaction method of the Tcl interface to the SQLite with a registered "trace" function, the stack trace is lost in case an error occurs inside the transaction. As an example I provide two outputs, the first one without a registered trace function and the second one with one (in which it *cannot* be seen where the exception cames from): ========= First: > ./a.tcl vorher BUMMM while executing "a" invoked from within "db transaction { puts "vorher" a puts "nachher" }" ("uplevel" body line 1) invoked from within "uplevel 1 [list db transaction { puts "vorher" a puts "nachher" }]" (procedure "b" line 2) invoked from within "b" (file "./a.tcl" line 28) ========= Second: > ./a.tcl BEGIN vorher ROLLBACK while executing "db transaction { puts "vorher" a puts "nachher" }" ("uplevel" body line 1) invoked from within "uplevel 1 [list db transaction { puts "vorher" a puts "nachher" }]" (procedure "b" line 2) invoked from within "b" (file "./a.tcl" line 28) ******** A scritp that demostrates this behaviour is attached. The only workaround is not to trace. Thanks #cfe8bd 2352 active 2007 May anonymous Pending 5 3 timeout just 500 msec to soon After upgrading from 3.3.12 to 3.3.17, the setting of a timeout behaves differently. It occurs exactly 500 msecs sooner. Of course assuming the database is locked and the timeout is set to a value larger than 500 msecs. #cfe8bd 2886 active 2008 Jan anonymous Pending 3 3 testfixture: -fPIC needed when building extension(s) (this fix/change is probably needed in older versions too, i meant to send this in earlier) -fPIC is needed when building extensions (some platforms don't need this or don't care --- x86-64 does) diff --git a/test/loadext.test b/test/loadext.test index 81e152f..2a7fa2e 100644 --- a/test/loadext.test +++ b/test/loadext.test @@ -64,7 +64,7 @@ if {![file exists $testextension]} { set srcdir [file dir $testdir]/src set testextsrc $srcdir/test_loadext.c if {[catch { - exec gcc -Wall -I$srcdir -I. -g -shared $testextsrc -o $testextension + exec gcc -Wall -fPIC -I$srcdir -I. -g -shared $testextsrc -o $testextension } msg]} { puts "Skipping loadext tests: Test extension not built..." puts $msg #cfe8bd 1056 active 2004 Dec anonymous Shell Pending 3 3 test pragma-9.4 fails during second pass in "make fulltest" During a "make fulltest" run, the pragma tests appear to run twice. On the first run, pragma-9.4 runs properly. On the second run, it gives an error: pragma-9.4... Expected: [] Got: [/Volumes/Local/Users/sqlite/test/bld] (where the path listed is the build directory for this build of sqlite). The pragma-9.4 test is a recent addition to sqlite. This is currently the only failure I'm seeing in a "make fulltest" of the current cvs tree on Mac OS X when the build/test directory is on a hard drive. 1 errors out of 68411 tests Failures on these tests: pragma-9.4 make: *** [fulltest] Error 1 #cfe8bd 2863 active 2007 Dec anonymous Pending 2 3 test cast-3.14, cast-3.18 and cast-3.24 fail 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 #cfe8bd 1799 active 2006 May anonymous Pager Pending 2 3 temp_store=MEMORY slower than FILE for large intermediate result sets (This ticket was split off from #1790 because that ticket was becoming too broad.) When temp_store=MEMORY it can negatively effect the performance of queries with large intermediate result sets generated from SELECTs of either file-based tables or memory-based tables. This is true when sufficient RAM is available to the SQLite process to completely hold the intermediate results in memory without swapping to disk. In the example below, "big" is a file-based table in foo.db with 10 million rows. It was created with "create table big(x,y)". # unmodified stock SQLite built from May 5 2006 CVS (after check-in [3178]) # compiled with default settings for SQLITE_DEFAULT_PAGE_SIZE and N_PG_HASH $ time ./may5-sqlite/sqlite3 foo.db "PRAGMA temp_store = MEMORY; select x, y from big order by y, x" >/dev/null real 13m23.828s user 13m18.452s sys 0m0.811s # SQLite built from May 5 2006 CVS, but compiled with proposed change of # SQLITE_DEFAULT_PAGE_SIZE set to 4096, and N_PG_HASH set to 16384 $ time ./may5-sqlite-hash-opt/sqlite3 foo.db "PRAGMA temp_store = MEMORY; select x, y from big order by y, x" >/dev/null real 6m16.031s user 6m13.108s sys 0m0.811s Compiling with SQLITE_DEFAULT_PAGE_SIZE = 1024, and N_PG_HASH = 32768 resulted in the same timing as the may5-sqlite-hash-opt test run above. If temp_store=FILE (with default SQLite values for SQLITE_DEFAULT_PAGE_SIZE and N_PG_HASH), the timings are comparable to temp_store=MEMORY with SQLITE_DEFAULT_PAGE_SIZE=4096, and N_PG_HASH=16384. Large intermediate results sets can cause SQLite to spend more than half of its CPU time in the function pager_lookup(). By increasing the value of N_PG_HASH and SQLITE_DEFAULT_PAGE_SIZE, the time spent in pager_lookup can be reduced to near zero, thus doubling performance in such cases. % cumulative self self total time seconds seconds calls ms/call ms/call name 51.97 118.31 118.31 119658386 0.00 0.00 pager_lookup 4.36 128.25 9.94 4000009 0.00 0.06 sqlite3VdbeExec 3.06 135.21 6.96 315629923 0.00 0.00 parseCellPtr 3.05 142.16 6.95 171797186 0.00 0.00 sqlite3VdbeRecordCompare 2.67 148.22 6.07 12000005 0.00 0.01 sqlite3BtreeMoveto 2.14 153.10 4.88 343594380 0.00 0.00 sqlite3VdbeSerialGet 1.68 156.93 3.83 171797188 0.00 0.00 sqlite3MemCompare 1.63 160.65 3.72 77995781 0.00 0.00 sqlite3pager_get 1.60 164.29 3.65 169734946 0.00 0.00 sqlite3pager_unref 1.58 167.88 3.59 654100795 0.00 0.00 get2byte _2006-May-07 18:37:50 by anonymous:_ {linebreak} Timings on same Windows machine with check-in [3180] applied: # FILE $ time ./may7-sqlite/sqlite3 foo.db "PRAGMA temp_store = FILE; select x, y from big order by y, x" >/dev/null real 5m7.157s user 4m19.905s sys 0m20.827s # MEMORY $ time ./may7-sqlite/sqlite3 foo.db "PRAGMA temp_store = MEMORY; select x, y from big order by y, x" >/dev/null real 5m12.328s user 5m9.781s sys 0m0.984s Much better. temp_store=MEMORY is now competitive with FILE, although temp_store=FILE (when the OS is able to cache the file entirely in memory) is marginally faster. I still think the MEMORY time can be reduced further by another 20 seconds judging by the sys time of 20.827s in the FILE test. The MEMORY subsystem of SQLite ought to have an advantage over the FILE subsystem because it does not incur any system call overhead. I'll see if a profile turns up anything obvious. #cfe8bd 1428 active 2005 Sep anonymous TclLib Pending 3 3 tclinstaller.tcl script problems The pkgIndex.tcl file generated by the tclinstaller.tcl script contains absolute pathnames to the TCL extension library. This causes problems if the extension subdirectory is moved. A more portable solution is shown below. A second problem is that the shared library does not have executable permission. This is a problem on HPUX operating systems. Adding the 0755 permission mode to the open command solves the problem for HPPA and does not cause problems for the other platforms. Here's a diff of the changes I made to address these two problems: cvs diff tclinstaller.tcl Index: tclinstaller.tcl =================================================================== RCS file: /sqlite/sqlite/tclinstaller.tcl,v retrieving revision 1.2 diff -r1.2 tclinstaller.tcl 17c17 < puts $fd "package ifneeded sqlite3 $VERSION \[list load $LIB sqlite3\]" --- > puts $fd "package ifneeded sqlite3 $VERSION \[list load \[file join \$dir $LIBNAME\]\]" 25c25,26 < set out [open $LIB w] --- > #Some platforms such as the HP requre that libraries have the executable bit set > set out [open $LIB w 0755] #e8e8bd 2903 active 2008 Jan anonymous Pending 2 2 tclinstaller.tcl fails on path and permissions issue When compiling using custom PREFIX, pointing to private directory, tclinstaller.tcl fails, because it tries to remove contents from /usr/share/tcl8.4/sqlite3.
./configure --prefix=/my/private/sqlite/sqlite-3.5.4 ... # success make ... # success make install ... tclsh ./tclinstaller.tcl 3.5 error deleting "/usr/share/tcl8.4/sqlite3": not owner while executing "file delete -force $LIBDIR/sqlite3" (file "./tclinstaller.tcl" line 17) make: *** [tcl_install] Error 1I've found two work-arounds: 1: If you run make install as root. 2: If you use ./configure --disable-tcl _2008-Jan-28 17:47:39 by anonymous:_ {linebreak} I also ran into this problem. make install as root will end up copying files into the system's library directory and is almost certainly not what you want if you specified your own --prefix. #cfe8bd 2203 active 2007 Jan anonymous Pending 2 3 table_info pragma "default" column format changed? Beginning with SQLite3 3.3.8, it looks like the format of the 'default' value returned by the table_info pragma has changed. Before, it used to be a bare string: dev:~> sqlite3 SQLite version 3.3.7 Enter ".help" for instructions sqlite> create table testings (a integer primary key, b string default 'Tester', c string default NULL); sqlite> pragma table_info(testings); 0|a|integer|0||1 1|b|string|0|Tester|0 2|c|string|0||0 After 3.3.8, the 'defaults' column is now a SQL-quoted string: dev:~> sqlite3 SQLite version 3.3.11 Enter ".help" for instructions sqlite> create table testings (a integer primary key, b string default 'Tester', c string default NULL); sqlite> pragma table_info(testings); 0|a|integer|0||1 1|b|string|0|'Tester'|0 2|c|string|0|NULL|0 Now, I think I do prefer the latter, where the default is a SQL-quoted string. However, this seems a rather significant change to make mid-stream, in a minor point release. It broke all Ruby on Rails applications that use sqlite3, for instance, because Rails reads that default value to determine how to default the value of each new record. Was this intentional? Or is this a bug? I'd love to see this behavior reverted and saved for a release with a more significant release number. _2007-Jan-29 22:01:54 by anonymous:_ {linebreak} One of your fellow Railers requested this change: Ticket #2078 ---- _2007-Jan-29 22:10:55 by drh:_ {linebreak} See also ticket #1919 which might also be an issue here. ---- _2007-Jan-29 22:33:19 by anonymous:_ {linebreak} Anonymous, you make it sound as if anyone associated with Rails can make a request of the sqlite3 team and have it be automatically assumed to be sanctioned by the Rails core team. Whoever did the original request did not do so under the umbrella of Rails core. If that change was the one that resulted in this behavior, it most definitely should not have been recommended, and would not have been blessed by any of the core team. At this point, though, I'm not interested in blame. I just want to see what can be done to make sqlite3 work with Rails again, preferably in a way that is backwards compatible with previous sqlite3 releases. ---- _2007-Jan-30 05:20:56 by anonymous:_ {linebreak} I agree the feature should be fixed due to backwards compatability, but Rails should try to accomodate both pragma variants since they are both "in the wild". You could base your decision on the sqlite version string, for instance. ---- _2007-Jan-30 18:39:44 by anonymous:_ {linebreak} Just FYI, there's another related ticket at the Rails trac at http://dev.rubyonrails.org/ticket/6523, and a Debian bug report with a patch at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397531. #f2dcdc 2048 active 2006 Oct anonymous Pending drh 1 1 table_info on columns with no default value are returned as string On line 486, noDflt is declared as{linebreak} static const Token noDflt = { (unsigned char*)"", 0, 0 };{linebreak} {linebreak} And on line 493:{linebreak} if( pDflt->z ){{linebreak} sqlite3VdbeOp3(v, OP_String8, 0, 0, (char*)pDflt->z, pDflt->n);{linebreak} }else{{linebreak} sqlite3VdbeAddOp(v, OP_Null, 0, 0);{linebreak} {linebreak} So columns with no default value aren't being set to null because the (pDflt->z) condition is non-null. #cfe8bd 2398 active 2007 Jun anonymous Pending 2 3 systemcalls should be restarted when they return EINTR Introduction: I'm a developer for Alcatel-Lucent, where I program softswitches. I'm a bit of a code-correctness nazi, because I've programmed several systems that have to be very reliable (5 figures), or I've corrected them if they didn't. I was browsing thru the source code of SQLite, to become familiar with it, and to see how reliable it was. Not that we currently use it in a product, but you may never known. The very first thing I noticed was that none of the systemcalls in os_unix.c was checked for EINTR. From experience, I know that a systemcall can be interrupted while inside the kernel, and return EINTR in errno. The correct reaction is to repeat the system call, just as if nothing happened. This is *not* an error, just a temporary situation which will be fixed the next time you call it again. One reason is that you call was interrupted by a higher priority interrupt (incoming IO for instance), or to avoid a deadlock in the kernel (returning your syscall will release any locks you might have). It's pretty rare in most usage, but I've seen it lots of times when testing a server under load. Example of the solution for seekAndWrite (this only shows write, but pwrite is similar) : got = write(id->h, pBuf, cnt); should be : do { got = write(id->h, pBuf, cnt); } while ( (got < 0) && (errno == EINTR) ); This has to be done for *every* systemcall that mentions it on its manpage (but please note, not every OS is the same). This includes many calls where everyone assumes that the call is safe to use, for instance close(). Almost nobody seems to realize that a close can fail, and often there's not even a check for the return code. But I can assure you, it can fail. _2007-Jun-05 13:39:08 by anonymous:_ {linebreak} I prefer the current SQLite behavior NOT to retry in the event of EINTR. I've seen too many UNIX OSes with bugs related to EINTR for system calls within threads over the years, including the most popular ones. Most of these OS bugs have since been fixed, but it's still not worth the trouble in case you come across an unpatched platform. Getting an infinite loop of EINTR errnos in a tight loop due to an OS bug is no fun in a production application. Technically, POSIX requires that you only read errno if -1 is returned by the system call. QNX is picky about this sort of thing. ---- _2007-Jun-05 17:02:55 by anonymous:_ {linebreak} Read my introduction again : I help make systems reliable in my daytime job. Ignoring a read- or write-error is not how you achieve 99.999% availability, especially not when it's easily correctable (a disk-full message or a I/O error due to a corrupt harddisk is another matter ofcourse). >Technically, POSIX requires that you only read errno if -1 is returned by the system call. QNX is picky about this sort of thing. well yes, that's what I mean. ---- _2007-Jun-05 17:20:07 by anonymous:_ {linebreak} All of SQLite's operations can also be retried if they fail. SQLite has an extensive test suite for disk failures, malloc failures and many other types of failures that you've likely never considered. I tend to trust the judgement of the authors of SQLite more than an anonymous guy puffing his chest out in this ticket tracking system. ---- _2007-Jun-05 22:24:09 by anonymous:_ {linebreak} hi. instead of blaming in this ticket, the ticket author could place a patch like:
got = write(id->h, pBuf, cnt);to do things like:
#ifdef SQLITE3_RETRY_EINTR_SYSCALLS do { #endif // SQLITE3_RETRY_EINTR_SYSCALLS got = write(id->h, pBuf, cnt); #ifdef SQLITE3_RETRY_EINTR_SYSCALLS } while ( (got < 0) && (errno == EINTR) ); #endif // SQLITE3_RETRY_EINTR_SYSCALLSby leaving SQLITE3_RETRY_EINTR_SYSCALLS undefined, this should not affect the current code behaviour and should address the issues ticket author says and he can compile with those 'paranoic' checks. []'s ---- _2007-Jun-05 22:25:06 by anonymous:_ {linebreak} I did pass my name (visible for the developers), but I'm not logged in. That why it's shown as anonymous (just as you are). Note that my co-workers have already decided it would be seen up as a negative point for this DBMS. At least for us, because it's a requirement for us to survive these errors. So if we ever are going to use SQLite, we're definitely going to use those changes. Hey, I'm a code-review nazi, don't blame me. It's just my job :-) ---- _2007-Jun-06 00:58:16 by anonymous:_ {linebreak} I think that the retrying would destroy the function expected of =sqlite3_interrupt=. Is there a problem in the following methods? *: Re-execute the SQLite API. *: Mask the signals while calling the API of SQLite. *: Mask the signals in the threads that call the API of SQLite. ---- _2007-Jun-06 01:04:47 by anonymous:_ {linebreak} As long as #ifdef SQLITE3_RETRY_EINTR_SYSCALLS is not enabled by default, knock yourselves out. ---- _2007-Jun-06 06:38:51 by anonymous:_ {linebreak} sqlite3_interrupt() knows nothing about UNIX signals. It just sets a flag that sqlite's VDBE checks from time to time to see if it should gracefully abort an SQL operation. shell.c happens to install an SIGINT signal handler that happens to call sqlite3_interrupt(), but that's unrelated. sqlite3_interrupt() could be called via any other means. ---- _2007-Jun-06 10:47:27 by anonymous:_ {linebreak} See also the SA_RESTART flag for sigaction(), which automatically will restart the systemcall instead of returning EINTR. Unfortunately not available everywhere, and not very consistent either : see Linus reply at http://lkml.org/lkml/2005/7/23/119 . Applications should still be able to handle EINTR returns gracefully. They're not errors per se (that would be EIO or similar), you can safely restart the system call. I haven't seen endless loops yet, but it's true that on some OS you might want this solution. But you still have to deal with the error (which might cause a rollback in SQLite). ---- _2007-Jun-06 14:51:14 by anonymous:_ {linebreak} I would be in favor of optionally compiling SQLite with a #define SQLITE_USE_SA_RESTART _or_ #define SQLITE_RETRY_ON_EINTR, where they are mutually exclusive and disabled by default. SQLITE_RETRY_ON_EINTR should have a maximum retry limit on buggy OSes, though. #f2dcdc 1775 active 2006 Apr anonymous Unknown Pending 1 1 strftime() not working in Windows Mobile 2005 The strftime() is not working in windows mobile 2005 pocket pc. I am using the beta version of visual studio 2005. _2006-Apr-17 13:10:20 by anonymous:_ {linebreak} Is it a compile/link problem or a runtime problem? ---- _2006-Apr-18 07:26:08 by anonymous:_ {linebreak} It's a runtime problem. I am not able to get the dates formated using strftime(). datetime(), date() and time() are working properly. #f2dcdc 2916 active 2008 Feb anonymous Pending 1 1 sqlitedll-3_5_5.zip is older 3.5.4 binary sqlitedll-3_5_5.zip in download section is same with old 3.5.4 binary. _2008-Feb-01 12:13:04 by anonymous:_ {linebreak} Yes , I can confirm it #cfe8bd 627 active 2004 Feb anonymous 3 3 sqliteRunVacuum returning wrong code? The last 3 lines of sqliteRunVacuum, as of the version checked in on Feb 12 2004, are: if( rc==SQLITE_ABORT ) rc = SQLITE_ERROR; if( sVac.rc!=SQLITE_OK ) rc = sVac.rc; return sVac.rc; It seems suspicious to set a local variable, rc, that one is never going to use again. I suspect that the last line should be return rc; _2004-Feb-27 00:54:03 by anonymous:_ {linebreak} The fix by check-in 1271 still doesn't look right to me. If one of the execsql calls returns SQLITE_CANTOPEN (which I have seen happen), then rc will be SQLITE_CANTOPEN and sVac.rc will be 0, and sqliteRunVacuum will return 0. #cfe8bd 2093 active 2006 Dec anonymous Pending 2 3 sqlite3_vtab_cursor doesn't have errMsg The sqlite3_vtab_cursor structure doesn't have a zErrMsg pointer. Only the containing vtable does. This means that operations on cursor objects that have an error have to set the error on the vtable not the cursor. Unfortunately this means that there are race conditions since two different cursors on the same vtable could have errors at the same time. If the cursors are in different threads then a crash or worse can happen. #cfe8bd 1633 active 2006 Jan anonymous VDBE Pending 3 3 sqlite3_step returns SQLITE_ERROR when interrupted When interrupting an execution of sqlite3_step, sqlite3_step will return a generic SQLITE_ERROR instead of the SQLITE_INTERRUPT error code I'd expect. This is because although in vdbe.c:4427 the SQLITE_INTERRUPT result code is set to the internal 'rc' field of the database connection, a plain SQLITE_ERROR is returned: vdbe_halt: if( rc ){ p->rc = rc; rc = SQLITE_ERROR; }else{ rc = SQLITE_DONE; } The SQLITE_ERROR returned is then also stored as the errCode inside the db handle by the calling function, so there's no way to find out whether the error occured due to an interrupt or some other error (since sqlite3_error() will return SQLITE_ERROR as well). I'd like to ignore interrupt errors where I call sqlite3_step, since those are not of importance to my users, but with the current scheme, I have no way of finding out whether an sqlite3_interrupt causes the error or whether it's a serious error... You get a more specific error-code (for example SQLITE_INTERRUPT) when you call sqlite3_finalize() or sqlite3_reset() on the statement. There shouldn't be any reason not to call one of these functions after sqlite3_step() returns SQLITE_ERROR, as you cannot do anything else with the statement handle at that point anyway. ---- _2006-Apr-26 11:58:01 by anonymous:_ {linebreak} Well, I get SQLITE_ERROR in sqlite3_finalize(), too after I interrupted the query, so I can't even find out at finalize time. However, it might be interesting to see the real error when stepping: in our C++ wrapper, the finalize occurs very late and we usually raise database exceptions when errors occur while stepping. I would really like to raise the proper exception (some sqlite_execution_interrupted exception) when the query was interrupted instead of raising some generic "sql error" exception... ---- _2006-Apr-26 12:24:02 by anonymous:_ {linebreak} Sorry, my previous comment was a bit too quick: I have to admit that _most_ of the time, I do in fact get SQLITE_INTERRUPTED as result from sqlite3_finalize, but every now and then, I do get SQL_ERROR. Maybe this happens when I try to interrupt just before the actual statement execution has started or when execution has just finished? ---- _2006-Jul-26 13:26:19 by anonymous:_ {linebreak} This might, of course, be related to my incorrect usage of =sqlite3_interrupt= from a different thread (Ticket #1897) ? #f2dcdc 2320 active 2007 Apr anonymous Pending drh 1 1 sqlite3_open(sFN_with_umlaut) Do it in a standard MS Visual Studio Project:
sqlite3* db = context->s.db;is the required variable for use with sqlite3_prepare, sqlite3_step and sqlite3_finalize etc. (That's my work-around){linebreak} What is needed only for loadable extension developers to stay aligned with new versions is the re-arrangement of existing struct sqlite3_context {Mem s} and struct Mem {sqlite3 *db} to become able to simply *typecast* sqlite3_context* into a sqlite3*; all the other internals of Mem would stay private to vdbe even when version numbers will grow.{linebreak} And now to answer the question "why the hell is he asking for this?" here my explanation by an example of what I made running:{linebreak}
select execSQL("select 'iniTable' as Title;select * from iniTable", '|', X'0D0A', X'0D0A'||'----'||X'0D0A' ); iniTable ---- Common|Integer|4711 Common|Float|3.1416927 Common|Double|3.1416927 Common|Text|Dies ist Text Common|Blob|X'0D0A'Think about an application which has to create a whole InMemory-Database table structure inclusive triggers and views:
select execSQL(stmt) from StatementTable where Usage='InMemory';And all within one and the same transaction. It is really that easy! This could answer also some points in the wishlist of the SQLite3 web site; all to do this is reordering Mem s in sqlite3_context and sqlite3*db in struct Mem to the beginning of the structures.{linebreak}Doing this with the release of version 3.5 is really a good moment, isn't it? _2007-Sep-07 11:54:38 by danielk1977:_ {linebreak} The usual approach is to pass the sqlite3* handle to sqlite3_create_function() as the 5th argument and then retrieve it from within the user function implementation using sqlite3_user_data(). If you depend on the definitions of internal data structures, you're living dangerously. ;) ---- _2007-Sep-07 12:54:56 by anonymous:_ {linebreak} Is then the following correct and will work in the same expected way (same pointer within ld-ex-function)? Even with sqlite_auto_extension called at DLL load time? (Win32 with Amalgamation and BDS2006){linebreak}
#includeThank's for the smilie and your hint. Of cause, I do not want to live dangerous. This was the purpose of my posting to get this fixed officially with the next release. But if you say it is not worth the "small change" of reordering and I'm doing it correct this way, then that's fine. I started similar to your proposal by using a static variable and assigned it from within sqlite3_extension_init but this would not work with more than one db-connection (the last one would win). The other open point for me is the right place and methode to link the same source code as used for the Loadable Extension Functions to become a DLL (for SQlite3.exe .load) as auto-loaded extensions into a specialized made of SQLite3.DLL for my applications. Do you have another trick than modifying the sqlite3_open-functions with compiler switches? This would be great. Even if above statements work, do you think the reordering makes sense for an easier transfer for the sqlite3* into the loadable extension function? The 5th argument would be kept free for other purposes. What is your estimation of likelyhood for that proposed change? What's against it? ---- _2007-Sep-07 14:11:38 by danielk1977:_ {linebreak} The code above is correct as far as I can see. As far as reordering structures to allow tricky casting, there's no particular argument against, other than it makes the code a bit tricky to follow. And limits the ways in which we can change the contents of the currently opaque sqlite3_context structure in the future. Something like: sqlite3 *sqlite3_get_connection(sqlite3_context *p){ return p->s.db; } might be a chance I guess. ---- _2007-Sep-10 18:58:09 by anonymous:_ {linebreak} That is a very good idea. Now I have a case, where I would like to make use of both, the db connection AND the user data:{linebreak} I have two database selections (by a list of keys) and I would like to used one function to compare "equal" and another "unequal". In this case I could use the same function body and use the userdata to distinguish between the cases equal and unequal while using the db connection to query the selection with the given keys.{linebreak} Using 2 functions which are sharing the same body of a 3rd function will be my workaround until this new API function becomes available with the next 3.5.x version. Many thanks. ---- _2007-Sep-10 19:09:51 by anonymous:_ {linebreak} I agree. It is very reasonable to want to use an sqlite3* connection from within a registered function as well. Scenario - perform an SQL query on same connection from within a user-defined function. Setting user data just for this common action is awkward. ---- _2008-Jan-08 14:46:14 by anonymous:_ {linebreak} when will this function become usable? will it come with 3.5.5 ? {linebreak} sqlite3 *sqlite3_get_connection(sqlite3_context *p) #cfe8bd 1885 active 2006 Jul anonymous Shell Pending 2 3 sqlite3 .mode insert and .dump do not list column names for selects In sqlite3 .mode insert does not list column names for selects - it should. This makes dumping selected columns from tables when intending to add or delete columns problematic. .dump doesn't list column names either, IMHO it should. Consider sqlite> .mode tabs{linebreak} sqlite> select * from users;{linebreak} ed 2006-07-05 52{linebreak} sqlite> .mode insert{linebreak} sqlite> select abs_tgt from users;{linebreak} INSERT INTO table VALUES(52);{linebreak} sqlite> Obviously the workaround is to hand edit the output SQL _2006-Jul-11 10:20:08 by anonymous:_ {linebreak} I've just noticed it doesn't include the table name in the INSERT statements either. #e8e8bd 2498 active 2007 Jul anonymous Pending 3 2 sqlite memory org on linux (related ticket #2473)... he sample programme that I run(wrote) in tty1 and there I operate the command of ps at tty2, there seems two items from the programme of ps command. This error was not at the version 3.3.13 but now it is happening at sqlite versions although i change nothing from the programme, If I turn to old versions, there is seen only one item again. When I upgrade to version 3.3.13 or later, there is seen two items again Is it normal or there is any mistake? (excuse my poor english) _2007-Jul-11 16:44:22 by anonymous:_ {linebreak} So you are seeing 2 processes instead of 1 on Linux? Linux 2.4 and earlier kernels show threads as seperate processes with unique process IDs. Is your program creating any threads? The only place where SQLite creates threads is the function below - but it joins with the thread right away.SQLITE_EXTENSION_INIT1 int sqlite3_extension_init( sqlite3 *db, char **pzErrMsg, const sqlite3_api_routines *pApi ) { SQLITE_EXTENSION_INIT2(pApi) sqlite3_create_function(db, "execSQL", -1, SQLITE_UTF8, db, execSqlFunc, 0, 0); ... } static void execSqlFunc( sqlite3_context *context, int argc, sqlite3_value **argv ) { sqlite3 *db = sqlite3_user_data(context ); /* instead of using context's internals ( sqlite3 *db = context->s.db ); or waiting for reordering of them and using typecase ( sqlite3 *db = (sqlite3*)context; ) respective ( sqlite3 *db = *(sqlite3**)context; )? */ ... }
/* ** This procedure attempts to determine whether or not threads ** can override each others locks then sets the ** threadsOverrideEachOthersLocks variable appropriately. */ static void testThreadLockingBehavior(int fd_orig){ int fd; struct threadTestData d[2]; pthread_t t[2]; fd = dup(fd_orig); if( fd<0 ) return; memset(d, 0, sizeof(d)); d[0].fd = fd; d[0].lock.l_type = F_RDLCK; d[0].lock.l_len = 1; d[0].lock.l_start = 0; d[0].lock.l_whence = SEEK_SET; d[1] = d[0]; d[1].lock.l_type = F_WRLCK; pthread_create(&t[0], 0, threadLockingTest, &d[0]); pthread_create(&t[1], 0, threadLockingTest, &d[1]); pthread_join(t[0], 0); pthread_join(t[1], 0); close(fd); threadsOverrideEachOthersLocks = d[0].result==0 && d[1].result==0; }If you post a small C program demonstrating what you're seeing, someone may be able to offer a suggestion. ---- _2007-Jul-11 16:47:10 by anonymous:_ {linebreak} I suppose it's not inconceivable that the join failed. Perhaps these pthread_join calls' return codes should be examined for errors. ---- _2007-Jul-11 18:53:36 by anonymous:_ {linebreak} If you're playing games with tty's and you've got an early Linux 2.6 kernel, it's possible that processes are dying because of http://lkml.org/lkml/2004/10/21/119. It was, last I checked, fixed in 2.6.10. The SIGHUP being generated might also interfer with a =pthread_join()=, although =pthread_join()= doesn't say anything about ever generating =EINTR=... c. ---- _2007-Jul-12 06:12:28 by anonymous:_ {linebreak} my example program is very simple, i not use threading-multithreading structure... If I turn to old versions of sqlite, there is seen only one item again, when I upgrade to version 3.3.13 or later, there is seen two items again Is it. note: /lib/libpthread.so.0 linked to /lib/libpthread-0.10.so (size 55468 byte) ---- _2007-Jul-12 11:36:37 by anonymous:_ {linebreak} Your description of the problem isn't clear enough, so the answers you're getting are just guesses. You may have more luck by describing the problem (with as much detail as possible) in your native language and hoping someone in the SQLite community can add a translation. I know you're doing your best with the english you speak, but it's not working well enough for someone to help with your problem. Adding code samples and command-line output would also help considerably, since that sort of this is mostly language independent. #cfe8bd 1893 active 2006 Jul anonymous Pending 3 3 sqlite doesn't use indexes containing primary key in prim. key selects I have table: CREATE TABLE IF NOT EXISTS 'customers' ( 'rowid' INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, 'fname' CHAR(40) NOT NULL, 'sname' CHAR(40) NOT NULL, 'birthno' CHAR(11) NULL) And index: CREATE UNIQUE INDEX IF NOT EXISTS 'idx_customers_sname' ON 'customers' ( 'sname' ASC, 'fname' ASC, 'rowid' ASC ); Command SELECT * FROM customers ORDER BY sname ASC, fname ASC, rowid ASC; doesn't use created index. Command SELECT * FROM customers ORDER BY sname ASC, fname ASC; uses index idx_customers_sname. I think this is a bug, but maybe (i don't know), it is by desing. If I don't specify rowid in ORDER BY, is the resultset ordered by rowid anyway? _2006-Jul-24 16:02:29 by anonymous:_ {linebreak} In SQL single quotes are used around string literals, and double quotes are used around identifiers where required to enclose keywords and/or embedded spaces. In your case no quotes are required at all because your table and column identifiers are continuos (i.e. do not contain embedded spaces) non-keyword names. If you are going to include unnecessary quotes then you should at least use the correct ones. CREATE TABLE IF NOT EXISTS "customers" ( "rowid" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "fname" CHAR(40) NOT NULL, "sname" CHAR(40) NOT NULL, "birthno" CHAR(11) NULL); CREATE UNIQUE INDEX IF NOT EXISTS "idx_customers_sname" ON "customers" ( "sname" ASC, "fname" ASC, "rowid" ASC ); Aside from that, this does look like a bug. SQLite is doing an unnecessary sort for the first query, and correctly using the index for the second. I suspected that it might be related to handling of the special column name rowid, but it does the same thing if rowid is replaced with a more generic name like id as shown below. SQLite version 3.3.6 Enter ".help" for instructions sqlite> CREATE TABLE IF NOT EXISTS "customers" ( ...> "id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, ...> "fname" CHAR(40) NOT NULL, ...> "sname" CHAR(40) NOT NULL, ...> "birthno" CHAR(11) NULL); sqlite> sqlite> CREATE UNIQUE INDEX IF NOT EXISTS "idx_customers_sname" ...> ON "customers" ( "sname" ASC, "fname" ASC, "id" ASC ); sqlite> sqlite> sqlite> explain query plan SELECT * FROM customers ORDER BY sname ASC, fname ASC , id ASC; 0|0|TABLE customers sqlite> explain query plan SELECT * FROM customers ORDER BY sname ASC, fname ASC ; 0|0|TABLE customers WITH INDEX idx_customers_sname ORDER BY sqlite> sqlite> .explain on sqlite> sqlite> explain SELECT * FROM customers ORDER BY sname ASC, fname ASC, id ASC; addr opcode p1 p2 p3 ---- -------------- ---------- ---------- --------------------------------- 0 OpenVirtual 1 5 keyinfo(3,BINARY,BINARY) 1 Goto 0 34 2 Integer 0 0 3 OpenRead 0 2 4 SetNumColumns 0 4 5 Rewind 0 19 6 Rowid 0 0 7 Column 0 1 8 Column 0 2 9 Column 0 3 10 MakeRecord 4 0 11 Column 0 2 12 Column 0 1 13 Rowid 0 0 14 Sequence 1 0 15 Pull 4 0 16 MakeRecord 5 0 17 IdxInsert 1 0 18 Next 0 6 19 Close 0 0 20 OpenPseudo 2 0 21 SetNumColumns 2 4 22 Sort 1 32 23 Integer 1 0 24 Column 1 4 25 Insert 2 0 26 Column 2 0 27 Column 2 1 28 Column 2 2 29 Column 2 3 30 Callback 4 0 31 Next 1 23 32 Close 2 0 33 Halt 0 0 34 Transaction 0 0 35 VerifyCookie 0 2 36 Goto 0 2 37 Noop 0 0 sqlite> explain SELECT * FROM customers ORDER BY sname ASC, fname ASC; addr opcode p1 p2 p3 ---- -------------- ---------- ---------- --------------------------------- 0 Noop 0 0 1 Goto 0 21 2 Integer 0 0 3 OpenRead 0 2 4 SetNumColumns 0 4 5 Integer 0 0 6 OpenRead 2 4 keyinfo(3,BINARY,BINARY) 7 Rewind 2 18 8 RowKey 2 0 9 IdxIsNull 0 17 10 IdxRowid 2 0 11 MoveGe 0 0 12 Rowid 0 0 13 Column 0 1 14 Column 0 2 15 Column 0 3 16 Callback 4 0 17 Next 2 8 18 Close 0 0 19 Close 2 0 20 Halt 0 0 21 Transaction 0 0 22 VerifyCookie 0 2 23 Goto 0 2 24 Noop 0 0 sqlite> ---- _2006-Aug-03 17:33:51 by anonymous:_ {linebreak} Thank you for clarification of single and double quotes usage. I will drop the quotes completely since using double quotes is little bit annoying inside C string literals... It seems that the problem with index and sorting on primary key is independent of primary key column name. In fact, previously I was using "id" :-) and the result was the same as you mentioned. #f2dcdc 2140 active 2007 Jan anonymous Pending 3 1 sqlite doesn't link to readline sqlite relies on another library to link to libreadline, causing this error with LDFLAGS=-Wl,--as-needed: gcc -O2 -march=i686 -pipe -DOS_UNIX=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -I. -I./src -DNDEBUG -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_CURSOR -DHAVE_READLINE=1 -I/usr/include/readline -o .libs/sqlite3 ./src/shell.c ./.libs/libsqlite3.so -lpthread -lncurses /tmp/cclOD1M7.o: In function `process_input': shell.c:(.text+0x37a5): undefined reference to `readline' shell.c:(.text+0x37c0): undefined reference to `add_history' /tmp/cclOD1M7.o: In function `main': shell.c:(.text+0x3f01): undefined reference to `read_history' shell.c:(.text+0x3f1a): undefined reference to `stifle_history' shell.c:(.text+0x3f22): undefined reference to `write_history' collect2: ld returned 1 exit status #cfe8bd 1026 active 2004 Dec anonymous Unknown Pending 3 3 sqlite automake sqlite3.pc file does not have version information When the configure of sqlite has been done, the sqlite3.pc file does not have information in the Version: section. This means there's no way to check for versions in other autogen/configure files concerning the sqlite version in the system, style: PKG_CHECK_MODULES(SQLITE, sqlite >= 3.0.3, AC_MSG_ERROR([$SQLITE_PKG_ERRORS])) #f2dcdc 1342 active 2005 Jul anonymous Pending 1 1 sqlite 3.2.2 will not load on Suse Linux 9.3 when trying to load the sqlite 3.2.2 .so lib with tcl I get this problem: couldn't load file "/usr/lib/sqlite3/tclsqlite-3.2.2.so": /usr/lib/sqlite3/tclsqlite-3.2.2.so: undefined symbol: sqlite3_version Sqlite 3.2.1 does not give an error, with the same script #cfe8bd 1508 active 2005 Nov anonymous BTree Pending 1 3 sqlite 2.8.16 crashes on 64-bit / strict memory alignment archs A few months ago, sqlite3 was fixed on 64-bit / strict memory alignment architectures. Would it be possible for those fixes to be backported to the version_2 code? I have an OpenBSD/sparc64 machine which I can provide ssh access to (as I did before to drh). I know sqlite2 is mostly unsupported, but as php5 uses sqlite2, it would be nice to have these fixes backported. _2006-Jan-05 02:28:23 by anonymous:_ {linebreak} with the attached patch, sqlite 2.8.17 passes all the regressions tests on openbsd/amd64 and openbsd/sparc64. #cfe8bd 1134 active 2005 Feb anonymous Pending drh 3 3 select command with a view and a condition gets no result In a view with more than one tables it is no longer possible to use that view within a select command; the columns of the view are not found. #f2dcdc 2294 active 2007 Apr anonymous Pending 2 1 segfault when destroying lock on WinCE with threads DestroyLock emulation on WinCE platform releases the zDeleteOnClose file outside the mutex acquire section. This lead to frequent segfault when working with several databases concurrently. Patch simply consists in moving code: if( pFile->zDeleteOnClose ){ DeleteFileW(pFile->zDeleteOnClose); sqliteFree(pFile->zDeleteOnClose); pFile->zDeleteOnClose=NULL; } from winClose() (os_win.c:980) to winceDestroyLock(), inside scope of winceMutexAcquire(pFile->hMutex): /* De-reference and close our copy of the shared memory handle */ UnmapViewOfFile(pFile->shared); CloseHandle(pFile->hShared); + if( pFile->zDeleteOnClose ){ + DeleteFileW(pFile->zDeleteOnClose); + sqliteFree(pFile->zDeleteOnClose); + pFile->zDeleteOnClose=NULL; + } /* Done with the mutex */ winceMutexRelease(pFile->hMutex); CloseHandle(pFile->hMutex); pFile->hMutex = NULL; _2007-Apr-13 00:21:33 by anonymous:_ {linebreak} Check in [3836] fixes it for me. eTcl regression tests, related to running several sqlite database concurrently in several threads, are now passed while they were frequently segfaulting without it. To help being confident with this _blind_ commit, let's mention that exactly same patch has been introduced in eTcl built since a couple of monthes, to fix issue reported by WM2003 users, and all reported a correct fix. However, I did suggest the patch, so testing and feedback from others may help :-) Also, note that [3836] has a typo, requesting feedback in ticket #2249 instead of #2294 ---- _2007-Sep-25 03:24:09 by anonymous:_ {linebreak} The fix doesn't work and should be reverted. Temporary files do not create locks, so when they are closed and hMutex is null, the winceDestroyLock() file is never called and the temporary files are not cleaned up properly. #cfe8bd 2613 active 2007 Sep anonymous Pending drh 3 3 replace doesn't work with blobs containing \x0, otherwise it does The replace expression function does not work with blobs in case of contained zero terminator character; but it does if there is not this special character included. I expected the function to work similar like substr with blob-safety in case of type is blob only. X'nnnn' is of type blob, so following example should have returned a blob type result X'0102FF0405' in the 2nd and 3rd line. How to get to this result?
SQLite version 3.4.2 Enter ".help" for instructions sqlite> select hex(replace(X'0102030405',X'03',X'FF')); 0102FF0405 sqlite> select hex(replace(X'0102000405',X'00',X'FF')); sqlite> select typeof(replace(X'0102000405',X'00',X'FF')); null sqlite>_2007-Sep-03 04:21:12 by anonymous:_ {linebreak} Replace was designed to work with strings. However, working with blobs would be an interesting extension. ---- _2007-Oct-18 06:13:10 by anonymous:_ {linebreak} I've seen a similar situation where I can't reliably store stings with nulls in the middle of them as TEXT. I can convert them to blobs, in which case length(...) works correctly. I if convert them back to strings, length(...) treats them as C-strings. Is this the expected behavior? I notice the entire column is preserved even when it's has TEXT affinity, I can append data to it as a string, cast back to a blob and see everything (am I explaining this poorly?) This all seems a bit counter intuitive in some ways. Perhaps strings shouldn't treat NULL characters as special? ---- _2007-Oct-27 16:45:41 by anonymous:_ {linebreak} Treatment of length operator is - as fas as I know - dependent on type: {linebreak} As text it is the length number of UTF-8 characters and as blob it is the number of bytes. As long as all the UTF-8 characters out of the lower half ASCII char-set (127 of them), this is identical beside the fact of different 0-terminator interpretation. {linebreak} To append is something different than using the replace operator. My suggestion would be to make the replace operator work with bytes (not UTF-8) in case of all 3 parameters are of type blob. {linebreak} Another suggestion: the UTF aware functions are Private declared and not usable from within a loadable extension dll/so. This should be changed. ---- _2008-Jan-28 19:36:39 by anonymous:_ {linebreak} Will there come a solution for this with the next release? It is really not fair to handle a blob only like text which cannot contain a zero terminator. With this unique useful function a zero-containing blob could be formed into a normal text string without loosing the part behind the zero terminator. It would be really a step forward without too much effort. #cfe8bd 1228 active 2005 Apr anonymous Unknown Pending 4 3 problem with select+union on a view with aliased columns CREATE TABLE tbl1 (col1 VARCHAR PRIMARY KEY); INSERT INTO tbl1 VALUES ('1'); INSERT INTO tbl1 VALUES ('2'); CREATE VIEW view1 AS SELECT col1 AS col1a FROM tbl1; This creates a view with one column (col1a). Normal SELECTs on this view return results as expected, but the following: SELECT col1a FROM view1 WHERE col1a = 1 UNION SELECT col1a FROM view1 WHERE col1a = 2; Produces: col1 1 2 When the column name should in fact be col1a (this is the behaviour in postgres). You can work around this by doing: SELECT col1a AS col1a FROM view1 WHERE col1a = 1 UNION SELECT col1a AS col1a FROM view1 WHERE col1a = 2; But that shouldn't be necessary. Thanks. --Sebastian Kun #cfe8bd 754 active 2004 Jun anonymous Shell drh 2 3 problem opening a dbfile in the upper directory (../dbname) there is a problem in the calculation of a full path name based on a relative path name in an uproot location (../). i have fixed this during my porting to dos, and the relevant diff is at http://www.sqlite.org/cvstrac/tktview?tn=524. best regards alex #e8e8bd 1901 active 2006 Jul anonymous Unknown Pending adamd 2 2 problem in select request with a alias table I have a table with 3 columns : c0, c1 and c2 My request is: select * from (select *, 'test' as new_col from table) as tmp inner join (select 'test' as new_col) as tmp1 on tmp.new_col = tmp1.new_col; The column's name as a result of this request (sqlite 3-3.3.6) is: |tmp.table.c0|tmp.table.c1|tmp.table.c2|tmp.new_col|tmp1.new_col In sqlite 3-3.2.7, the column's name is: |c0|c1|c2|collected|new_col|new_col Before this version, my request ran on mysql, postgresql and sqlite. Now I don't have the possibility of using this request with the new sqlite version. _2006-Jul-31 10:11:59 by anonymous:_ {linebreak} sorry in In sqlite 3-3.2.7, the column's name is: |c0|c1|c2|new_col|new_col ---- _2007-Jan-08 14:52:43 by anonymous:_ {linebreak} I had a similar problem with SQLite in PHP, see my bug report here: http://bugs.php.net/bug.php?id=40064 #e8e8bd 1884 active 2006 Jul anonymous Pending 3 2 pragma table_info caches results from previous query this problem is observed with pysqlite's latest windows build 2.3.2 and others. it does not occur on unix-based builds, which is why I suspect the issue is in sqlite, since pysqlite's code is platform-neutral. if you get a result from a "pragma table_info()" call, and do not consume all the results, then a subsequent call to the same statement does not return up-to-date results, i.e. if the table had been dropped in between. it behaves as though the results of "pragma table_info" are globally cached somewhere, ignoring the fact that is was executed again. this test program illustrates the problem: from pysqlite2 import dbapi2 as sqlite connection = sqlite.connect(':memory:') # check for a nonexistent table c = connection.execute("pragma table_info(users)") row = c.fetchone() assert row is None # its good. # now create the table connection.execute(""" create table users ( foo VARCHAR(10), name VARCHAR(40) ) """) # do the table_info pragma. returns two rows c = connection.execute("pragma table_info(users)") # get the first row row = c.fetchone() print row # but then dont get the second, close out the cursor instead. #row2 = c.fetchone() # uncomment to fully consume both rows, then it works c.close() c = None # rollback too. connection.rollback() # now drop the table connection.execute("DROP TABLE users") print "dropped" # now it should be gone, right? well it is, but the pragma # call starts off with the former result set c = connection.execute("pragma table_info(users)") row = c.fetchone() print row assert row is None # fails. #cfe8bd 2241 active 2007 Feb scouten Pending 3 3 pragma integrity_check no longer affects command-line tool's exit code With the 3.3.5 build, if you did the following: sqlite3 /path/to/db "PRAGMA integrity_check;" You seemed get a 1 result back on the command line if the check failed in any way (and 0 if it was "ok"). With 3.3.13, this doesn't seem to be the case, even if you specify the -bail command line parameter. (I also tried "PRAGMA integrity_check=1;", which is all I care about in this case.) I have a database with errors that returns 0 to the calling process (that is, the sqlite command line's main function returns 0). We would like to see the 3.3.5 behavior return. _2007-Mar-29 18:32:54 by drh:_ {linebreak} I pulled versions of SQLite going back to 2006-01-01 and I could not find one where the shell returned a non-zero exit code when PRAGMA integrity_check failed. Are you sure that you do not have a customized version of the 3.3.5 shell? #cfe8bd 1085 active 2005 Jan anonymous Pending 2 3 pragma full_column_names and short_column_names still broken the following statement : SELECT T1.*,D1.* FROM test T1,dt D1 WHERE T1.id=D1.id does not give "long" column names, even if full_column_names is ON. But, the following does: SELECT T1.ID,D1.NAME FROM test T1,dt D1 WHERE T1.id=D1.id in other words, tablename prefix is applied only to explicit columns, not to "*" selected columns. #cfe8bd 2223 active 2007 Feb scouten Pending 3 3 pragma auto_vacuum doesn't survive .dump & reconstitute When you run sqlite3 path/to/database .dump, it does not contain pragma auto_vacuum even if that option was chosen when creating the source database. _2007-Feb-08 18:13:27 by scouten:_ {linebreak} We wonder if other pragmas are also not being propogated. ---- _2007-Feb-08 18:53:42 by anonymous:_ {linebreak} No pragmas are output from .dump. SQLite should have a .dump_with_pragmas command or equivalent. ---- _2007-Nov-27 02:11:05 by anonymous:_ {linebreak} auto_vacuum is especially important since you need to specify it *before* loading the tables in the dump; if you notice that it's missing after loading a dump, it's too late. I'd also appreciate user_version surviving. Would patches be welcome for these? I would be happy to contribute one: mail glasser@davidglasser.net. #cfe8bd 575 active 2004 Jan anonymous VDBE drh 3 3 pragma (default_)temp_store implementations seems incomplete This problem is a conflict between documented behaviour and actual behaviour, and could fall in the 'Documentation' category as well. There seems to be a problem with 'pragma default_temp_store'. In pragma.c code exists to handle it, and that code stores the provided value in Cookie 5 (as VDBE instruction argument; that is the _sixth_ metadata integer, and would correspond to meta[6] in sqliteInitOne() in main.c). However, the code loading a database (the aforementioned sqliteInitOne() in main.c) never looks at that value, and the setting is ignored. (Also, Vacuum doesn't seem to copy it.) A related problem is that using the default_temp_store or temp_store pragma's doesn't work as advertised, at least not in the precompiled commandline tool sqlite.exe: you will always get the following error, even if you use the pragma at init time: SQL error: The temporary database already exists - its location cannot now be changed Trying to set the flag (the value at offset 0x50 in a database file) to 2 (attempting to force an in-memory database for temp tables) with a hex editor has only partial success: the handcrafted value is reported by _pragma default_temp_store;_ but typing _.databases_ still shows a file name for the temporary data base, and using the filemon tool (a windows file activity monitor, downloadable from www.sysinternals.com) shows that the temp file is actually accessed when giving a 'create temp table' command (not surprising, if there is no code to actually ever initialize the db->temp_store from the Cookie). If for some reason it is infeasible to circumvent the issue that the temp table will always be open before executing the pragma, I suggest changing the semantics of _pragma default_temp_store_ to _only_ change the default (as stored in the file), but _not_ change the current value. This would allow executing _pragma default_temp_store_ even while a temp table is open (though its effect will only be visible when the database is opened again). Note that this issue has a few documentation issues: *: lang.html suggests that _pragma default_temp_store_ and _pragma temp_store_ are currently working. At least in the commandline tool they aren't (I didn't make a dedicated test program to see if the problem already exists at the C-API level) *: fileformat.html doesn't document the location where the temp_store flag is stored. In fact, I consider the fact that the fifth meta value (meta[5] a.k.a. Cookie 4) is seemingly not used anywhere slightly suspicious. *: the number of metadata values is documented inconsistently in fileformat.html: in one place it mentions there are 6 values including the two leading values (which makes 4 metavalues), a bit later 9 metavalues are mentioned... #e8e8bd 2440 active 2007 Jun rse Pending 2 2 pkg-config(1) script "sqlite.pc" does not provide Autoconf's LIBS On some platforms it isn't sufficient to link a library just against "-lsqlite". For instance under Solaris one needs "-lsqlite -lrt" because of the use of "fdatasync()". The SQLite Autoconf glue already contains the necessary check for this in order to correctly build SQLite and especially link its sqlite(1). But this information is not passed through to the applications which use pkg-config(1) to build against SQLite. Possible fix from OpenPKG's "sqlite" package is following:
Index: sqlite3.pc.in --- sqlite3.pc.in.orig 2004-07-19 06:25:47 +0200 +++ sqlite3.pc.in 2007-06-20 18:09:00 +0200 @@ -8,5 +8,5 @@ Name: SQLite^M Description: SQL database engine^M Version: @VERSION@^M -Libs: -L${libdir} -lsqlite3^M +Libs: -L${libdir} -lsqlite3 @LIBS@^M Cflags: -I${includedir}^M#cfe8bd 2165 active 2007 Jan anonymous Pending drh 4 3 pager performance and checksum pager.c Embedd the 2 byte pager_pagehash() result into the page, near the beginning of the page. Use the intire page to calculate the pager_pagehash exclusive of the two byte page_hash data embedded in the page. That way a simple xor as in CHECK_PAGE of the entire page including the 2 byte pager_pagehash is all that is needed to validate a page. Also you could include the "4 byte" random at the beginning and at the end... But that would be a bit of overkill. The sampling of only every 200 bytes is interesting. Review change the SQLITE_CHECK_PAGES ifdef to a SQLITE_OMIT_PAGE_CHECK.. As on disk page validity is very important. Could this be integrated into a pragma setting? _2007-Jan-12 18:08:49 by anonymous:_ {linebreak} uint16_t pg_chkval(Dpage *pg, uint32_t pg_size) { register int i; register uint16_t val = 0; register uint16_t *bw = (uint16_t *) pg; for(i= 0; i < pg_size;i=i+2 ) val= val^ *bw++ ; return val; } uint16_t pg_calcval(Dpage *pg, uint32_t page_size) { int i; register uint16_t val = 0; register uint16_t *bw = (uint16_t *) pg; /* Scan up to location where chk val is stored */ for(i= 0; i < 8;i=i+2 ) val= val^ *bw++ ; val = val^ 0; bw ++ ; /* Now scan the tail of the block */ for(i=10; i < page_size;i=i+2 ) val= val^ *bw++ ; return val; } #f2dcdc 1457 active 2005 Sep anonymous Shell Pending 3 1 non-latin chars not recognized by CLI Hello, If i am trying to execute an SQL statement via the CLI of a self-compiled (Win via MinGW) or the prebuilded exe all chars that are not iso are converted to something ugly. For example, the German Umlaute or the è are not entered correctly into a table name, field value and so on. If the same commands are executed from the sqlite>> promt everything works well. As I need to compile my own sqlite.exe I need to be able to change that in code. Thank you for this great Product and a solution to this problem. btw: This is my first request here, so please be patient with me if I´ve set the priority wrong... It´s obviously highest priority to me ;) _2005-Sep-26 21:44:12 by anonymous:_ {linebreak} è should be the accented e in my post, sorry for that #f2dcdc 1111 active 2005 Feb anonymous Unknown Pending 3 1 no such column error with a subselect as a table Execute the following script. In 3.0.8, you get the following results: line 0 line 2 in 3.1.1 beta, you get the following error: SQL error: no such column: bb.a SCRIPT: create table test1 (a int); insert into test1 values (0); insert into test1 select max(a)+1 from test1; insert into test1 select max(a)+1 from test1; create table test2 (a int, b text); insert into test2 select a,'line ' || a from test1; select test2.b from (select test1.a from test1 where a%2 = 0) as bb join test2 on bb.a = test2.a; _2005-Feb-21 17:48:20 by anonymous:_ {linebreak} Tested in 3.1.3, issue still exists ---- _2005-Jun-12 22:09:08 by drh:_ {linebreak} Workaround: select test2.b from (select test1.a as a from test1 where a%2=0) as bb join test2 on bb.a=test2.a; #f2dcdc 2715 active 2007 Oct anonymous Pending 1 1 no authorization needed to remove authorizer there should be a new auth code created and the auth function should be consulted for permission for removal. _2007-Oct-10 01:08:48 by drh:_ {linebreak} I'm assuming that this feature request comes from {quote: RockShox} and that the development language is Tcl. No. If your adversary has the ability to invoke the interface that removes an authorizer, then you system is already pwned. What you really need is the ability to [interp alias] the eval method into a safe interpreter. That way you can: *: Open the database in the main interpreter *: Set up the authorizer in the main interpreter to invoke a script in the main interpreter *: Set up the [interp alias] so that the safe interpreter can do [db eval ...] but not [db auth ...] It seems like an "-interp" option on the "eval" method of the database connection object would likely be the right interface. Or perhaps there should be separate "safeeval" method. Either way, it has been years and years since I have done anything with safe interpreters so I will have to look into what needs to be done to make that happen. ---- _2007-Oct-17 20:11:23 by anonymous:_ {linebreak} ok i think i agree with that. currently you cannot use an interp alias since the target command runs in the target interp and all your variables and commands are in the wrong scope. this means one needs to load sqlite again in the new interp, and sqlite will not load in a safe interp so a regular interp is required. to be useful, a -interp flag would need to execute in the current scope of the interp and not the global scope. #cfe8bd 1200 active 2005 Apr anonymous Pending 2 3 new versions of SQLite return different (incorrect) results. Newer versions of SQLite are returning different, and I believe incorrect, results compared to those returned by older versions. Using version 3.0.8 the following query returns the correct results given the attached database. sqlite> select * from device_property_list where device_property_value = 0; 1|Station|3|Initial Volume|0 1|Station|1|Template|0 2|Station|3|Initial Volume|0 2|Station|1|Template|0 3|Station|3|Initial Volume|0 3|Station|1|Template|0 This same query does not return any results using versions 3.1.6 and 3.2. If the query is changed slightly, by quoting the zero in the where condition, then both of the newer versions return the same set of results as 3.0.8. sqlite> select * from device_property_list where device_property_value = '0'; 1|Station|3|Initial Volume|0 1|Station|1|Template|0 2|Station|3|Initial Volume|0 2|Station|1|Template|0 3|Station|3|Initial Volume|0 3|Station|1|Template|0 The device_property_list is a view that hides a complex join of several tables, and a long case expression that select the value to return for device_property_value; the field that is being tested by the condition. I have attached a sample database and the sql script used to create it for testing. #e8e8bd 2905 active 2008 Jan anonymous Pending pweilbacher 2 2 mutex_os2.c - incorrect mutex implementation The OS/2 version of sqlite3_mutex_alloc() is badly broken. It creates named mutexes which, by design, are global rather than process-specific as intended. This might be minimally acceptable except that the function reuses the same name every time it attempts to create a SQLITE_MUTEX_FAST or SQLITE_MUTEX_RECURSIVE. The result is that every call returns the exact same semaphore to every thread in every process using sqlite3. Once this mutex is owned by one process, other processes calling sqlite3_mutex_enter() will be blocked. Much the same is true for the static mutexes. Every process ends up using the exact same SQLITE_MUTEX_STATIC_MASTER, SQLITE_MUTEX_STATIC_MEM, etc. There's another flaw that is fairly minor compared with the above: in an attempt to avoid concurrency when creating the static mutexes, this function uses an API call that is thoroughly deprecated. The attached patch remedies all of these issues. Since the logic that protects the creation of the static mutexes may not be self-evident, here's an explanation: The existence (or non-existence) of a given named mutex is itself a semaphore. If the isInit flag is false, the code attempts to create a mutex whose name is unique to that process. If the attempt is successful, there are two possibilities: (1) either the current thread is the first to reach this code & may proceed; (2) or while the current thread was making its preparations, another thread created the mutex, did the init, then closed the mutex. Testing isInit immediately after creating the mutex determines which possibility is valid. If mutex creation fails due to a duplicate name, then another thread is currently performing the init. In this case, the current thread simply has to wait a while until the other thread is done & isInit becomes true. Submitted by Rich Walsh (richATe-vertise.com) #f2dcdc 1323 active 2005 Jul anonymous Pending 1 1 misuse-4.4...gmake: *** [test] Segmentation Fault (core dumped) misuse-4.4...gmake: *** [test] Segmentation Fault (core dumped) on both solaris 8 and 9 build env export CPPFLAGS="-I/tps/include" export LDFLAGS="-L/tps/lib -R/tps/lib" export PKG_CONFIG_PATH=/tps/lib/pkgconfig CC=/tps/bin/gcc CXX=/tps/bin/g++ LD_LIBRARY_PATH=/tps/lib:/tps/lib/sparcv9:/lib:/usr/lib:/usr/local/lib:\ /usr/ccs/lib:/usr/dt/lib:/usr/ucblib:/usr/openwin/lib PATH=/tps/bin:/tps/java/bin:/dsw/source/bin:/dsw/depot-5.13/bin:\ /usr/ccs/bin:/usr/bin:/usr/openwin/bin:/bin:/usr/local/bin:/sbin:\ /usr/sbin:/usr/ucb:/etc:.:/sfoc/bin:/usr/dt/bin:\ /dsw/source/harvest/bin:/usr/afsws/bin:/dsw/pgp-2.6.2s/bin export CC CXX LD_LIBRARY_PATH PATH where /tps is my version of /usr/local where I put all the configuration controlled open source and licensed s/w for my network.
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_OKBut if I move the file to c:\My documents\Data_Jobs this works ok. It's improbable behaviour, but I can't work around yet. Although, prepare() functions work ok as well in both cases. Yuri Noyanov. _2007-Oct-11 19:33:34 by drh:_ {linebreak} All string arguments to SQLite, and especially filename arguments, must be UTF-8 or UTF-16 (depending on the function). If you use string parameters which are not UTF-8 or UTF-16 (as appropriate) then the behavior of SQLite is undefined and probably not what you want. ---- _2007-Oct-12 04:25:56 by anonymous:_ {linebreak} but ALL programs to handle SQLite DBs (SQLIteBrowser, SQLite Control) fail to handle the files as well. Till I move the file to different directory !!! ---- _2007-Oct-12 04:27:54 by anonymous:_ {linebreak} Also I must note, that I CAN open the database, I CAN execute some SQLs with sqlite_prepare function OK. But sqlite_prepare16 FAILS if I just rename my database !!! ---- _2007-Oct-12 04:31:46 by anonymous:_ {linebreak} Also note to make my issue clearer: sqlite_prepare16() with the same code either works OK either doesn't work. depends on database filename or folder path. The database is opened OK in both cases (I used utf8 conversion). sql_prepare() works ok in both cases. ---- _2007-Oct-13 06:37:43 by anonymous:_ {linebreak} That appears to be only with INSERT sql statement. Both SELECT and UPDATE work fine with sqlite_prepare16. #cfe8bd 2882 active 2008 Jan anonymous Pending 3 3 fulltest failure: ./testfixture: wrong # args: should be "cksum db" exclusive-ioerr-2.2.1... Ok ./testfixture: wrong # args: should be "cksum db" while executing "ifcapable vacuum { do_ioerr_test ioerr-2 -cksum true -sqlprep { BEGIN; CREATE TABLE t1(a, b, c); INSERT INTO t1 VALUES(1, randstr(50,..." (file "../test/ioerr.test" line 58) invoked from within "source $testdir/ioerr.test" (file "../test/exclusive3.test" line 50) invoked from within "source $testfile" ("foreach" body line 5) invoked from within "foreach testfile [lsort -dictionary [glob $testdir/*.test]] { set tail [file tail $testfile] if {[lsearch -exact $EXCLUDE $tail]>=0} continue ..." ("for" body line 7) invoked from within "for {set Counter 0} {$Counter<$COUNT && $nErr==0} {incr Counter} { if {$Counter%2} { set ::SETUP_SQL {PRAGMA default_synchronous=off;} } else ..." (file "..//test/all.test" line 85) _2008-Jan-14 23:25:49 by anonymous:_ {linebreak} The latest code seems to have fixed this. I would close this but I don't see how to do that. #f2dcdc 2057 active 2006 Nov anonymous Pending 3 1 full_column_names when 2 or more tables are joined is not working Version 2.8 has the behavior described in the documentation in respect to full_column_names when 2 or more tables are present with (table/alias).*, but 3.3.8 doesn't, mixing the pragmas "full_column_names" and "short_column_names" can only force to have full_column_names allways or never, some programs expect the behavior described in the documentation to remain working. _2006-Nov-08 20:10:13 by anonymous:_ {linebreak} Version 3.3.3 as well has the same problem. ---- _2006-Nov-09 09:34:52 by anonymous:_ {linebreak} Changing the line 977 of select.c (3.3.8) from: if( pEList->a[i].zName){ to: if( pEList->a[i].zName && pTabList->nSrc==1){ with pragma short_column_names = 0 behaves like 2.8 series. #cfe8bd 2793 active 2007 Nov anonymous Pending 3 3 fts3 lacks scoping It would be nice if the fts3 symbols could optionally be made private/static as the rest of the sqlite3 library. Not sure why sqlite3_api becomes public when used with the amalgamation, for that matter. make TOP=`pwd` BCC=gcc TCC=gcc AR=ar RANLIB=echo NAWK=gawk -f \ main.mk sqlite3.h sqlite3.c fts3amal.c cat fts3amal.c >> sqlite3.c gcc -DSQLITE_THREADSAFE -DSQLITE_API=static -DSQLITE_PRIVATE=static \ -DSQLITE_EXTERN=static -DSQLITE_ENABLE_FTS3 -c sqlite3.c nm sqlite3.o | grep -v ' [trUbd] ' 00000004 C sqlite3_api 00064da2 T sqlite3Fts3HashClear 000652a4 T sqlite3Fts3HashFind 00064d60 T sqlite3Fts3HashInit 0006533b T sqlite3Fts3HashInsert 00064b4c T sqlite3Fts3Init 00066b34 T sqlite3Fts3InitHashTable 000669bd T sqlite3Fts3PorterTokenizerModule 0006702d T sqlite3Fts3SimpleTokenizerModule #f2dcdc 1465 active 2005 Oct anonymous CodeGen Pending 1 1 fdatasync not available and not yet fixed fdatasync is still there ... i downloaded the current configure files which should check for it. do i have to use something else too? ./libtool --mode=link cc -g -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -DHAVE_READLINE=0 \ -o sqlite3 ./src/shell.c libsqlite3.la -lcurses cc -g -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I./src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_OMIT_CURSOR -DHAVE_READLINE=0 -o .libs/sqlite3 ./src/shell.c ./.libs/libsqlite3.so -lcurses "./src/shell.c", line 355: warning: argument #1 is incompatible with prototype: prototype: pointer to const unsigned char : "./src/shell.c", line 84 argument : pointer to const char "./src/shell.c", line 523: warning: argument #1 is incompatible with prototype: prototype: pointer to const unsigned char : "./src/shell.c", line 84 argument : pointer to char "./src/shell.c", line 694: warning: argument #2 is incompatible with prototype: prototype: pointer to const char : "./src/shell.c", line 583 argument : pointer to const unsigned char Undefined first referenced symbol in file fdatasync ./.libs/libsqlite3.so ld: fatal: Symbol referencing errors. No output written to .libs/sqlite3 make: *** [sqlite3] Error 1 _2005-Oct-04 21:42:26 by drh:_ {linebreak} Clear out your build directory (or start a new one) and rerun configure from scratch. Save the output of configure. Then rerun make. If you still have a problem, attach the output of configure to this ticket. #f2dcdc 2517 active 2007 Jul anonymous Pending dflam 1 1 exception on reading text in vista but not xp My companies sqlite 3.1 db works perfectly on Win XP but when we moved to Vista (I'm using Vista 64)it is trowing an exception when I access a text field that contains this data: 'A/C Pressure Sensor, raw1 = A/C on, 0 = A/C off (A/C status determines which IACTx cell is used)' Interestingly when I view data I've inserted using sqliteman3 it has unprintable characters added to it. (A/C status determines which IACTx cell is used)9 If I define the field as Char[512] this artifact goes away. But reading your literature this isn't supposed to make a difference because everything is char. I've changed the values in the error column, but the error seems to be depending on length rather than value. Any help appreciatied! Jim _2007-Jul-19 15:13:41 by drh:_ {linebreak} We will be better able to help you with your problem on the SQLite mailing list. See http://www.sqlite.org/support.html for instructions on joining the mailing list. #e8e8bd 2215 active 2007 Feb anonymous Pending 1 2 error messages in virtual table are not propagated I'm trying to return a customized error message in xBestIndex in my virtual table implementation. Rather than copying my implementation here the problem can be reproduced by changing the fulltextBestIndex method from fts1. For example: /* Decide how to handle an SQL query. */ static int fulltextBestIndex(sqlite3_vtab *pVTab, sqlite3_index_info *pInfo){ int i; TRACE(("FTS1 BestIndex\n")); pVTab->zErrMsg = sqlite3_mprintf ("THIS IS AN ERROR MESSAGE"); return SQLITE_ERROR; for(i=0; i
--- 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)#f2dcdc 1485 active 2005 Oct anonymous Unknown Pending jshen 3 1 cyrilic problem(suppose Unicode as a whole, for PPC) I think there is a problem in the utf.c file. _2005-Oct-14 06:18:45 by anonymous:_ {linebreak} Pocket PC support isn't provided in the default SQLite provider. The code necessary to support the Pocket PC is at http://sourceforge.net/projects/sqlite-wince and its there that a bug report should be filed. #f2dcdc 1158 active 2005 Mar anonymous VDBE Pending 1 1 core dump on solaris, some sqlite functions core dumped on solaris. I tracked this back to a byte alignment problem in Vdbeint.h. I added the __attribute__ ((__aligned__(16))) to the zshort character string.
/* ** A single level of the stack or a single memory cell ** is an instance of the following structure. */ struct Mem { int i; /* Integer value */ int n; /* Number of characters in string value, including '\0' */ int flags; /* Some combination of MEM_Null, MEM_Str, MEM_Dyn, etc. */ double r; /* Real value */ char *z ; /* String value */ char zShort[NBFS] __attribute__ ((__aligned__(16))); /* Space for short strings */ }; typedef struct Mem Mem;_2005-Mar-09 22:06:47 by anonymous:_ {linebreak} I think this is a duplicate of bug #700.... simply adding the attribute seems to reslove the bug... select the sum of an integer column, to reproduce.... sqlite> select sum(seqval) from tbl; Bus Error(coredump) #f2dcdc 1974 active 2006 Sep anonymous Unknown Pending 1 1 column type not consistent in views package require sqlite3 sqlite3 db test.db db eval { create table one ( size FLOAT ); create view two as select size from one; } db eval {insert into one values(50.0)} puts [db eval {select size from one}] puts [db eval {select size from two}] outputs: 50.0 50 #cfe8bd 1058 active 2005 Jan anonymous BTree Pending 3 3 btree.c pageSize -> usableSize Check-in [2125] was a fix for Ticket #1010, but left out some of the fixes proposed in the ticket. I'm not sure whether this was an oversight or an intentional omission. I tried to re-open the ticket, but those edits didn't persist (I'm not sure why). Here are the remaining instances of pageSize that I believe should be changed to usableSize in btree.c: --- sqlite/src/btree.c.ORIG Wed Nov 24 18:54:30 2004 +++ sqlite/src/btree.c Wed Nov 24 20:29:21 2004 @@ -220,13 +220,13 @@ /* The following value is the maximum cell size assuming a maximum page ** size give above. */ -#define MX_CELL_SIZE(pBt) (pBt->pageSize-8) +#define MX_CELL_SIZE(pBt) (pBt->usableSize-8) /* The maximum number of cells on a single page of the database. This ** assumes a minimum cell size of 3 bytes. Such small cells will be ** exceedingly rare, but they are possible. */ -#define MX_CELL(pBt) ((pBt->pageSize-8)/3) +#define MX_CELL(pBt) ((pBt->usableSize-8)/3) /* Forward declarations */ typedef struct MemPage MemPage; @@ -1745,7 +1745,7 @@ Pgno finSize; /* Pages in the database file after truncation */ int rc; /* Return code */ u8 eType; - int pgsz = pBt->pageSize; /* Page size for this database */ + int pgsz = pBt->usableSize;/* Usable bytes on each page */ Pgno iDbPage; /* The database page to move */ MemPage *pDbMemPage = 0; /* "" */ Pgno iPtrPage; /* The page that contains a pointer to iDbPage */ #f2dcdc 2664 active 2007 Sep danielk1977 Pending 1 1 attaching the same db twice in shared-cache mode fails The following SQL script can cause an assert() to fail in shared-cache mode. ATTACH 'db' AS aux1; ATTACH 'db' AS aux2; CREATE TABLE aux1.abc(a, b, c); CREATE TABLE aux2.abc(a, b, c); See also #2653 #cfe8bd 1264 active 2005 May anonymous Unknown Pending 3 3 access() undefined on MSVC shell.c(1705) : warning C4013: 'access' undefined; assuming extern returning int Add this: #if defined(_WIN32) && defined(_MSC_VER) # include
+#ifndef SQLITE_DONT_DEFINE_XOPEN_SOURCE #if !defined(_XOPEN_SOURCE) && !defined(__DARWIN__) && SQLITE_THREADSAFE # define _XOPEN_SOURCE 500 /* Needed to enable pthread recursive mutexes */ #endif +#endif_2007-Dec-01 09:23:15 by anonymous:_ {linebreak} Also when using Python, it sets _XOPEN_SOURCE to 600. No idea what the 500 vs 600 difference is about. ---- _2007-Dec-01 15:58:28 by anonymous:_ {linebreak} I've used a couple of different Linux OSes and _XOPEN_SOURCE is not needed. Maybe it's for OSes more than 5 years old. Recursive mutexes are pretty much standard these days since the popularity of Java which uses them extensively. ---- _2007-Dec-01 17:21:05 by drh:_ {linebreak} See also tickets #2673, #2681, and #2741. ---- _2007-Dec-02 02:08:26 by anonymous:_ {linebreak} On Linux, PTHREAD_MUTEX_RECURSIVE is the same as PTHREAD_MUTEX_RECURSIVE_NP: PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP, Since PTHREAD_MUTEX_RECURSIVE_NP is always available, you could avoid defining _XOPEN_SOURCE and use this code instead:
- pthread_mutexattr_settype(&recursiveAttr, PTHREAD_MUTEX_RECURSIVE); + pthread_mutexattr_settype(&recursiveAttr, +#ifdef linux + PTHREAD_MUTEX_RECURSIVE_NP +#else + PTHREAD_MUTEX_RECURSIVE +#endif + );---- _2007-Dec-02 02:17:22 by anonymous:_ {linebreak} A quick google search reveals how various projects deal with this recursive mutex declaration problem (in no particular order): *: #define _XOPEN_SOURCE 500 and use PTHREAD_MUTEX_RECURSIVE *: #define _XOPEN_SOURCE 600 and use PTHREAD_MUTEX_RECURSIVE *: #define _GNU_SOURCE and use PTHREAD_MUTEX_RECURSIVE *: don't define anything and use PTHREAD_MUTEX_RECURSIVE_NP on linux, and PTHREAD_MUTEX_RECURSIVE elsewhere. Unfortunately, since PTHREAD_MUTEX_RECURSIVE is an enum on Linux, so you can't use the #ifdef PTHREAD_MUTEX_RECURSIVE compile-time technique. #f2dcdc 1882 active 2006 Jul anonymous Pending 1 1 Wrong algorithm of SQLITE_VERSION_NUMBER calculation The sqlite3.h comment describing how numeric version number is calculated is as follows: "The SQLITE_VERSION_NUMBER is an integer with the value (X*100000 + Y*1000 + Z). For example, for version "3.1.1beta", SQLITE_VERSION_NUMBER is set to 3001001." But the value of SQLITE_VERSION_NUMBER is greater than the equation above suggests. The value X*100000 should be changed to X*1000000 (one milion). #f2dcdc 2322 active 2007 Apr anonymous Pending 1 1 Windows error: datetime('2000-10-29 06:00:00','localtime') NY time zone. Windows (from http://sqlite.org/sqlite-3_3_17.zip) SELECT coalesce(datetime('2000-10-29 06:00:00','localtime'),'NULL'); 2000-10-29 02:00:00 Linux (from latest CVS, same TZ) SELECT coalesce(datetime('2000-10-29 06:00:00','localtime'),'NULL'); 2000-10-29 01:00:00 make test errors on Windows only: date-6.2... Expected: [{2000-10-29 01:00:00}] Got: [{2000-10-29 02:00:00}] date-6.3... Expected: [{2000-04-02 01:59:00}] Got: [{2000-04-02 02:59:00}] date-6.6... Expected: [{2000-10-29 07:00:00}] Got: [{2000-10-29 06:00:00}] date-6.7... Expected: [{2000-04-02 06:59:00}] Got: [{2000-04-02 05:59:00}] _2007-Apr-26 23:09:12 by anonymous:_ {linebreak} Confirmed Windows bug on Windows 2000 in NY time zone with Y2K7DST OS patch. ---- _2007-Apr-27 22:03:25 by drh:_ {linebreak} Do I correctly understand the previous remark to say that this is confirmed to be a bug in Windows, not a bug in SQLite? It is identical code in SQLite for both operating systems, so I would certainly suspect that the problem is in windows and not in SQLite. But it would be nice to have confirmation of this before closing the ticket. ---- _2007-Apr-28 03:19:06 by anonymous:_ {linebreak} I meant to write "This erroneous SQLite datetime() output can also be seen on my Windows 2000 machine." Does it work correctly for you under Windows XP or 2000 with the DST patch? OS bug or not, it would be strange to not have the datetime() function correctly on a primary platform. If that were the case, it would be better to #ifdef it out of the Windows compile altogether. ---- _2007-Apr-28 03:59:27 by anonymous:_ {linebreak} This is a bigger mess than I thought. http://groups.google.com/group/perl.perl5.porters/msg/e632557614474014?hl=en& Key phrase: "This API only provides the transition times according to the *current* DST rules. There is no database of historical transition times. That means that localtime() applied to previous years will use the new transition times even for old timestamps." Please don't close this bug. Perhaps some industrious Windows programmer will have a correct solution for it one day. But in the meantime, Windows SQLite users should be aware of it. #e8e8bd 2539 active 2007 Jul anonymous Pending 2 2 WinCE: Temporary etilqs_ files are not removed from temporary folder Hi, when temporary etilqs_* files are created during SQLite work on Windows CE devices, they are not removed at all. Temporary folder at CE devices: /Application Data/Volatile I've research that it winClose(os_win.c) function has been changed at do not remove this file, assuming it to be removed at winceDestroyLock(os_win.c), so if no lock was happened then files will stay here forever. Has fixed it in my local copy, with hope that it will be fixed when new cool versions of SQLite will be available. My fix at os_win.c:
static int winClose(OsFile **pId){ winFile *pFile; int rc = 1; if( pId && (pFile = (winFile*)*pId)!=0 ){ int rc, cnt = 0; OSTRACE2("CLOSE %d\n", pFile->h); do{ rc = CloseHandle(pFile->h); }while( rc==0 && cnt++ < MX_CLOSE_ATTEMPT && (Sleep(100), 1) ); #if OS_WINCE winceDestroyLock(pFile); // fix begin if( pFile->zDeleteOnClose ){ DeleteFileW(pFile->zDeleteOnClose); sqliteFree(pFile->zDeleteOnClose); } // fix end #endif OpenCounter(-1); sqliteFree(pFile); *pId = 0; } return rc ? SQLITE_OK : SQLITE_IOERR; }Thanks, Fedor _2007-Jul-28 16:41:41 by anonymous:_ {linebreak} The solution is to revert checkin 3836 and re-open ticket #2294.
Looking at the wince locking mechanism, the only time we ever use the zDeleteOnClose flag is when we've opened a database for exclusive access in sqlite3WinOpenExclusive. To save time and resources (and because its not necessary) we never bother creating a locking mechanism for exclusively-opened files. So pFile->hMutex is NULL when hitting winceDestroyLock(), and the file is never deleted.
Is it possible that the original poster of #2294 was trying to close the same connection on multiple threads at the same time? ---- _2007-Jul-31 05:32:39 by anonymous:_ {linebreak} This is actually a duplicate of #2533 ---- _2007-Sep-21 14:20:05 by anonymous:_ {linebreak} So when the fix of [3836] was applied, the code to delete the file was only put in the section that is called when we have a mutex. I wonder, if the deletion of the file should also take place if there was no mutex. Works for me at least: static void winceDestroyLock(winFile *pFile){ if (pFile->hMutex){ /* Acquire the mutex */ winceMutexAcquire(pFile->hMutex); /* The following blocks should probably assert in debug mode, but they are to cleanup in case any locks remained open */ if (pFile->local.nReaders){ pFile->shared->nReaders --; } if (pFile->local.bReserved){ pFile->shared->bReserved = FALSE; } if (pFile->local.bPending){ pFile->shared->bPending = FALSE; } if (pFile->local.bExclusive){ pFile->shared->bExclusive = FALSE; } /* De-reference and close our copy of the shared memory handle */ UnmapViewOfFile(pFile->shared); CloseHandle(pFile->hShared); * if( pFile->zDeleteOnClose ){ * DeleteFileW(pFile->zDeleteOnClose); * sqliteFree(pFile->zDeleteOnClose); * pFile->zDeleteOnClose = 0; * } /* Done with the mutex */ winceMutexRelease(pFile->hMutex); CloseHandle(pFile->hMutex); pFile->hMutex = NULL; } + else + { + if( pFile->zDeleteOnClose ){ + DeleteFileW(pFile->zDeleteOnClose); + sqliteFree(pFile->zDeleteOnClose); + pFile->zDeleteOnClose = 0; + } + } } The code marked with * was put there in #f2dcdc 2479 active 2007 Jun anonymous Pending 1 1 WinCE regression on some systems. Any db open fails. Because Windows CE is a modular system, meaning many parts of it can be optionally ommited by the system builder, some don't include the CP_UTF8 conversion algorithms for MultiByteToWideChar and family. I believe Windows 95 and early 98 systems can also lack this encoding if not updated with a later Internet Explorer version. Solution is to just use the sqlite internal functions that already know how to do the same thing. Attached is an untested patch to os_win.c (I don't have a windows machine nor a cross-compiler set up) to show where the problem is and a possible (sub-optimal) solution. I believe the right thing to do would be to just drop the utf8ToUnicode and unicodeToUtf8 functions, add the sqlite3Utf8to16 equivalent to utf.c and use them instead. ~Nuno Lucas _2007-Jun-29 14:54:11 by anonymous:_ {linebreak} The title is wrong. It should say "Any db open using the UTF-8 API", as using the open16 API will work. #cfe8bd 1502 active 2005 Oct anonymous Unknown Pending anonymous 2 3 When selected in a union, view column names are incorrect. When used in a union, a view transfers an underlying table's column names into the result set. The expected result is that column names in the second half (or further) of the union needn't match those in the first. Problem is also visible in TCL binding.
.mode columns .headers on select 'Create two tables, with nasty column names.' as remark; create table t_a (c_a integer); create table t_b (c_a integer); select 'Create two views which each alias the column names of the above tables.' as remark; create view v_a as select c_a as pretty from t_a; create view v_b as select c_a as pretty from t_b; select 'Insert some data' as remark; insert into t_a values (1); insert into t_b values (2); select 'Notice that the views work fine by themselves.' as remark; select 'The column names are both as we asked.' as remark; select pretty from v_a; select pretty from v_b; select 'Notice that used in concert, with a join, the column name is now wrong.' as remark; select pretty from v_a union select pretty from v_b; select 'Aliasing the name of the column in the first half of the join is no help.' as remark; select pretty as pretty from v_a union select pretty from v_b; select 'Alias the name of the column in the second half of the join "fixes" the result.' as remark; select pretty from v_a union select pretty as pretty from v_b;_2005-Oct-25 03:05:27 by anonymous:_ {linebreak} same as ticket 1228 ---- _2005-Oct-26 07:59:17 by anonymous:_ {linebreak} see also #1327 #cfe8bd 2127 active 2006 Dec anonymous Pending 2 3 Virtual tables do not always free zErrmsg The documentation for virtual tables and in particular the sqlite3_vtab structure says "The SQLite core will free and zero the content of zErrMsg when it delivers the error message text to the client application or when it destroys the virtual table." The latter part does not appear to be true ("when it destroys the virtual table"). I can't find any code that does actually that. (eg vtab.c:496 definitely doesn't, nor does vtab.c:76) Usually the former case happens. However some operations have their error codes ignored (eg xClose). This can result in the zErrMsg pointing to a message but no error code returned upstream (which would clear the message). Finally as far as I can tell the responsibility for freeing sqlite3_vtab is with the xDisconnect/xDestroy callbacks since the corresponding xCreate/xConnect callbacks allocated it. Consequently there is no way for SQLite to even access zErrmsg since it would be a member of a freed structure after xDisconnect/xDestroy returned. #e8e8bd 1754 active 2006 Apr anonymous Pager Pending anonymous 2 2 Version 3.3.5 error if SQLITE_OMIT_MEMORYDB is defined My solution is to move the following code to de line the the syncJournal is "forwarded" at line 1809.
#ifndef SQLITE_OMIT_MEMORYDB /* ** Clear a PgHistory block */ static void clearHistory(PgHistory *pHist){ sqliteFree(pHist->pOrig); sqliteFree(pHist->pStmt); pHist->pOrig = 0; pHist->pStmt = 0; } #else #define clearHistory(x) #endif#f2dcdc 2510 active 2007 Jul anonymous Pending 1 1 Vacuum modified FTS2 rowids VACUUM modifies FTS2 rowids. Here is the test: drop table if exists a; create virtual table a using fts2 (t); insert into a (t) values ('one'); insert into a (t) values ('two'); insert into a (t) values ('three'); select rowid, * from a; delete from a where t = 'two'; vacuum; select rowid, * from a; Unfortunately there is no workaround since table a is auto-generated by the FTS2 module. _2007-Jul-17 14:05:58 by anonymous:_ {linebreak} http://www.sqlite.org/cvstrac/chngview?cn=4157 ---- _2007-Jul-17 14:24:29 by anonymous:_ {linebreak} Yes, this behavior has been recently documented, but there is no user workaround like PRIMARY KEY for FTS2 rowids. Therefore I consider this as a bug which should be fixed in fts2.c. ---- _2007-Jul-17 14:55:57 by anonymous:_ {linebreak} Should virtual tables be VACUUMable? What exactly is being vacuumed here - an internal table? ---- _2007-Jul-17 16:34:55 by shess:_ {linebreak} I agree, I think this is a bug. Rather severe, too, the entire fts system implicitely depends on rowids not changing, this means that vacuum will break fts tables (fts1 or fts2).
drop table if exists t; create virtual table t using fts2; insert into t (content) values ('This is a test'); insert into t (content) values ('This is a string'); insert into t (content) values ('That was a test'); insert into t (content) values ('A random string'); select content from t where t MATCH 'test'; delete from t where content = 'This is a string'; vacuum; select content from t where t MATCH 'test';The first select outputs 'This is a test' and 'That was a test'. The second select outputs 'This is a test', and 'A random string'. ---- _2007-Jul-17 17:27:21 by anonymous:_ {linebreak} This patch seems to address the FTS2 VACUUM problem and passes all fts2 tests. It adds an INTEGER PRIMARY KEY docid column to the hidden %_content table. Note: this new table format is not backwards compatible with existing FTS2 databases. -Joe Wilson
Index: ext/fts2/fts2.c =================================================================== RCS file: /sqlite/sqlite/ext/fts2/fts2.c,v retrieving revision 1.40 diff -u -3 -p -r1.40 fts2.c --- ext/fts2/fts2.c 2 Jul 2007 10:16:50 -0000 1.40 +++ ext/fts2/fts2.c 17 Jul 2007 17:19:49 -0000 @@ -1769,9 +1769,9 @@ typedef enum fulltext_statement { */ static const char *const fulltext_zStatement[MAX_STMT] = { /* CONTENT_INSERT */ NULL, /* generated in contentInsertStatement() */ - /* CONTENT_SELECT */ "select * from %_content where rowid = ?", + /* CONTENT_SELECT */ "select * from %_content where docid = ?", /* CONTENT_UPDATE */ NULL, /* generated in contentUpdateStatement() */ - /* CONTENT_DELETE */ "delete from %_content where rowid = ?", + /* CONTENT_DELETE */ "delete from %_content where docid = ?", /* BLOCK_INSERT */ "insert into %_segments values (?)", /* BLOCK_SELECT */ "select block from %_segments where rowid = ?", @@ -1860,14 +1860,14 @@ static struct fulltext_vtab *cursor_vtab static const sqlite3_module fts2Module; /* forward declaration */ /* Return a dynamically generated statement of the form - * insert into %_content (rowid, ...) values (?, ...) + * insert into %_content (docid, ...) values (?, ...) */ static const char *contentInsertStatement(fulltext_vtab *v){ StringBuffer sb; int i; initStringBuffer(&sb); - append(&sb, "insert into %_content (rowid, "); + append(&sb, "insert into %_content (docid, "); appendList(&sb, v->nColumn, v->azContentColumn); append(&sb, ") values (?"); for(i=0; i---- _2007-Jul-18 00:13:56 by shess:_ {linebreak} BTW, AFAICT this only happens for sqlite3.4. Older versions don't seem to have the problem. ---- _2007-Jul-18 01:31:49 by anonymous:_ {linebreak} The rowid changing after VACUUM predates 3.4.0...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 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 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---- _2007-Jul-18 15:59:24 by anonymous:_ {linebreak} As you may know, INTEGER PRIMARY KEY indexes are the ROWID, so I must supect they would change after a VACUUM. The best workaround is to put docid as INTEGER, then adding a PRIMARY KEY index for the docid column. #f2dcdc 1149 active 2005 Feb anonymous Pending 2 1 VACUUM, DUMP/RESTORE fail in certain cases When a database has interacting views, such as the following:
CREATE VIEW test1 AS SELECT * FROM tableA; CREATE VIEW test AS SELECT COUNT(*) FROM test1;then a dump and restore fails, because the views will be created in the alphabetical order of the table names, rather than the order of their dependence. Thus, the create of table test will fail. Because the script otherwise runs to completion, the restore will usually be adequate except that the views are not recreated. VACUUM appears to fail the same way, probably for the same reason. In this case, however, the VACUUM fails without clearly alerting the user. I ran into this problem trying to VACUUM a large file, which produced the otherwise inexplicable error message about the syntax of a dependent view definition. Users can workaround, once the problem is understood, either by renaming views so that their names have alphabetical sequence consistent with their dependency, or by dropping them prior to a vacuum or dump/restore and then recreating them later. Of course, the view order can be repaired in the dump file, but this usually requires patience with a powerful text editor, and some capacity to understand the problem. #cfe8bd 2879 active 2008 Jan anonymous Pending anonymous 4 3 VACUUM enters temporary sequence numbers in sqlite_sequence I have two TEMPORARY tables added to a database, that both contain an INTEGER PRIMARY KEY AUTOINCREMENT field. After issuing a VACUUM command, the maximum value of these fields is added to the sqlite_sequence table. And stay there after the connection closes. #f2dcdc 2126 active 2006 Dec anonymous Pending 3 1 Update hook not invoked when deleteing all rows from table I was testing the update hook feature of SQLite and incidentally I noticed that hook is not invoked for "DELETE FROM" statement with no WHERE clause. Hook works well for "DELETE FROM ... WHERE ..." statement. Steps to reproduce: 1: Open database, setup update hook 2: Execute:{linebreak}CREATE TABLE Test(Test INTEGER); 3: Insert some data:{linebreak}INSERT INTO TEST (Test) VALUES (1); -- update hook invoked for INSERT{linebreak}INSERT INTO TEST (Test) VALUES (2); -- update hook invoked for INSERT{linebreak}INSERT INTO TEST (Test) VALUES (3); -- update hook invoked for INSERT 4: Execute:{linebreak}DELETE FROM TEST; -- update hook IS NOT INVOKED(!) for each row. _2006-Dec-22 15:38:44 by drh:_ {linebreak} Triggers don't work either. This is a feature not a bug. When you do "DELETE FROM table" with no WHERE clause, SQLite drops and recreates the table. Doing it this way have a huge speed boost. If you really need the update hook to work add a "WHERE 1" to the end of the query. ---- _2006-Dec-22 16:11:11 by anonymous:_ {linebreak} I don't really need it, maybe other users. You should update the documentation of _sqlite3_update_hook()_ and _triggers_ mentioning this behaviour. Another solution is to perform "DELETE FROM" as if it was with WHERE clause, if there is an update hook regitered. #f2dcdc 1941 active 2006 Aug anonymous Pending 1 1 Unrevolved _sqlite3ExprCodeAndCache with SQLITE_OMIT_TRIGGER If =SQLITE_OMIT_TRIGGER= is set, linker complains about an unresolved =_sqlite3ExprCodeAndCache= symbol. =sqlite3ExprCodeAndCache= is defined in =expr.c= and wrapped with =#ifndef SQLITE_OMIT_TRIGGER=. However, references in insert.c, line 536 update.c, line 348 and 362 are not wrapped with #ifndef =SQLITE_OMIT_TRIGGER=. I followed the suggestion quoted below (posted earlier to this list) without avail. Is it safe (or even required?) to change sqliteInt.h to #ifndef SQLITE_OMIT_TRIGGER void sqlite3ExprCodeAndCache(Parse*, Expr*); #else # define sqlite3ExprCodeAndCache(A,B) #endif In the mailing list, DRH argued that the above change will probably fail and suggested that a safer fix would be to remove the #ifndef SQLITE_OMIT_TRIGGER from around the sqlite3ExprCodeAndCache function. _2006-Oct-12 17:35:32 by anonymous:_ {linebreak} The problem is still present in 3.3.8. Removing the #ifndef SQLITE_OMIT_TRIGGER from around the sqlite3ExprCodeAndCache function seems to fix it. Could you commit this? #f2dcdc 2810 active 2007 Nov anonymous Pending 1 1 Unregistered collation problems with simple subselects As discussed on the mailing-list: Imagine that a SQLite3 database opened in a custom application with a registered a collation sequence named "unknown" has created the following table: CREATE TABLE a (b COLLATE unknown); Now open this table in the default SQLite3 CLI. Up to here, everything works as expected. Simple queries like "SELECT * FROM a;" work fine. But subselects, in their most basic form and with no sorting or comparisons, result in an error: sqlite> INSERT INTO a VALUES ('one'); sqlite> SELECT * FROM a, (SELECT * FROM a); SQL error: no such collation sequence: unknown sqlite> SELECT * FROM (SELECT * FROM a); SQL error: no such collation sequence: unknown sqlite> SELECT *, * FROM a; one|one This is surprising because the collation sequence should not matter to the queries. In fact, the union without the subselect works just fine and without errors. To demonstrate, here is the explain output of a table with a registered collation sequence. No mention of the collation name here: sqlite> CREATE TABLE b (b collate nocase); sqlite> EXPLAIN SELECT * FROM b, (SELECT * FROM b); 0|Goto|0|17| 1|Integer|0|0| 2|OpenRead|0|3| 3|SetNumColumns|0|1| 4|Integer|0|0| 5|OpenRead|2|3| 6|SetNumColumns|2|1| 7|Rewind|0|14| 8|Rewind|2|13| 9|Column|0|0| 10|Column|2|0| 11|Callback|2|0| 12|Next|2|9| 13|Next|0|8| 14|Close|0|0| 15|Close|2|0| 16|Halt|0|0| 17|Transaction|0|0| 18|VerifyCookie|0|4| 19|TableLock|0|3|b 20|Goto|0|1| 21|Noop|0|0| #cfe8bd 1733 active 2006 Mar anonymous VDBE Pending drh 4 3 Unaligned Access on ia64: aggregate_context ptr isn't 16-bytes aligned There is a problem on ia64 with pointer returned by sqlite3_aggregate_context function. If the size requested is less than NBFS bytes, then the pointer returned is 8 bytes aligned while every pointer returned by allocator function must be 16-bytes aligned (the specification requires that the pointer is aligned so that every basic typed can be stored there and long double is 16 bytes on Itanium). So if a user allocates, say, 24 bytes for his context, and the first member in his context happens to be a long double, he will get unaligned access exception. This will lead to performance hit on Linux and to crash on HP-UX, since no default SIGBUS handler is present on HP-UX (IIRC). _2006-Mar-27 10:37:37 by anonymous:_ {linebreak} Additional details can be found in this mailing list thread: http://thread.gmane.org/gmane.comp.db.sqlite.general/18144 #cfe8bd 2530 active 2007 Jul anonymous Pending 2 3 Unable to write to windows share, even with exclusive lock It has been mentioned that the file locking does not work on windows shared network drives (Samba or SMB drives from Windows or Linux). It seems that an exclusive lock should be a workaround for this problem if you need to write to a shared drive. Currently a more complicated locking is being attempted and failing on network drives. With an exclusive lock, SQLite could resort to simply holding a open write or append enabled file handle to the database as a more primitive locking system that is more likely to work on network drive. No other process could open the database but that would be expected with an exclusive lock. The following case should then function: grudy@gamma:~$ mount | grep Files //winserver/FileDump on /mnt/Files type cifs (rw,mand,noexec,nosuid,nodev) grudy@gamma:~$ touch /mnt/Files/i_have_write_permissions.txt; rm /mnt/Files/i_have_write_permissions.txt grudy@gamma:~$ sqlite3 /mnt/Files/foo.sqlite SQLite version 3.3.17 Enter ".help" for instructions sqlite> PRAGMA locking_mode = EXCLUSIVE; exclusive sqlite> create table bar (foobar); SQL error: database is locked sqlite> #f2dcdc 709 active 2004 Apr anonymous Unknown drh 1 1 Unable to unregister or replace functions I believe this started with 2.8.13, as it did work previously. There appears to be a show-stopper with unregistering or replacing existing functions. Specifically, if one tries to replace (or remove by passing nulls) one of the built-in functions, for example "like" or "upper", the function does not get replaced, and is in fact still called and available. The odd thing is that if you try to replace one of the functions with an underscore, such as "change_count", it works fine! This is causing problems as we replace a lot of the existing functions, and allow users to add and replace their own functions, which are now failing. _2004-Apr-26 20:56:19 by anonymous:_ {linebreak} Alright, turns out this is due to mismatch in argument count when unregistering functions. It would be useful if we could unregister all instances of a function name, irregardless of argument counts. ---- _2004-Apr-26 23:11:43 by anonymous:_ {linebreak} Turns out there really is a bug... the problem is in the sqliteFindFunction function's matching of inexact argument counts, when being called from sqliteExprCheck with >0 argument count. This is the scenario. I override the "upper" function with my own, but first removing the old "upper", specifying 1 argument and null for the function. I then register a new "upper" with -1 for the argument count, and a valid function. When sqliteFindFunction attempts to locate the upper function, It locates the new function, but because it is registered with -1, it tries to find a better match. It then runs into the original one, and because it has a null function pointer, it fails. This causes sqliteExprCheck to try again with -1 as the count, and since that matches, it reports an error of wrong_num_args. Unfortunately this means there is no way to override an existing method (it would be good if we could just delete them, rather than override them, although I still think this behaviour with -1 is wrong). ---- _2004-Apr-26 23:29:23 by anonymous:_ {linebreak} I've applied the following patch in the sqliteFindFunction function, that I believe addresses the problem:
/* Change this if( p && !createFlag && p->xFunc==0 && p->xStep==0 ){ return 0; } */ /* To this */ if( p && !createFlag && p->xFunc==0 && p->xStep==0 ){ return pMaybe;By returning pMaybe we provide a function that will work, while returning 0 if no variable argument function was found. #f2dcdc 798 active 2004 Jul anonymous Unknown 1 1 Unable to run tests on Tru64 bit Linux platform I was able to compile SQLite 3.0.2 on a RedHat 64-bit Linux system; however, when running the tests I would get a segmentation fault when executing a blob test. I was wondering if anyone has attempted to build SQLite for a 64-bit architecture and run all tests successfully. If so I was hoping to get any configuration parameters needed. #f2dcdc 1351 active 2005 Aug anonymous Shell Pending 1 1 Unable to parse UTF8 input I'm in the process of writing a program which parses in UTF8 data, and then processes it and writes a UTF8 output into a text file. This textfile needs to be imported into SQLite. However the commandline SQLite program doesnt support UTF8 input text files for its ".read" command. Considaring the database itself supports UTF8, would it be possible to allow UTF8 text file input. I can't progress much further on my program if this can't be fixed. _2005-Aug-08 13:56:24 by drh:_ {linebreak} Please attach an example UTF-8 script that ".read" is not reading correctly. ---- _2005-Aug-08 17:58:44 by anonymous:_ {linebreak} I can't seem to attach a text file, so instead i'll put it on my FTP, and it should be accessible from there. If you have trouble with that, i could email the text file. So if you have trouble, give me an email to send it to. There will be a sample of a text file that won't ".read" available here: ftp://62.231.38.73/ in approximately 10 minutes. Thanks for the fast reply. I'd be surprised if it was a problem with my text file generation, but stranger things have happened :p ---- _2005-Aug-11 01:40:08 by drh:_ {linebreak} Attach files using the [Attach] hyperlink at the top-right of this page. Please do not send RAR files since that is an obscure archive format. If you want to use a compressed archive, make it either ZIP or GZIP. ---- _2005-Aug-11 09:46:23 by anonymous:_ {linebreak} I can only attach one because neither winzip or gzip are great at compressing text files. The files keep ending up over 100kb except for the artists.txt file. Thats the only one that went below 100kb. I'm unwilling to try editing the file to remove lines of text from it because i want you to have the exact output that i'm getting from my program. Not the output that i'd get from notepad if i edited it. That will help identify whether it is a problem in my program, or a problem with SQLite. Its always possible its a proglem with my source data, and its not actually proper UTF8, but i doubt that as SQLite doesn't seem to read the normal text correctly (such as the first line which is supposed to start a transaction, but SQLite instead ignores the line, and throws an error when it reachs the commit; at the end. #f2dcdc 2414 active 2007 Jun anonymous Unable_to_fix 1 1 Unable t I designed a tool in C# using the Sqlite.Net.dll and sqlite3.dll v 3.2.5. The call to sqlite3_step after the sqlite3_prepare function, causes a huge delay to return (~7MINS), sometimes it doesn't return at all. This happens when I'm using v3.2.5 but when I replace it with v 3.3.7, everything works normal. I have tried so many combination of things to get it to work on v3.2.5 (this is the version of the libraries the hardware uses), which includes setting the PRAGMA legacy_file_format to 1, but after every save it reverts back to 0. i will appreciate if I can get a response with any suggestions. Thanks in advance. _2007-Jun-13 15:58:00 by anonymous:_ {linebreak} Please post the schema and the SELECT command that is slow under 3.2.5 and is fast under 3.3.7 so it can be reproduced using the sqlite3 commandline shell. #f2dcdc 1851 active 2006 Jun anonymous Unknown Pending 2 1 USE "ORDER BY" error on uClinux when I use "ORDER BY" function in a "select" on uClinux 2.4.24, I get a error:"SQL error or missing database" but the same program run on windows or Linux OK. _2006-Jun-16 11:20:15 by drh:_ {linebreak} This is certainly a strange error. Combined with #1850, it suggests a problem with your build, not a problem in SQLite. I have no ability to use or run uCLinux. So if the error cannot be reproduced on a desktop system, there is not much I can do to address the problem. I am afraid you are on your own on this one. ---- _2006-Jun-19 03:12:31 by anonymous:_ {linebreak} I'm just wondering that SQLite 3.2.8 runs on this uClinux system OK but SQLite 3.3.5 is error. #cfe8bd 1327 active 2005 Jul ghaering VDBE Pending 2 3 UNION causes sqlite3_column_decltype to always return NULL create table test(foo bar); select foo from test union select foo from test; Normally, sqlite3_column_decltype() will return 'bar', but with the UNION, it will always return NULL. This is quite annoying for pysqlite users, because it renders the type detection useless for UNION queries (and EXCEPT and INTERSECT). #cfe8bd 2010 active 2006 Oct anonymous Fixed_in_3.0 3 3 Timeout ignored in Shared-Cache locking model With shared cache enabled, the busy timeout seems to be ignored. SQLITE_BUSY comes immediately. This occurs at least for locking situations within one shared cache. My server (if i may call the cache sharing thread that way) has its own timeout handling. But I thought that a small timeout in sqlite3 might help to distinguish locks from deadlocks. This was reproduced with both Python wrappers. These just call sqlite3_enable_shared_cache and sqlite3_busy_timeout and then execute BEGIN IMMEDIATE from two connections. _2006-Oct-06 13:56:21 by anonymous:_ {linebreak} Weird, I thought it's my fault, but I see exactly the same behaviour with the C# ADO.NET 2.0 wrapper w/ the shared cache patch. #f2dcdc 1541 active 2005 Nov anonymous Unknown Pending 1 1 Ticket #924 not fixed in the 2.8 branch Ticket 924: http://www.sqlite.org/cvstrac/tktview?tn=924 This problem seams to have been fixed on the 3.2 branch but is still in the 2.8.16 #e8e8bd 369 active 2003 Jun anonymous 3 2 Testsuite fails on btree-1.1.1 (Mac OS X, SQLite 2.8.4) On Mac OS X the testsuite fails: btree-1.1.1..../src/btree.c:2687: failed assertion `pPage->isInit' make: *** [test] Abort trap SQLite version: 2.8.4, OS Version: 10.2.6 Obtained same result. Mac OS X 10.2.6, Developer Tools Dec 2002, SQLite 2.8.5. ---- Shared libraries are busted on Macs. As far as I can tell, this appears to be Apple's fault. Until a workaround is devised, do not attempt to compile using shared libraries. Add the --disable-shared option to the configure script: ../sqlite/configure --disable-shared ---- On 2.8.5+, this shows up on 2689. Also, configure does not allow the use of --disable-shared (probably requries a fix in the configure scripts). On a G5 in 10.3.2, this error shows up as a Bus Error. Builds work fine otherwise. This issue may be related to the warnings received in src/test1.c thru src/test4.c and in src/tclsqlite.c regarding Tcl_SetVar, Tcl_GetInt, Tcl_GetBoolean, Tcl_GetIndexFromObj. All warnings are regarding promotion of arguments to pointers of invalid type. oso2k/Louis ---- _2004-Feb-11 22:57:17 by anonymous:_ {linebreak} I did some quick testing of 2.8.12 on the machines I have available to me. In general, there seems to be more warnings than I remember (I believe I was testing 2.8.9 from cvs before it went live).{linebreak} {linebreak} *:G3 700MHz/640MB iBook 10.2.8{linebreak} Same results as we last spoke. Fails make test at:{linebreak} btree-1.1.1{linebreak} {linebreak} *:Dual G4 800MHz/1.25GB 10.2.8{linebreak} Same results as we last spoke. Fails make test at:{linebreak} btree-1.1.1{linebreak} {linebreak} *:G5 1.6GHz/1.25GB 10.3.2{linebreak} 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. #f2dcdc 2350 active 2007 May anonymous Pending 1 1 Temp files not deleted on WinCE When using SQLite 3.3.17 on WinCE device temp files end up being accumulated in Temp directory, eventually filling up device's open file quota (999?) and making further operation that requires creation of files impossible. I have noticed that after a while all queries start failing on the device although if I copied the database to PC and tried the same query I had no problems with it. Started tracing through the code and noticed that =sqlite3WinOpenExclusive()= is consistently failing to create a file (=CreateFileW()= would always fail). It turned out that Temp directory was full of 0 length temp files -- after deleting all of them device started working again for a while. Then started looking for the cause -- =winceDestroyLock()= never gets to execute =DeleteFileW()= and delete the file even though =pFile->zDeleteOnClose= is set because check on the top of the =winceDestroyLock()= function (=if (pFile->hMutex)=) always fails thanks to =pFile->hMutex= being 0. =sqlite3WinOpenReadWrite()= calls =winceCreateLock()= on temporary file (=zFilename=) but =sqlite3WinOpenExclusive()= doesn't hence =winceDestroyLock()= cannot delete temporary file. =sqlite3PagerClose()= contains this piece of commented out code: /* Temp files are automatically deleted by the OS ** if( pPager->tempFile ){ ** sqlite3OsDelete(pPager->zFilename); ** } */ Comment is not true for WinCE as WinCE doesn't support =FILE_ATTRIBUTE_TEMPORARY= and =FILE_FLAG_DELETE_ON_CLOSE= flags. Perhaps it should be surrounded with =#if OS_WINCE/#endif= instead of being commented out? ---- _2007-May-14 00:09:20 by anonymous:_ {linebreak} Tried re-enabling that piece of code in =sqlite3PagerClose()= and it doesn't help. Looks like even file handles for temporary files never get closed on WinCE so not only number of temporary file in =Temp= directory just keeps growing but also filed descriptor for each of them remains open, draining system resources (consistent with observed behavior of rapid and nasty system performance deterioration). It appears that =sqlite3VdbeFreeCursor()= always exits immediately because =pCx= is always =NULL= and thus =sqlite3BtreeClose()= never gets called: void sqlite3VdbeFreeCursor(Vdbe *p, Cursor *pCx){ if( pCx==0 ){ return; } if( pCx->pCursor ){ sqlite3BtreeCloseCursor(pCx->pCursor); } if( pCx->pBt ){ sqlite3BtreeClose(pCx->pBt); } =sqlite3BtreeClose()= then calls =sqlite3PagerClose()= which probably explains why re-enabling that code doesn't help -- =sqlite3PagerClose()= itself never gets called. ---- _2007-May-14 05:16:59 by anonymous:_ {linebreak} Did some comparison between operation of the SQLite on WinXP and WinCE. Comment in previous remark about =sqlite3VdbeFreeCursor()= always exiting immediately because =pCx= is always =NULL= is not correct. =pCX= is =NULL= most of the time but this is true for both WinXP and WinCE. WinXP has no problems getting rid of its temp files thanks to its support for =FILE_ATTRIBUTE_TEMPORARY= and =FILE_FLAG_DELETE_ON_CLOSE= flags. WinCE also does get its temp file descriptors closed (previous statement incorrect on that account too), it's just that its temp files do not get cleaned up automatically. Initial statement that this was caused because of =winceDestroyLock()= actually is correct. Temp files are opened with =sqlite3WinOpenExclusive()= which DOESN'T use mutex (instead of with =sqlite3WinOpenReadWrite()= which DOES use mutex) so part of =winClose()= that was supposed to take care of deleting files after handle is closed (i.e. calling =winceDestroyLock()=) doesn't work: static int winClose(OsFile **pId){ winFile *pFile; int rc = 1; if( pId && (pFile = (winFile*)*pId)!=0 ){ int rc, cnt = 0; OSTRACE2("CLOSE %d\n", pFile->h); do{ rc = CloseHandle(pFile->h); }while( rc==0 && cnt++ < MX_CLOSE_ATTEMPT && (Sleep(100), 1) ); #if OS_WINCE winceDestroyLock(pFile); #endif =OS_WINCE= part should go something like this (although probably not exactly like this as this feels like an ugly hack): #if OS_WINCE if (pFile->hMutex){ winceDestroyLock(pFile); }else{ if( pFile->zDeleteOnClose ){ DeleteFileW(pFile->zDeleteOnClose); sqliteFree(pFile->zDeleteOnClose); pFile->zDeleteOnClose = 0; } } #endif ---- _2007-May-14 05:20:33 by anonymous:_ {linebreak} Tried the code from the previous remark and it does clean up =Temp= directory! I also tried uncommenting that piece of code in =sqlite3PagerClose()= mentioned in the first remark and it looks like that temp files it tries to delete are never there. I'm guessing that that piece of code can remain commented out. Will keep an eye on it -- in case temp files still eventually start accumulating again even after the fix from previous remark is applied I'll reconsider. #f2dcdc 1305 active 2005 Jun anonymous TclLib Pending 1 1 Tcl installs pkgIndex with wrong path Correct script below: # This script attempts to install SQLite3 so that it can be used # by TCL. Invoke this script with single argument which is the # version number of SQLite. Example: # # tclsh tclinstaller.tcl 3.0 # set VERSION [lindex $argv 0] set LIBFILE .libs/libtclsqlite3[info sharedlibextension] if { ![info exists env(DESTDIR)] } { set DESTDIR "" } else { set DESTDIR $env(DESTDIR) } set LIBDIR [lindex $auto_path 0] set LIBNAME [file tail $LIBFILE] set LIB $LIBDIR/sqlite3/$LIBNAME file delete -force $DESTDIR$LIBDIR/sqlite3 file mkdir $DESTDIR$LIBDIR/sqlite3 set fd [open $DESTDIR$LIBDIR/sqlite3/pkgIndex.tcl w] puts $fd "package ifneeded sqlite3 $VERSION \[list load $LIB sqlite3\]" close $fd # We cannot use [file copy] because that will just make a copy of # a symbolic link. We have to open and copy the file for ourselves. # set in [open $LIBFILE] fconfigure $in -translation binary set out [open $DESTDIR$LIB w] fconfigure $out -translation binary puts -nonewline $out [read $in] close $in close $out #f2dcdc 2060 active 2006 Nov anonymous Pending 1 1 Table references enclosed in parenthesis become "invisible" Hi, I'm developing an RDF-based system, which translates queries from SPARQL into SQL. While trying to add support for SQLite (MySQL is already supported) I came across the following problem: when table references in a FROM clause are enclosed in parenthesis, they cannot be referenced from outside the parenthesized expression. For example, given the table definitions CREATE TABLE IF NOT EXISTS t1 (a, b); CREATE TABLE IF NOT EXISTS t2 (c, d); CREATE TABLE IF NOT EXISTS t3 (e, f); The following queries all fail with "no such column" errors: SELECT t1.a, t3.f FROM (t1 CROSS JOIN t2 ON t1.b = t2.c) LEFT JOIN t3 ON t2.d = t3.e; SELECT t1.a, t3.f FROM t1 CROSS JOIN (t2 LEFT JOIN t3 ON t2.d = t3.e) ON t1.b = t2.c; SELECT t1.a, t2.d FROM (t1), (t2) WHERE t1.b = t2.c; I'm not sure if it is always possible to reformulate the queries in such a way that the extra parenthesis aren't necessary, but I suspect that complex expressions involving joins may require them to achieve the intended semantics. In any case, my system would require large changes to be able to get rid of the parenthesized subjoins, so it would be nice if this problem could be fixed. :-) _2006-Nov-10 03:56:46 by anonymous:_ {linebreak} For what it's worth, here's the parse trees of two similar queries ("SELECT t1.a, t2.d FROM t1, t2 WHERE t1.b = t2.c" and "SELECT t1.a, t2.d FROM (t1), (t2) WHERE t1.b = t2.c"), as well as one of the other more complicated join queries previously listed. SELECT t1.a, t2.d FROM t1, t2 WHERE t1.b = t2.c; Select { op: TK_SELECT isResolved: 1 pSrc: { a[0]: { zName: t1 iCursor: 0 colUsed: 0x00000003 pTab: t1 jointype: JT_INNER } a[1]: { zName: t2 iCursor: 1 colUsed: 0x00000003 pTab: t2 } } pEList: { a[0]: { pExpr: { op: TK_COLUMN span: {t1.a} affinity: SQLITE_AFF_NONE iTable: 0 iColumn: 0 pTab: t1 } } a[1]: { pExpr: { op: TK_COLUMN span: {t2.d} affinity: SQLITE_AFF_NONE iTable: 1 iColumn: 1 pTab: t2 } } } pWhere: { op: TK_EQ span: {t1.b = t2.c} pLeft: { op: TK_COLUMN span: {t1.b} affinity: SQLITE_AFF_NONE iTable: 0 iColumn: 1 pTab: t1 } pRight: { op: TK_COLUMN span: {t2.c} affinity: SQLITE_AFF_NONE iTable: 1 iColumn: 0 pTab: t2 } } } SELECT t1.a, t2.d FROM (t1), (t2) WHERE t1.b = t2.c; Select { op: TK_SELECT isResolved: 1 pSrc: { a[0]: { zAlias: sqlite_subquery_5C0A10_ iCursor: 0 pTab: sqlite_subquery_5C0A10_ pSelect: { op: TK_SELECT isResolved: 1 pSrc: { a[0]: { zName: t1 iCursor: 1 colUsed: 0x00000003 pTab: t1 } } pEList: { a[0]: { zName: a pExpr: { op: TK_COLUMN token: {a} span: {a} affinity: SQLITE_AFF_NONE iTable: 1 iColumn: 0 pTab: t1 } } a[1]: { zName: b pExpr: { op: TK_COLUMN token: {b} span: {b} affinity: SQLITE_AFF_NONE iTable: 1 iColumn: 1 pTab: t1 } } } } jointype: JT_INNER } a[1]: { zAlias: sqlite_subquery_5BE4F0_ iCursor: 2 pTab: sqlite_subquery_5BE4F0_ pSelect: { op: TK_SELECT isResolved: 1 pSrc: { a[0]: { zName: t2 iCursor: 3 colUsed: 0x00000003 pTab: t2 } } pEList: { a[0]: { zName: c pExpr: { op: TK_COLUMN token: {c} span: {c} affinity: SQLITE_AFF_NONE iTable: 3 iColumn: 0 pTab: t2 } } a[1]: { zName: d pExpr: { op: TK_COLUMN token: {d} span: {d} affinity: SQLITE_AFF_NONE iTable: 3 iColumn: 1 pTab: t2 } } } } } } pEList: { a[0]: { pExpr: { op: TK_COLUMN span: {t1.a} flags: EP_Resolved EP_Error iTable: -1 iColumn: 0 } } a[1]: { pExpr: { op: TK_DOT span: {t2.d} pLeft: { op: TK_ID token: {t2} span: {t2} } pRight: { op: TK_ID token: {d} span: {d} } } } } pWhere: { op: TK_EQ span: {t1.b = t2.c} pLeft: { op: TK_DOT span: {t1.b} pLeft: { op: TK_ID token: {t1} span: {t1} } pRight: { op: TK_ID token: {b} span: {b} } } pRight: { op: TK_DOT span: {t2.c} pLeft: { op: TK_ID token: {t2} span: {t2} } pRight: { op: TK_ID token: {c} span: {c} } } } } SQL error: no such column: t1.a SELECT t1.a, t3.f FROM (t1 CROSS JOIN t2 ON t1.b = t2.c) LEFT JOIN t3 ON t2.d = t3.e; Select { op: TK_SELECT isResolved: 1 pSrc: { a[0]: { zAlias: sqlite_subquery_5BFA30_ iCursor: 0 pTab: sqlite_subquery_5BFA30_ pSelect: { op: TK_SELECT isResolved: 1 pSrc: { a[0]: { zName: t1 iCursor: 1 colUsed: 0x00000003 pTab: t1 jointype: JT_INNER JT_CROSS } a[1]: { zName: t2 iCursor: 2 colUsed: 0x00000003 pTab: t2 } } pEList: { a[0]: { zName: a pExpr: { op: TK_COLUMN span: {t1.a} affinity: SQLITE_AFF_NONE iTable: 1 iColumn: 0 pTab: t1 } } a[1]: { zName: b pExpr: { op: TK_COLUMN span: {t1.b} affinity: SQLITE_AFF_NONE iTable: 1 iColumn: 1 pTab: t1 } } a[2]: { zName: c pExpr: { op: TK_COLUMN span: {t2.c} affinity: SQLITE_AFF_NONE iTable: 2 iColumn: 0 pTab: t2 } } a[3]: { zName: d pExpr: { op: TK_COLUMN span: {t2.d} affinity: SQLITE_AFF_NONE iTable: 2 iColumn: 1 pTab: t2 } } } pWhere: { op: TK_EQ span: {t1.b = t2.c} flags: EP_FromJoin EP_Resolved iRightJoinTable: 2 pLeft: { op: TK_COLUMN span: {t1.b} affinity: SQLITE_AFF_NONE flags: EP_FromJoin EP_Resolved iTable: 1 iColumn: 1 iRightJoinTable: 2 pTab: t1 } pRight: { op: TK_COLUMN span: {t2.c} affinity: SQLITE_AFF_NONE flags: EP_FromJoin EP_Resolved iTable: 2 iColumn: 0 iRightJoinTable: 2 pTab: t2 } } } jointype: JT_LEFT JT_OUTER } a[1]: { zName: t3 iCursor: 3 pTab: t3 } } pEList: { a[0]: { pExpr: { op: TK_COLUMN span: {t1.a} flags: EP_Resolved EP_Error iTable: -1 iColumn: 0 } } a[1]: { pExpr: { op: TK_DOT span: {t3.f} pLeft: { op: TK_ID token: {t3} span: {t3} } pRight: { op: TK_ID token: {f} span: {f} } } } } pWhere: { op: TK_EQ span: {t2.d = t3.e} flags: EP_FromJoin iRightJoinTable: 3 pLeft: { op: TK_DOT span: {t2.d} flags: EP_FromJoin iRightJoinTable: 3 pLeft: { op: TK_ID token: {t2} span: {t2} flags: EP_FromJoin iRightJoinTable: 3 } pRight: { op: TK_ID token: {d} span: {d} flags: EP_FromJoin iRightJoinTable: 3 } } pRight: { op: TK_DOT span: {t3.e} flags: EP_FromJoin iRightJoinTable: 3 pLeft: { op: TK_ID token: {t3} span: {t3} flags: EP_FromJoin iRightJoinTable: 3 } pRight: { op: TK_ID token: {e} span: {e} flags: EP_FromJoin iRightJoinTable: 3 } } } } SQL error: no such column: t1.a ---- _2006-Nov-11 18:29:33 by anonymous:_ {linebreak} The resolving bug appears to be that unique column names or column aliases are searched across all subqueries, but table names and table aliases are only searched at their current SELECT level only. With this in mind, here are mechanical workarounds without using column aliases (assumes the column names in all joined tables are unique): SELECT a, f FROM (t1 CROSS JOIN t2 ON t1.b = t2.c) LEFT JOIN t3 ON d = e; SELECT t1.a, f FROM t1 CROSS JOIN (t2 LEFT JOIN t3 ON t2.d = t3.e) ON t1.b = c; SELECT a, d FROM (t1), (t2) WHERE b = c; And here are mechanical workarounds using column aliases (assumes the column names are not unique between tables): SELECT t1.a, t3f FROM t1 CROSS JOIN (select t3.f t3f, t2.c t2c from t2 LEFT JOIN t3 ON t2.d = t3.e) ON t1.b = t2c; SELECT t1a, t3.f FROM (select t1.a t1a, t2.d t2d from t1 CROSS JOIN t2 ON t1.b = t2.c) LEFT JOIN t3 ON t2d = t3.e; SELECT t1a, t2d FROM (select t1.a t1a, t1.b t1b from t1), (select t2.c t2c, t2.d t2d from t2) WHERE t1b = t2c; Notice that t3.f in the second query did not require an alias because the table "t3" was part of its immediate SELECT. You could make an alias for every column just in case, I just wanted to highlight the difference. ---- _2007-Feb-13 15:40:31 by anonymous:_ {linebreak} Fixing this issue would slow down SELECT parsing and column resolution for all queries (more specifically all prepared statements) due to the recursion required for column resolution. It would be easier to change your SQL code generator to accomodate SQLite. Just make aliases for every table at every subselect level and have the SELECT at any given level only work with the table aliases at that level. #cfe8bd 1822 active 2006 May anonymous Duplicate 3 3 Table Alias together with Subquery seems not to work proper SELECT * FROM auth AS a LEFT JOIN (SELECT tm.team FROM teammbs AS tm) AS tr ON a.ateam=tr.team; Error message: No such colum tr.team But if I run the sub-query itself, it works fine. Of course, this example can be expressed different, so no subquery required. But the complete expression looks like this: SELECT a.auth, a.avalue FROM auth a LEFT JOIN (SELECT tm.member, tm.team FROM teammbs tm, team t WHERE tm.team=t.teamid AND (t._state<64 or (t._state>120 AND t._state<192)) AND (tm._state<64 or (tm._state>120 AND tm._state<192))) AS tr ON a.ateam=tr.team WHERE (a._state<64 or (a._state>120 AND a._state<192)) AND (a.auser='test' OR tr.member='test') ORDER BY a.auth; It works fine with MySQL 5, and brings the same error on SQLite 3: No such column tr.team. Any idea? #f2dcdc 2874 active 2008 Jan anonymous Pending 1 1 THREADSAFE #define HAVE_LOCALTIME_R, HAVE_GMTIME_R in os_unix.c The precompiled shared sqlite3 library for Linux on sqlite.org which appears to be built with pthread support is using localtime and gmtime which are not threadsafe. For THREADSAFE builds could either configure be changed to detect the functions gmtime_r and localtime_r or change os_unix.c to explicitly #define HAVE_LOCALTIME_R and HAVE_GMTIME_R? #f2dcdc 2766 active 2007 Nov drh Pending 1 1 TCL transaction started from within a query does not commit This is a problem with the TCL interface. Consider the following TCL script: file delete -force test.db test.db-journal sqlite3 db test.db db eval { CREATE TABLE t1(x,y); INSERT INTO t1 VALUES(1,2); CREATE TABLE t2(a,b); INSERT INTO t2 VALUES(8,9); } db eval {SELECT * FROM t1} { db transaction { db eval {UPDATE t2 SET a=a*2} } } The [db transaction] statement starts a transaction and it is suppose to commit the tranaction at the end of the code block. But because the transaction started while a query was active, the tranaction is unable to commit. The TCL interface never commits the tranaction nor does it give any kind of error indication. It is unclear if an error should be returned or if the commit should be deferred until outer query finishes. If the code within the [db transaction] block throws an error, we really need the transaction to rollback right away. Perhaps there should be a new API that cancels all pending queries. Perhaps a call to sqlite3_interrupt() would suffice for this. Need to investigate further.... #cfe8bd 1815 active 2006 May anonymous Parser Pending 3 3 Support of W3C-DTF(ISO8601 subset) is incomplete "Z" of a time zone is ignored. Reference: http://www.w3.org/TR/NOTE-datetime CREATE table test(dt); INSERT INTO "test" VALUES('2006-05-20T01:10:20+00:00'); INSERT INTO "test" VALUES('2006-05-20T01:10:20Z'); INSERT INTO "test" VALUES('2006-05-20T10:10:20+09:00'); SELECT datetime(dt) from test; 2006-05-20 01:10:20 2006-05-20 01:10:20 #f2dcdc 2897 active 2008 Jan anonymous Pending 1 1 String or BLOB exceed size limit This error was shown after attemp to read script from SQLite 3.5.4 shell in order to recreate old DB. Details: 1. Database was created with SQLite 3.3.4. Around 20 standard fieds and one BLOB. 2. The only one existed table was dumped with shell of SQLite 3.5.4. SQL script seems to be coorrect. 3. Opened SQLite 3.5.4 and read script in new DB. The error "String or BLOB exceed size limit" are sown for several lines. Many records missing. 4. Attempted to dump table with shell of version 3.3.6 (have no more 3.3.4 shell) and read into new DB with 3.5.4 shell The same errors are shown. The same steps was attempted with 3.3.6. shell only. All seems to be correct. _2008-Jan-17 20:23:25 by drh:_ {linebreak} This size limit on BLOBs in SQLite version 3.5.4 is 1GB. How big is your blob, exactly? ---- _2008-Jan-17 22:22:24 by anonymous:_ {linebreak} BLOB in each record is no more than few MB. Mostly it is few KB (e-client and news application). Whole DB have around 200MB. ---- _2008-Jan-18 02:28:11 by drh:_ {linebreak} This issue is probably resolved by check-in [4636], then. ---- _2008-Jan-18 14:28:13 by anonymous:_ {linebreak} If directive SQLITE_MAX_SQL_LENGTH is not defined it is set to 1,000,000 (10^6) in amalgamation code of 3.5.4. #f2dcdc 2059 active 2006 Nov anonymous Pending 1 1 Still missing .DEF file from Windows 3.3.8 source code distribution The file sqlite3.def is missing from the zip archive of sources used to build sqlite3 on Windows. Ticket number 2031 was closed with a remark that this file is generated during the build process. That is true if one is building on Linux with MinGW32 configured as a cross-compiler. If one were building using that method then I assume one would not be downloading the src.zip archive anyway. My impression is that the src.zip archive is prepared once the build has been performed on Linux so Windows developers can directly build sqlite (and the generated files) without need of the other tools that the build process depends on. If this is accurate, then it would be very helpful if the src.zip archive could also include the sqlite3.def file. Without this file it is not possible for Windows developers to create a DLL from the src.zip archive. Thanks _2006-Nov-09 20:05:23 by anonymous:_ {linebreak} Works fine as is with MinGW ./configure && make sqlite3.exe #f2dcdc 2037 active 2006 Oct anonymous Pending 1 1 Sqlite3 can't use datafile in Chinese path with Win2000 and WindowsXP. Sqlite3 can't use datafile in Chinese path with Win2000 and WindowsXP. This is a bug in os_win.c . My firend modify code to so , it work right. /* ** Convert a UTF-8 string to UTF-32. Space to hold the returned string ** is obtained from sqliteMalloc. */ static WCHAR *utf8ToUnicode(const char *zFilename){ int nChar; WCHAR *zWideFilename; if( !isNT() ){ return 0; } nChar = MultiByteToWideChar(CP_THREAD_ACP, MB_COMPOSITE, zFilename, -1, NULL, 0); zWideFilename = sqliteMalloc( nChar*sizeof(zWideFilename[0]) ); if( zWideFilename==0 ){ return 0; } nChar = MultiByteToWideChar(CP_THREAD_ACP, MB_COMPOSITE, zFilename, -1, zWideFilename, nChar); if( nChar==0 ){ sqliteFree(zWideFilename); zWideFilename = 0; } return zWideFilename; } /* ** Convert UTF-32 to UTF-8. Space to hold the returned string is ** obtained from sqliteMalloc(). */ static char *unicodeToUtf8(const WCHAR *zWideFilename){ int nByte; char *zFilename; nByte = WideCharToMultiByte(CP_THREAD_ACP, WC_COMPOSITECHECK, zWideFilename, -1, 0, 0, 0, 0); zFilename = sqliteMalloc( nByte ); if( zFilename==0 ){ return 0; } nByte = WideCharToMultiByte(CP_THREAD_ACP, WC_COMPOSITECHECK, zWideFilename, -1, zFilename, nByte, 0, 0); if( nByte == 0 ){ sqliteFree(zFilename); zFilename = 0; } return zFilename; } _2006-Oct-20 10:26:46 by anonymous:_ {linebreak} The proposed fix is completely wrong, but the bug exists nonetheless. The problem is that SQLite expects file names in UTF-8 encoding (and there is probably bug in your application too guessing from the proposed fix). While this works fine on NT systems where the UTF-8 encoding is converted to UTF-16 and passed to system wide-character APIs, the code path for non-NT systems (Win 9x) with ANSI-only APIs doesn't convert the UTF-8 file names into the ANSI code page which is expected by the system APIs. #f2dcdc 2043 active 2006 Oct anonymous Pending 1 1 Spaces in view statement If you have a table defined with fields that contain spaces. create table table1 ("field one", "field two", "field three"); Then you do a select select "field one" from table1; That works fine. However if you save it as a view create view view_one as select "field one" from table1; Then if you run a select on the view it fails. select * from view_one; #cfe8bd 700 active 2004 Apr anonymous VDBE 2 3 Solaris-sparc segfaults on sum() On Solaris (sparc) trying to do a sum() (sometimes) SEGVs: this is because the result is placed in a chunk of memory which is allocated as a char * and therefore isn't aligned to 16-byte boundaries (which SPARC-Solaris seems to want). One fix for this which seems to work for me is to change vdbeInt.h:118 to char zShort[NBFS] __attribute__ ((__aligned__(16))); /* Space for short strings */ and change sqlite_aggregate_context to assign p->pAgg to zShort rather than z (since z is malloc()ed you can't align it) - I don't know if this would cause problems elsewhere though. _2004-Apr-22 16:10:37 by dougcurrie:_ {linebreak} malloc() should always return memory aligned for any purpose; I don't think this is the problem. Looking at the function sqlite_aggregate_context though, I wonder: *:where is p->z initialized? *:where is p->pAgg sqliteFree()d? *:what happens when sqlite_aggregate_context and sqlite_set_result_string share Mem.zShort? ---- _2004-Apr-23 09:58:03 by anonymous:_ {linebreak} > malloc() should always return memory aligned for any purpose; I don't think this is the problem. I didn't make it clear: I'm getting a Bus Error, not just a normal SEGV. There are several places mentioned on the web which suggests that solaris' malloc() aligns memory to 8-byte boundaries, while (on 64-bit, I assume) a double is 128 bits... however you're correct, the manpage does insist that all malloc()s are aligned to data large enough for any purpose. I suppose if s.z isn't even assigned at this point (but hasn't been cleared at initialisation) it might contain something completely non-aligned. However I now can't reproduce the problem, although that's not to say that it means the thing isn't broken... I'll try and break it again and let you know. As to your other point: the reason I posted was because of exactly this: I don't know the code well enough (I'd never heard of it until yesterday!) to be able to say whether .zShort could be used elsewhere at the same time as a sum() function. ---- _2004-Apr-23 10:35:11 by anonymous:_ {linebreak} Aha. A core file lying around may well help.
... Program terminated with signal 10, Bus Error. ... #0 0xff33d4a4 in sumStep (context=0x2a158, argc=203556, argv=0x3ac08) at src/func.c:421 421 p->sum += sqliteAtoF(argv[0], 0); ... (gdb) list 416 static void sumStep(sqlite_func *context, int argc, const char **argv){ 417 SumCtx *p; 418 if( argc<1 ) return; 419 p = sqlite_aggregate_context(context, sizeof(*p)); 420 if( p && argv[0] ){ 421 p->sum += sqliteAtoF(argv[0], 0); 422 p->cnt++; 423 } 424 } .... (gdb) print &p.sum $5 = (double *) 0x31b24Now my basic maths (a hex 16-byte aligned number should end in 0, right?) says that somehow p.sum has become misaligned by 4 bytes. sqlite_aggregate_sum simply assigns p->pAgg to p->s.z and returns p->pAgg, which means that p->s.z is misaligned also. Further investigation makes more worrying reading:
(gdb) print *context $18 = {pFunc = 0x75736572, s = {i = 0, n = 0, flags = 16, z = 0x0, r = 3.6586602629506839e-309, zShort = '\000'Note that pAgg is 0x10 (!?) and s.z is 0. Something seriously unhappy going on there: I think it's likely there's some corruption going on due to some specific set of events which was being run. I'll rerun the exact scenario and try again. ---- _2004-May-03 02:27:25 by anonymous:_ {linebreak} i have seen this exact same problem on sparc/solaris. my core looks exactly the same. it really does look like an alignment issue. ---- _2004-Jul-12 13:09:26 by anonymous:_ {linebreak} I had this exact problem on solaris 8 with gcc3.3.4 and well, every version of sqlite over 2.5. Heres my solution, hopefully it will help someone with more time and IQ points to figure out the real problem After forcing PTR_FMT to %x in test1.c (so i can run all the tests) I changed src/vbdeInt.h #define NBFS from 32 to 15 (one less than a long double on a sparc) thus forcing all long doubles to be malloced. This allowed me to run all the tests (and my application) bus error free. 5 of the tests failed, which looks like a precision problem and seems harmless in my applications. date-1.19... Expected: [2451545.00000116] Got: [2451545.00000] date-1.20... Expected: [2451545.00000012] Got: [2451545.00000] date-1.21... Expected: [2451545.00000001] Got: [2451545.00000] expr-2.4... Expected: [0.525641025641026] Got: [0.52564102564] expr-2.5... Expected: [1.90243902439024] Got: [1.90243902439] ---- _2004-Jul-17 12:26:31 by anonymous:_ {linebreak} I found a better solution than my changing NBFS solution. from what little info i found, doubles in a structure are aligned to 8. so align zShort to 8 and it works with NBFS as 32. change PTR_FMT to %X instead of %x and it passes all the tests. #f2dcdc 2487 active 2007 Jul anonymous Pending 1 1 SQLite database locked error on NFS mounted home dir I have a c program using the provided API. My home directory is NFS mounted, Im using SQLite 3.3.17. I open a new database using "sqlite3_open", then strcpy () a SQL command to create a table, and run "sqlite3_exec" with this string. I get a return code of 5=database locked. I then tried to manually (command line using sqlite3) create a table within a database in my home dir, that fails too. =========== x@y> sqlite3 db2 SQLite version 3.3.17 Enter ".help" for instructions sqlite> create table test (Lastname varchar); SQL error: database is locked sqlite> ============== If I try this on my local machine (a Mac), it works fine, but I need it to work in my home directory mounted via NFS as that is where the output of our program goes _2007-Jul-06 19:04:15 by anonymous:_ {linebreak} If you're using a Mac, compile sqlite with SQLITE_ENABLE_LOCKING_STYLE in os_unix.c ---- _2007-Jul-07 11:51:10 by drh:_ {linebreak} This is a problem with your NFS implementation - it does not appear to support posix advisory locking. There is nothing much that SQLite can do about this. Anonymous above suggests making use of the dot-locking mechanism contributed by Apple. This might be an effective work-around. But remember that there is performance impact. Also remember that an SQLite database that uses dot-locking is subtly imcompatible with a standard SQLite database. The file format itself is the same, but if two processes try to access the database file at the same time and one uses dot-locks and the other uses posix advisory locks, you will end up with corruption. ---- _2007-Jul-07 12:44:09 by anonymous:_ {linebreak} It's very odd that Apple does not fix their Mac OSX POSIX locks for NFS given their resources. #f2dcdc 1862 active 2006 Jun anonymous TclLib Pending tclguy 1 1 SQLite cannot load/import data from file I found the problem when I tried to load a data file into a table. To reproduce the problem, I got a mini testcase. DATA FILE - test.dat --------------------------- 1 0 0 2 90000 0 3 366000 0 --------------------------- Log from SQLite: ------------------------------------------------------ khronos-yajun>sqlite3 test SQLite version 3.3.6 Enter ".help" for instructions sqlite> create table test (id INT, x1 INT, x2 INT); sqlite> .import test.dat test test.dat line 1: expected 3 columns of data but found 1 sqlite> .exit ------------------------------------------------------- The problem also exists when I use tcl wrapper (sql copy abort test test.dat). I looked into the code in src/tclsqlite.c, In Lines 1045 nByte = strlen(zSql); 1046 rc = sqlite3_prepare(pDb->db, zSql, 0, &pStmt, 0); 1047 sqlite3_free(zSql); Is the third argument of sqlite3_prepare supposed to be the length of zSql, hence nByte? Also in lines 1070 zSql[j++] = ')'; 1071 zSql[j] = 0; 1072 rc = sqlite3_prepare(pDb->db, zSql, 0, &pStmt, 0); 1073 free(zSql); If I change these two places to reflect the length of zSql, I seem to succeed. Yajun _2006-Sep-27 16:25:47 by anonymous:_ {linebreak} This is a duplicate of #1797 #cfe8bd 1856 active 2006 Jun anonymous Pending 2 3 SQLITE_OMIT_UTF16 breaks 'make test' When compiling sqlite 3.3.6 with -DSQLITE_OMIT_UTF16 and you say 'make test' it fails: make test ./libtool --mode=link gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -I. -I./src -DSQLITE_DEBUG=2 -DSQLITE_MEMDEBUG=2 -DSQLITE_OMIT_UTF16 -I/usr/include -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_CURSOR -DTCLSH=1 -DSQLITE_TEST=1 -DSQLITE_CRASH_TEST=1 \ -DTEMP_STORE=1 -o testfixture ./src/btree.c ./src/date.c ./src/func.c ./src/os.c ./src/os_unix.c ./src/os_win.c ./src/os_os2.c ./src/pager.c ./src/pragma.c ./src/printf.c ./src/test1.c ./src/test2.c ./src/test3.c ./src/test4.c ./src/test5.c ./src/test6.c ./src/test7.c ./src/test_async.c ./src/test_md5.c ./src/test_server.c ./src/utf.c ./src/util.c ./src/vdbe.c ./src/where.c ./src/tclsqlite.c \ libsqlite3.la -L/usr/lib -ltcl8.4 -ldl -lpthread -lieee -lm gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -I. -I./src -DSQLITE_DEBUG=2 -DSQLITE_MEMDEBUG=2 -DSQLITE_OMIT_UTF16 -I/usr/include -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_CURSOR -DTCLSH=1 -DSQLITE_TEST=1 -DSQLITE_CRASH_TEST=1 -DTEMP_STORE=1 -o .libs/testfixture ./src/btree.c ./src/date.c ./src/func.c ./src/os.c ./src/os_unix.c ./src/os_win.c ./src/os_os2.c ./src/pager.c ./src/pragma.c ./src/printf.c ./src/test1.c ./src/test2.c ./src/test3.c ./src/test4.c ./src/test5.c ./src/test6.c ./src/test7.c ./src/test_async.c ./src/test_md5.c ./src/test_server.c ./src/utf.c ./src/util.c ./src/vdbe.c ./src/where.c ./src/tclsqlite.c ./.libs/libsqlite3.so -L/usr/lib -ltcl8.4 -ldl -lpthread -lieee -lm -Wl,--rpath -Wl,/home/cla/proj/caissadb/sqlite/sqlite/lib ./src/test1.c: In function 'Sqlitetest1_Init': ./src/test1.c:3742: error: 'unaligned_string_counter' undeclared (first use in this function) ./src/test1.c:3742: error: (Each undeclared identifier is reported only once ./src/test1.c:3742: error: for each function it appears in.) make: *** [testfixture] Error 1 Maybe there is a '#ifndef SQLITE_OMIT_UTF16' / '#endif' needed around Tcl_LinkVar(interp, "unaligned_string_counter", (char*)&unaligned_string_counter, TCL_LINK_INT); in Line 3742 in file src/test1.c? Regards. #cfe8bd 1053 active 2004 Dec anonymous Pager Pending 3 3 SQLITE_IOERR and strange rollback when db is busy Environment on which bug was found:{linebreak} Windows XP, both SP1 and SP2, on different computers. The SQLite library was built using the precompiled source from the download page (as static library). Description of bug scenario: One process performs very long reads from a db (multiple joins, so the cartesian product is *very* large, and the reader needs a while to complete). Another process performs a _BEGIN TRANSACTION_ , then executes lots of _INSERT INTO ... VALUES_ .{linebreak} 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. #f2dcdc 2509 active 2007 Jul anonymous New 1 1 SQLITE_DATE SELECT CAST(MyDate AS DATE), CAST(MyTime AS TIME) FROM MyData I hope, it will result/return DATE, TIME. Please support to SQLITE_DATE and SQLITE_TIME. Thanks. #e8e8bd 2708 active 2007 Oct anonymous Pending 4 2 SQL error:disk I/O error I cross-compile sqlite to embedded Linux,but after I insert data to the table ,it failed.the warning is "SQL error:disk I/O error". _2007-Oct-09 05:12:28 by anonymous:_ Why do you think it is SQLite error ?? ---- _2007-Oct-09 05:46:06 by danielk1977:_ {linebreak} We'll need a bit more data than that to figure this out. Did earlier SQLite versions work? Can you post the entire output of the compile process so that we can see if there are any clues there? Can you run strace so that we can see if there really is an IO error, or at least when SQLite believes there to be one? #cfe8bd 685 active 2004 Apr anonymous CodeGen 1 3 SELECT from a VIEW with GROUP BY When you SELECT from a VIEW (which is having a GROUP BY statement) and try to apply another GROUP BY statement you get: $ sqlite ../../db/main.db SQLite version 2.8.13 Enter ".help" for instructions sqlite> .dump prod_elem_totals BEGIN TRANSACTION; CREATE VIEW prod_elem_totals AS SELECT pe.elem_id AS elem_id, p.prod_id AS prod_id, e.name AS name, p.name AS p_name, pe.count AS count, SUM(b.count) / pe.count AS p_max, SUM(b.count) AS total, SUM(b.price * b.count) / SUM(b.count) AS price, e.min AS min FROM products AS p, elements AS e, batches AS b, prod_elems AS pe WHERE p.prod_id = pe.prod_id AND pe.elem_id = b.elem_id AND pe.elem_id = e.elem_id GROUP BY p.prod_id, pe.elem_id ORDER BY e.name; COMMIT; sqlite> SELECT * FROM prod_elem_totals GROUP BY elem_id; sqlite: src/select.c:1775: flattenSubquery: Assertion `p->pGroupBy==0' failed. Aborted It seams it doesn't matter which column I GROUP BY. I can prepare a full test case if needed. Maybe somehow connected with #678. After further investigation I found that when I add a aggregate function like "SUM (count * 10) AS min" it works... #cfe8bd 2901 active 2008 Jan anonymous Pending 3 3 ROLLBACK and COMMIT statements should not expire Currently, whenever a statement changes the schema of the database, all prepared statements will be expired, no matter whether they actually need to be prepared again or not. This is especially problematic for ROLLBACK statements in a multi-statement transaction. Currently there is no way to guaranty that a multi-statement transaction can at least be rolled back in case of an error, because one has to (re)prepare the ROLLBACK statement to roll back the transaction, which can fail because of OOM (in a multi-threaded application). #cfe8bd 1515 active 2005 Nov anonymous Unknown Pending 4 3 Quotes incorrect included in colum names. The names of columns returns by sqlite_exec has the quotes which has written in the query. I will try to show with examples in the sqlite command line. create table test("Full Name" varchar(30), "Login" varchar(15), Age integer); insert into test ("Full Name", "Login", Age) values ("Enrique Esquivel", "the_kique", 24); .headers on select * from test; SQLite returns: Full Name|Login|Age Enrique Esquivel|the_kique|24 But when write: select "Full Name", "Login", Age from test; returns: "Full Name"|"Login"|Age Enrique Esquivel|the_kique|24 Moreover when quote all fields: select "Full Name", "Login", "Age" from test; returns: "Full Name"|"Login"|"Age" Enrique Esquivel|the_kique|24 Also: select [Full Name], [Login], [Age] from test; SQLite returns wrong: [Full Name]|[Login]|[Age] Enrique Esquivel|the_kique|24 The quotes should be used for SQLite only for understand the identifiers, the fields in result must be unquoted. Try to test with other dbms and anyone has this behavior. #e8e8bd 2378 active 2007 May anonymous Pending 2 2 Quoted fields come back corrupted, using GROUP BY *Description:* When executing a query, where field names are quoted, and using GROUP BY, the field names are returned with quotes around. *SQLite version:* SQLite support => enabled PECL Module version => 2.0-dev $Id: sqlite.c,v 1.166.2.13.2.7 2007/03/06 02:17:13 stas Exp $ SQLite Library => 2.8.17 SQLite Encoding => iso8859 *Reproduce code* string(1) "1" } *Actual result* array(1) { [""id""]=> string(1) "1" } _2007-May-21 18:14:27 by anonymous:_ {linebreak} Corrupted is probably not the right term, but the fields are returned with quotes around them in sqlite3 as well when group by is used on a quoted column: SQLite version 3.3.17 Enter ".help" for instructions sqlite> .header on sqlite> create table t1(a); sqlite> insert into t1 values(1); sqlite> select "a" from t1; a 1 sqlite> select "a" from t1 order by 1; a 1 sqlite> select "a" from t1 group by 1; "a" 1 sqlite> select "a" from t1 group by 1 order by 1; "a" 1 sqlite> select "a" from t1 group by a; "a" 1 #f2dcdc 1415 active 2005 Sep anonymous Unknown Pending drh 1 1 Querying for BLOB type fields How do I query for BLOB type fields? 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. _2005-Sep-13 08:00:28 by anonymous:_ {linebreak} Using version 3.2.5, you might use the quote function to convert a blob into a string which you can filter using the like operator: select * from test where quote(text) like '%6263%'; is working and usable but may not work as expected because like '%26%' would find the same and this was not expected, isn't it? select * from test where like(quote(text),'%6263%'); doesn't work and select * from test where like(quote(text),'%6263%','%'); doesn't work either ---- _2005-Oct-04 05:44:08 by anonymous:_ {linebreak} This should really be taken to the mailing list, preferably with descriptions of how other DBMSs handle LIKE as applied to BLOB columns. #cfe8bd 154 active 2002 Sep drh Pager drh 3 3 Prohibit links on database files. If a database file is aliased using either hard or symbolic links, it can happen that an aborted transaction will not roll back correctly. Consider this scenario. The database file is named both a.db and a.db. Application one opens a.db and starts to make a change. This creates a journal file a.db-journal. But application one crashes without completing the transaction. Later, application two attempts to open the database as b.db. App two looks for a journal file to rollback, but it thinks the journal should be named b.db-journal. So it fails to see the a.db-journal that app one left and fails to rollback the transaction. The only way I can think of to prevent this kind of thing it to refuse to open any database file that contains two or more hard links and to refuse to open a file through a symbolic link. _2004-Mar-16 20:46:17 by anonymous:_ {linebreak} What if the journal file name wasn't based on the database name, but instead was based on the starting inode of the database file? For instance, "journal-10293" would be used if the starting inode for the associated database file was 10293. ---- _2004-Mar-20 17:17:41 by anonymous:_ {linebreak} Using Inode-numbers to solve this problem is a dangerous proposition, as disk defragmenters can alter the inode the db starts at in between a crash and a subsequent roll-back attempt. ---- _2007-Jun-05 03:57:17 by anonymous:_ {linebreak} On unix, you can use ftok() to solve this problem. It guarantees to return the same key for all paths to the same file, including symbolic and hard links. I have to experience programming in Windows, but have no doubt a similar function call exists in that API. #f2dcdc 2077 active 2006 Nov anonymous Pending 2 1 Problems with using ASCII symbols 0x80 - 0xFF in database path Platform: Windows., "\020\000\000\000\000\000\002¡\230", '\000' }, pAgg = 0x10, isError = 0 '\000', isStep = 0 '\000', cnt = 172464}
void *zConverted = convertUtf8Filename(zFilename); if( zConverted==0 ){ return SQLITE_NOMEM; }and use another string converted with another function to save the filename that will be deleted in windows ce:
#if OS_WINCE f.zDeleteOnClose = delFlag ? utf8ToUnicode(zFilename) : 0; f.hMutex = NULL; #endifalso, the variable fileflags should be a DWORD (unsigned integer 32-bit) instead of a native C compiler integer. 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); }_2006-Dec-21 00:48:28 by drh:_ {linebreak} On wince, convertUtf8Filename() calls utf8ToUnicode() to do its work, so these routines end up computing exactly the same filename. ---- _2006-Dec-21 01:30:33 by anonymous:_ {linebreak} Yes, I figured out that they still calling the same function, but why converting / freeing then converting agains ? just save some CPU cycles (this could help a lot in Windows CE < 200 mhz, just like my app runs (windows ce 2.11, SH3 130MHz HP Jornada 680)!!! Please apply my patch to make it faster. #cfe8bd 969 new 2004 Oct anonymous TclLib Pending 3 3 PRAGMA empty_result_callbacks not working in tclsqlite-3.0.8.so part 2 Referencing ticket # 967, I stated that it was the tclsqlite code that was not functioning properly, not the ./sqlite3 executable.{linebreak} 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_2006-May-16 18:29:44 by anonymous:_ {linebreak} This is still a problem in the 3.3.5 version of the tclsqlite library. The tclsqlite.c code never calls the callback code on empty results when PRAGMA empty_result_callbacks=1 is set. #f2dcdc 2809 active 2007 Nov anonymous Pending 1 1 PRAGMA collation_list shows unregistered collations As presented on the mailing list: Imagine that a SQLite3 database opened in a custom application with a registered a collation sequence named "unknown" has created the following table: CREATE TABLE a (b COLLATE unknown); Now open this table in the default SQLite3 CLI. Up to here, everything works as expected. Next issue "PRAGMA collation_list;" and notice that "unknown" lists next to the other registered collations, even though "unknown" is not registered with the default SQLite3 CLI: sqlite> PRAGMA collation_list; 0|unknown 1|NOCASE 2|BINARY Responses from the mailing list indicate that this is not the expected behaviour. "PRAGMA collation_list;" should list registered collations only. _2007-Nov-28 16:12:17 by anonymous:_ {linebreak} I don't think this is a bug. If the CLI is not aware of the collation, it should not process the query that makes use of the collation because it would certainly be wrong if it simply ignored the collation. This is not unlike a user-registered SQL function that does not exist in the CLI. I would not expect or want the sqlite3 CLI to ignore the unknown function, nor would I want the CLI to process queries ignoring the custom collation. #f2dcdc 691 active 2004 Apr anonymous Unknown drh 1 1 OS X File Sharing Hello Sir: This ticket may be considered a duplicate of ticket #301. I am unable to access SQLite databases from HFS or SMB network shares when using Mac OS X (10.3.3) as a client. The more technical aspects of the problem are explained well in ticket #301. I am using SQLabs SQLite plugin for RealBasic 5.5, and would like to use SQLite exclusively as my DB.
%token_type { char * } %token_destructor { printf("Deleting token '%s' at %x\n", $$, (int)$$); free($$); } result ::= nt. nt ::= FOO BAR.Running the following code against the grammar should theoretically show 2 allocations and two destructions. It won't though, unless you modify the rule for nt to have an empty body, like: {linebreak} nt ::= FOO BAR. {}
char *mkStr(const char *s) { printf("Allocating '%s' at 0x%x\n", s, (int)(s)); return strdup(s); } int main(int argc, char **argv) { void *parser = ParseAlloc(malloc); Parse(parser, FOO, mkStr("foo")); Parse(parser, BAR, mkStr("bar")); Parse(parser, 0, 0); ParseFree(parser, free); return 0; }---- _2005-Jan-14 17:50:26 by anonymous:_ {linebreak} Here is another test grammar. This one demonstrates (a) default destructors being called on the 'error' symbol, and (b) problems with default destructors being called on the wrong symbol type.
%token_type { char * } %token_destructor { delete [] $$; } %default_destructor { delete $$; } %type result { int } %destructor result { } result ::= fooStruct barStruct. { } %type fooStruct { Foo * } fooStruct(lhs) ::= FOO(f). { lhs = new Foo(f); } %type barStruct { Bar * } barStruct(lhs) ::= BAR(b). { lhs = new Bar(b); }Here is the code generated by lemon (with comments added & removed for clarity):
typedef union { ParseTOKENTYPE yy0; int yy4; Bar * yy5; Foo * yy7; int yy15; } YYMINORTYPE; static const char *const yyTokenName[] = { "$", "FOO", "BAR", "error", "result", "fooStruct", "barStruct", }; static void yy_destructor(YYCODETYPE yymajor, YYMINORTYPE *yypminor){ switch( yymajor ){ case 1: case 2: { delete [] (yypminor->yy0); } break; case 3: /* error */ case 5: /* fooStruct of type "Foo *" */ case 6: /* barStruct of type "Bar *" */ #line 3 "typeBug.y" { delete (yypminor->yy5); } /* Yikes! yy5 is a "Bar *" */ #line 308 "typeBug.c" break; case 4: #line 6 "typeBug.y" { } #line 313 "typeBug.c" break; default: break; /* If no destructor action specified: do nothing */ } }#cfe8bd 1063 active 2005 Jan anonymous Pending 1 3 Lemon bug: Strings in rule code should not be interpreted There are two related bugs in the lemon parser related to processing code snippets defined in rule actions. Here is a simple grammar that demonstrates the problem: %include { extern int line_number; extern const char *file_name; } result(r) ::= TOKEN(s). { printf("BAD: Got a token on line '%d'\n", line_number); printf("BAD: \tFile = '%s'\n", file_name); r = s; } The first bug is that the "%d" in the first printf is interpreted by the append_str function, when it shouldn't be, producing code that looks like: printf("BAD: Got a token on line '0d'\n", line_number); I believe that the solution is to have append_str() NOT do %d substitution when it is copying the code. The second bug is that the "s" in the "%s" format is being interpreted as a symbolic name, producing code that looks like: printf("BAD: \tFile = '%yymsp[0].minor.yy0'\n", file_name); I believe that the solution is to have translate_code() ignore symbolic names inside of quoted strings. #f2dcdc 2898 active 2008 Jan anonymous Pending 1 1 Latest CVS for 3.5.4 fails to build test1.c gcc -pipe -O3 -g -Wall -DSQLITE_DISABLE_DIRSYNC=1 -I. -I../src -DNDEBUG -I/usr/include -DSQLITE_THREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DTCLSH=1 -DSQLITE_TEST=1 -DSQLITE_CRASH_TEST=1 -DSQLITE_NO_SYNC=1 -DTEMP_STORE=1 -o .libs/testfixture ../src/attach.c ../src/btree.c ../src/build.c ../src/date.c ../src/expr.c ../src/func.c ../src/insert.c ../src/malloc.c ../src/os.c ../src/os_os2.c ../src/os_unix.c ../src/os_win.c ../src/pager.c ../src/pragma.c ../src/prepare.c ../src/printf.c ../src/select.c ../src/test1.c ../src/test2.c ../src/test3.c ../src/test4.c ../src/test5.c ../src/test6.c ../src/test7.c ../src/test8.c ../src/test9.c ../src/test_autoext.c ../src/test_async.c ../src/test_btree.c ../src/test_config.c ../src/test_hexio.c ../src/test_malloc.c ../src/test_md5.c ../src/test_onefile.c ../src/test_schema.c ../src/test_server.c ../src/test_tclvar.c ../src/test_thread.c ../src/tokenize.c ../src/utf.c ../src/util.c ../src/vdbe.c ../src/vdbeapi.c ../src/vdbeaux.c ../src/vdbemem.c ../src/where.c parse.c ../src/tclsqlite.c ./.libs/libsqlite3.so -L/usr/lib64 -ltcl8.4 -ldl -lpthread -lieee -lm -Wl,--rpath -Wl,/common/pkgs/sqlite-3.5.4.3/lib ../src/build.c: In function 'sqlite3RefillIndex': ../src/build.c:2275: warning: cast to pointer from integer of different size ../src/func.c: In function 'trimFunc': ../src/func.c:919: warning: cast from pointer to integer of different size ../src/func.c: In function 'sqlite3RegisterBuiltinFunctions': ../src/func.c:1464: warning: cast to pointer from integer of different size ../src/func.c:1483: warning: cast to pointer from integer of different size ../src/insert.c: In function 'sqlite3GenerateConstraintChecks': ../src/insert.c:1200: warning: cast to pointer from integer of different size ../src/insert.c:1034: warning: 'j2' may be used uninitialized in this function ../src/insert.c: In function 'sqlite3Insert': ../src/insert.c:373: warning: 'regFromSelect' may be used uninitialized in this function ../src/test1.c: In function 'test_collate_func': ../src/test1.c:2085: warning: cast from pointer to integer of different size ../src/test1.c: In function 'test_collate_needed_cb': ../src/test1.c:2209: warning: cast to pointer from integer of different size ../src/test1.c: In function 'alignmentCollFunc': ../src/test1.c:2258: warning: cast from pointer to integer of different size ../src/test1.c:2259: warning: cast from pointer to integer of different size ../src/test8.c: In function 'echoBestIndex': ../src/test8.c:722: warning: 'nRow' may be used uninitialized in this function ../src/vdbe.c: In function 'sqlite3VdbeExec': ../src/vdbe.c:502: warning: 'pOut' may be used uninitialized in this function ../src/vdbe.c:501: warning: 'pIn3' may be used uninitialized in this function ../src/vdbe.c:501: warning: 'pIn2' may be used uninitialized in this function ../src/vdbe.c:501: warning: 'pIn1' may be used uninitialized in this function ../src/vdbeaux.c: In function 'sqlite3VdbeChangeP4': ../src/vdbeaux.c:529: warning: cast from pointer to integer of different size ../src/vdbemem.c: In function 'sqlite3ValueText': ../src/vdbemem.c:911: warning: cast from pointer to integer of different size /tmp/ccsuOeus.o: In function `reset_prng_state': /build/work/sqlite-3.5.4.3/bld/../src/test1.c:4280: undefined reference to `sqlite3ResetPrngState' /tmp/ccsuOeus.o: In function `restore_prng_state': /build/work/sqlite-3.5.4.3/bld/../src/test1.c:4267: undefined reference to `sqlite3RestorePrngState' /tmp/ccsuOeus.o: In function `save_prng_state': /build/work/sqlite-3.5.4.3/bld/../src/test1.c:4254: undefined reference to `sqlite3SavePrngState' collect2: ld returned 1 exit status make: *** [testfixture] Error 1 _2008-Jan-17 23:54:58 by anonymous:_ {linebreak} Problem appears to be here in libsqlite.3.so.0.8.6 as shown by: nm -A .libs/libsqlite3.so.0.8.6 | grep sqlite3ResetPrngState which shows no entry point. And: nm -A .libs/random.o | grep sqlite3ResetPrngState which also shows no entry point. ---- _2008-Jan-17 23:56:55 by anonymous:_ {linebreak} Ah... It appears -DSQLITE_TEST should be passed when building test1.c and left off when building prior to install. ---- _2008-Jan-21 20:16:00 by anonymous:_ {linebreak} In the makefile the right flag appears to be set, it's just not making it through to the compile for some reason. ---- _2008-Jan-21 20:16:24 by anonymous:_ {linebreak} Still fails the same based on today's cvs update. ---- _2008-Jan-23 03:14:49 by anonymous:_ {linebreak} This bug fixed as of latest cvs pull #e8e8bd 2875 active 2008 Jan anonymous Pending 3 2 LIKE does not work with lowercase swedish characters Swedish letters å,ä,ö is not supported by the LIKE statement. When trying to perform a query like SELECT * FROM table WHERE name LIKE "å%" we will not get a match for names starting on Å (which is uppercase for å). To recreate: ============================================== SQLite version 3.5.4 Enter ".help" for instructions sqlite> CREATE TABLE TestingTable(Name varchar(20)); sqlite> INSERT INTO TestingTable values ('Sweden'); sqlite> INSERT INTO TestingTable values ('sweden'); sqlite> INSERT INTO TestingTable values ('Åland'); sqlite> INSERT INTO TestingTable values ('åland'); sqlite> SELECT * FROM TestingTable; Sweden sweden Åland åland sqlite> SELECT * FROM TestingTable WHERE Name LIKE "swe%"; Sweden sweden sqlite> SELECT * FROM TestingTable WHERE Name LIKE åla%"; åland ============================================================ #e8e8bd 1960 active 2006 Sep anonymous Pending 4 2 Issues with .import in sqlite.exe I ran into two possible problems when using the .import operation in sqlite3: - .import seems to be confused by NULLs; in the file NullTest.dat the null is at the end of the line - .import chokes on empty field when importing to field of type: integer PRIMARY KEY AUTOINCREMENT For example line like: ~2~3~4~5~6 Example: Schema: --Table with autoincrement CREATE TABLE test1( id integer PRIMARY KEY AUTOINCREMENT, c1 integer NULL , c2 integer NULL , c3 text NULL, c4 text NULL, c5 text NULL ); -- Table with no autoincrement field CREATE TABLE test2( id integer NULL, c1 integer NULL , c2 integer NULL , c3 text NULL, c4 text NULL, c5 text NULL ); .separator ~ .import NullTest.dat test1 .import NullTest.dat test2 .import NoNullTest.dat test2 I have short test files that I can email to the person who is looking at this. #f2dcdc 2907 active 2008 Jan anonymous Pending 1 1 Issues of sqlite3 with Windows Mobile 5/6 hi. we are currently using sqlite3 for our mobile application. it has been running without a hitch on pocket pc 2003 and previous versions. come windows mobile 5 and 6 we have been getting errors, although not consistent yet. one example is 'EXCEPTION_DATATYPE_MISALIGNMENT'. another is 'SELECT STATMENTS TO THE LEFT AND RIGHT OF UNION ARE NOT EQUAL'. i was wondering if you have any known compatibility issues of your product with this version of windows mobile. thanks in advance. _2008-Jan-28 13:26:26 by anonymous:_ {linebreak} EXCEPTION_DATATYPE_MISALIGNMENT is thrown when you try to use and Odd pointer address. I wrote a custom allocator for WinCE/ARM platform, and I have to take care about memory alignment (I used to align at 2 bytes, and at that time it solved the problem) #f2dcdc 1980 active 2006 Sep drh Pending 1 1 Initializing FTS1 twice causes it to fail. If you try to load the shared module twice, it causes the module to no longer work. #e8e8bd 684 active 2004 Apr anonymous Unknown 3 2 Incorrect function result type when using SQLITE_ARGS I registered a function using the SQLITE_ARGS return type. I then execute the statement "select test('sample')". The type information returned from sqlite_step in the pazColName is incorrectly reported as "NUMERIC". If I use a "0", specifying the first column, instead of SQLITE_ARGS when registering the function, the return value is correctly set to "TEXT". #e8e8bd 2066 active 2006 Nov anonymous Pending 2 2 Incorrect error message in the case of ENOLCK If you're trying to open a sqlite database that is stored on a filesystem that doesn't support locking, then you'll get the error when you try to execute any commands on it: Error: file is encrypted or is not a database If you run sqlite under strace, you see: read(0, ".schema\n.quit\n", 4096) = 14 fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, len=1}, 0xafa5cd70) = 0 fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=1073741826, len=510}, 0xafa5cd70) = 0 fcntl64(3, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=1073741824, len=1}, 0xafa5cd70) = 0 access("/mnt/www/zzz_old_sites/trac.db-journal", F_OK) = -1 ENOENT (No such file or directory) fstat64(3, {st_mode=S_IFREG|0644, st_size=584704, ...}) = 0 _llseek(3, 0, [0], SEEK_SET) = 0 read(3, "** This file contains an SQLite "..., 1024) = 1024 fcntl64(3, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}, 0xafa5cdd0) = -1 ENOLCK (No locks available) write(2, "Error: file is encrypted or is n"..., 46Error: file is encrypted or is not a database Sqlite should really check the exact error code, and give a more helpful error (eg "Locking not available on this filesystem. Databases may only be stored on filesystems that support locking") #c8c8c8 1598 review 2006 Jan anonymous Pending 3 2 Incorrect case-insensitive comparison of non-latin UTF-8 characters Sqlite incorrectly compares case-insensitivly UTF-8 non-latin characters. I created a patch that fixes this problem and posted it to the mailing list. I wonder if someone could review my patch and eventually include it in the main project. Regards Stanislav Nikolov _2006-Jan-10 22:49:08 by drh:_ {linebreak} The sqlite3_create_collation() and sqlite3_create_function() APIs exists for the purpose of allowing users to define comparisons and any other operations in any way they see fit. There is no need to make changes to the SQLite core to accomodate cyrillic comparisons. Indeed, there are good reasons not to, namely if we correctly compare cyrillic, we should also need to correctly compare chinese, japanese, and korean to name but a few. Very quickly the comparison functions can grow to be many many times larger than the rest of SQLite. We conclude, therefore, that this is all best left to the discretion of the programmer who uses SQLite in their project. Hence we provide the afore mentioned sqlite3_create_collation() and sqlite3_create_function() APIs. ---- _2006-Jan-11 00:24:50 by anonymous:_ {linebreak} Okay, let me try that again. First, the patch I created does not correspond only to Cyrillic letters, but also to the Greek and the accented characters up to U+044F. According to UNICODE.ORG there are actually five alphabets in the world (of which one does not use cases anymore) that have different cases: (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 lowercase 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 ---- _2006-Jan-11 00:33:19 by drh:_ {linebreak} Please attach the patch to this ticket. ---- _2006-Jan-11 00:52:38 by drh:_ {linebreak} OK, I was able to reconstruct the patch from the mailing list. 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. ---- _2006-Jan-11 03:10:09 by drh:_ {linebreak} Based on what I can glean from http://www.unicode.org/Public/UNIDATA/CaseFolding.txt, the case folding table in the patch seems to be incomplete. A full unicode case folding table would need to be much larger. Perhaps somebody with more experience in unicode case folding can comment. ---- _2006-Jan-11 09:52:38 by anonymous:_ {linebreak} I think that the size of the library could be effectivly shrunk if we don't use an array, because over 50% of the information is redundant. I think that the same effect could be achieved by changing sqlite3UpperToLower[] to a function, and in there to check for the ranges of the capital letters (that is, we need to check for 4-5 different regions and return x+20 ort x+1 for capital letters for example). I can try do that? ---- _2006-Jun-08 10:32:06 by anonymous:_ {linebreak} Has anybody worked on this lately? This is quite an issue if you happen to use non-latin chars. Keep up the good work. Anze ---- _2006-Oct-11 10:58:15 by anonymous:_ {linebreak} could you tell me how to run the patch for WindowXP? Thanks a lot. #cfe8bd 1804 active 2006 May anonymous Unknown Pending 4 3 Inconsistent value type returned by SUM when using a GROUP BY Using a schema with test table: CREATE TABLE Tbl1 (Key1 INTEGER, Num1 REAL) And test data: INSERT INTO Tbl1 (Key1,Num1) VALUES (1,5.0) The query: SELECT SUM(Tbl1.Num1) AS Num1Sum FROM Tbl1 Returns a column with the value type correctly reported as FLOAT (2). However, the query: SELECT Tbl1.Key1, SUM(Tbl1.Num1) AS Num1Sum FROM Tbl1 GROUP BY Tbl1.Key1 Returns two columns with value types INT (1) and INT (1). The SUM function is returning a different value type for these two queries when both should return FLOAT (2). This problem does not occur when any SUMmed value is not a whole number in which case, both queries return a value type of FLOAT for the SUM column. I have applied the patch from Check In 3169 (relating to #1726 and #1755) to select.c but this does not resolve the problem. _2006-May-10 09:34:11 by anonymous:_ {linebreak} I should have added that this problem was seen in a Windows CE build running on Pocket PC 2003 and built using eMbedded Visual C++ 4.0. ---- _2006-May-10 11:24:47 by anonymous:_ {linebreak} I can confirm that exactly the same behaviour is exhibited when built under Windows XP (32-bit). ---- _2006-May-10 12:40:21 by drh:_ {linebreak} The answer you are getting back is exactly correct. Why do you care what its datatype is? If you don't like the datatype, cast it. ---- _2006-May-10 13:42:14 by anonymous:_ {linebreak} For maximum compatibility with other SQL databases, both SELECT SUM(field2) FROM table and SELECT field1, SUM(field2) FROM table GROUP BY field1 should return the same data type for the SUM column. All other databases I have worked with do this. I understand that SQLite uses manifest typing but believe that it should be consistent. The problem I have is that in my query function (which takes an SQL string and returns a page of results as a 2D array of objects), I don't know whether to use sqlite3_column_double or sqlite3_column_int because I don't know what the calling function requires this column to be returned as. I am currently using the sqlite3_column_decltype call to switch which sqlite3_column_* function I use (and falling back on sqlite3_column_type when the declared type is not known e.g. for aggregate functions like SUM). If the return type of SUM is unpredictable, my calling functions can't assume returned values will be of the same type as the field that is being SUMmed (as is the case with other SQL databases). If you don't consider this to be a problem with SQLite, then I think my only option will be for calling functions to pass in an array of return types so that I always return objects of the correct type. #cfe8bd 2383 active 2007 May anonymous Pending 3 3 Inconsistent conversion of BLOB revisited BLOBs of function results are converted as UTF-8 even if the encoding is UTF-16. $ ./sqlite3 SQLite version 3.3.17 Enter ".help" for instructions sqlite> pragma encoding = 'UTF-16BE'; sqlite> select quote(cast(cast('ab' as blob) as text)); -- OK 'ab' sqlite> select quote(cast(a as text)) from (select X'00610062' a); -- OK 'ab' sqlite> select quote(cast(X'00610062' as text)); -- fixed by [3975] 'ab' sqlite> select quote(cast(substr(X'110061006222', 2, 4) as text)); -- NG '' sqlite> select quote(cast(substr(X'11616222', 2, 2) as text)); 'ab' sqlite> select quote(upper(substr(X'11616222', 2, 2))); 'AB' #e8e8bd 2859 active 2007 Dec anonymous Pending drh 3 2 Inconsistent column names with DISTINCT Given the following SQL:{linebreak} CREATE TABLE foo(a,b); INSERT INTO foo (a, b) VALUES (1,2); SQLite returns inconsistent column names when using the DISTINCT clause:{linebreak} SELECT DISTINCT foo.A, foo.B FROM foo; foo.A|foo.B 1|2 SELECT DISTINCT a, b FROM foo; a|b 1|2 SELECT DISTINCT * FROM foo; a|b 1|2 SELECT DISTINCT foo.* FROM foo; a|b 1|2 Compared with SELECT without DISTINCT:{linebreak} SELECT foo.A, foo.B FROM foo; a|b 1|2 SELECT a, b FROM foo; a|b 1|2 SELECT * FROM foo; a|b 1|2 SELECT foo.* FROM foo; a|b 1|2 #e8e8bd 2511 active 2007 Jul anonymous Pending drh 3 2 Inconsistent Pragma output Pragma output is inconsistent when setting the value. Most do not generate any output and silently set the value, while others generate a singleton row with the set value. Here is a list of pragmas that generate output while setting the values: sqlite> PRAGMA locking_mode = NORMAL; normal sqlite> PRAGMA max_page_count = 100000; 100000 The following do not generate any output upon query: PRAGMA case_sensitive_like; PRAGMA incremental_vacuum; Sqlite was built from almagamation using the following configuration flags: --enable-threadsafe --disable-tcl --enable-tempstore #cfe8bd 2075 active 2006 Nov anonymous Pending 3 3 Improve VACUUM speed and INDEX page locality In testing several 100 Meg - 1 Gig databases (including the Monotone OpenEmbedded database) I found that changing the order of the SQL commands executed by VACUUM to create indexes after table inserts results in 15% faster VACUUM times, and up to 25% faster cold-file-cache queries when indexes are used. This patch effectively makes the pages of each index contiguous in the database file after a VACUUM, as opposed to being scattered throughout the pages of the table related to the index. Your results may vary, but I think this is a very safe change that can potentially boost average database performance. Index: src/vacuum.c =================================================================== RCS file: /sqlite/sqlite/src/vacuum.c,v retrieving revision 1.65 diff -u -3 -p -r1.65 vacuum.c --- src/vacuum.c 18 Nov 2006 20:20:22 -0000 1.65 +++ src/vacuum.c 20 Nov 2006 21:09:27 -0000 @@ -143,14 +143,6 @@ int sqlite3RunVacuum(char **pzErrMsg, sq " AND rootpage>0" ); if( rc!=SQLITE_OK ) goto end_of_vacuum; - rc = execExecSql(db, - "SELECT 'CREATE INDEX vacuum_db.' || substr(sql,14,100000000)" - " FROM sqlite_master WHERE sql LIKE 'CREATE INDEX %' "); - if( rc!=SQLITE_OK ) goto end_of_vacuum; - rc = execExecSql(db, - "SELECT 'CREATE UNIQUE INDEX vacuum_db.' || substr(sql,21,100000000) " - " FROM sqlite_master WHERE sql LIKE 'CREATE UNIQUE INDEX %'"); - if( rc!=SQLITE_OK ) goto end_of_vacuum; /* Loop through the tables in the main database. For each, do ** an "INSERT INTO vacuum_db.xxx SELECT * FROM xxx;" to copy @@ -162,10 +154,22 @@ int sqlite3RunVacuum(char **pzErrMsg, sq "FROM sqlite_master " "WHERE type = 'table' AND name!='sqlite_sequence' " " AND rootpage>0" - ); if( rc!=SQLITE_OK ) goto end_of_vacuum; + /* Create indexes after the table inserts so that their pages + ** will be contiguous resulting in (hopefully) fewer disk seeks. + */ + rc = execExecSql(db, + "SELECT 'CREATE UNIQUE INDEX vacuum_db.' || substr(sql,21,100000000) " + " FROM sqlite_master WHERE sql LIKE 'CREATE UNIQUE INDEX %'"); + if( rc!=SQLITE_OK ) goto end_of_vacuum; + + rc = execExecSql(db, + "SELECT 'CREATE INDEX vacuum_db.' || substr(sql,14,100000000)" + " FROM sqlite_master WHERE sql LIKE 'CREATE INDEX %' "); + if( rc!=SQLITE_OK ) goto end_of_vacuum; + /* Copy over the sequence table */ rc = execExecSql(db, _2007-Feb-11 00:49:50 by drh:_ {linebreak} My alternative plan is to modify insert.c so that it recognizes the special case of INSERT INTO table1 SELECT * FROM table2; when table1 and table2 have identical schemas, including all the same indices. When this special case is recognized, the generated bytecode will first transfer all table entries from table2 to table1, using a row by row transfer without decoding each row into its constituient columns. Then it will do the same for each index. There will be two benefits here. First, when the above construct occurs during the course of a VACUUM, the table and each index, including intrisic indices associated with UNIQUE and PRIMARY KEY constraints, will be transferred separately so that all of there pages will be adjacent in the database file. The second benefit will occur when trying to load large quantities of data into an indexed table. Loading indexed data into a very large table is currently slow because the index entries are scattered haphazardly around in the file. But if data is first loaded into a smaller temporary table with the same schema, it can then be transferred to the main table using an INSERT statement such as the above in what amounts to a merge operation. ---- _2007-Feb-11 06:58:36 by anonymous:_ {linebreak} There's no question that your proposal will greatly improve VACUUM speed which relies on the "INSERT INTO table1 SELECT * from table2" construct. But would it be possible for you to relax the restriction on having identical indexes for table1 and table2? For that matter it would be nice if table2 could be any subselect or view. Then "REPLACE INTO table1 SELECT ...anything..." could also be optimized. Since you can detect that SQLite is doing a bulk insert anyway, it could generate code to make a temporary staging table with automatically generated identical indexes to table1 which could be periodically merged into table1 and truncated every X rows. X could be either set via pragma or be a function of the size of the page cache. The temporary staging table would be dropped after the bulk INSERT INTO ... SELECT. Every user inserting large volumes of data would have to perform this procedure anyway. Manually recreating all the indexes for a given temporary table to match the original table and performing the looping logic is cumbersome and error-prone. It would be very conveniant if SQLite were to do it on the user's behalf. This scheme could only work if there are no triggers on table1, of course. ---- _2007-Feb-11 09:16:25 by drh:_ {linebreak} My initial enhancement does nothing to preclude the more agressive enhancement described by anonymous. In order to avoid subtle bugs, and in view of my limited time available to work on this, I think it best to take the more conservative approach first and defer the more elaborate optimization suggested by anonymous until later. ---- _2007-Feb-11 13:54:34 by anonymous:_ {linebreak} It should be possible to identify contiguous blocks of individual "INSERT INTO table1 VALUES(...)" statements to the same table within a large transaction and perform the same proposed optimization as with "INSERT INTO table1 SELECT ...". This would require higher level coordination by the parser. Anytime a read operation (SELECT, UPDATE) occurs on such a table marked for bulk INSERT within the large transaction, its temp staging table could be merged into the INSERT destination table and the staging table truncated. The process could be repeated for the remainder of the transaction. Such an optimization would be a huge benefit to SQLite users since they would need not know the idiosynchracies of the implementation of "INSERT INTO table1 SELECT ..." in order to have efficient table and index population. Alternatively, if you wish to avoid the complexity of re-assembling and staging individual INSERT statements, it might be a good opportunity for SQLite to support the multi-row variant of the INSERT command: INSERT INTO table1 (a,b,c) VALUES(1,2,3), (4,5,6), (7,8,9); Which is essentially a transform of: CREATE TEMP TABLE table1_staging (a,b,c); INSERT INTO table1_staging VALUES(1,2,3); INSERT INTO table1_staging VALUES(4,5,6); INSERT INTO table1_staging VALUES(7,8,9); INSERT INTO table1 SELECT * FROM table1_staging; -- TRUNCATE OR DROP table1_staging as necessary which could use the same bulk staging optimization. ---- _2007-Feb-13 02:42:41 by anonymous:_ {linebreak} Any harm in checking in the simple patch above for the 3.3.13 release? ---- _2007-Feb-13 12:51:47 by drh:_ {linebreak} I have a much better fix standing by that I intend to check-in as soon as I get 3.3.13 out the door. I don't want this in 3.3.13 for stability reasons. ---- _2007-Feb-18 23:07:08 by anonymous:_ {linebreak} Some related analysis and an .import patch using a :memory: staging table with the "INSERT INTO table1 SELECT FROM table2" construct can be found here: http://www.mail-archive.com/sqlite-users%40sqlite.org/msg22143.html #e8e8bd 2627 active 2007 Sep anonymous Pending 3 2 Improper parsing of nested JOIN SQLite has a problem with multiple nested JOINs. The only way to get it workig is to remove the surrounding brackets. Removing the brackets unfortunately do not work in other DB systems such as MS SQL, mysql etc. This does not work: Select ContactPhone.* From (ContactPhone LEFT OUTER JOIN ContactLocation ON ContactPhone.PHNLCT_ID = ContactLocation.LCT_ID) LEFT OUTER JOIN ContactItem ON ContactLocation.LCTITM_ID = ContactItem.ITM_ID (It complains about LCT_ID or similar) This works after removing the brackets: Select ContactPhone.* From ContactPhone LEFT OUTER JOIN ContactLocation ON ContactPhone.PHNLCT_ID = ContactLocation.LCT_ID LEFT OUTER JOIN ContactItem ON ContactLocation.LCTITM_ID = ContactItem.ITM_ID All other major DB systems require the surrounding brackets. Do you think it is possible to fix it? Apart from this little little SQLite is an awesome project. Thank you Jakub Klos _2007-Sep-06 13:07:32 by anonymous:_ {linebreak} I don't have access to MS SQL Server, but MySQL and Oracle have no issue with the query without parentheses:
create table x1(a int, b int); create table x2(c int, d int); create table x3(e int, f int); mysql> select x1.* from x1 left join x2 on x1.a=x2.c left join x3 on x2.d=x3.e; Empty set (0.00 sec)---- _2007-Sep-06 19:03:33 by anonymous:_ {linebreak} MSSQL also has no problems without the parens. As a matter of fact, the only DB that I know of that requires them is MS Access (JET). ---- _2007-Sep-06 20:11:31 by anonymous:_ {linebreak} I guess he had no luck filing a JET bug. ---- _2007-Sep-11 17:22:28 by anonymous:_ {linebreak} True, MS access requires the parens but all other major DBs support the query syntax with the parens. So why SQLite does not like it? It should simply ignore them if possible. Thank you #e8e8bd 1983 active 2006 Sep anonymous Pending 2 2 I/O Error at a size of 4GB and auto_vacuum=1 when i'm building a database with auto_vacuum=1 and page_size=8192, i get an I/O error at a size of about 4GB. All tables are still readable but then it isn't possible to insert any more data. The table is filled with a column of BLOBs and some columns with numbers. I use the 3.3.7 binary with Windows 2000 Server. #cfe8bd 1809 active 2006 May anonymous CodeGen Pending 1 3 Huge slowdown/increased memory use when using GROUP BY on big dataset This seemingly nonsensical query is a greatly reduced test case taken from several queries I use with SQLite 3.2.1. The real example joins various huge tables and much more complicated views. I'd like to upgrade beyond SQLite 3.2.1, but this is a showstopper. It takes 13 seconds to run on SQLite 3.2.1 and uses just 1.2M of memory. With 3.3.5+ from CVS it takes 185 seconds and uses 230M of memory. PRAGMA temp_store=MEMORY; CREATE TABLE n1(a integer primary key); INSERT INTO "n1" VALUES(1); INSERT INTO "n1" VALUES(2); INSERT INTO "n1" VALUES(3); INSERT INTO "n1" VALUES(4); INSERT INTO "n1" VALUES(5); INSERT INTO "n1" VALUES(6); INSERT INTO "n1" VALUES(7); INSERT INTO "n1" VALUES(8); INSERT INTO "n1" VALUES(9); INSERT INTO "n1" VALUES(10); INSERT INTO "n1" VALUES(11); INSERT INTO "n1" VALUES(12); INSERT INTO "n1" VALUES(13); INSERT INTO "n1" VALUES(14); INSERT INTO "n1" VALUES(15); CREATE VIEW vu as select v3.a a, v5.a-v2.a*v7.a b from n1 v1,n1 v2,n1 v3,n1 v4,n1 v5,n1 v6,n1 v7; select a a, sum(b) T from vu where a=7 group by a; It seems that SQLite 3.2.1 had a much more efficient GROUP BY algorithm that discarded unnecessary data as the view was traversed. _2006-May-13 03:01:28 by anonymous:_ {linebreak} Seeing as this ticket concerns the GROUP BY statement it would make more sense to have an example like this: select a a, sum(b) T from vu where a<4 group by a; But both queries exhibit the same slowdown and memory increase, in any event. ---- _2006-May-13 15:09:39 by anonymous:_ {linebreak} This GROUP BY slowdown/memory increase is not specific to VIEWs. I repeated the test against a comparably sized table with the same results. You'll see this effect for any SELECT operating on a large number of rows using GROUP BY. ---- _2006-May-13 16:44:04 by anonymous:_ {linebreak} The slowdown first appears in SQLite 3.2.6 in check-in [2662]. ---- _2006-May-24 13:19:29 by anonymous:_ {linebreak} Here's an example to show an actual real-life use of GROUP BY in SQLite <= 3.2.5... Imagine performing mathematical operations on every combination of rows in several large tables for statistical analysis. The GROUP BY algorithm change in 3.2.6 now makes using GROUP BY on huge cross joins not usable for this purpose because it creates an intermediate result set of the product of all cross joins - several times larger than the size of the (already huge) database itself. Indexing is not useful in this case because there is nothing to index by design. All table rows must be traversed. Older versions of SQLite performed this operation extremely efficiently because grouping took place in the main traversal loop. I would think that the old algorithm could be used, but instead of keeping the intermediate results in memory, an index and a table in temp store could be used. #e8e8bd 1700 active 2006 Mar anonymous Parser Pending 2 2 Handling column names for aliased queries is broken The following query does not work, SELECT DISTINCT * FROM (SELECT t1.ID FROM GR_ADDRESS t1 WHERE t1.ID > 1 UNION ALL SELECT t1.ID FROM PERSON t1) t1 ORDER BY t1.ID DESC but this one does, SELECT DISTINCT * FROM (SELECT t1.ID FROM GR_ADDRESS t1 WHERE t1.ID > 1 UNION ALL SELECT t1.ID FROM PERSON t1 ORDER BY t1.ID DESC) Dennis Cote responded with: I think you have found another example of the problems SQLite has handling columns names. The following log first shows what SQLite thinks the column name is for the query without the order by clause (i.e. t1.ID). Then we try to order by that column name, with or without the table alias. Both cases result in an error. Finally there is a work around that you could use that applies an alias to the selected columns in the two tables that are combined by the union operation. SQLite version 3.3.2 Enter ".help" for instructions sqlite> create table GR_ADDRESS(id, data); sqlite> create table PERSON(id, data); sqlite> .mode column sqlite> .header on sqlite> insert into gr_address values(1, 10); sqlite> insert into person values(2, 20); sqlite> insert into gr_address values(3, 30); sqlite> SELECT DISTINCT * ...> FROM ...> (SELECT t1.ID ...> FROM GR_ADDRESS t1 ...> WHERE t1.ID > 1 ...> UNION ALL ...> SELECT t1.ID ...> FROM PERSON t1) ...> t1; t1.ID ---------- 3 2 sqlite> SELECT DISTINCT * ...> FROM ...> (SELECT t1.ID ...> FROM GR_ADDRESS t1 ...> WHERE t1.ID > 1 ...> UNION ALL ...> SELECT t1.ID ...> FROM PERSON t1) ...> t1 ORDER BY t1.ID DESC; SQL error: no such column: t1.ID sqlite> SELECT DISTINCT * ...> FROM ...> (SELECT t1.ID ...> FROM GR_ADDRESS t1 ...> WHERE t1.ID > 1 ...> UNION ALL ...> SELECT t1.ID ...> FROM PERSON t1) ...> t1 ORDER BY ID DESC; SQL error: no such column: ID sqlite> SELECT DISTINCT * ...> FROM ...> (SELECT t1.ID as ID ...> FROM GR_ADDRESS t1 ...> WHERE t1.ID > 1 ...> UNION ALL ...> SELECT t1.ID as ID ...> FROM PERSON t1) ...> t1 ORDER BY t1.ID DESC; ID ---------- 3 2 You may also be interested in the discussion of a similar problem under ticket #1688. #f2dcdc 2873 active 2008 Jan anonymous Pending 1 1 HAVE_USLEEP, HAVE_FDATASYNC=1 detected but not used by configure; make I noticed that a couple of open source projects were not picking up usleep() for recent sqlite builds and used the coarser grained sleep() instead. Around 11 months ago something changed in sqlite's build process. It seems that both -DHAVE_USLEEP=1, -DHAVE_FDATASYNC=1 and -DOS_UNIX=1 are detected correctly by configure but not used by the generated Makefile. As result, UNIX builds of sqlite3 via ./configure do not use usleep() and fdatasync() and do not define OS_UNIX. I don't know whether the lack of fdatasync() versus the default fsync() affects anyone. Please apply the following patch which corrects the problem with "./configure && make". Thank you.
Index: configure =================================================================== RCS file: /sqlite/sqlite/configure,v retrieving revision 1.45 diff -u -3 -p -r1.45 configure --- configure 27 Nov 2007 14:50:07 -0000 1.45 +++ configure 5 Jan 2008 07:41:00 -0000 @@ -18520,9 +18520,9 @@ if test "$TARGET_EXEEXT" = ".exe"; then OS_UNIX=0 OS_WIN=0 OS_OS2=1 - TARGET_CFLAGS="$TARGET_CFLAGS -DOS_OS2=1" + CFLAGS="$CFLAGS -DOS_OS2=1" if test "$ac_compiler_gnu" == "yes" ; then - TARGET_CFLAGS="$TARGET_CFLAGS -Zomf -Zexe -Zmap" + CFLAGS="$CFLAGS -Zomf -Zexe -Zmap" BUILD_CFLAGS="$BUILD_CFLAGS -Zomf -Zexe" fi else @@ -18530,14 +18530,14 @@ if test "$TARGET_EXEEXT" = ".exe"; then OS_WIN=1 OS_OS2=0 tclsubdir=win - TARGET_CFLAGS="$TARGET_CFLAGS -DOS_WIN=1" + CFLAGS="$CFLAGS -DOS_WIN=1" fi else OS_UNIX=1 OS_WIN=0 OS_OS2=0 tclsubdir=unix - TARGET_CFLAGS="$TARGET_CFLAGS -DOS_UNIX=1" + CFLAGS="$CFLAGS -DOS_UNIX=1" fi @@ -19392,7 +19392,7 @@ fi echo "$as_me:$LINENO: result: $ac_cv_func_usleep" >&5 echo "${ECHO_T}$ac_cv_func_usleep" >&6 if test $ac_cv_func_usleep = yes; then - TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_USLEEP=1" + CFLAGS="$CFLAGS -DHAVE_USLEEP=1" fi @@ -19491,7 +19491,7 @@ fi echo "$as_me:$LINENO: result: $ac_cv_func_fdatasync" >&5 echo "${ECHO_T}$ac_cv_func_fdatasync" >&6 if test $ac_cv_func_fdatasync = yes; then - TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_FDATASYNC=1" + CFLAGS="$CFLAGS -DHAVE_FDATASYNC=1" fi Index: configure.ac =================================================================== RCS file: /sqlite/sqlite/configure.ac,v retrieving revision 1.31 diff -u -3 -p -r1.31 configure.ac --- configure.ac 27 Nov 2007 14:50:07 -0000 1.31 +++ configure.ac 5 Jan 2008 07:41:00 -0000 @@ -310,9 +310,9 @@ if test "$TARGET_EXEEXT" = ".exe"; then OS_UNIX=0 OS_WIN=0 OS_OS2=1 - TARGET_CFLAGS="$TARGET_CFLAGS -DOS_OS2=1" + CFLAGS="$CFLAGS -DOS_OS2=1" if test "$ac_compiler_gnu" == "yes" ; then - TARGET_CFLAGS="$TARGET_CFLAGS -Zomf -Zexe -Zmap" + CFLAGS="$CFLAGS -Zomf -Zexe -Zmap" BUILD_CFLAGS="$BUILD_CFLAGS -Zomf -Zexe" fi else @@ -320,14 +320,14 @@ if test "$TARGET_EXEEXT" = ".exe"; then OS_WIN=1 OS_OS2=0 tclsubdir=win - TARGET_CFLAGS="$TARGET_CFLAGS -DOS_WIN=1" + CFLAGS="$CFLAGS -DOS_WIN=1" fi else OS_UNIX=1 OS_WIN=0 OS_OS2=0 tclsubdir=unix - TARGET_CFLAGS="$TARGET_CFLAGS -DOS_UNIX=1" + CFLAGS="$CFLAGS -DOS_UNIX=1" fi AC_SUBST(BUILD_EXEEXT) @@ -565,13 +565,13 @@ AC_SUBST(TARGET_DEBUG) ######### # Figure out whether or not we have a "usleep()" function. # -AC_CHECK_FUNC(usleep, [TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_USLEEP=1"]) +AC_CHECK_FUNC(usleep, [CFLAGS="$CFLAGS -DHAVE_USLEEP=1"]) #-------------------------------------------------------------------- # Redefine fdatasync as fsync on systems that lack fdatasync #-------------------------------------------------------------------- -AC_CHECK_FUNC(fdatasync, [TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_FDATASYNC=1"]) +AC_CHECK_FUNC(fdatasync, [CFLAGS="$CFLAGS -DHAVE_FDATASYNC=1"]) ######### # Generate the output files._2008-Jan-05 08:24:29 by anonymous:_ {linebreak} It appears that http://www.sqlite.org/sqlite3-3.5.4.bin.gz and http://www.sqlite.org/sqlite-3.5.4.so.gz use sleep and fsync even though usleep and fdatasync are available on Linux. On the Linux man page, it claims that fdatasync is more efficient than fsync: "Unfortunately, fsync() will always initiate two write operations: one for the newly written data and another one in order to update the modification time stored in the inode. If the modification time is not a part of the transaction concept fdatasync() can be used to avoid unnecessary inode disk write operations." #e8e8bd 2857 active 2007 Dec anonymous Pending 2 2 GROUP BY cost estimate wrong with WHERE clause There seems to be an issue with the sqlite cost heuristic with an INDEX present on GROUP BY with certain types of WHERE clauses. Given the database formed by running these statements: create table stuff(a,b,c,d); insert into stuff values(1,2,3,4); create temp view v1 as select random()%100, random()%100, random()%1000, random()%10000 from stuff x, stuff y; insert into stuff select * from v1; insert into stuff select * from v1; insert into stuff select * from v1; insert into stuff select * from v1; insert into stuff select * from v1; create index stuff_b on stuff(b); create index stuff_c on stuff(c); create index stuff_d on stuff(d); analyze; Using sqlite.org's sqlite3-3.5.4.bin, this query takes 47 seconds: select c from stuff where a=23 group by c; while this query takes just 2 seconds: select c from stuff where a=23 group by +c; It is more efficient in this case to do a full table scan instead of using the INDEX on column c. _2007-Dec-23 23:14:06 by anonymous:_ {linebreak} The queries above both run in a couple of seconds with this naive patch:
--- src/where.c 12 Dec 2007 17:42:53 -0000 1.266 +++ src/where.c 23 Dec 2007 22:48:37 -0000 @@ -1514,6 +1514,12 @@ static double bestIndex( flags = 0; } + if( pWC && pWC->nTerm>0 && pOrderBy ){ + /* Reduce cost if both an ORDER/GROUP BY exists with a WHERE. */ + cost /= 100; /* A very rough guess. */ + WHERETRACE(("... WHERE + ORDER BY decreases cost to: %.9g\n", cost)); + } + /* If the table scan does not satisfy the ORDER BY clause, increase ** the cost by NlogN to cover the expense of sorting. */ if( pOrderBy ){But it has not been tested on queries with more than one table. Its logic could be flawed. ---- _2007-Dec-24 00:09:00 by drh:_ {linebreak} The complaint is centered around these two queries: /* 1 */ SELECT c FROM stuff WHERE a=23 GROUP BY c; /* 2 */ SELECT c FROM stuff WHERE a=23 GROUP BY +c; Query 1 runs in about 40 seconds and query 2 in about 1.5 seconds on my macbook. But with the patch, both queries run in about 1.5 seconds. Fair enough. But now consider these two queries: /* 3 */ SELECT c FROM stuff WHERE a!=23 GROUP BY c; /* 4 */ SELECT c FROM stuff WHERE a!=23 GROUP BY +c; In this case, query 3 runs in 42 seconds on an unpatched version of 3.5.4 and query 4 runs in about 109 seconds. So in cases where the WHERE clause is not particularly selective, the first version is faster than the second by a good margin. On a patched version of 3.5.4, both queries 3 and 4 run in about 110 seconds. So it seems to me that the patch is robbing Peter to pay Paul. It makes ORDER BY queries with very selective WHERE clauses run faster but at the expense of making queries with unselective WHERE clauses running slower. But notice this: in the current (unpatched) implementation, the programmer at least has the ability to select a different algorithm by the judicious placement of a "+" sign. After the patch, this is no longer possible. The patch forces the second algorithm to be used in all cases, even cases where it is slower. It seems to me to be better to leave things as they are since the current approach at least allows the programmer to override SQLite's algorithm selection if SQLite chooses incorrectly. The only way, it seems to me, to automatically choose the correct algorithm is to devise some test that will determine (in advance) whether or not the WHERE clause weeds out many or few rows from the result set. I'm thinking that determination is going to be very hard (or impossible) to do without first doing a full table scan. ---- _2007-Dec-24 05:40:47 by anonymous:_ {linebreak} It think it would be surprising to average users that _adding_ an index (on column C in this case) may significantly _decrease_ query performance for some queries. It was surprising to me, at least. In my opinion, a query being 20 times slower in a default bad guess situation is worse than a query only being 2.5 times slower with a default bad guess in a worst case scenario. It's a question of relative magnitude of the difference. This is why I think that the database should err on the side of the WHERE clause having a more selective bias. (Side note: the query timings difference is less pronounced if you use PRAGMA temp_store=memory, in which case query 3 running on an unpatched 3.5.4 takes just 50% more time to run than query 4 on my machine.) But you raise a good point in that if there's a wrong guess in the selectivity bias it would be nice to be able to manually override it. How much do you hate this type of syntax that some other databases use? select c from stuff where a!=23 group by /*+stuff_c*/ c; SQLite does not currently offer a way to pick a specific index. I think it would be quite useful. ---- _2007-Dec-24 17:05:16 by anonymous:_ {linebreak} Another option is to collect WHERE clause statistics in a table like create table sqlite_stat2( where_clause_md5 BLOB primary key, where_clause TEXT, rows_examined INT, rows_true INT ); where the last 2 columns are cumulative for each query. The statistics option could be enabled/disabled via a PRAGMA sqlite_collect_statistics. The where_clause column could be a string generated fairly easily from the walking the parse tree of the resolved Select statement's pWhere. This way the where_clause is normalized and a single query with many subselects could generate more than 1 where_clause, and different queries that happen to use the same normalized where clause would update the same entry in the stat2 table. where_clause normalization would strip off aliases and only refer to the original table and column names. For example the 2 queries below: -- CREATE TABLE t1(a, b); -- CREATE TABLE t2(b, c); SELECT t1.a*c as AC, t2.b-a as BA FROM t1, t2 WHERE AC>BA; SELECT *, t1.a Foo FROM t2, t1 WHERE Foo*c > t2.b - t1.a; would generate the same normalized where_clause string "(T1.A*T2.C)>(T2.B-T1.A)". The table information is already encoded within it. The generated VDBE code would have to generate Mem counters that would be incremented by each WHERE test, and lazily updated at the end of transactions or periodically written to the stat2 table to minimize disk use, as this information is not critical. One could also manually set the stat2 table with statistical values they would like their queries to use even if PRAGMA sqlite_collect_statistics=off; Any time the schema is changed, the entire sqlite_stat2 table would be cleared. #cfe8bd 2825 active 2007 Dec anonymous Pending 3 3 FormatMessage (win32) should use extra flag and convert from Unicode The call to FormatMessageA in the win32 source code needs to have the flags changed from: FORMAT_MESSAGE_FROM_SYSTEM to FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS This ensures that any system messages that expect arguments do not try to grab the argument from some random memory location. ref: http://blogs.msdn.com/oldnewthing/archive/2007/11/28/6564257.aspx _2007-Dec-06 14:07:53 by anonymous:_ {linebreak} I also noticed that the result is NOT converted to UTF-8. FormatMessageA returns the text in the local ANSI codepage. FormatMessageW should be used on NT systems, and either result should be converted to the SQLite UTF-8 default. ---- _2007-Dec-11 00:34:37 by anonymous:_ {linebreak} to simplify what is meant even more... http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/os_win.c&v=1.118 Search for FormatMessageA (only 1 instance) - FORMAT_MESSAGE_FROM_SYSTEM, + FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, No breakage, ensures that no crashes with some messages (e.g. filesystem errors). The encoding issue should be addressed separately. ---- _2007-Dec-11 01:27:07 by anonymous:_ {linebreak} The function should be changed to the following to correctly handle the conversion from Unicode/MBCS.
static void winDlError(sqlite3_vfs *pVfs, int nBuf, char *zBufOut){ int error = GetLastError(); #if OS_WINCE if( error>0x7FFFFFF ){ sqlite3_snprintf(nBuf, zBufOut, "OsError 0x%x", error); }else{ sqlite3_snprintf(nBuf, zBufOut, "OsError %d", error); } #else if( isNT() ){ LPWSTR zWinTemp = NULL; DWORD dwLen = FormatMessageW( FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, error, 0, (LPWSTR) &zWinTemp, 0, 0 ); if (dwLen > 0) { char * zOut = unicodeToUtf8(zWinTemp); LocalFree(zWinTemp); sqlite3_snprintf(nBuf, zBufOut, "%s", zOut); free(zOut); } }else{ LPSTR zWinTemp = NULL; DWORD dwLen = FormatMessageA( FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, error, 0, (LPSTR) &zWinTemp, 0, 0 ); if (dwLen > 0) { char * zOut = mbcsToUtf8(zWinTemp); LocalFree(zWinTemp); sqlite3_snprintf(nBuf, zBufOut, "%s", zOut); free(zOut); } } #endif }#f2dcdc 2100 active 2006 Dec anonymous Pending 1 1 Fixes for SQL lower() and upper() As acknowledged in the documentation, the SQL lower() and upper() functions might not work correctly on UTF-8 characters. This bug might show if a country specific locale is used instead of the standard C locale. Under certain circumstances, SQL lower() or upper() can even corrupt the UTF-8 string into invalid UTF-8 if the tolower() and toupper() C functions convert character values starting from 0x80. Below I propose implementations of lowerFunc() and upperFunc() which work correctly with UTF-8 characters, regardless of the implementation of the C library tolower() and toupper() functions. If these C functions are implemented to support high ASCII or even Unicode case conversion, the new SQL lower() and upper() will support them as well. The proposed C implementation applies a technique also found in sqlite3VdbeMemTranslate() in utf.c and makes use of some macros contained in that unit. To avoid duplicating existing code, it could make sense to move lowerFunc() and lowerFunc() to utf.c, just as it has been done with sqlite3utf16Substr(). Finally, here is the code: /* ** Implementation of the upper() and lower() SQL functions. */ static void upperFunc(sqlite3_context *context, int argc, sqlite3_value **argv){ const unsigned char *zIn, *zInTerm; unsigned char *z, *zOut; int c, l; if( argc<1 || SQLITE_NULL==sqlite3_value_type(argv[0]) ) return; zIn = sqlite3_value_text(argv[0]); if( zIn==0 ) return; l = sqlite3_value_bytes(argv[0]); zInTerm = &zIn[l]; /* When converting case, the maximum growth results from ** translating a 1-byte UTF-8 character to a 4-byte UTF-8 character. */ zOut = sqliteMalloc( l * 4 ); z = zOut; while( zIn
#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